Space Considerations
Note: Small Total Represents the amount of space taken with only 1 set of kernel modules and without the documentation, toolchain and checksums.
| Root Directory |
Size (MB) |
| bin |
202 |
| boot |
17 |
| checksum |
79 |
| documentation |
348 |
| etc |
4.3 |
| firmware |
20 |
| home |
42 |
| lib |
571 |
| modules |
48 |
| sbin |
44 |
| share |
226 |
| toolchain |
197 |
| Total |
1793.64453
(1.75160) |
| Small Total |
1170.3125
(1.14288 GB) |
| Squashed Total |
540.56640 |
| Squashed Small Total |
425.11718 |
| Key Space Consumers for "lib" |
| Directory |
Size (MB) |
| Image Magick |
3.4 |
| X11 (xorg) |
45 |
| abiword-2.8 |
2.2 |
| aspell |
3.9 |
| avifile-0.7 |
1.1 |
| claws-mail |
1.3 |
| gegl-0.0 (gimp) |
1.7 |
| gimp |
6.2 |
| git-core |
9.6 |
| gtk-2.0 |
1.3 |
| libgphoto2 |
2.1 |
| mysql |
9.7 |
| perl5 |
56 |
| php |
14 |
| postgresql |
4.2 |
| purple-2 (pidgin) |
4.0 |
| python2.6 |
64 |
| sane |
5.9 |
| seamonkey-2.0 |
33 |
| sox |
1.1 |
| tcl8.5 |
18 |
| tk8.5 |
9.9 |
| transcode |
2.3 |
| wireshark |
3.2 |
| xfce4 |
1.5 |
| xine |
4.8 |
|
| Root Directory |
Size (MB) |
| bin |
87 |
| boot |
15 |
| checksum |
28 |
| documentation |
300 |
| etc |
4.2 |
| firmware |
20 |
| home |
1.3 |
| lib |
232 |
| sbin |
14 |
| share |
145 |
| toolchain |
211 |
| modules |
41 |
| Total |
1094.29687
(1.06864 GB) |
| Small Total |
557.3125
(0.54425 GB) |
| Squashed Total |
313.86718 |
| Squashed Small Total |
202.6875 |
| Key Space Consumers for "share" |
| Directory |
Size (MB) |
| abiword-2.8 |
8.1 |
| alsa |
4.9 |
| aspell |
1.4 |
| dvb |
3.5 |
| fonts |
25 |
| games/blobAndConquer |
38 |
| gimp |
6.2 |
| icons |
15 |
| kbd |
2.8 |
| lbreakout2 |
4.1 |
| link-grammar |
1.3 |
| mime |
2.5 |
| misc |
1.8 |
| multitalk |
1.9 |
| nmap |
2.7 |
| orage |
2.6 |
| poppler |
12 |
| sane |
1.6 |
| sounds |
1.8 |
| themes (xfce) |
22 |
| vim |
12 |
| wireshark |
10 |
| wv |
1.9 |
| xfce4 |
4.7 |
| xine |
2.0 |
| zenmap (Nmap) |
2.0 |
|
SSH Handshaking
This will assume that you are on the client machine and need to connect to a server and have working ssh access to the server.
Step 1, generate the key (-d is for DSA, no -d is for RSA)
ssh-keygen -d
Step 2, Skipping password, just press enter on password prompt to leave it empty so that passwordless handshaking can work.
This should create the .ssh/id_dsa and the .ssh/id_dsa.pub files, and this may take some time, depending on your hardware.
Step 3, Put the necessary files on the remote server to do the handshaking with
username = your username to connect to the server
remotehost = the address used to connect to the server
/yourhome/directiry = the path to your home directory
scp .ssh/id_dsa.pub username@remotehost:/yourhome/directory/
ssh username@remotehost
mkdir -p ~/.ssh/
cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
Step 4, now you can delete the id_dsa.pub file from the remote host and exit.
rm id_dsa.pub
exit
Step 5, DONE
You should be able to ssh to the remote host without a password now, given that the .ssh/id_dsa file and the .ssh/id_dsa.pub file exist on your client machine for the user you intend to connect with.
Adding SSHFS on top of the SSH Handshaking
See the SSH Handshaking above first
Now that you can handshake from the above example, you should now be able to run the sshfs command and even put it in a logon or boot script, without exposing your password
Mounting from sshfs
sshfs username@remotehost:/remote/directory/ /local/directory/
Unmounting from sshfs
fusermount -u /local/directory/
If you did not use the SSH Handshaking above, then you will be prompted for a password on the sshfs command
If you did use the SSH Handshaking above, and are still being asked for a password, then there is a problem with the RSA/DSA keys
This password will still be prompted for any other client you use that does NOT have the private .ssh/id_dsa key
Encrypted Booting
The encrypted boot process potentially requires additional files to exist on the boot device.
This explains what those files are and how to configure these files.
Inside of the effective /boot/ directory of the boot device there needs to be a /settings/ directory.
Inside this directory there are currently only a few types of files searched for:
- Files that end in: .device
- Files that end in: .key
- Files that end in: .ask
At this time only a limited set of device files are supported and they are:
- rootfs.device
- home.device
- etc.device
- var.device
- tmp.device
The only thing allowed inside of these files are the name of device to be decrypted.
Allowed names are anything allowed by the mount command, such as:
- /dev/sda1
- my_encrypted_drive
- 98ff3608-7631-4381-a04a-27cc09f42ae1
There should be nothing else inside of these files.
The
.key and
.ask files are optional and must have the same name as the particular device file they represent.
For example, for rootfs.device an ask file would be:
rootfs.ask.
The
.key and
.ask files determine how a particular device is decrypted.
If a
.ask file exists for a particular device, then during the boot process a prompt for the password will be presented to the user.
If a
.key file exists then that file is expected to contain the key that will be used to decrypt the drive.
This key will allow for automatic decryption during boot.
If both a
.key file and a
.ask file exist, then the
.key will be processed first.
If that
.key file fails to decrypt the drive, then the user will be asked to enter in the password to decrypt.
Important boot commands to pay attention to when dealing with encrypted booting are:
- settings=
- settingsname=
- settingscdromsearch=
- settingsmmcsearch=
- etcdevice=
- homedevice=
- vardevice=
- tmpdevice=
- finalroot=
The only device encryption supported at this time is LUKS.
Encrypting a Drive
WARNING: Creating an encrypted drive requires formatting a device, which will delete all data on that device.
Lets say you wanted to encrypt a partition (/dev/sda6) and use a key file.
- Fill the drive with random data (this will delete all data on the device /dev/sda6):
dd if=/dev/urandom of=/dev/sda6
- Create a keyfile using randomly generated data:
dd if=/dev/urandom of=~/some.key bs=1c count=512
- Use the keyfile to encrypt the device with LUKS encryption:
cryptsetup -c aes-xts-plain:sha512 -s 512 luksFormat /dev/sda6 ~/some.key
- Now that the device is encrypted, decrypt the device so that the device can be properly formatted (calling the decrypted device: some_name_here):
cryptsetup luksOpen /dev/sda6 some_name_here -d ~/some-key
- Format the decypted device (this example format creates an ext4 filesystem with a label of: some_fs_label):
mkfs.ext4 -L some_fs_label /dev/mapper/some_name_here
Lets say you wanted to encrypt a partition (/dev/sda6) and use a password.
- Fill the drive with random data (this will delete all data on the device /dev/sda6):
dd if=/dev/urandom of=/dev/sda6
- Encrypt the device with LUKS encryption:
cryptsetup -c aes-xts-plain:sha512 -y -s 512 luksFormat /dev/sda6
Then enter in your desired password when prompted.
- Now that the device is encrypted, decrypt the device so that the device can be properly formatted (calling the decrypted device: some_name_here):
cryptsetup luksOpen /dev/sda6 some_name_here
Enter in the password you used in the previous step when prompted.
- Format the decypted device (this example format creates an ext4 filesystem with a label of: some_fs_label):
mkfs.ext4 -L some_fs_label /dev/mapper/some_name_here
Lets say you wanted add a new key to an existing encrypted device.
- If not already created, create a new key using random data:
dd if=/dev/urandom of=~/new.key bs=1c count=512
- Add the new key (Assuming that the old key is called old.key and is stored in your home directory):
cryptsetup -d ~/old.key luksAddKey /dev/sda6 ~/new.key
If the encrypted device did not use a key, then use the following command instead and enter in the appropriate password when prompted:
cryptsetup luksAddKey /dev/sda6 ~/new.key
Lets say you wanted add a new password to an existing encrypted device.
- Add the new key (Assuming that the old key is called old.key and is stored in your home directory):
cryptsetup -d ~/old.key luksAddKey /dev/sda6
Then enter in your desired password when prompted.
If the encrypted device did not use a key, then use the following command instead:
cryptsetup luksAddKey /dev/sda6
You will first be prompted for the decryption password, enter in that first.
Enter in the new password after the first password properly decrypts the device.
Lets say you wanted delete an existing password or key file from the drive.
- Both the password and the key file are stored in slots.
In order to delete either of these, you will need to know which slot to delete.
This information can be found by decrypting a device with the key or password you wish to delete.
Whenever the device gets decrypted a message should be presented, stating which key slot was used.
Once you have the propery slot identified (lets call this desired_slot), delete that slot (Assuming that the old key is called old.key and is stored in your home directory):
cryptsetup -d ~/old.key luksDelKey /dev/sda6 desired_slot
If the encrypted device did not use a key, then use the following command instead:
cryptsetup luksDelKey /dev/sda6 desired_slot
Enter in the decryption password when prompted.
To learn how to encrypt using LUKS in detail, visit the
LUKS website.