Accessing your virtual machine

This lecture requires practical exercises. Each group will have access to two virtual machines to mimic 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:

mistudent@w10m:~/.ssh$ pwd
/stud/mistudent/.ssh
mistudent@w10m:~/.ssh$ ls -al
total 24
drwxrwx---+  2 mistudent mi    0 Okt 17 17:45 .
drwx------+ 32 mistudent mi    0 Okt 17 17:44 ..
-rwxrwx---+  1 mistudent mi  396 Okt 17 17:45 authorized_keys
-rwxrwx---+  1 mistudent mi 1675 Okt 17 17:38 id_rsa
-rwxrwx---+  1 mistudent mi  396 Okt 17 17:38 id_rsa.pub

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

mistudent@w10m:~/.ssh$ getfacl  authorized_keys
# file: authorized_keys
# owner: mistudent
# group: mi
user::rwx
user:mistudent:rwx
group::---
group:users:---
mask::rwx
other::---

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

mistudent@w10m:~/.ssh$ setfacl -m user:mistudent:--- authorized_keys
mistudent@w10m:~/.ssh$ setfacl -m user::rw- authorized_keys
mistudent@w10m:~/.ssh$ getfacl authorized_keys
# file: authorized_keys
# owner: mistudent
# group: mi
user::rw-
user:mistudent:---
group::---
group:users:---
mask::---
other::---

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

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

mistudent@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_rsa
-rw-r--r--+  1 mistudent mi  396 Okt 11 14:46 id_rsa.pub
-rw-------+  1 mistudent mi  442 Okt 11 14:49 known_hosts

Access to these virtual machines is initially being controlled by password. A client will allow you to connect:

[goik]$ ssh root@sdi4a.mi.hdm-stuttgart.de
The authenticity of host 'sdi4a.mi.hdm-stuttgart.de (141.62.75.104)' can't be established.
ECDSA key fingerprint is b1:ee:e1:3d:db:3c:0b:06:e9:fb:b3:ae:b8:ed:e2:a8.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'sdi4a.mi.hdm-stuttgart.de,141.62.75.104' (ECDSA) to the list of known hosts.
root@sdi4a.mi.hdm-stuttgart.de's password:
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 2.6.32-19-pve x86_64)

 * Documentation:  https://help.ubuntu.com/
Last login: Fri Mar 27 08:29:40 2015 from 192.168.1.66

Since password access is generally being considered insecure (e.g. due to insufficient length or poor choice of password) we will configure public key authentication by a public/private key pair:

  1. Copy your public ssh key to your remote VM still using password access:

    root@goiki:~# scp /ma/goik/.ssh/id_rsa.pub root@sdi4a.mi.hdm-stuttgart.de:
    root@sdi4a.mi.hdm-stuttgart.de's password:
    id_rsa.pub                                  100%  736     0.7KB/s   00:00
    
  2. On the remote VM append your public key the the list of allowed users:

    root@sdi4a:~# cat id_rsa.pub >> ~/.ssh/authorized_keys
  3. You should now be able to log in by public key:

    [goik@goiki Sdi]$ ssh root@sdi4a.mi.hdm-stuttgart.de
    #Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 2.6.32-19-pve x86_64)
    
     * Documentation:  https://help.ubuntu.com/
    Last login: Fri Mar 27 08:38:03 2015 from 192.168.1.66
    

    Notice the absence of a password prompt. You may want to execute ssh -v once to watch the log and try to identify the key exchange.

  4. You should now disable password login. The ssh daemon is being configured by /etc/ssh/sshd_config. Edit this file and look for the following lines

    ...
    # Change to no to disable tunnelled clear text passwords
    #PasswordAuthentication yes
    ...

    As being proposed inside the comment remove the directive's starting comment and set its value to no:

    ...
    # Change to no to disable tunnelled clear text passwords
    PasswordAuthentication no
    ...

    We need to instruct the ssh daemon to reload its configuration:

    root@sdi4a:~# reload ssh

    Password login should no longer be on offer:

    root@goiki:~# ssh -v root@sdi4a.mi.hdm-stuttgart.de
    OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
    debug1: Reading configuration data /etc/ssh/ssh_config
    ...
    debug1: SSH2_MSG_SERVICE_REQUEST sent
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey
    debug1: Next authentication method: publickey
    debug1: Trying private key: /root/.ssh/id_rsa
    debug1: Trying private key: /root/.ssh/id_dsa
    debug1: Trying private key: /root/.ssh/id_ecdsa
    debug1: Trying private key: /root/.ssh/id_ed25519
    debug1: No more authentication methods to try.
    Permission denied (publickey).