8. Target Configuration
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:
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 available Key Exchange Methods, Public Key Algorithms, Ciphers and MAC Hashes supported by suSSHi.
Our recommendations are as follows:
(Host) Key Exchange Methods
Public Key Algorithms
Check if your server software supports the algorithms and how to generate the appropriate keys.
18.104.22.168. 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 very well described on the Sweet32 website, and the possible attacks are also explained. 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.
Avoid using RC4, is our recommendation.
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
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.
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).
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:
authorized_keysfile, which in principle enables the suSSHi Gateway(s) to access the target with any user.
authorized_keysfile that can 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 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
$ 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 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
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 authentication, 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 > Edit 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:
AuthorizedKeysFileparameter 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_keys2in 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.
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):
from="22.214.171.124/24" ssh-ed25519 AAAAC3Nz(...)r2g524dX suSSHi2 Authentication Key from="126.96.36.199/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 Userdirectives 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
By default, the SSH server looks 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 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
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:
sshd: 192.168.100.101, 192.168.100.102