Passwordless or Single Password SSH with Key Exchange

IMPORTANT UPDATE In the ten years since this article was published a lot has changed. Please see my updated article Generate and Automatically Load SSH Keys for Convenient Passwordless Authentication for a more secure and convenient implementation.

In the last two articles we have covered in detail the main flaw of any username-password authentication scheme and how to defend against attacks by increasing their time/resource cost. Unfortunately this does nothing to eliminate the problem but key-exchange authentication - while not unbreakable - changes the shape of the playing field and it's becoming an increasingly favoured authentication scheme for a myriad of applications including SSH and VPN protocols. This article will show you how to quickly generate and exchange keys with remote hosts and disable traditional password authentication.

First you will need to generate a key pair:

ssh-keygen -t rsa

You are going to have to decide here whether you want to encrypt your private key with a passphrase and enter one password every time you use key exchange or make login instant at the expense of a more vulnerable key. You need to consider the possible damage that could be done if a given machine with unrestricted shell access to other hosts is compromised.

The least level of protection you can apply is exchanging only lesser-privileged accounts as a first step toward higher levels, i.e. by using su. Key exchange suffers from this weakness only when the private key is stored locally and unencrypted. One could keep the private key (~/.ssh/id_rsa) on a USB stick, however your key is vulnerable when the device is mounted. Even when using an encrypted key if the file is intercepted it can eventually be cracked. Smart cards (themselves) do not share these weaknesses and will be the topic of an upcoming article.

Never allow root to directly shell into a machine regardless of the authentication scheme you choose to use, make sure your target's sshd_conf includes:

PermitRootLogin no
AllowUsers user1 user2 user3

Where user1,2,3 are the names of specific users permitted to login. This may not be practical for larger or public installations.

If the target account on the remote host has not yet used ssh you may have to create ~/.ssh. Add the new private key to the remote host's authorized keys list:

cat ~/.ssh/id_rsa.pub | ssh xxx.xxx.xxx.xxx "xargs --null echo >> ~/.ssh/authorized_keys"

If you have not already shelled into the remote host from this account you will be prompted to accept its public key. You may then be prompted for your password. If the copy was successful you will be returned to the command line without a message. Try logging into the remote host, if you are not asked for a password or you are asked your private key's passphrase you have successfully performed the key exchange.

Once you've finished exchanging keys with all of the hosts which should have access to the target you might proceed to disable password based authentication. The previous command will no longer work to import new keys, you will have to transfer them via other means (i.e. a host that has already exchanged keys with the target). Edit /etc/ssh/sshd_config to reflect:
PasswordAuthentication no ChallengeResponseAuthentication no
and restart sshd. Try logging in from a machine that has not exchanged keys with it. You should see something like:
Permission denied (publickey).
In an ideal world you wouldn't run management services (SSH, webmin, snmp etc) on public address space. One can keep SSH from being exposed in the first place by making it listen on a private subnet and connecting to it via VPN. The only time I can see someone wanting to expose SSH in particular is to provide sftp and chances are you'll be dealing with a number of users where key exchange isn't practical. You can address this by keeping password authentication and enabling a chroot jail, which I'll cover in a future article. If an attacker does manage to break into an account despite your fail2ban setup they will at least be confined to their own little slice of the filesystem.


There are no comments for this item.