8. Target Configuration
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:
Through a network perimeter firewall or corresponding network filter.
Through a local firewall on the target system (e.g. iptables).
Using a TCP wrapper with restrictions in
from="a.b.c.d"pattern in the
authorized_keysfiles 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
Public Key Algorithms
Check your server software to see if it supports the algorithms and how to generate the appropriate keys.
188.8.131.52. 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
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
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:
authorized_keysfile, which enables the suSSHi Gateway(s) in principle access to every user on the system.
authorized_keysfile, 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 email@example.com,ecdh-sha2-nistp256 Ciphers firstname.lastname@example.org,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 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
$ 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
- Permit Root Login
Please refer to Login Users for more details.
- Host-based Authentication
Specifies whether authentication using
/etc/hosts.equivis allowed along with successful client-host public key authentication (host-based authentication). The default is
Allow/disallow challenge-response authentication. The default is
Allow/disallow kerberos authentication. The default is
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
Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default,
sshdbinds remote port forwardings to the loopback address. The default is
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.
X11forwarding is permitted. The default is
Specifies whether sshd should print
/etc/motdwhen a user logs in interactively. (On some systems it is also printed by the shell,
/etc/profile, or equivalent.) The default is
You can think of a disclaimer message on all your systems stored in
/etc/motd. Alternatively you may look into the
Banneroption 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:
AuthorizedKeysFile parameter specifies the file(s) that contain(s) the public keys used for authentication.
The default is
This would cause the SSH server to look for authorized keys from
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:
Finally, you can add the suSSHi Gateway Authentication Public Keys to
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="184.108.40.206/24" ssh-ed25519 AAAAC3Nz(...)r2g524dX suSSHi2 Authentication Key from="220.127.116.11/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
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:
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_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
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: 192.168.100.101, 192.168.100.102