SSH Basics
Site Navigation:
 
 

SSH Basics

Author:  Sven Knispel
Updated:  [udate]

I sepent a few hours re-generation my keys on a per-machine basis and took some notes while looking up the basic commands.
This how-to is the result...

Following steps are detailed in this article:

  • Creating keys
  • Distributing public keys
  • Testing ssh accesses
  • Troubleshooting
  • Verifying key fingerprint

1. Creating keys

Keys are created with the command ssh-keygen:
# ssh-keygen -t <key-type> -b <key-len> -C "comment" -f <name>
where:

  • key-type is dsa or rsa (dsa is the most commonly used these days)
  • key-len is the length of the key. For dsa 1024 bits is considered as secure enough, 2048 is considered more than secure. Keys larger than 2048 should only be used if erformance is not an issue
  • name is the name of the key-files. Defaults are id_rsa for rsa and id_dsa for dsa. I personally use id_dsa-<host-name>

The result are two files, id_dsa-<host-name> the private key and id_dsa-<host-name>.pub the public key.

2. Distributing public keys

In order to use the private/public key sheme to encrypt the session data the private key must be installed on the remote machine.

Copy the private key to the remote machine: # scp id_dsa-<host-name>.pub <user>@>remote-host>:/home/<username>/.ssh
Then connect to the remote machine and install the public key by adding it to ~/.ssh/authorized_keys2: # cat id_dsa-<host-name> >> authorized_keys2
Please note:

  • authorized_keys2 shall not be world readable (chmod 600 authorized_keys2)
  • If you decided to use rsa keys the public key has to be placed in authorized_keys


After having installed the public key on the remote machine log off.
If you use a key naming that is different from the default id_dsa/id_rsa it is required to instruct ssh about the key name. Therefore edit ~/.ssh/ config and add following line to it: IdentityFile=~/.ssh/id_dsa-<host-name/gt; This tells ssh which identity (private key) file to use.
Finally chmod the file as not world readable (chmod 600 config.

3. Testing ssh accesses

Test ssh with following command:
# ssh-v <user>@<remote-host> First thing to check: make shure you are asked for your passphrase, not your password
. In case of any trouble the debug display can be used for tracing the decisions made during the access (also see "Troubleshooting").

4. Troubleshooting

4.1. Using debug mode on client and server

For troubleshooting ssh both client and server provide detailed tracing options:

  • The ssh option -v traces details during the session establishment (e.g. selection of identity file)
  • You can start the sshd server on an alternate port using the command sshd -p <alternate-port> -d -D. In this mode the server displays important information at session begin

4.1. Common errors

  • ~/.ssh and/or the private data as well as config file are world readable
  • If using a non-standard identity filename is is not defined in ~/.shh/config (you can also try forcing the identity file using the -i ssh option

5.Verifying key fingerprints

The authenticity of host '<ip>' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? When establishing a ssh connection ssh may asks for to validate the fingerprint of the server key. This message can mean:

  • a "man-in-the-middle" attack
  • the server is not known yet
  • the server may simply have been reconfigured

The fingerprint can be easily be verified by comparing it to the fingerprint of the server's key: # ssh-keygen -l -f ssh_host_rsa_key