Accessing your virtual machine

This lecture requires practical exercises. Each group will have access to two virtual machines for mimicking client-provider and replication scenarios.

If you do not yet have a public/private ssh key pair the ssh-keygen command is your friend. It allows for generating a pair inside your ~/.ssh subdirectory. Working on a network drive your first problem may be inappropriate file permissions of and inside your ~/.ssh directory:

Figure 950. ssh-keygen generating an elliptic key Slide presentation
$ ssh-keygen  -a 256 -t ed25519  -C "$(hostname)-$(date +'%d-%m-%Y')"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/foo/.ssh/id_ed25519): 
Created directory '/home/foo/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/foo/.ssh/id_ed25519 
Your public key has been saved in /home/foo/.ssh/ 

Elliptic key type from {dsa| ecdsa| ecdsa-sk| ed25519| rsa}.

Private key passphrase theft protection.

Generated private key: DO NOT CHANGE ITS NAME!

Corresponding public key.

Figure 951. Result of ssh-keygen execution Slide presentation
~/.ssh$ cd ~/.ssh
/home/foo/.ssh cp authorized_keys
mistudent@w10m:~/.ssh$ ls -al
total 24
drwxrwx---+  2 student mi    0 Okt 17 17:45 .
drwx------+ 32 student mi    0 Okt 17 17:44 ..
-rwxrwx---+  1 student mi  396 Okt 17 17:45 authorized_keys 
-rwxrwx---+  1 student mi 1675 Okt 17 17:38 id_ed25519 
-rwxrwx---+  1 student mi  396 Okt 17 17:38 

Allowed keys to log on to current machine.

Private key

Corresponding public key

The permissions of the directory itself and the files within are too open . The sshd daemon will deny remote access due to possible security implications. Unfortunately the standard chmod command from UNIX does not suffice on modern cifs based network file systems using extended ACLs. The getfacl command reveals details:

Figure 952. Extended ACLs, ways too open Slide presentation
mistudent@w10m:~/.ssh$ getfacl  authorized_keys
# file: authorized_keys
# owner: mistudent
# group: mi

The counterpart setfacl allows for revoking permissions e.g. on authorized_keys:

Figure 953. Revoking permissions using setfacl Slide presentation
foo@w10m:~/.ssh$ setfacl -m user:foo:--- authorized_keys
foo@w10m:~/.ssh$ setfacl -m user::rw- authorized_keys
foo@w10m:~/.ssh$ getfacl authorized_keys

foo@w10m:~/ssh$ ls -al authorized_keys
-rw-------+ 1 foo mi 396 Okt 17 17:45 authorized_keys

Addressing each file and the directory itself in a similar fashion leads to:

Figure 954. Corrected permissions Slide presentation
foo@w10m:~/.ssh$ ls -al
total 32
drwx------+  2 mistudent mi    0 Okt 17 17:44 .
drwx------+ 32 mistudent mi    0 Okt 17 17:44 ..
-rw-------+  1 mistudent mi 1132 Okt 17 17:40 authorized_keys
-rw-------+  1 mistudent mi 1679 Okt 11 14:46 id_ed25519
-rw-r--r--+  1 mistudent mi  396 Okt 11 14:46
-rw-------+  1 mistudent mi  442 Okt 11 14:49 known_hosts

You should now be able accessing your virtual machines:

Figure 955. Logging in Slide presentation
The authenticity of host ' (' can't be established.
ED25519 key fingerprint is SHA256:sEagSHefcv9OkiFibKIZFlPL/4FxbO+9kvJnwkV7ltU.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '' (ED25519) to the list of known hosts.