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:

you are using password-based authentication (PAM), but you want to use key-based authentication

paste the public key into the vi session (right-click anywhere on the PuTTY session screen)

press Esc to exit Insert mode

save and exit the editor

chmod 600 /usr/home/username/.ssh/authorized_keys

chown username /usr/home/username/.ssh/authorized_keys

if you were creating a new key:

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)

using PuttyGen, click the button: Save private key, and save the private key onto the local system

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)

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:

on the user's workstation, open PuTTY

select the correct session, then click the Load button

in Connections.. SSH.. Auth, click Browse

locate the private key file, and double-click it

click Session.. Save

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)

"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

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:

login to the FreeBSD server as root

vi /etc/ssh/sshd_config

comment out or delete the AllowUsers line that contains the relevant UserName and IP address

save and exit the editor

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.

login to the FreeBSD server as root

vi /etc/ssh/sshd_config

set these lines as follows:

PasswordAuthentication no
ChallengeResponseAuthentication no

save and exit the editor

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.