When i set up a new machine these days, I often disable password-based
ssh access by setting PasswordAuthentication and
ChallengeResponseAuthentication to no in /etc/ssh/sshd_config.
This protects my users (and the machine) from dictionary attacks based
on the crappy passwords that humans seem to traditionally prefer.
However, /usr/sbin/sshd is justifiably picky about whether to trust
the contents of the user's key file, which is (by default) stored in
~/.ssh/authorized_keys. In particular, the file must be writable only
by the user or root, and the directory it is stored in should have the
same restrictions (so that an altered file can't be moved into place
maliciously).
so i set up the machine to automatically create a blank
authorized_keys file for the user upon account creation, with the
appropriate permissions and ownership. This is easy to do:
mkdir /etc/skel/.sshtouch /etc/skel/.ssh/authorized_keys
Now, when i get a public key i want to use to authorize fred, i can
drop it into the appropriate file simply by doing:
cat >> ~fred/.ssh/authorized_keys
followed by pasting the key into the buffer, and then ctrl-D (to
signify end-of-file). fred can now log in, and i don't have to worry
about tuning permissions or building out the directory if it's not
already there.
Note: i'm aware that there are problems with key-based authentication as well, but given that the majority of these boxes are on the public internet, it's a pretty good protection against the most common class of attack out there: the brute-force password scanning attack. It also tends to protect against the "I use a good password, but it's the same password on every system i contact" class of foible, since a compromised machine which knows a user's public key for authentication can't use it to compromise another system which trusts the same pubkey. So at the moment, it seems to me like the authentication option which sucks less than all the others.
Tags: public key authentication, ssh, tip