ssh is an extremely useful tool to work remotely and securely on *nix systems.
But the usual password protected access strategy is not the safest way to go; anyone can try to guess your password, use a keylogger attack, etc.
One (big) safety step above is the pubkey (identity) authentication. This uses a pair key-passphrase for remote access.
You can make your system way safer with just 3 simple steps.
- Create your public-private key pair of files.
- Register your public key on the server you want to access.
- [optional and recommended] Allow only login using the pubkey on the server.
This adds one more layer of security – for a successful connection to remote machine you need both the passphrase for your key, and the public-private key pair of files.
Note that the passphrase is connected with the pubkey; when authenticating using pubkey, you’re asked for the passphrase for the key, and not for the password for the remove user account.
It is possible to create pubkey without a passphrase, which can be useful for script-based ssh connections (scp, rsync, etc. including), but is not recommendable for daily personal use.
And even for scripts, you should use passphrased pubkeys for safety; since you’re unable to type in passphrase in a script, you can register these credentials using ssh-agent.
It’s trivial to take care of what pubkey belongs to what user account – see details for step 2. further on.
- To generate the public-private key pair, use ssh-keygen -t rsa.
You’ll be prompted for where to save the pubkeys, then for passphrase (either empty, or 5+ letters), repeat if non-empty, and the keys get generated.
You should chmod 600 both key files, and be very careful about them.
Highly recommended is to hold them in a truecrypt partition or the like.
- Transfer the created *.pub file (typically id_rsa.pub) to the server you want to log into remotely (only the pub file; the other key file is your private key). There, all you have to do to register the key is to append it to list of authorized keys for the user this key belongs to, like this:
cat id_rsa.pub >> ~/.ssh/authorized_keys
Of course, if you’re root, replace ~ with home of any user you want to allow to enter with this pubkey.
The .ssh/authorized_keys file should of course also be chmod 600, and the ~/.ssh folder chmod 700.
- [can be done only by root] Edit the /etc/ssh/sshd_config file (or /usr/local/etc/sshd_config on BSD’s). Add/update the following lines:
Then restart ssh – /etc/init.d/ssh restart (or /usr/local/etc/rc.d/ssh restart on BSD’s).
Using several keys to access several remote servers is very simple; just specify the key to use:
ssh -i /where/is/my/key/id_rsa firstname.lastname@example.org .
Without -i directive, ssh, scp, rsync, etc. typically look for your key as ~/.ssh/id_rsa.
You always need both id_rsa and id_rsa.pub files to login.
Another option is to use ~/.ssh/config file to declare explicitly what key to use for what host (remote server); but it’s useful only on one place, not when you need to connect from different computers.
In ~/.ssh/config, you simply specify:
and ssh email@example.com will now be equivalent to the above call. See man ssh_config(5) for more details.
Tips and recommendations:
- Disable root account ssh login; rather allow login for some “general” account, such as “admin”, that has su rights. Simply add/update PermitRootLogin no line to sshd_config.
- You can very easily allow only certain users to enter remotely (e.g. all from your family have access to your computer, but only you want to access it remotely, to minimize possible exposures) – simply add AllowUsers user_name1 user_name2 … to sshd_config.
For more info, see man sshd_config(5).
- Change your ssh port to some other than the usual 22; of course, don’t forget to open that port in your firewall. Simply edit the Port 22 line in sshd_config.
- Be very careful about your keys; treat them as you’d treat keys from your house. Make them readable only by you, never give any of them to anyone, and never give out your passphrases.
- Use e.g. truecrypt partition to store your keys and other sensitive data.
- Just as with passwords, use strong passphrases for your keys.
- ssh typically caches authorizations for keys during the user session (i.e. you don’t need to enter passphrase for your key on the next connection). To clear this cache, use ssh-add -D.