There are a few basic things that most admins will already know (and that tiger will warn you about if you forget):
- only allow version 2 of the protocol
- disable root logins
- disable password authentication
This is what
/etc/ssh/sshd_config should contain:
Protocol 2 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key UsePrivilegeSeparation sandbox AuthenticationMethods publickey PasswordAuthentication no PermitRootLogin no
Once you've done that, make sure you have all of the required host keys by running:
You may also want to ensure you are using strong ciphers and hash functions:
KexAlgorithms <insert Mozilla list> Ciphers <insert Mozilla list> MACs <insert Mozilla list>
Whitelist approach to giving users ssh access
To ensure that only a few users have ssh access to the server and that newly created users don't have it enabled by default, create a new group:
and then add the relevant users to it:
adduser francois sshuser
Finally, add this to
Deterring brute-force (or dictionary) attacks
One way to ban attackers who try to brute-force your ssh server is to
install the fail2ban
package. It keeps an eye on the ssh log file (
temporarily blocks IP addresses after a number of failed login attempts.
Using restricted shells
Should they attempt to log into the server, these users will be greeted with the following error message:
This account is restricted by rssh. Allowed commands: rsync If you believe this is in error, please contact your system administrator. Connection to server.example.com closed.
Restricting authorized keys to certain IP addresses
In addition to listing all of the public keys that are allowed to log into a
user account, the
~/.ssh/authorized_keys file also allows (as the
points out) a user to impose a number of restrictions.
Perhaps the most useful option is from which allows a user to restrict the IP addresses which can login using a specific key.
Here's what one of my
authorized_keys looks like:
from="192.0.2.2" ssh-rsa AAAAB3Nz...zvCn bot@example
You may also want to include the following options to each entry:
Increasing the amount of logging
The first thing I'd recommend is to increase the level of verbosity in
which will, amongst other things, log the fingerprints of keys used to login:
sshd: Connection from 192.0.2.2 port 39671 sshd: Found matching RSA key: de:ad:be:ef:ca:fe sshd: Postponed publickey for francois from 192.0.2.2 port 39671 ssh2 [preauth] sshd: Accepted publickey for francois from 192.0.2.2 port 39671 ssh2
Secondly, if you run logcheck
and would like to whitelist the "Accepted publickey" messages on your
server, you'll have to start by deleting the first line of
/etc/logcheck/ignore.d.server/sshd. Then you can add an entry for all of
the usernames and IP addresses that you expect to see.
Finally, it is also possible to
log all commands issued by a specific user over ssh
by enabling the
pam_tty_audit module in
session required pam_tty_audit.so enable=francois
Identitying stolen keys
One thing I'd love to have is a way to identify a stolen public key. Given the IP
restrictions described above, if a public key is stolen and used from a different IP,
I will see something like this in
sshd: Connection from 198.51.100.10 port 39492 sshd: Authentication tried for francois with correct key but not from a permitted host (host=198.51.100.10, ip=198.51.100.10). sshd: Failed publickey for francois from 198.51.100.10 port 39492 ssh2 sshd: Connection closed by 198.51.100.10 [preauth]
So I can get the IP address of the attacker (likely to be a random VPS or a Tor exit node), but unfortunately, the key fingerprints don't appear for failed connections like they do for successful ones. So I don't know which key to revoke.
Is there any way to identify which key was used in a failed login attempt or
is the solution to only ever have a single public key in each
authorized_keys file and create a separate user account for each user?