contact :: legal :: webstats  also on this site: - select - home tech writings green business studies conspiracy popular pages welcome  also in this section:  tech index  most popular pages  search: Like this site? Your donation is welcome!

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:

1. you are using password-based authentication (PAM), but you want to use key-based authentication
2. your server is running FreeBSD, and you're using SSHD
3. you login to the server remotely using PuTTY
4. you're familiar with FreeBSD, security, SSH, PuTTY, and PKI principles

The process

First, configure the server to accept key-based authentication. This only needs to be done once:

1. login to the FreeBSD server as root
2. vi /etc/ssh/sshd_config
3. uncomment the lines:

   RSAAuthentication yes
   PubkeyAuthentication yes
   AuthorizedKeysFile     .ssh/authorized_keys
   

4. save and exit the editor
5. restart the SSH daemon: /etc/rc.d/sshd restart

Next, for each user, create a keypair:

1. on a workstation, open PuttyGen
2. either load an existing key, or create a new key:
   1. select SSH2-DSA
   2. enter a keylength in bits - 2048 is good
   3. click the button: Generate

3. login to the FreeBSD server as root
4. mkdir /usr/home/username/.ssh
5. vi /usr/home/username/.ssh/authorized_keys
6. press i to put vi into Insert mode
7. using PuTTYGen, select the public key and copy it into the clipboard
8. paste the public key into the vi session (right-click anywhere on the PuTTY session screen)
9. press Esc to exit Insert mode
10. save and exit the editor
11. chmod 600 /usr/home/username/.ssh/authorized_keys
12. chown username /usr/home/username/.ssh/authorized_keys
13. if you were creating a new key:
    1. using PuttyGen, enter a passphrase and confirm it (the user will need to enter this each time they login - note it down for future reference)
    2. using PuttyGen, click the button: Save private key, and save the private key onto the local system
    3. using PuttyGen, click the button: Save public key, and save the public key onto the local system (this is optional as the public key is saved on the server, however if the key is ever lost or deleted, a new keypair will need to be generated)
    4. close PuttyGen

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:

1. on the user's workstation, open PuTTY
2. select the correct session, then click the Load button
3. in Connections.. SSH.. Auth, click Browse
4. locate the private key file, and double-click it
5. click Session.. Save
6. close PuTTY

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:

• You probably screwed up the key generation or pasting, redo it. Be careful when pasting into vi, that Insert mode is already enabled, otherwise you'll only paste some of your key. Also ensure to press Esc before attempting to exit vi, or you'll insert your exit command into the key (as Insert mode will still be enabled).
• ensure to select the correct key type before clicking the Generate button in PuttyGen, SSH2-DSA works for us. A SSH2-DSA keyfile should start with the string "ssh-dss" and end with your key comment (definable during key generation) - by default this is "dsa-key-YYYYMMDD" where YYYYMMDD is the current date.
• "server refused our key" may also appear if the server cannot read the keyfile (for example, if the permissions are set incorrectly, or it does not exist)
• "server refused our key" may also appear if the permissions and/or ownership of the .ssh directory are set incorrectly - the dir should have permissions 755, and be owned by root

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:

1. login to the FreeBSD server as root
2. vi /etc/ssh/sshd_config
3. comment out or delete the AllowUsers line that contains the relevant UserName and IP address
4. save and exit the editor
5. restart the SSH daemon: /etc/rc.d/sshd restart

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).

Disabling PAM

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.

1. login to the FreeBSD server as root
2. vi /etc/ssh/sshd_config
3. set these lines as follows:

    PasswordAuthentication no
    ChallengeResponseAuthentication no
   

4. save and exit the editor
5. restart the SSH daemon: /etc/rc.d/sshd restart

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.

Other notes

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.

related articles:  my FreeBSD diary  FreeBSD and ATA disks  adding a disk  upgrading a disk  FreeBSD backups  backing up to a remote volume  Samba as a file server (low security)  Samba as a file server (high security)  Samba as a Primary Domain Controller  Samba as a member server  Samba as a print server (with CUPS)  troubleshooting Samba  troubleshooting printing with CUPS  configuring sendmail  installing phpMyAdmin  dealing with mail for root  working with cron  installing and using GPG  automated PHP scripting  special-purpose users  upgrading to key-based authentication  distributed data warehousing  doing a minor version upgrade  upgrading from 6.1 to 6.4  upgrading 6.2 and below  installing and using Webmin  installing and using denyhosts  filesystem access controls  unix basics