SSH Hardening

[5kt]

We need to ensure that the SSH server is configured according to SAP corporate standards

1. Direct root login must be disabled
2. TCP forwarding must be disabled
3. X11 forwarding must be disabled
4. Use public key authentication
5. Use a verbose log level
6. Disable host authentication
7. Use secure cipher suites, kex algorithms and macs

[5kt]

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

[5kt]

Also, at the moment the sftp subsystem is wrongly configured (the test is also broken).

[waldiTM]

Also, at the moment the sftp subsystem is wrongly configured (the test is also broken).

Well. sftp should use internal-sftp, except of really special circumstances.

[waldiTM]

Some remarks:

1. Direct root login must be disabled

This is handled by cloud-init on platforms using it. cloud-init allows to specify root as primary user, Hetzner does that for example. For GCP this should be disabled.

2. TCP forwarding must be disabled
3. X11 forwarding must be disabled

Shell access but no TCP forwarding is always fun. nc or socat for the win.

4. Use public key authentication

Azure allows the user to specify either password or public key on start of new instances.

[waldiTM]

Could you please explain your selection? There are some notable differences to the default values (which I quoted below).

Ciphers

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Default:

                   chacha20-poly1305@openssh.com,
                   aes128-ctr,aes192-ctr,aes256-ctr,
                   aes128-gcm@openssh.com,aes256-gcm@openssh.com

GCM and CTR swapped.

Key exchange

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Default:

                   curve25519-sha256,curve25519-sha256@libssh.org,
                   ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
                   diffie-hellman-group-exchange-sha256,
                   diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,
                   diffie-hellman-group14-sha256

The now standardized curve25519-sha256 is missing, some other newer DH ones are missing.

Message authentication code

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

Default:

                   umac-64-etm@openssh.com,umac-128-etm@openssh.com,
                   hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
                   hmac-sha1-etm@openssh.com,
                   umac-64@openssh.com,umac-128@openssh.com,
                   hmac-sha2-256,hmac-sha2-512,hmac-sha1

[marwinski]

Keep in mind that we have corporate requirements for the ssh hardening that we implemented originally.

[waldiTM]

Still, the users of an open product, which you want to provide here, deserve at least some form of explanation for changes. Especially changes that can have critical security implications.

And the OP listed "good practices" as reason, not "corporate requirements".

[waldiTM]

Also, those cipher etc changes have limited practical effect. The OpenSSH server only selects what algorithms it is willing to accept, not what preference they have. So changes in the order of entries needs to be done for the client, not server.

[marwinski]

I did some research. Here are my comments:

Direct root login must be disabled

This is handled by cloud-init on platforms using it. cloud-init allows to specify root as > primary user, Hetzner does that for example. For GCP this should be disabled.

We have at least two platforms without cloud-init at the moment (Azure, GCP). Disabling direct root login is not an issue from my point of view.

TCP forwarding must be disabled X11 forwarding must be disabled

Shell access but no TCP forwarding is always fun. nc or socat for the win.

Well yes, I'd prefer TCP forwarding in favour of nc or socat. This said, we are not compliant here with our own rules as we have enabled TCP forwarding. The use case is the bastion host for the gardenctl ssh feature. We should really fix that but then the priority for that is quite low.

Use public key authentication

Azure allows the user to specify either password or public key on start of new instances.

Yes, but what is the problem with a policy that explicitly forbids that? This is from my point of view quite common and not some exotic restriction.

As for the ciphers I have insufficient knowledge for being able to judge those or the order. I am not sure how many experts could have a detailed discussion on this and in how far they would agree. The only point I am taking here is why curve25519-sha256 and some newer DH ones are missing. I am not sure the ordering had any meaningful background.

To your point:

Still, the users of an open product, which you want to provide here, deserve at least some form of explanation for changes. Especially changes that can have critical security implications.

I really don't see a point where those settings have security implications. Is this a deliberate insecure setup from your point of view?

[waldiTM]

Direct root login must be disabled

This is handled by cloud-init on platforms using it. cloud-init allows to specify root as > primary user, Hetzner does that for example. For GCP this should be disabled.

We have at least two platforms without cloud-init at the moment (Azure, GCP). Disabling direct root login is not an issue from my point of view.

So disable it on Azure and GCP and leave cloud-init using platforms alone? I saw Hetzner on your wishlist, where I'm not sure you could actually change the user.

TCP forwarding must be disabled X11 forwarding must be disabled

Shell access but no TCP forwarding is always fun. nc or socat for the win.

Well yes, I'd prefer TCP forwarding in favour of nc or socat. This said, we are not compliant here with our own rules as we have enabled TCP forwarding. The use case is the bastion host for the gardenctl ssh feature. We should really fix that but then the priority for that is quite low.

So, document it properly, and don't tell people it's "good practice", while it is not?

Use public key authentication

Azure allows the user to specify either password or public key on start of new instances.

Yes, but what is the problem with a policy that explicitly forbids that? This is from my point of view quite common and not some exotic restriction.

Okay, I just realized that waagent and cloud-init will fix this up anyway. So as long as the sshd config is writable this feature will continue to work.

As for the ciphers I have insufficient knowledge for being able to judge those or the order. I am not sure how many experts could have a detailed discussion on this and in how far they would agree. The only point I am taking here is why curve25519-sha256 and some newer DH ones are missing. I am not sure the ordering had any meaningful background.

As I said, the order does not matter anyway. If you want to remove particular ones, use the Option -xxx variant.

Still, the users of an open product, which you want to provide here, deserve at least some form of explanation for changes. Especially changes that can have critical security implications.

I really don't see a point where those settings have security implications. Is this a deliberate insecure setup from your point of view?

It is ssh, of course everything can have security implications. That's why pointing at stuff, citing "good practices" but nothing else, is not a practical way to do them if you want people to trust your decisions. You may want to check again why CVE-2008-0166 happened.

[marwinski]

TCP forwarding must be disabled X11 forwarding must be disabled

Shell access but no TCP forwarding is always fun. nc or socat for the win.

Well yes, I'd prefer TCP forwarding in favour of nc or socat. This said, we are not compliant here with our own rules as we have enabled TCP forwarding. The use case is the bastion host for the gardenctl ssh feature. We should really fix that but then the priority for that is quite low.

So, document it properly, and don't tell people it's "good practice", while it is not?

Well I am not telling people that this is good practice. This said, it is not obvious why allowing TCP and X11 forwarding would be good practice which I believe it is not.

As for the ciphers I have insufficient knowledge for being able to judge those or the order. I am not sure how many experts could have a detailed discussion on this and in how far they would agree. The only point I am taking here is why curve25519-sha256 and some newer DH ones are missing. I am not sure the ordering had any meaningful background.

As I said, the order does not matter anyway. If you want to remove particular ones, use the Option -xxx variant.

I am puzzled. This means that everything new that is introduced is automatically supported!? In the security space this is something that people usually don't do (e.g. allow everything and then disable the stuff they don't want). I'd rather be in control on what I configure and add new stuff once I am confident about it.

It is ssh, of course everything can have security implications. That's why pointing at stuff, citing "good practices" but nothing else, is not a practical way to do them if you want people to trust your decisions. You may want to check again why CVE-2008-0166 happened.

Well, I am not citing good practices here. Anyway, I think I read about this CVE a long time ago but would appreciate if you could share a link to good analysis.

[nanory]

Hi everyone,

I'm currently trying to evaluate the requirements mentioned here and the actual implementation within Garden Linux in order to get a better understanding of what needs to be done.

So for me, the current situation looks like this (unmarked items are not configured in the current sshd_config of Garden Linux):

• [x] Direct root login must be disabled
  • This is already implemented in Garden Linux via the server feature
  • Since it is already active for a specific time and there haven't been problems with this, I think the requirement is fulfilled and the current configuration be left as it is.
• [ ] TCP forwarding must be disabled
  • As mentioned earlier, disabling TCP forwarding has limit affect on the actual security because an administrator can simply install own forwarders and use nc or socat once the administrator has SSH access.
  • Moreover, Gardener uses this feature for the bastion host. The requirement stats that TCP forwarding should be disable unless there is a hard reason to keep it.
  • Since disabling TCP forwarding has limit affect on the security and it is needed in case of Gardener, we can probably leave this parameter as it is for now.
• [x] X11 Forwarding
  • By default, this feature is set to no according to the OpenSSH documentation
  • In addition, Garden Linux already sets this parameter, as one can see here
• [x] Use public key authentication
  • There may be some cloud providers that offer password authentication and they will modify the running instance to allow this, but I think there is no reason not to set this as the default.
  • In addition, this has already been set in the sshd_config.
• [x] Use a verbose log level
  • It has been configured here, so this requirement should be fulfilled.
• [x] Disable host authentication
  • It has been configured here as well, so this requirement should be fulfilled, too.
• [x] Use secure cipher suites, key algorithms and macs
  • As far as I understand, the currently used cipher suites in Garden Linux are already matching the default suites that OpenSSH provides.
  • They are configured in the sshd_configuration
  • They may be sorted differently than the default ones but this has no affect and I think there is also no special reason for this rather than a changed order due to a simple copy paste from the requirement document.
  • The configured key algorithms on the other hand are lacking some newer algorithms. The default OpenSSH configuration uses key algorithms that are considered to be strong, as RFC9142 states
  • One could argue that the default ciphers, key algorithms and MACs used by OpenSSH are already secure and that there is no reason to modify them as long as a newer versions of OpenSSH is installed.
  • According to RFC6194, the used HMAC-SHA-1 for example, doesn't have a security implication yet and there is no specific reason to omit it. As a result, this MAC is still used by OpenSSH.
  • If a key algorithm or cipher shouldn't be secure enough anymore, most probably the Debian SSH Team will remove these ciphers from the default list.

In summary, I would suggest to document this analysis underneath the docs/ directory explaining what hardening configurations have been implemented and why.

After that, we could discuss, how we want to move on with the Ciphers, Key Algorithms and MACs in the current sshd_config then.