Stribika

Technically you don't need the root password, you can always password recovery if you have access to the box. And how exactly did you lock yourself out of every account with sudo? Of course there's always "messed up my ldap or general network settings, can't log in to fix them". There's nothing wrong with setting your root password to a random string and throwing it away, after verifying your sudo works, I guess.

I will admit to being lazy, and with full automation its faster to spawn a new virtual image and let ansible run its course than to do root password recovery where you boot and tell the bootloader to make the init system /bin/sh and hand edit /etc/shadow and /etc/passwd and then reboot again, etc etc. I mean I can set up a new image almost as fast as I can reboot an old image, and I set up images a lot more often than I do password recovery, so...

Scrap the ssh commentary and set up ssh company wide as per stribika plus or minus local modifications:

https://stribika.github.io/2015/01/04/secure-secure-shell.html

"On large scale, you'll be better off with a full automated setup using something like Ansible"

At ANY scale you're better off, unless you're experimenting or time isn't money. It'll take longer to add the time to document and test what you're doing by hand than to convince ansible to do it for you. If you don't document or test you're just doomed, so its not like you can avoid that effort. With automation this is like "first two minutes on a…

For OpenSSH, take a close, hard look at /etc/ssh/moduli (or wherever it's at) too, in addition to EC curves. I would consider deleting the default moduli and regenerating it.

https://stribika.github.io/2015/01/04/secure-secure-shell.html

In my mind, more generally: EC attempts to make crypto algos stretch using fewer bits but implementations are harder to prove both theoretically (by being more esoteric, therefore fewer eyeballs are able to catch errors) and functionally correct (by having more moving parts). Why haven't more conservative stretching / extension of proven algos happened?

Also, even more broadly, this and at lot of other crypto decisions in TLS come off as seat-of-the-pants, guesswork, cooking by committee rather than simple, feature-minimal and bullet-resistant standards (how many way over-engineered and over-featured encodings do certs need?). The result smells like a pile of poo that will get recall after recall, patch after patch until something about the inputs and decision-making process changes. We can't keep having OpenSSL and the TLS committee saying "yes" instead of "no" to (feature creep) throwing every little edge use-case live into production 1.x branch, the codebase is huge enough, and it's nearly impossible to compile out all the little used crap, even in forks. Doing the same thing and expecting a different result is either stupid or insane, or both. OpenSSL and TLS leadership, process changes perhaps?

This is my standard on new server setup (which is admittedly overkill but I'd rather have it slightly slower and safer):

http://www.catb.org/esr/sshexport/

https://stribika.github.io/2015/01/04/secure-secure-shell.html

SERVER SIDE:

sources.list (if you're on an older version of debian)
deb http://http.debian.net/debian wheezy-backports main

apt-get -t wheezy-backports install --reinstall ssh

====

cd /etc/ssh

rm ssh_host_key

ssh-keygen -t ed25519 -f ssh_host_ed25519_key -a 256 < /dev/null

ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

(do not password protect server side keys)

====

/etc/ssh/sshd_config

Protocol 2

HostKey /etc/ssh/ssh_host_ed25519_key

HostKey /etc/ssh/ssh_host_rsa_key

KexAlgorithms curve25519-sha256@libssh.org,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,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

====

CLIENT SIDE:

/etc/ssh/ssh_config

Host *

KexAlgorithms curve25519-sha256@libssh.org,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…

Thank you!

So to help everyone (read whole post first), you should probably have the line

KexAlgorithms sntrup4591761x25519-sha512@tinyssh.org,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

in /etc/ssh/sshd_config of server and /etc/ssh/ssh_config of client (under "Host ").

(The rest of the kex recommendations are from https://stribika.github.io/2015/01/04/secure-secure-shell.html)

---

However, for some reason after running "/usr/sbin/sshd -T" it said

"/etc/ssh/sshd_config line 2: Bad SSH2 KexAlgorithms 'sntrup4591761x25519-sha512@tinyssh.org'."

so I played around. It's hard for me to go back on everything I tried but a working solution seemed to be to add the

KexAlgorithms sntrup4591761x25519-sha512@tinyssh.org,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

line to server's "/usr/local/etc/sshd_config" and to client's "/usr/local/etc/ssh_config" under "Host ".

You then need to start the server by running "sudo /usr/local/sbin/sshd" and you need to use the ssh client with the binary "/usr/local/bin/ssh".

My hardened ~/.ssh/config on OS X 10.11:

Host *
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
HostKeyAlgorithms ssh-ed25519,ssh-rsa
ChallengeResponseAuthentication no
UseRoaming no

If you only connect to newer servers you can further restrict ciphers to only use AEADs (only list the chacha20-poly1305 and aes-gcm ciphers). I assume using AEADs-only makes the MACs keyword obsolete, is this correct?

Config is based on tips from https://stribika.github.io/2015/01/04/secure-secure-shell.html

If you configure your SSH server for a limited, secure set of ciphers and HMACs, these automated attacks won't even get to the point of attempting authentication.

https://stribika.github.io/2015/01/04/secure-secure-shell.html

Since following the above guide, my auth log has been filled with nothing but this:

Sep 30 09:46:00 myserver sshd[74033]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com server hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com [preauth]

Of course, I can't use old SSH clients to connect, but it's a good tradeoff, IMO.