8. Target Configuration

8.1. General

8.1.1. Perimeter Security

While SSH is in principle a very secure protocol, which usually does not require any 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-on user on a target server - depending on rights - to deposit 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.


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 Key Exchange Methods, Public Key Algorithms, Ciphers and MAC Hashes available and supported by suSSHi.

Our recommendations are as follows:



(Host) Key Exchange Methods

curve25519-sha256, ecdh-sha2-nistp256

Public Key Algorithms

ssh-ed25519, ssh-rsa


chachae20-poly1305, aes256-ctr

MAC Hashes

hmac-sha2-512, hmac-sha2-256

Check your server software to see if it supports the algorithms and how to generate the appropriate keys. 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 more modern cipher and is designed with a very high security margin. It is very fast. While AES is secure, the CBC mode leads to some potential vulnerabilities, so it is no longer recommended. CTR mode, or better GCM, would be preferred. ChaCha20 on the other hand is a stream cipher, so it does not use a block mode of operation and is therefore not able to use CBC insecurely. ChaCha20 additionally uses Poly1305 for authentication, making an HMAC unnecessary. 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 per se, but they have a 64-bit block size. This means the key must be reseeded periodically. 3DES additionally, due to a meet-in-the-middle attack, has its effective security reduced from 168 bits to 112 bits. This is not horrible, but it is not ideal. The issue with 64-bit block sizes is described quite well on the Sweet32 website, describing the attacks made possible. The gist of it is that encrypting a large amount of data with a single key can leak information about the plaintext. When 32 GiB of data are encrypted, things get really bad. It’s often recommended to change keys after every 4 GiB. While small block sizes are not great, OpenSSH does automatically reseed these ciphers more often than otherwise to attempt to mitigate this flaw. The ciphers themselves are not particularly bad. These ciphers, while old, are not subject to any known attacks that allow a complete break of the cipher. There are simply better alternatives out there.

The ugly

Arcfour, or RC4, is stated not particularly secure. Severe statistical biases have been known to exist for a while, 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.


Avoid using RC4, is our recommendation.


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

8.1.3. Login Users

There is, of course, a wide-ranging discussion as to whether it is better to allow remote login to privileged or unprivileged users. Both have their advantages and disadvantages, e.g. for administrative logins with an 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 e.g. should change from a “normal” unprivileged user to an admin user like “admin” or “root”? If this is to be done 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 by 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.


With suSSHi, our clear recommendation is to allow the login for all users who 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 have a 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).


This is our setup recommendation, because 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 look at two variants:

    • A global authorized_keys file, which enables the suSSHi Gateway(s) in principle access to every user on the system.

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

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                         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 have been used for many years. Newer OpenSSH Versions (from 7.6 on) do not 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 so suSSHi Gateway does) store host keys for hosts they have ever connected to. These stored host keys are called known host keys, and the collection is often called known hosts.

Modern operation systems normally generate proper and unique SSH Host Keys during installation. If you have to generate them by your own, 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.


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


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.


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.


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


Allow/disallow kerberos authentication. The default is no.


May be disabled as well since we don’t want sessions to be established across this host. Could be disabled in suSSHi Profile, so no need to disable here. Default is yes.


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.


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


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


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.


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 / Partition Settings / Client Sessions.


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

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.


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:

 AuthorizedKeysFile                /etc/ssh/authorized_keys

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

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


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


Just 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):

 from="" ssh-ed25519 AAAAC3Nz(...)r2g524dX suSSHi2 Authentication Key
 from="" 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:

 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.

Decentralized Authorized Keys Files

The default option is for the SSH server to look 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 controlled 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 can’t go with an 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 the /etc/hosts.allow and deny all other access in /etc/hosts.deny, for example as follows:

sshd: ALL