29

I work heavily with SSH and SFTP, to be specific between two machines, both of which have their SSH port open on a public IP address.

What are the toughest SSH daemon settings in terms of encryption, handshake, or other cryptographic settings in 2018?

I am specifically interested in the cryptographic protocols. Securing SSH with good password selection, good key management, firewalling, etc. are out of scope for what I am asking here.

So far, I have found and set on both machines in /etc/ssh/sshd_config:

AuthenticationMethods publickey
Ciphers aes256-cbc
MACs hmac-sha2-512-etm@openssh.com
FingerprintHash sha512
#KexAlgorithms

This can be considered a follow-up question of Hardening SSH security on a Debian 9 server which I have posted before some time ago. But in a specific way, I want to know the highest settings.

LinuxSecurityFreak
  • 1,562
  • 2
  • 18
  • 32
  • 6
    "X in 2018" questions generally aren't well suited for Stack Exchange - the site is architected to just have one "X" question that gets updated answers as updates need to happen. – Xiong Chiamiov Feb 05 '18 at 17:41
  • 6
    On Linux: `service sshd stop` is the toughest. ;) – Jason Feb 06 '18 at 00:16
  • This is why I love OpenBSD: secure as hell by default. –  Feb 06 '18 at 05:51

4 Answers4

29

You have a good discussion here: https://wiki.mozilla.org/Security/Guidelines/OpenSSH

On modern OpenSSH they recommend:

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

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

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

This page gives explanations for each choice: https://stribika.github.io/2015/01/04/secure-secure-shell.html

(do not be fooled by the hardcoded date in the URL, the document is updated from time to time as can be seen from its "changelog" at https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md)

Against Logjam, see the end of https://weakdh.org/sysadmin.html :

KexAlgorithms curve25519-sha256@libssh.org
Patrick Mevzek
  • 1,748
  • 2
  • 10
  • 23
  • For the best configurations, you should probably only be using ETM for the HMAC, or ideally doing away with HMAC entirely with AEAD. – forest Feb 05 '18 at 03:16
  • @MichaelHampton indeed but the date hardcoded in the URL or at top of document is misleading. But a changelog of the page is here: https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md and shows last update in november 2017. I have edited my answer in that direction. – Patrick Mevzek Feb 05 '18 at 20:39
  • _diffie-hellman-group-exchange-sha256_ is only recommended if you have manually removed primes of less than 2048 bits from _/etc/ssh/moduli_ – bain Feb 06 '18 at 00:22
26

To be honest, I don't understand these things too much, I just want strong encryption and everything

I don't know what you mean by "everything" but if you just want strong encryption then don't mess with the default settings - its possible they could be more secure but you are more likely to break the security than improve it if you don't know what you are doing.

The authentication and negotiation ciphers are far more important than the symmetric algorithm for the overall security - and you've told us nothing about these.

Wanting to know more is a good thing - but the consensus of opinion on the strongest ciphers in February 2018 (at least when you're referring to a an up to date version of well maintained software) is of very little value compared with an understanding of the protocol works and how the implementation integrates with your operating system.

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
symcbean
  • 18,278
  • 39
  • 73
11

Following config can provide higher security level while keeping some degree of compatibility and reduce configuration complexity.

WARNING: The following configuration is not compatible with all clients

# Change the port number avoid automated attack
Port 2222

# Limit to SSH2 only (the default value)
Protocol 2

# Use RSA and Ed25519 host key only
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

# No root login, obvious
PermitRootLogin no

# Log the finger print of public key used to login, provide audit trails. Might take up more storage.
LogLevel VERBOSE

# 2 Factor Authentication. User must present a valid public key first, then enter the correct password to login
AuthenticationMethods publickey,password

# How fast you can type your password?
LoginGraceTime 20

# Key Exchange
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

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

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

# Only allow specific group member login via SSH
AllowGroups ssh-user

# Renew encryption key every 30 minutes or 1 GB of transferred data (overkill & generate overhead, use with caution, especially on slow network)
#RekeyLimit 1G 1800

Remove moduli under 3072 bits for security (Thanks Mozilla)

awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli

The security can further improve with more tweaks such as firewall (iptables), fail2ban, Tor hidden service, switch to custom moduli and tcpwrapper, but those topics are out of scope in this answer. Note that the configuration is not completed, you might need other essential parts for the daemon to work. Remember to backup the original config file so you can roll back if any things goes wrong.

Hartman
  • 426
  • 2
  • 11
  • 1
    If you're using public key authentication, there's no reason not to enable root logins. Also, the default protocol is already 2, so no reason to explicitly set that. – forest Feb 05 '18 at 03:17
  • 3
    I don't recommend to use root account except special cases. If need root privileges, why not use sudo? – Hartman Feb 05 '18 at 03:19
  • 5
    If you need root, it's best to log in as root. Logging in as a lesser user and then using su or sudo actually reduces your security (LD_PRELOAD or LD_LIBRARY_PATH on the shell, env stuff like PATH, calls like ptrace, process_vm_writev, etc). – forest Feb 05 '18 at 03:20
  • 1
    @forest If two people login straight to root (via different keys), how do you know whom to "blame"? – kubanczyk Feb 05 '18 at 08:29
  • 7
    @forest, there are several questions on this site about logging in as root vs. using `sudo`. Basically, the big advantage of `sudo` is that it provides an audit trail in a multi-administrator environment. – Mark Feb 05 '18 at 08:43
  • 4
    @2awm366, the big advantage of changing the port is that it cleans up your logs. It doesn't provide any actual security if you're already requiring public-key logins, since those can't be brute-forced in a reasonable amount of time. – Mark Feb 05 '18 at 08:46
  • 2
    @Mark: Or if a vulnerability is found in SSHD, an alternate port might keep you safe from automated attacks looking for an SSHD on any IP address long enough for you to patch the system. Alternatively, if you *do* enable password logins on an alternate port, running an SSHD on port22 that doesn't allow password logins creates a honeypot that catches any bots that don't look for alternate SSHD ports after finding one on port22. – Peter Cordes Feb 05 '18 at 10:35
  • The automated attack would just scan on 222 and own you. It's not worth the trouble. – gparent Feb 05 '18 at 17:05
  • @Mark Correct, it does provide a good audit trail, but when its only use is `sudo -i` immediately after SSHing into a lesser user, that benefit is taken away (as PAM already records direct root logins). – forest Feb 06 '18 at 02:11
  • @forest `sudo` policy can be configured to log all uses, as well as input and output so you know who ran what and when. More importantly, disabling root login and using `sudo` provides you an audit trail *back to an actual user* via user logins. If everyone is logging in as `root` you don't know which of several people with `root` access it was. If they're logging in as normal users you do. This can help answer the question "which actual person with admin access made what change"? Very important for auditing changes and access. – Schwern Feb 06 '18 at 03:16
  • @Schwern Can't different users use different public keys to authenticate as root? – forest Feb 06 '18 at 03:20
  • 1
    @forest then why not keep it simple and everyone use `sudo`?!?! Using different public keys to authenticate as root take extra step to map which key belongs to whom while I can view the actual username with `sudo`. Furthermore, using different public keys doesn't mean you know who issue a specific command while `sudo` can give a clear audit. – Hartman Feb 06 '18 at 03:25
  • @Hartman Because then a compromised lesser user can hijack the entire system by replacing `sudo`. As a rule, if your environment is compromised (PATH, LD_PRELOAD, etc), elevating privileges will result in root being compromised as well. Note that I am only talking about a situation where one logs in as root using sudo (i.e. `sudo -i`), not someone who has to run a particular command whitelisted by sudoers (e.g. `sudo /usr/bin/permitted-command`). – forest Feb 06 '18 at 03:39
  • @forest setuid binaries like `sudo` ignore `LD_PRELOAD` and many other potentially dangerous environment variables. [There may be ways to get around that](https://blog.maleadt.net/2015/02/25/sudo-escalation/), but they're a lot more sophisticated than just setting `LD_PRELOAD` in a compromised user account. `sudo -i` limits what environment variables are passed to the root shell. If things are set up correctly, your users shouldn't habitually be using `sudo` to get a shell. They should need to do very little as root and use `sudo` to run individual commands. – Schwern Feb 06 '18 at 04:02
  • @Schwern I am aware of that. Setting it however in order to compromise a shell is all you need to execute a malicious copy of `sudo`. Attacking it is not complicated at all, and given access to a user account, it would be trivial to gain root access if that user ever uses `sudo` to run a privileged command (assuming privileged commands are not whitelisted in sudoers). – forest Feb 06 '18 at 04:07
  • @forest [I believe I've found the argument you're making](http://dmitry.khlebnikov.net/2015/07/should-we-use-sudo-for-day-to-day.html). I see the point that `sudo` means you have to enter your password. If that account is already compromised the attacker can steal your password in various ways and use it to run `sudo` themselves. However your solution to hand these same users which you don't trust to secure their own accounts root logins seems worse than the disease. And it messes with auditing to catch compromised accounts. There must be a better solution. That's for another question. – Schwern Feb 06 '18 at 04:34
  • 1
    The comment section become too long to debate the topic of using `sudo` or not. I think it is good to discuses it in a chat room and edit the answer afterward. – Hartman Feb 06 '18 at 05:34
  • How do I use "Pubic key authentication"? ;) – Dom Feb 06 '18 at 14:57
  • -1 for suggesting to bind to a high port. **Do not do this.** – forest Mar 28 '18 at 02:30
3

I gave a detailed answer to this in my answer to How to (further) ensure SSH security?, and per ssh.com and the OpenSSH changelog it appears that updates include

  • if you prefer ecdsa to ed25519, that's an option on some SSH software
  • StrictHostKeyChecking has more options.
  • DisableForwarding is new
  • use all SHA2 signatures, no SHA1 signatures
Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
  • 1
    Even if ecdsa is an option, my recent reading suggests it is discouraged, thereby not being the best answer to what was asked for ("the toughest" ... "settings"). Two citations: **1.** [Upgrade your SSH keys!](https://blog.g3rt.nl/upgrade-your-ssh-keys.html) says "ECDSA:" ... "Recommended to change" , and **2.** [Using Ed25519 for OpenSSH keys (instead of DSA/RSA/ECDSA)](https://linux-audit.com/using-ed25519-openssh-keys-instead-of-dsa-rsa-ecdsa/) says "Ed25519" ... "offers better security than ECDSA" – TOOGAM Feb 06 '18 at 03:58
  • @TOOGAM I agree that I personally prefer ed25519. Thank you very much for adding the links, they'll help guide readers to ed25519 unless there are overriding other concerns, such as industry or government regulation. – Anti-weakpasswords Feb 09 '18 at 03:17