Proxmox New Install - SSH

As SSH is our mostly used tool, we need to make it safe.

Proxmox New Install - SSH
Photo by Florian Klauer / Unsplash

Keep SSH up to date

Please consult the OpenSSH pages to ascertain the most recent version and any security concerns that have been identified. You can update it from your repository or build it yourself.

Hardening – SSH Key pairs

OpenSSH server can impose restrictions on a per-key basis. You can control access for machine-to-machine sessions, as well as allow non-sudo users to set restrictions for their own user account.

SSH-keys

Use SSH keys (ed25519) certificates and not passwords

Using keys

Begin by opening your .ssh/authorized_keys file in nano. Since these configurations apply on a per-key basis, you’ll need to edit each individual key within each individual authorized_keys file that you want them to apply to, for all users on your system. Usually you will only need to edit one key/file, but this is worth considering if you have a complex multi-user system.

The following restriction options are available:

  • no-agent-forwarding: Disable SSH agent forwarding.
  • no-port-forwarding: Disable SSH port forwarding.
  • no-pty: Disable the ability to allocate a TTY (i.e. start a shell).
  • no-user-rc: Prevent execution of the ~/.ssh/rc file.
  • no-X11-forwarding: Disable X11 display forwarding.

Hardening in general

The exact hardening configuration that is most suitable for your own server depends heavily on your own threat model and risk threshold. However, the configuration you’ll use in this step is a general secure configuration that will suit the majority of servers.

We will edit the main OpenSSH configuration file in /etc/ssh/sshd_config to set the majority of the hardening options. Before continuing, it is a good idea to create a backup of your existing configuration file so that you can restore it in the unlikely event that something goes wrong.

Before doing anything, make a copy

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

After you done something, test the config

This command will execute the OpenSSH server in an extended test mode, thereby validating the entire configuration file and displaying the effective configuration values.

sshd -T

Edit the config -file

When you edit your configuration file, some options can be commented out by using a single character (#) at the beginning of the line. To turn on the option, remove the hash.

nano /etc/ssh/sshd_config
...
PermitRootLogin no
...
MaxAuthTries 3
...
LoginGraceTime 0          # see Security
...
ObscureKeystrokeTiming no # see Security
...
PasswordAuthentication no
...
PermitEmptyPasswords no
...
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

OpenSSH configuration changes /etc/ssh/sshd_config

The first option is to disable logging in via SSH as the root user. Set the PermitRootLogin option to no.

Limit the maximum number of authentication attempts for a particular login session by configuring the MaxAuthTries option 3– 5 is ok.

If required, you can also set a reduced login grace period, which is the amount of time a user has to complete authentication after initially connecting to your SSH server, set LoginGraceTime to 0, 20 if your version is never than 9.7p1!

Configured SSH keys for authentication, rather than using passwords, disable SSH password authentication to prevent leaked user passwords from allowing an attacker to log in or brute force attacks to succeed. Set PasswordAuthentication to no and also set PermitEmptyPasswords to no.

Most of the time, SSH will only use public key authentication. OpenSSH server also supports many other authentication methods, some of which may be enabled by default. If you don't need these features, you can turn them off to make your SSH server less vulnerable, ChallengeResponseAuthentication to no, KerberosAuthentication to no and GSSAPIAuthentication to no.

X11 forwarding is not usually in us, set X11Forwarding to no

OpenSSH server allows connecting clients to pass custom environment variables. Hardly any uses cases for it, set PermitUserEnvironment to no. And then you should also make sure to comment out any references in the configuration file to AcceptEnv by adding a hash (#) to the beginning of any line that specifies that option.

Disable several miscellaneous options related to tunneling and forwarding if you won’t be using these on your server. AllowAgentForwarding, AllowTcpForwarding and PermitTunnel all to no.

Disable verbose SSH banner, is usually enabled by default, as it shows various information about your system, set DebianBanner to no.

Test the syntax for success

sshd -t

Test mode. Only check the validity of the configuration file and sanity of the keys.

No output means a valid configuration. If issues, you will have output describing the syntax error.

Extended test mode. Check the validity of the configuration file, output the effective configuration to stdout, and then exit sshd -T.

Reload and Apply

systemctl reload sshd.service

Hardening – Allowlist

IP Address Allowlist

Many times, you only access your server from a few known and trusted IP addresses: your home internet, an office VPN, and a static jump box or bastion host in a data center.

AllowUsers *@84.0.100.1 *@84.0.100.2 *@192.0.2.0/24 *@172.16.*.1

AllowUsers [email protected] [email protected]

AllowUsers *@84.0.123.*

AllowUsers *@84.0.123.1

AllowUsers *@84.0.123.0/24

/etc/ssh/sshd_config

Match User nalle
  AllowUsers [email protected]

Restrict a specific user to a specific IP address, while allowing all other users to log in with no restrictions: /etc/ssh/sshd_config

Add it to the bottom of your OpenSSH server configuration file and test and reload as in the previous section.

Hardening – Shell of a User

You can use the /usr/sbin/nologin shell to disable interactive logins for certain user accounts, while still allowing non-interactive sessions to function, like file transfers, tunneling, and so on.

  • When adding a user adduser --shell /usr/sbin/nologin carl
  • Change the shell of a user sudo usermod --shell /usr/sbin/nologin danny

If you then attempt to interactively log in as one of these users, su carl, the request will be rejected, other actions such as file transfers will still be allowed.

You should combine your usage of the nologin shell with some additional configuration options in /etc/ssh/sshd_config.

Match User alex
  ForceCommand internal-sftp
  ChrootDirectory /home/alex/

Add it to the bottom of your OpenSSH server configuration file and test and reload as in the previous section.

Security issues

Some of the issues with older versions than and, including 9.7p1. PVE is at 9.2p1.

LoginGraceTime 0          
ObscureKeystrokeTiming no 
⚠️
Read the OpenSSH security page! ⚠️


References

OpenSSH [1] [2] [3] [4] [5] [6] [7] [8]


  1. OpenSSH homepage ↩︎

  2. OpenSSH Manuals ↩︎

  3. OpenSSH Security ↩︎

  4. – remote login client, ssh man page ↩︎

  5. – client configuration file, ssh_config man page ↩︎

  6. – daemon configuration file, sshd_config man page ↩︎

  7. – authentication agent, ssh-agent man page ↩︎

  8. Generate a ed25519 key pair, see the man page ↩︎