SSH: Best practices
blog.0xbadc0de.be
SSH: Best practices
1–10 of 123 posts
Re: SSH: Best practices
#2Re: SSH: Best practices
#3I bookmarked something similar:
https://stribika.github.io/2015/01/04/secure-secure-shell.ht...
Re: SSH: Best practices
#4Cached version https://webcache.googleusercontent.com/search?q=cache:BZ3Zeq...
yeah - the link seems to be hugged to death or something
Re: SSH: Best practices
#5I thought using per-service SSH keys was an useful mitigation against e.g. GitHub public keys being exposed:
- https://blog.benjojo.co.uk/post/auditing-github-users-keys
- http://arstechnica.com/security/2015/06/assume-your-github-a...
Re: SSH: Best practices
#6I thought using per-service SSH keys was an useful mitigation against e.g. GitHub public keys being exposed: - https://blog.benjojo.co.uk/post/auditing-github-users-keys - http://arstechnica.com/security/2015/06/assume-your-github-a... - https://news.ycombinator.com/item?id=9645703
Public keys being exposed isn't something I think needs to be mitigated. That's the whole point, they're public.
Re: SSH: Best practices
#7I thought using per-service SSH keys was an useful mitigation against e.g. GitHub public keys being exposed: - https://blog.benjojo.co.uk/post/auditing-github-users-keys - http://arstechnica.com/security/2015/06/assume-your-github-a... - https://news.ycombinator.com/item?id=9645703
Public keys being exposed isn't something I think needs to be mitigated. That's the whole point, they're public.
Security is not binary. In this case it depends on whether disclosing your identity to the servers you connect to is a problem in your threat model.
Saying "they are public so it's ok" is technical oversimplification.
Re: SSH: Best practices
#8The article didn't make mention multiplexing and MaxSessions defaults in OpenSSH. The default is 10 which means you auth once, and all subsequent logins are without auth and without syslog entries. If you manage secure systems and have 2FA, this allows bypassing 2FA and logging.
All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will drop a key on your machine, fire up ssh using that key and tunnel back to my host. Now I have full control of your secure (banking, government, eCommerce) environment, completely bypassing 2 factor authentication. Just one link to one of your email distros and up to 10% of your folks will run it.
Combine this with sudo credential caching and now I have root on all of your systems without having to bother finding vulns.
Thx to Prandium for the demo of this simple social engineering exploit.
Re: SSH: Best practices
#9Still a big fan of the BetterCrypto guide: https://bettercrypto.org/
Re: SSH: Best practices
#10SSH's new AuthenticationMethods directive is extremely useful for pairing SSH keys with a password and/or 2FA. You should absolutely use keys everywhere, and encourage your users to encrypt their keys, but enforcing a password as well ensures that logins are "something you have" (the SSH key) and "something you know" (the password) as a sort of 2FA.
As a cherry on top you can put the password in LDAP or RADIUS server and hook up traditional 2FA (Google Auth, Yubikey, Email, SMS) for that legendary 3FA (ah... "something (else) you have"). Sounds hokey, but defense is best in depth.