Here are some projects to help you roll out new infrastructure without SSH passwords:
https://github.com/gravitational/teleport ( I work on this one with our team) and
https://github.com/Netflix/bless (heard great things about it, especially if you are using AWS)
Here's a nice article about setting up a CA for your OpenSSH servers:
It's better to generate short lived certificates and teleport does exactly that - you can use it with existing OpenSSH infrastructure:
Trusting host keys... I no longer need to check (or ignore and just type yes) when I first connect to a server.. which is literally as bad as on a brand new machine hitting a web browser, going to your online bank and ignoring the certificate warning.
Distributing trust, New employee - I don't need to push public keys out to all servers or rely on centralised auth such as LDAP/AD/Kerberos.
But the real gem is time limited access.. All without touching each server separately.
Ie, I want access to your fleet of servers for 2 hours, on Sunday 18th between 10:00-12:00 UTC. I create a certificate pair with that validity, pass you the public part and you sign it using the CA. Without you needing to touch any of your servers, I now have full access for the window as agreed.
Both GitHub and Launchpad provide a public registry for these:
Unless I'm missing something, anyone with control over your CA can easily sign in as you.
Private key (only you know) -> signed by CA -> public key you share.
You put the public key on the server , the CA can't change that file... And they can't make that particular cert work without a private key that you hold.
Most CA can do is revoke and break the chain on you.
In the browser world.. A a rouge CA, I could generate a certificate pair for https://google.com and your web browser would trust it.
The same is true with this setup... the solution, for this is to be your own CA and add the CA to all of your clients, rather than adding all of your clients to the server. So this reverses the problem, which for many should be easier.
(I honestly can't see anyone using a public CA for this.. it would be nuts)
If the public key is going to be there, then the CA is not doing anything.
Realistically, they're basically equivalent. Do whichever you're more comfortable with.
If I use a password, a suitably designed client can have absolutely no trace of my credential after it has been used.
If I use a key/certificate, that credential must be stored somewhere on the client, and even in encrypted form, it exists in persistent storage.
The fact that a private key file exists suggests that the user is very likely to be using SSH regularly.
The fact that an SSH client exists is far less informational (there's one by default on most Linuxes and Mac OS).
If I only ever use password authentication with SSH and don't save anything else, not even server keys, the attacker has far less information. That might be important in some scenarios, especially related to anonymity.
(I get the feeling I'm missing something here, but...)
Actually, I think you're probably right about the ease of brute-forcing passphrases in practice. That's not to say some random person is going to get access to your SSH key, but if you're actually being targeted as a "person of interest" by a nation-state you're probably SoL unless you're actually practicing due diligence... but then I think that's generally the name of the game, no? I mean OPSEC is still a thing even if you're only doing stuff that's shady-but-definitely-not-illegal.
 This isn't quite a "thing" yet, so some random burglar who steals your laptop isn't going to be attempting brute force.
Sometimes the best way to make something secure, is to make it look like there is actually nothing to secure.
No one needs to bother trying to infer from FDE that I'm hiding something. I will tell them I am if they ask. Financial records, intimate correspondence, and employer trade secrets (I'm authorized to work at home on my personal computer) immediately come to mind and there is probably more.
I'm sure I'm not unusual in this regard. Most people have things they are hiding.
If some rando steals your laptop they probably have no clue what SSH even stands for.
Do you also do things like stop all system logging? Or shell logging? Even with only user-level access, a simple 'history' will show where you're ssh'ing to, regardless of whether you use a keyfile or not.
You may think it's all over at that point, but there's different levels of secrecy, and it'd be better that the attacker cannot even know that a further level exists beyond.
Sounds vague, can you please elaborate or cite? (I am not aware of this and if properly set up, I doubt this is true, so I am excited to learn what you know about this)
If you can't trust your client device, you probably have bigger issues with either method - for instance, can you trust that the client is not logging all keystrokes?
Setting a passphrase on your key file is also actually widely considered a "best practice" and "conventional wisdom" ... so maybe those old guys knew something after all...
If your argument is that your client is untrusted, then typing in your password is a lot more risky than generating a fresh key pair.
If your laptop get stolen, then just remove the corresponding line in your authorized_keys file.
Do you frequently use a computer that you don't control?
But password requirements in this case are definitely higher. You can restrict login attempts in the remote ssh machine, but you can't restrict bruteforcing of stolen encrypted key.
Private keys are like passwords, try not to re-use them.
Don't scare everybody off because it's not a best practice. If his/her server gets pwned they'll fix, learn, and move on.
A password is fine for your fun server. It's not super secure. It you're probably not interesting enough to get pwned using it.
I'm now on a fast enough connection with good enough hardware that if you were able to get into one of my desktops or even just the router I'd be inadvertently sending out a lot of spam or "donating" a lot of bandwidth to a DDoS.
Also, scans of the entire IPv4 internet take less than an hour now, so there's absolutely no security-through-obscurity.
I recommend reading this XKCD comic for how to come up with strong passphrases.
It uses gpg to encrypt each site's username and a random password (using /dev/urandom or CryptGenRandom as the entropy source) in a separate file ~/Documents/Passwords/<domain>.gpg . At the time I first wrote it, I wanted something that was future-proof and where I could decrypt my passwords anywhere, and where a hardware fault while adding a new password was unlikely to cause corruption of pre-existing passwords.
Make your xkcd wordlist (http://google.com/search?q=oxford+3000 is a good start), one line per word, and bzip2 compress it as ~/Documents/Passwords/wordlist.txt.bz2 (or My Documents\Passwords\wordlist.txt.bz2 on Windows) and run the password generator with --alphabet 100 (restricting choices of "alphabets" to those with over 99 characters) and you'll get xkcd-style pass phrases. I also put some numbers in my word list, so I get passwords like
blood Evil pint Urge occupy short railway 38
Diagram elbow Arrest 80 Ceremony monday salt sector
Have a look at my script. It's all of 200 lines. Easy to audit, and I'm not doing any of my own crypto or random number generation.
Nice implementation of xkcd passwords.
Security is not terribly hard, but it is completely and totally unforgiving. If you slip up on security, you will suffer, or others will suffer because of you.
Don't slip up on security.
2. If you do, put Tails on a USB drive and use S/Key one-time passwords to access your hosts. Tails should protect you from most real-time stealing of your passwords, and S/Key should protect you from most hardware keylooggers (by the time the one-time password is exfiltrated, it's useless).
there is no need to send the password to the server to authenticate a password in this day and age. i thought ssh was one of the first protocols to not do this.
On the other side, it could be possible to create sshd implementation which will use its own user database. But it's probably not convenient.
And neither should it.
auth system creates a one time usable "ticket" which is a one way function of the user password and a nonce.
The server gives the nonce to the user, who creates his own ticket based on the nonce and his password, gives his ticket to the server, which then checks if the two tickets match, if they do -> authenticated. -> at no point is the actual user password transmitted.
Kerberos extends this further (allows authentication across multiple servers with a single login)
But as far as I know the ticketing system is standard ssh protocol.
Looking at the spec however:
It appears I am not correct.
might be SSHv2
You could go one step further and have the server store an augmented PAKE authenticator derived from the crypt(3) output.
Which SSH does support, btw.
even at the very lowest level of server recovery (bare metal bios or uefi), crash carts are obsolete. you can cut and paste everywhere now through ethernetworked or emulated serial means.
Password auth discloses your password to the server. Clearly this is unfortunate if you connect to the wrong server, but it also means that a compromised server can intercept the passwords of anyone logging in.
The same extends to anyone using password auth with LDAP. In practice this means that if an organization uses LDAP with passwords for SSH authentication, the ability to execute arbitrary code on one server (combined with a routine privilege escalation) implies complete access to any infrastructure accessible with the same password. Most MFA schemes simply force the attacker to act quickly to utilize an intercepted token on a higher value target. Probably this means trying to find a copy of the private key that the devops team is using to run Ansible without having to MFA to every single server.
For small scale use private keys are a simple way to combat this, but at scale they're difficult to manage, and tend to result in high value static credentials lying around on laptops.
A lot of companies are combatting this using SSH certificates. Certificates can be short-lived (as low as minutes given the right tooling), and the CA that issues them can be heavily audited and linked to an existing identity system.
Netflix has open-sourced BLESS: https://github.com/Netflix/bless
Lyft has adapted BLESS for use without a bastion, start at slide 28: http://www.slideshare.net/aspyker/netflix-open-source-meetup...
Facebook has their own certificate scheme: https://code.facebook.com/posts/365787980419535/scalable-and...
Google has something they don't talk about that seems to be along the same lines.
At ScaleFT we're building a commercial solution that uses very short lived certificates: https://www.scaleft.com/
We're hiring if anyone is interested, my email is in my profile.
Netflix's BLESS project is a neat example of how to build a simple OpenSSH PKI using AWS primitives.
So don't do that. Use kerberos auth with LDAP, and use native kerberos support in apps, don't use kerberos with pam.
Do you know of a good guide for how to set this up on Linux? Or a good book that covers the topic? I've looked into this before and it's seemed to be an absolute jungle. I'd like to explore setting this up at my company but don't know where to start.
I'd be looking for something that's comparably easy to understand and employ as Facebook's recent post about SSH with certificates: https://code.facebook.com/posts/365787980419535/scalable-and...
What's the best straightforward way to set up LDAP, Kerberos, etc from scratch?
You'd need to install and configure a FreeIPA server. They make it easy to setup master-master replication which you'll likely want to do. You'd create a user, add a HOTP secret (from a Yubikey or Authenticator app), and force the use of 2FA. Then once you add a client to the domain you'll have to log in using your password and a HOTP token.
Most of it would be applicable to any modern Linux distro.
(Speaking of someone who setup and maintained Kerberos authenticated webapps, clients and servers for the last 10 years, with Microsoft AD as the ultimate backend).
As an aside AD is fine if you have someone to maintain it, but in the past various changes in AD, Linux and Java have made for interesting times.
In fact it's so easy, that I recommend anyone to use Kerberos even if they don't want to manage the complexity of LDAP. If you use NFS in any meaningful capacity, you have to implement Kerberos, even if you don't have LDAP, otherwise you're implementing a security footgun. Luckily, Kerberos is easy to set up in this configuration, without LDAP.
It's true that LDAP+Kerberos is too hard to deploy and manage, but that's LDAP's fault, not Kerberos'.
What important application doesn't have Kerberos support already? If you talk about adding Kerberos support to your own applications, I have that to be pretty easy.
Or buy into the Hashicorp ecosystem and use Vault + one-time passwords (SSH) and dynamically generated credentials (everything else like database creds).
1. Most people don't bother to verify the host key of the server they are connecting to.
2. An attacker with root on the server can modify or observe sshd in order to get the plaintext password.
I think that's a more interesting question ... presumably most SSH users know not to connect when the server keys mismatch and you get the BIG NASTY WARNING.
However, let's say you connect properly to a host you typically use, but through inattention or confusion you start to enter a password for some other SSH host ... and then hit ctrl-C.
I think I have understood that the remote SSH server actually receives the keystrokes character by character, but does it decrypt that all at once after you hit enter, or is it decrypting the characters one by one ?
The client program asks you for the password, in response to negotiations with the server. The password will be sent as a whole and not as typed, as part of the complete auth packet.
1. https://www.ietf.org/rfc/rfc4252.txt - sections 5, 8
Until that point your password is just in the tty's buffer - so you are save (if your local machine is not owned - but then you are screwed anyway).
Most people use the same username or email address for all sites. It's pretty common to attempt to log in with the wrong password for that site, but one that is valid for other sites with the same credentials. While that password attempt shouldn't be logged, there's no guaranteeing it isn't - perhaps even via rouge admin and unbeknownst to the rest of the company.
The biggest threat here is email addresses as usernames, and attempting to login with the password that's actually used for the email account. Very easy to automate any incorrect (or correct) passwords against the original email account.
Those dang rouge admins (sorry, but I found that typo particularly amusing :-D).
So, is a rouge admin embarrassed? Or is he just so terribly mad at the world that he has turned red?
Personally, I place a lot of faith and trust in Google so I don't think they'd store failed password attempts about me (I've already volunteered them more information about me than I would volunteer to my own elected representatives anyway). If I ever realized I made a mistake the other way round, I'd reset the password to my Google account even though it has 2FA.
It wouldn't surprise me if they're storing failed attempts at all. More data to feed the machines.
$ passwd --status
Password age is kept in /etc/shadow, not /etc/passwd.
So the passwd command is (needs to be) setuid.
Redhat generally limits what setuid programs can do.
On which there are leaderboards for password attempts:
A password that was tried 11633 times, almost as much as 11684 times that 'password' was tried is 'wubao'.
That led me here:
which indicated that this is one of the two first passwords used by sshPsycho when attempting a brute force attack.
According to the poster these two passwords are tried often:
> wubao = 誤報, means something wrongly reported
> jiamima = 加密碼, can mean ‘add password’ or ‘encryption code’
Discussion about the use of kippo to log ssh login attempts:
Kippo is available here:
There is a hacky middleground whereby a ssh client could hash what you think is your password with the server's identity to derive your actual password. But there's the issue of coming up with a canonical identity for a server, and if we merely trust the server to provide it then the scheme fails to a malicious one. Nevermind it would require special setup on the server, and the utility of password auth is for before you've setup public key auth.
But yeah, general point remains that currently, crypt(3) is a black box to login methods. To make any login method not have to handle the actual password, it needs to be some well-defined function that is compatible with such math.
But the best password based authentication scheme will only allow an impostor one guess at the password. For example
That is, as long as you don't ignore the "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" message.
Filippo Valsorda from Cloudflare built a demo of this - try running:
If you want to avoid this you should configure ssh to only send a single specific key.
You can prove that you know a particular secret (your private key) without actually divulging what it is.
This is why you should tell SSH to use specific keys for specific hosts, and fall back to a nonexistent key for unknown hosts.
> The remote host 'ssh.overwathc.org' WANTS TO SEE YOUR PASSWORD, even though current versions of SSH can authenticate without revealing it. You have never connected to this host before -- it could be operated by an attacker. Are you sure you want to show your password to this host (yes/no)?
E.g. your first idea might be "ok, so the client just sends a SHA-256 hash of the password, simple." But... if you do that, then the SHA-256 hash _is_ the password. A rogue server can capture that SHA-256 hash to log in elsewhere.
So you might try and improve that scheme by having the server supply something to hash together with the password. But that means you can't use /etc/passwd anymore, since that
doesn't store the password, it just stores a hash with one particular salt.
Now, to be fair this does mean that you have to give every client the salt for the user they're trying to authenticate as. However IMO a password storage system should still remain secure even after you get the salt for the passwords (you didn't get the hash, so the salt is not useful information to an attacker).
Would that be a viable method, or have I missed something obvious?
But your scheme has made the password hash be the password, which is unacceptable because it's equivalent to storing the plaintext password on the server.
Illustration. Here's /etc/shadow
f(nonce + hash)
(FWIW, I initially thought your scheme worked, but couldn't believe a solution had been overlooked and so I tried it with a concrete example and only then realised where the problem lay. )
Pretty hard to get better security.
Might be somewhat far stretched but it is definitely something one should be aware of.
Of course, if you've got a bunch of computers, you can just configure SSH to use Kerberos auth. The capability is there, IIRC, and not through PAM either.
Except a small percentage of servers that are malicious.
Security people are so pie in the sky sometimes.
This is true for any remote system that you're authenticating to with a password that must be verified on the server side, and isn't specific to ssh's password auth.