8. Target Configuration

8.1. General

8.1.1. Perimeter Security

While SSH is in principle a very secure protocol that usually does not require additional protection by a firewall etc., in a secure environment, where access to a target server should only be possible via suSSHi, it is of great advantage to restrict the sources for SSH connections to a target server to the IP addresses of the suSSHi Gateways. Otherwise, it would be relatively easy for a logged-in user on a target server - depending on his permissions - to store his own authentication key for later logins and then connect directly.

In addition, this basic protection can be hardened in various ways:

  1. Through a network perimeter firewall or corresponding network filter.

  2. Through a local firewall on the target system (e.g. iptables).

  3. Using a TCP wrapper with restrictions in /etc/hosts.allow or /etc/hosts.deny.

  4. With a from="a.b.c.d" pattern in the authorized_keys files together with the corresponding public keys.

Tip

Please refer to man 8 sshd, man hosts_access and man hosts_options for more details.

8.1.2. Key Exchange Methods, Public Key Algorithms, Ciphers and MAC Hashes

It is more than recommended to configure the SSH server to allow only the strongest available Key Exchange Methods, Public Key Algorithms, Ciphers and MAC Hashes supported by suSSHi.

Our recommendations are as follows:

Type

Recommendation

(Host) Key Exchange Methods

curve25519-sha256, ecdh-sha2-nistp256

Public Key Algorithms

ssh-ed25519, ssh-rsa

Ciphers

chachae20-poly1305, aes256-ctr

MAC Hashes

hmac-sha2-512, hmac-sha2-256

Check if your server software supports the algorithms and how to generate the appropriate keys.

8.1.2.1. Some Comments about Ciphers

The good

AES and ChaCha20 are the best ciphers currently supported. AES is the industry standard and all key sizes (128, 192 and 256) are currently supported with a variety of modes (CTR, CBC, and GCM). ChaCha20 is a very fast, more modern cipher and was designed with a very high security margin. While AES is secure, CBC mode leads to some potential vulnerabilities, so it is no longer recommended. CTR mode, or better GCM, would be preferable. ChaCha20, on the other hand, is a stream cipher, so it does not use block mode and therefore is not able to use CBC in an insecure way. ChaCha20 additionally uses Poly1305 for authentication, which eliminates the need for an HMAC. Unlike an HMAC, Poly1305 does not rely on the assumption of security of any hashing algorithm. As long as the underlying cipher is secure, the authentication will be unbroken.

The bad

Blowfish, IDEA and CAST128 are not bad ciphers in principle, but they have a 64-bit block size, which is why the key must be reseeded periodically. Also with 3DES, the effective security has been reduced from 168 bits to 112 bits due to a meet-in-the-middle attack. This is not horrible, but it is not ideal either. The issue with 64-bit block sizes is described on the OpenSSL website. Essentially, the issue is that encrypting a large amount of data with a single key can reveal information about the plaintext. For example, if the amount of encrypted data reaches the 32 GiB limit, things can get really bad. Therefore it is often recommended to change keys after every 4 GiB. While small block sizes are not great, OpenSSH automatically reseeds these ciphers more often than usual to attempt to mitigate this flaw. These ciphers themselves are old, but there are no known attacks that could completely break the cipher. However, there are simply better alternatives

The ugly

Arcfour, or RC4, is considered particularly secure. Severe statistical biases have been known for some time, and new attacks keep being discovered. While OpenSSH does drop the first 1536 problematic bytes of the cipher, it is still subject to a variety of other attacks.

Warning

Avoid using RC4, is our recommendation.

Tip

Overall, you should use ChaCha20 or AES and avoid RC4. For backward compatibility, use 3DES only when necessary. On any up to date OpenSSH installation, the default settings should be sufficient in virtually all circumstances. You can’t go wrong by using the default settings.

8.1.3. Login Users

There is of course a wide discussion about whether it is better to allow remote login for privileged or unprivileged users. Both have their advantages and disadvantages, e.g. for administrative logins with unprivileged access we still need the possibility to privilege the user, which is done with tools like the widespread sudo.

But even a system like sudo needs a managed and well maintained configuration, which can mean a lot of work for many target systems. And how does the user authenticate himself who, for example, should change from a “normal” unprivileged user to a privileged user like “admin” or “root”? If this is to be accomplished using a local password, the target system must have an appropriate password or be integrated into a federation that can check passwords (e.g. via PAM / LDAP). The user must then know this password and change it regularly. Or one allows the execution of certain commands via sudo without entering a password, which can also not be in the sense of the inventor.

If we consider the use case with suSSHi, the discussion takes a different turn. suSSHi controls all accesses of a (real or managed) gateway user to any target system and there again to a specific target user.

Tip

With suSSHi, our clear recommendation is to allow the login for all users that require access using the suSSHi Gateway key(s). This allows to manage everything else in the suSSHi Access Rules in one place.

On most target servers in an IT environment, administrative tasks are usually handled by privileged system users like root anyway, so why create personal users there at all?

8.2. OpenSSH Server

Allow login via suSSHi Gateway Authentication Keys only

In this setup, we will look at a configuration of an OpenSSH server that is integrated into a suSSHi environment and is to be authenticated via the gateway key(s).

Note

We recommend this configuration as it provides much higher protection against unauthorized access than authentication with user keys or even a password.

The features of this setup are:

  • Authentication at the destination is only possible via public key authentication.

  • Log in exclusively via suSSHi and the suSSHi Gateway key(s).

  • Regarding the allowed target user, we consider two variants:

    • A global authorized_keys file, which in principle enables the suSSHi Gateway(s) to access the target with any user.

    • A per-user authorized_keys file that can also can be manipulated more easily by the user.

/etc/ssh/sshd_config
Protocol                          2
HostKey                           /etc/ssh/ssh_host_ed25519_key
HostKey                           /etc/ssh/ssh_host_rsa_key
KexAlgorithms                     curve25519-sha256@libssh.org,ecdh-sha2-nistp256
Ciphers                           chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs                              hmac-sha2-512,hmac-sha2-256
AuthenticationMethods             publickey
StrictModes                       yes
PermitRootLogin                   without-password
HostbasedAuthentication           no
PasswordAuthentication            no
ChallengeResponseAuthentication   no
KerberosAuthentication            no
AllowAgentForwarding              no
GatewayPorts                      no
UsePAM                            yes
X11Forwarding                     yes
PrintMotd                         yes
AcceptEnv                         LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv                         LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv                         LC_IDENTIFICATION LC_ALL
AcceptEnv                         SUSSHI_*

Following, we will discuss the options in detail.

SSH Protocol

SSH protocol version 2 is the only version that should used for many years. Newer OpenSSH Versions (from 7.6 on) no longer support Version 1, so this option is obsolete as well. SSH Protocol version 1 is also not supported by suSSHi.

SSH Host Keys

Each host (i.e., computer) should have a unique host key. Sharing host keys is strongly not recommended, and can lead to man-in-the-middle attacks. However, in computing clusters, sharing hosts keys may sometimes be acceptable and practical.

SSH clients (and thus suSSHi Gateway) store host keys for hosts they have ever connected to. These stored host keys are called known host keys, and the collection is often referred to as known hosts.

Modern operation systems normally generate proper and unique SSH Host Keys during installation. If you need to generate them by yourself, run the following commands as user root:

$ ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
$ ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""
Kex Algorithms

Specifies the available Key Exchange (KEX) algorithms. Multiple algorithms must be comma-separated.

Ciphers

Specifies the allowed ciphers. Multiple ciphers must be comma-separated.

MACs

Specifies the available Message Authentication Code (MAC) algorithms. The MAC algorithm is used for data integrity protection. Multiple algorithms must be comma-separated.

Authentication Methods

Allow/disallow Public Key Authentication only.

StrictModes

Specifies whether sshd should check file modes and ownership of the user’s files and home directory before accepting login. The default is yes.

Permit Root Login

Please refer to Login Users for more details.

Host-based Authentication

Specifies whether authentication using /etc/rhosts or /etc/hosts.equiv is allowed along with successful client-host public key authentication (host-based authentication). The default is no.

ChallengeResponseAuthentication

Allow/disallow challenge-response authentication. The default is yes.

KerberosAuthentication

Allow/disallow kerberos authentication. The default is no.

AllowAgentForwarding

May also be disabled, as we do not want sessions to be established across this host. Can be disabled in suSSHi Profiles, so no need to disable here. Default is yes.

GatewayPorts

Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd binds remote port forwardings to the loopback address. The default is no.

UsePAM

On some operating systems with systemd, this is required to be set to yes. But since we have deactivated password and Keyboard-Interactive authentication, this is no problem.

X11Forwarding

Specifies whether X11 forwarding is permitted. The default is no.

PrintMotd

Specifies whether sshd should print /etc/motd when a user logs in interactively. (On some systems it is also printed by the shell, /etc/profile, or equivalent.) The default is yes.

Note

You can think of a disclaimer message on all your systems stored in /etc/motd. Alternatively you may look into the Banner option for displaying a banner before logging in.

You can also configure a central banner within suSSHi to display a disclaimer about access, logging, etc. under Partitions > Edit Settings > Client Sessions.

AcceptEnv

A list of accepted environment variables. We recommend to allow the suSSHi environment variables along with the others often set by some clients.

Authorized Keys Configuration

  1. Central Authorized Keys File

    Regarding the allowed target user, we consider two variants:

    The AuthorizedKeysFile parameter specifies the file(s) that contain(s) the public keys used for authentication. The default is %h/.ssh/authorized_keys %h/.ssh/authorized_keys2. This would cause the SSH server to look for authorized keys from .ssh/authorized_keys or .ssh/authorized_keys2 in the user’s home directory.

    Tip

    With a suSSHi Gateway in front, you may allow the gateway to (potentially) login to all users by providing one central authorized keys file instead of per-user files.

    This can be achieved by specifying:

    /etc/ssh/sshd_config
     AuthorizedKeysFile                /etc/ssh/authorized_keys

    Finally, you can add the suSSHi Gateway Authentication Public Keys to /etc/ssh/authorized_keys:

    /etc/ssh/authorized_keys
     ssh-ed25519 AAAAC3Nz(...)r2g524dX suSSHi2 Authentication Key
 ssh-rsa AAAAB3Nz(...)Zh07vsZQ== suSSHi2 Authentication Key

    Tip

    You can download your suSSHi Gateway keys from suSSHi Chef under Partition > Keys.

    Tip

    Specify only one key per line without any line breaks in between!

    Additionally, you may restrict the usage of these keys to the IP addresses of the suSSHi Gateway(s):

    /etc/ssh/authorized_keys
     from="100.22.22.0/24" ssh-ed25519 AAAAC3Nz(...)r2g524dX suSSHi2 Authentication Key
 from="100.22.22.0/24" ssh-rsa AAAAB3Nz(...)Zh07vsZQ== suSSHi2 Authentication Key

    If you are not fine with the idea that suSSHi is now able to potentially login to all users, you may use the Match User directives to restrict to which users the central authorized keys file should be applied:

    /etc/ssh/sshd_config
     Match User root,admin
    AuthorizedKeysFile                %h/.ssh/authorized_keys
 Match User !root,!admin,*
    AuthorizedKeysFile                /etc/ssh/authorized_keys

    Other options to restrict access to users / groups further:

    • AllowUsers

    • AllowGroups

    • DenyUsers

    • DenyGroups

    Please refer to man sshd_config for more details.

  2. Decentralized Authorized Keys Files

    By default, the SSH server looks into user-local authorized_key files (~/.ssh/authorized_keys or ~/.ssh/authorized_keys2) to see if they contain the presented public key for authentication.

    Thus it is of course also possible to configure the central suSSHi Gateway key in the individual user-specific authorized keys files, allowing control at this level.

    Here, too, you should of course make sure that the user has no possibility to add additional keys in an uncontrolled way. This can be prevented e.g. by appropriate file rights.

Restrict Access to SSH Server with TCP Wrapper

If you do not have a network based firewall in your environment or cannot use a host-based firewall like iptables, you may consider using the TCP wrapper to control access to your OpenSSH server:

Simply specify the IP addresses of the suSSHi Gateways in /etc/hosts.allow and deny all other access in /etc/hosts.deny, for example, as follows:

/etc/hosts.allow
sshd: 192.168.100.101, 192.168.100.102
/etc/hosts.deny
sshd: ALL