Is your SSH password revealed when you attempt to connect to the wrong server? | Hacker News Reader

Is your SSH password revealed when you attempt to connect to the wrong server?

unix.stackexchange.com

330 pointsbased2164 comments

I highly recommend to move off password-based SSH at all in favor of SSH keys or (even better, certificates).

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)

I find this common "wisdom" or "best practice" questionable. Something to think about:

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.

If someone is able to steal my private key file, then they have probably compromised my computer and could just as well install a keylogger.

Consider the scenario in which your computer is stolen (and might not ever be returned, so whether the attacker installs a keylogger is irrelevant):

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.

If your computer is stolen and you don't have full disk encryption, a leaked private key is probably far from the only problem.

alexk already addressed your concern: your keys, preferably issued by your org's CA (instead of being generated by you) should be short-lived, oftentimes for the duration of your "work shift". The tools listed above support this.

You are aware it's usually recommended to have passphrases for keys, yes? Plus, you really should have whole-disk encryption for laptops.

(I get the feeling I'm missing something here, but...)

Regardless of whether the keyfile has a passphrase, the point is that it exists. And FDE also suggests you may be hiding something.

Sometimes the best way to make something secure, is to make it look like there is actually nothing to secure.

> And FDE also suggests you may be hiding something.

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 anyone's targeting your specific laptop for theft they already think that you're hiding something.

If some rando steals your laptop they probably have no clue what SSH even stands for.

Security-by-obscurity only works alongside other layers.

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.

Not these days. FDE is so common and easy to use now, it might well have been an option you blindly hit upon install. And that's just in consumer environments. In corporate environments, in any company with a half-decent infosec department, all employees' computers will simply be required to have FDE, regardless of what they do on the computers.

FDE is also apparently not entirely impossible to bypass, which leaves you in the same situation of an attacker knowing that those SSH keyfiles exist on your machine.

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.

> FDE is also apparently not entirely impossible to bypass

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)

Passphrases on SSH keys used to be really easy to brute-force by default and I think they still are. Until two or three years ago the only way to slow down brute-forcing attacks was to use a complicated incantation with openssl to convert the keys to use a slower key derivation. Few people did.

Well, except I'm using "Correct Horse...". Oh. Well, I'm actually using a similar scheme to that, but I don't want to give too much away :).

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[1], 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.

[1] This isn't quite a "thing" yet, so some random burglar who steals your laptop isn't going to be attempting brute force.

Yes, what you're missing is that userbinator is probably trolling us

What about your known_hosts? Do you delete that every connection?

HashKnownHosts?

Still establishes that SSH was being used, which seems to be userbinator's concern.

And of course if you do, that is weakening you against other kinds of attacks.

You're essentially arguing for SSH security to be reduced to the "something you know" prong of multifactor authentication.

Which can (and should) be stored in a way that requires a password to access (ssh supports this, as do most other certificate systems).

That's why short lived certs are better then just private keys - even if the key is stolen, the system can cut off the access by not issuing the renewed certificate. This makes private key itself to be irrelevant, in fact it can be generated as well once a day for example.

This objection is weak. Generate a unique key pair on the client. De-authorize it when you're done or just delete it.

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.

Well you can always keep your keys in a removable drive rather than on persistent storage in your client device.

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?

Which is why you generate your private key with a passphrase (which is used exclusively client side in an ssh client) and only store it on HDD, flash or SSD that uses full disk encryption.

smart cards cost like $15

i am somewhat scared to use smart cards because they might break at some point and i am loosing access... if i would use some kind of local ca to provision the keys i could just as well use them directly... so i would need some kind of secured (air gaped and what not) device to provision them. which will be unavailable when i am abroad... all in all it seems to me it doesn't solve more problems than it makes...

The CA or smart card software is only needed for provisioning smart cards for clients, and is likely to be of little concern for setting up a new server. The card itself stores a non-phishable credential which you can physically secure.

Your private key should remain password protected, I don't think anyone here is recommending a passwordless login. Also usually with ssh you are more worried about the remote server being compromised than your local client machine.

If someone has remote access to your computer then either way you are screwed. Using password or key file won't change anything.

If your laptop get stolen, then just remove the corresponding line in your authorized_keys file.

If the key is encrypted, then it doesn't exist as long as the password is good enough to resist a bruteforce.

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.

You can also use bcrypt and adjust the work factor; assuming use of ssh-agent and/or shared connections, you could add a delay of multiple minutes to each try.

I think this "wisdom" or "best practice" is targeted at the overwhelming amount of the population that are concerned with using SSH on a computer they control and are therefore not concerned with leaving footprints behind.

Do you frequently use a computer that you don't control?

You must not be aware that you can set a password (which ssh-keygen calls a passphrase) on your private key file. The private key file will be encrypted and without the password will be useless, if your password is strong. Then you get the best of both.

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

I'm perfectly aware that you can and almost always should encrypt the keyfile; the point I'm trying to make is that you still need a keyfile and the existence of that file can itself be a concern in some situations even it it can't be immediately used by an attacker.

Why?

This would mean I'd have to either remember to carry around a flash drive to access my server from the computers at the college library, or keep a copy of my private key on my networking drive there, a network I don't have any reason to believe is perfectly secure.

Protect it with a strong passphrase.

https://www.xkcd.com/936/

I recommend reading this XKCD comic for how to come up with strong passphrases.

https://pypi.python.org/pypi/xkcdpass/1.8.2

Nice implementation of xkcd passwords.

Or.. you can use the web with this one!

https://xkpasswd.net/

Bright idea! Using someone elses Computer To generate your password!

It's easier to use for the lay person than a from-source-compilation you execute as a command line binary.

Yes, it's easier, but it's completely and totally insecure.

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.

I recently put up on github the latest incarnation of a password generator I've been using for over a decade now.[1]

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

It defaults to making the password/pass phrase length ceil(96 * log(2) / log(len(alphabet))) (96 bits of entropy). If you want to dial that up to 128 bits (or down to 80 bits), put { "bits" : 128 } in ~/Documents/Passwords/config.json (My Documents/Passwords/config.json on windows).

[1]https://github.com/kmag/store_password_gpg

Look at diceware for another great system to generate passwords.

Yes, I started out with a script that used the diceware wordlist to generate passwords and manually used gpg to store my passwords, then evolved my script to combine the two steps I was doing manually.

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.

And set the encryption to use pkcs8 with a million iterations.

In either case generate different private keys to use there, so you can revoke the ones used from those computers easily without revoking your more tightly controlled keys.

Private keys are like passwords, try not to re-use them.

This can be quite inconvenient, that's why there's a way to make it more user friendly by using 2FA authentication or Google based SSO with your SSH:

http://gravitational.com/teleport/docs/admin-guide/#openid-o...

I wouldn't use untrusted computers to access my servers.

This. If you're typing in your password on a library computer, you're very vulnerable.

My first server was totally exposed in the DMZ. I ran windows RDP with the password "supersecret" for a long time also. I remember at one point also realizing that I could login to ftp anonymously. It was horrendous security in those early days and I had no idea what the heck I was doing.

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.

The problem is insecure PCs and servers are a net negative for the Internet as a whole.

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.

This is wrong. Compromised servers often become part of bot nets that cause real damage.

Heck, even compromised wireless routers[1] and CCTV systems[2] become part of botnets. Anything that's known to be insecure will be exploited.

[1]: http://krebsonsecurity.com/2015/01/lizard-stresser-runs-on-h...

[2]: https://blog.sucuri.net/2016/06/large-cctv-botnet-leveraged-...

Any server is interesting enough to get pwned to join in on DDoS botnets. I've seen it happen to so many cheap personal VPSes.

I keep it on my phone.

If you want to be paranoid, I wouldn't type sensitive info into those machines (for any number of reasons)

You can also store the key file on your phone and copy it to whatever computer you want to login to, carrying a phone is easier then an extra flash drive

1. Don't use untrusted hosts to access trusted hosts.

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

If you're accessing computers you care about from a computer you don't control, you don't really care about them. It's already game over: sufficiently-advanced software could easily permit you to log in, then execute any sequence of commands leading to the downfall of your servers.

Is it better to use certificates or keys? If certificates, how do you set those up? I have SSH keys setup right now.

Certificates are better - you don't need to worry about distributing your public keys everywhere.

Here's a nice article about setting up a CA for your OpenSSH servers:

https://www.digitalocean.com/community/tutorials/how-to-crea...

It's better to generate short lived certificates and teleport does exactly that - you can use it with existing OpenSSH infrastructure:

http://gravitational.com/teleport/docs/admin-guide/#using-te...

keys are better, even though you need to distribute them, nobody else has them...

Err, letting the world have your public keys is perfectly normal.

Both GitHub and Launchpad provide a public registry for these:

  - https://github.com/USERNAMEE.keys
  - https://launchpad.net/~USERNAME/+sshkeys

For example, mine are:

  - https://github.com/Daviey.keys
  - https://launchpad.net/~davewalker/+sshkeys

Feel free to add them to your servers. :)

If you use someone else's CA, wouldn't they have your private keys?

No, The CA only signs the public key, the private key never leaves your machine.

But can't they sign some other key pair, representing you?

No, they can't represent you, because they don't have your private key.

The server doesn't care what private key you use. If it's signed by the CA, the server trusts it.

Unless I'm missing something, anyone with control over your CA can easily sign in as you.

This is only true if you don't trust the machine you are connecting to.

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.

Uhm. No... he's right.

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)

You might be surprised to see the nut things people would do for convenience... but in this case you are probably right as the average computer user probably don't use SSH.

The whole point of using a CA is to not put every public key on every server.

If the public key is going to be there, then the CA is not doing anything.

So this is awesome for 3 main reasons..

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.

Certificates are more convenient than keys, but strictly speaking somewhat less secure than keys, because more mechanism is required to verify them.

Realistically, they're basically equivalent. Do whichever you're more comfortable with.

As a cloud support engineer, if you break your networking, I don't want to type a 256-character SSH key into the console to recover your server. Please use certificate-based VPNs and use internal addresses to keep connections within your own networks.

there is absolutely no reason you would need to type an ssh key by hand.

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.

It'll take at least another decade to get rid of all equipment without IPMI or alternatives. No, I'm not kidding.

you're not getting what i'm saying. it doesn't matter how old the gear you're working on is. if you're typing in long strings by hand, you're not thinking hard enough about how to do your job.

Or you have to deal with real world constraints, which can - and do - involve having equipment where e.g. attaching external KVMs etc. is not always an option that is made available to you (cost constraints; space constraints).

Please tell me how to paste into a VMWare VM console. To my knowledge, this is not possible.

vmware is a commercial product, ask the vendor.

What about for a home network with a laptop, desktops and many VMs? I'd like to have a better setup than manually scp'ing files around, but these systems seem like overkill. Is there a middle ground?

Why'd keys be an overkill? It's just two files which need to be put at proper places.

wow. im not sure i believe this...

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.

What system are you thinking of? Which works with existing crypt(3) based system used on Unix?

If you are willing to tell anyone who connects your salt, you could, in principle, run a balanced PAKE using the crypt output.

You could go one step further and have the server store an augmented PAKE authenticator derived from the crypt(3) output.

Here's half an answer: Kerberos.

Which SSH does support, btw.

The problem is, ssh daemon doesn't know anything about user password. It uses existing libraries to supply login and password in clear form (like Linux PAM) and they check if it's valid. How this check is done, is abstracted too: it could be /etc/shadow file lookup, it could be LDAP request or really anything.

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.

The ssh auth protocol is extensible, the client and server negotiate which methods they support, so it is possible to implement new methods.

->ssh daemon doesn't know anything about user password

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: https://tools.ietf.org/html/rfc4252#page-10

It appears I am not correct.

might be SSHv2

SSH is like a candy store for advanced attackers.

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.

Quick plug:

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.

> The same extends to anyone using password auth with LDAP.

So don't do that. Use kerberos auth with LDAP, and use native kerberos support in apps, don't use kerberos with pam.

> Use kerberos auth with LDAP

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 might look into FreeIPA [0].

[0]: https://www.freeipa.org/page/Main_Page

I recommend FreeIPA. You can find thorough documentation here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

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.

There is no easy route to learning and using kerberos. That said, you could start with say the Redhat admin guides.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

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.

> So don't do that. Use kerberos auth with LDAP, and use native kerberos support in apps, don't use kerberos with pam.

Or buy into the Hashicorp ecosystem and use Vault + one-time passwords (SSH) and dynamically generated credentials (everything else like database creds).

Yeah, that sounds like a lot of fun for a masochist. As if LDAP isn't a big enough pain in the arse to set up, Kerberos is even worse. Not to mention how much of a pain it is to integrate it in an application.

What's so hard about Kerberos? Kerberos is orders of magnitude easier to deploy and manage than LDAP. It takes literally minutes (if you have done it before and know what you are doing).

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.

The difficulty of managing ssh keys can be partially mitigated by establishing a PKI and handing out certificates to everyone, then deriving an ssh key from those. OpenSSH supports using a crl, so if you have a trusted infrastructure management of that should be fairly straightforward.

OpenSSH actually has native support for using certificates (in a custom format, not X.509), so if you're building out PKI with SSH in mind it's probably worth going that route.

See: https://www.digitalocean.com/community/tutorials/how-to-crea...

Netflix's BLESS project is a neat example of how to build a simple OpenSSH PKI using AWS primitives.

what about PKI + password auth? user auth should be encrypted using server's public key

If I understand you correctly, that's basically how SSH already works. The problems are:

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.

What about the password you have entered before you press "enter" ?

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 ?

Please correct me if I am wrong, but I would say you do not have to worry if you do not hit "Enter". In fact, I would say, that even the application, i.e. ssh doing the read(), does not see it, as sending CTRL-C (SIGINT) will destroy the process (ssh waiting for read() to return).

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

The TTY is opened after you log in. When you are entering password, the characters are collected by the client and are sent after you press enter.

Character by character occurs only after a secure channel is established.

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]

1. https://www.ietf.org/rfc/rfc4252.txt - sections 5, 8

While this question is aimed at SSH, be careful about a similar vector happening on more standard http username/email and password logins at any website.

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.

"perhaps even via rouge admin"

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?

And further more, are the rouge admins connected to the rouge angles of satin? Are these rouge admins satinic?

I've often wondered if this is a vulnerability in all kinds of services. Try to log in to some website with the wrong password and you're probably giving them your Facebook password by accident.

You've just described phishing.

Wouldn't phishing be more like "make a site that looks like Facebook and try to get people to input their Facebook passwords?" What this person described is more abusing password recycling no?

It doesn't even have to be recycling. In fact, I have incorrectly pasted a wrong password to my Google account not realizing I had copied from one row underneath.

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.

Have you ever noticed that if you enter a password previously used on a Google account it will tell you "password changed X units of time ago"? That surprised me.

It wouldn't surprise me if they're storing failed attempts at all. More data to feed the machines.

Every Linux machine knows when you last changed your password, too.

  $ passwd --status

Only root can do that.

I'm not sure why that would matter, but that's not true. No sudo needed to look up that I set my password on this VM on 2013-10-08.

That was a direct copy'n'paste from a session on centos7.

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.

Probably sensible.

Obligatory xkcd: https://xkcd.com/792/

One of the answers mentioned: https://livesshattack.net/

On which there are leaderboards for password attempts: https://livesshattack.net/leaderboards

A password that was tried 11633 times, almost as much as 11684 times that 'password' was tried is 'wubao'.

That led me here: https://ewedaa.wordpress.com/2015/07/02/what-the-heck-is-wub...

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: http://www.cubieforums.com/index.php?topic=3739.0

Kippo is available here: https://github.com/desaster/kippo

Yes. To fix this generally, we'd have to stop hashing passwords for storage so we could use a ZK proof to verify.

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.

You can hash the password in a way that allows the server to verify but without providing the server or an interceptor with the ability to impersonate. SRP/PAKE and SCRAM are examples.

Doh. It felt like there should be a more complex method replacing the hash with an asymmetric op, but I knew it would be hard to casually describe. In retrospect, obviously the "zero knowledge" bit must imply the server does not know the password!

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.

I'm not sure what you mean by ZK proof.

But the best password based authentication scheme will only allow an impostor one guess at the password. For example https://en.wikipedia.org/wiki/Socialist_millionaires

I think it stands for "zero knowledge" proof?

Thankfully, if someone is MITM'ing you, or has acquired the IP of your host, then the SSH fingerprint check against your known_hosts will prevent them from snagging your password in this manner. (provided the host's private key hasn't also been stolen)

That is, as long as you don't ignore the "IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!" message.

What about if you sign into one with key based authentication? Does that server now know your key?

Your public key, yes, but that shouldn't be an issue.

I wish people would stop saying thay. It is an issue. Maybe not for you, but for a lot of people. It allows any server you connect to to enumerate all of your public keys and identities. If you use nasty leaky services like Github then at least one of your public keys can be used to identify you. This is bad and stupid.

This is why you should tell SSH to use specific keys for specific hosts, and fall back to a nonexistent key for unknown hosts.

Yes, the server knows your public key. In fact, unless you have specified which public key to use (via command line option or ~/.ssh/config), the server receives all your public keys. This is identifying information - most people have at least 1 ssh public key in github, and github makes those completely public as well.

Filippo Valsorda from Cloudflare built a demo of this - try running:

  ssh whoami.filippo.io

and if you have any of your keys in github, it will identify you.

If you want to avoid this you should configure ssh to only send a single specific key.

I don't know why, but it has never, ever gotten me. I guess maybe they're a point in time snapshot and all my keys have rolled since then.

This is the clever thing about asymmetric encryption.

You can prove that you know a particular secret (your private key) without actually divulging what it is.

Really surprised that a simple and perhaps intuitive question got 131 points. You can just reframe it to "if I send my password to the wrong website, will it be able to read it?" and answer is still yes. Maybe it's 'of course'.

There is a lot of password-based authentication schemes that enables to not share the password with the remote end. You can send a hash. Or you can answer a challenge.

Indeed, you're correct. Although the server always got something. And if it was a hashed password, well, works as if the password wasn't hashed UNLESS the hash changes AFTER some challenge prior the authentication attempt.

This seems like an odd vulnerability. I use SSH keys instead, but I always imagined that if I used a password instead then my password would be used (on both the server and the client) to help derive private keys. If I have the wrong password, the encrypted messages we send to each other would just be garbled nonsense.

SSH predates PAKE as a widely accepted practice

It seems like it should be really easy to fix too: add a proper authentication protocol, with protocol negotiation, and then in subsequent versions of SSH, make the warning messages more and more scary. Something like

> 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)?

Really easy...

I think that would be "really easy" only if password hashing was done the same over all platforms SSH runs on. I wouldn't want to be the one to bolt on something like SRP on an already existing login system that uses subtly different "third party" mechanisms for authentification.

Prior to any authentication, a private session key is negotiated and used for encryption for the life of the session. The password (or proof of key ownership, or cert) used for auth is only used for auth, and is only sent after DH key negotiation is complete.

The server doesn’t have your password (just its hash), so it can’t derive a key from it.

Why isn't the password hashed before it is sent to the server? Is it because the client cannot know how the passwords are hashed on the server side? If so, couldn't the password hashing method be sent to the client?

Try designing a specific means to do this and you'll find that it's not easy.

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.

Just thinking out loud, but what happens if the SSH server provides two salts. One is the /etc/shadow salt (including the hash type and so on) and the other is a one-time nonce salt to avoid replay attacks. So the client will first generate a crypt(3)-style string (which is equal to the one that the server has stored in /etc/shadow) and then will hash it with the connection-unique nonce to produce a hash that the server can then verify.

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?

Your scheme successfully avoids revealing the password to a rogue server, so it solves the immediate problem.

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

    cyphar:salt:hash

With your scheme, an attacker is allowed to log in by providing

    f(nonce + hash)

so that's a red flag: the attacker doesn't need to know the password, just the hash. Looking at it another way, you've made the hash be the password.

(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. )

Yeah, I see what you mean. And this would presumably allow someone who has read access to /etc/shadow to be able to log into the server with ssh (something they couldn't do with `sudo` without cracking the password first).

Private key stored in a passworded file on an encrypted disk, plus a key fob as second factor.

Pretty hard to get better security.

There's a challenge response authentication scheme. The authentication method can be enforced on the client but not sure if you can exclude completely password based authentication and enforce certifcate or challenge response authentication, servers need to be configured accordingly.

It is frightening that I never realized this up until now. I always thought that this information was not exposed during the authentication process. But I can't see how it can be an issue unless you are intentionally trying to connect to a place that you are not supposed to ...

i think one way could be if you have a coworker or someone who is able to get root on the machine you are trying to log into. if you have the same password on your own machines sshd he might even easily get back to it and read credentials stored in your browser or use your credentials to damage some part of the comapny in your name etc...

Might be somewhat far stretched but it is definitely something one should be aware of.

I wonder of we can get SSH to bcrypt/scrypt the password clientside.

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.

Of course not! Because you have password authentication disabled and never type your login password in to SSH, right? You use ssh keys and ssh-agent, right? :-)

Yes, because for some inexplicable reason almost no one has adopted zero-knowledge password agreement protocols (like SRP).

It's possible to set up multi-factor auth in SSH - I use both SSH keyfile & password to log into my home server.

Correct answer is no, absolutly not.

Except a small percentage of servers that are malicious.

Security people are so pie in the sky sometimes.

That is the wrong answer. The correct answer is Yes.

Correct answer is actually yes. And it's no different than logging in to the wrong web site. You're trusting that the server you incorrectly connected to is not capturing your failed credentials - which it absolutely does see if you're using password auth - with malicious intent.

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.

Reply on news.ycombinator.com