Key-based SSH login

Do these on your own system. They get harder. Check each result, then tick it off.

1. Warm-upDone

   Create a key pair

   As user alex on node1, create an Ed25519 key pair with an empty passphrase (for the exam style task) in the default location, and list the two files created. Say which one must never leave the machine.

   Check your result

   ~/.ssh/id_ed25519 (mode 600) and ~/.ssh/id_ed25519.pub exist. The private key is id_ed25519.

   Hint

   ssh-keygen -t ed25519 -N '' -f ~/.ssh/id_ed25519. -N '' sets an empty passphrase.

   Solution

   ssh-keygen -t ed25519 -N '' -f ~/.ssh/id_ed25519
   ls -l ~/.ssh
   ssh-keygen -lf ~/.ssh/id_ed25519.pub

2. PracticeDone

   Log in to node2 without a password

   Install alex's public key into alex's account on node2 and prove you can run ssh node2 hostname without being asked for a password. Show the line that was added on node2 and its file's permissions.

   Check your result

   ssh node2 hostname prints node2.lab.example immediately. On node2 ~/.ssh/authorized_keys contains the key and has mode 600; ~/.ssh has mode 700.

   Hint

   ssh-copy-id alex@node2 asks for the password once and appends the key. Add -o PreferredAuthentications=publickey when testing to prove the key is used.

   Solution

   ssh-copy-id alex@node2
   ssh -o PreferredAuthentications=publickey node2 hostname
   ssh node2 'ls -ld ~/.ssh; ls -l ~/.ssh/authorized_keys; cat ~/.ssh/authorized_keys'

3. PracticeDone

   Install a key by hand

   Without ssh-copy-id, install alex's public key for the account dana on node2 by logging in as root there (or sudo) and creating the directory and file with correct owner, mode and SELinux label. Then test ssh dana@node2 using alex's private key on node1.

   Check your result

   ls -ldZ /home/dana/.ssh shows dana dana ... ssh_home_t with mode 700; authorized_keys is mode 600. ssh -i ~/.ssh/id_ed25519 dana@node2 id succeeds without a password.

   Hint

   Create ~dana/.ssh as dana (install -d -m 700 -o dana -g dana), append the key, chmod 600, then restorecon -Rv /home/dana/.ssh.

   Solution

   # on node2, as root
   sudo install -d -m 700 -o dana -g dana /home/dana/.ssh
   echo 'PASTE-THE-PUBLIC-KEY-LINE' | sudo tee -a /home/dana/.ssh/authorized_keys
   sudo chown dana:dana /home/dana/.ssh/authorized_keys
   sudo chmod 600 /home/dana/.ssh/authorized_keys
   sudo restorecon -Rv /home/dana/.ssh
   # on node1, as alex
   ssh -i ~/.ssh/id_ed25519 dana@node2 id

4. PracticeDone

   A key with a passphrase and an agent

   Create a second key ~/.ssh/id_work with a passphrase, install it for alex on node2, and show that ssh -i ~/.ssh/id_work node2 asks for the passphrase. Then load it into ssh-agent so you are asked only once, and list the loaded keys.

   Check your result

   Without the agent the passphrase prompt appears each time. After ssh-add, ssh-add -l lists the key fingerprint and logins no longer prompt.

   Hint

   eval "$(ssh-agent -s)" starts an agent for this shell, ssh-add ~/.ssh/id_work unlocks the key into it.

   Solution

   ssh-keygen -t ed25519 -f ~/.ssh/id_work
   ssh-copy-id -i ~/.ssh/id_work.pub alex@node2
   ssh -i ~/.ssh/id_work node2 hostname
   eval "$(ssh-agent -s)"
   ssh-add ~/.ssh/id_work
   ssh-add -l
   ssh -i ~/.ssh/id_work node2 hostname

5. ChallengeDone

   The key is ignored: find out why

   On node2 deliberately set chmod 777 ~/.ssh and then chmod 666 ~/.ssh/authorized_keys. Try the login, read the client's ssh -v output and the server's log to find the reason, then repair it. Name three other causes of the same symptom (wrong owner, SELinux label, home directory writable by others).

   Check your result

   With loose modes the key is skipped and the password prompt appears. ssh -v shows Offering public key then Authentications that can continue; journalctl -u sshd on node2 shows Authentication refused: bad ownership or modes for directory. After chmod 700 / 600 the key works again.

   Hint

   sshd has StrictModes yes by default, which refuses keys when the home directory, .ssh or authorized_keys are writable by others.

   Solution

   # on node2
   chmod 777 ~/.ssh; chmod 666 ~/.ssh/authorized_keys
   # on node1
   ssh -v node2 true 2>&1 | grep -E 'Offering|Authentications|Permission'
   # on node2
   sudo journalctl -u sshd -n 5 --no-pager
   chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys
   restorecon -Rv ~/.ssh