Using password-based authentication means IP addresses should be specified in sshd_config's AllowUsers line, or the account is vulnerable to brute-forcing. However, if IP addresses are specified in the AllowUsers line, users cannot login from any other IP address. This may be problem if the user is on a dynamic IP.
Using key-based authentication allows you to remove the IP address restriction, while still protecting the account from brute-forcing. Using keys means it doesn't matter which IP address is used - if the keys validate, then the user is authenticated.
Note that retaining an IP address restriction while also using keys is possible, this configuration will prevent an attacker who has stolen a password-less private key from using it. However password-less keys are not recommended, except for automated tasks.
This article assumes:
First, configure the server to accept key-based authentication. This only needs to be done once:
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
Next, for each user, create a keypair:
Note: in the sample commandlines above, substitute username for the name of the user being configured
Note: permissions on the authorized_keys file MUST be set to 600 (-rw-------), and the file must be owned by the user (not by root)
Note: PuTTY uses its own key format (PPK). You cannot simply copy-and-paste between Putty's keyfile and keyfiles generated by ssh-keygen. You must use the load/save functions in PuttyGen if you generate keys with ssh-keygen. The recommended method is to use PuttyGen to generate the keys.
Next, for each user, add the key to the user's PuTTY configuration:
The key should now be available for use. If you see a "server refused our key" error when you try and login, this may happen for any of the following reasons:
Note: later, it might be necessary to upgrade the server - authorized_keys files can be migrated to a new server, put in the correct location with the correct permissions (as above) - and users will be able to login to the new server with their keys as usual. They will get a security alert the first time they connect to the migrated server - this is normal and is OK to accept.
The last job, if applicable/desired, is to remove the IP address restriction in the /etc/ssh/sshd_config file. Do this once key-based authentication is known to work correctly. To remove an IP address restriction:
This will allow the user to login from any IP address, as long as they are in possession of their key.
Once all users are using key-based authentication, password-based authentication should be disabled (see below).
Note: the process above adds key-based authentication capability to the SSH server. It does NOT remove password-based authentication capability. To remove password-based authentication capability for ALL users:
Warning: ensure to test that key-based authentication is working, before disabling PAM. If PAM is disabled but key-based logins aren't working, all users will be locked out of the system.
PasswordAuthentication no ChallengeResponseAuthentication no
Verify this change has taken effect by temporarily removing the private key from a PuTTY profile used to access the server. PuTTY will attempt to use PAM and if it is correctly configured, the server will refuse the connection. PuTTY will show a nasty error, "Disconnected: No supported authentication methods available" and the session will become inactive.
This article does NOT create a password-less login. Users must still enter a password, although it's actually the passphrase for their private key, rather than the password to their account. To create a password-less login, don't set a passphrase on the private key. Doing this still permits key-based authentication, however it allows anyone who gets a copy of the private key to login.
A passphrase-protected private key is still subject to a brute-force attack, but the key must be obtained first (eg. an attacker requires access to the computer hosting the key before they can try to brute-force it).
PuTTY has the ability to save the username and provide it automatically. We don't recommend using this, except for unprivileged accounts. The username is the last bit of info that an attacker will need, assuming he has your private key, and the passphrase that is associated with it.