28

This question already has an answer here:

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.

marked as duplicate by symcbean, D.W., Xiong Chiamiov, Matthew, Tobi Nary Feb 7 '18 at 14:05

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 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 5 '18 at 17:41
  • 6
    On Linux: service sshd stop is the toughest. ;) – Jason Feb 6 '18 at 0:16
  • This is why I love OpenBSD: secure as hell by default. – Alhadis Feb 6 '18 at 5:51
31

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
  • 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 5 '18 at 3: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: github.com/stribika/stribika.github.io/commits/master/_posts/… and shows last update in november 2017. I have edited my answer in that direction. – Patrick Mevzek Feb 5 '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 6 '18 at 0: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.

10

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

# Turn on Privilege Separation (should be on by default)
UsePrivilegeSeparation sandbox

# 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.

  • 3
    I don't recommend to use root account except special cases. If need root privileges, why not use sudo? – Hartman Feb 5 '18 at 3: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 5 '18 at 3:20
  • 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 5 '18 at 8: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 5 '18 at 8: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 5 '18 at 10:35
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
  • 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! says "ECDSA:" ... "Recommended to change" , and 2. Using Ed25519 for OpenSSH keys (instead of DSA/RSA/ECDSA) says "Ed25519" ... "offers better security than ECDSA" – TOOGAM Feb 6 '18 at 3: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 9 '18 at 3:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.