14 ms·
Is your SSH password revealed when you attempt to connect to the wrong server?
- Hondor 10y agoI'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.
- ilikebits 10y agoYou've just described phishing.
- markcerqueira 10y agoWouldn'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?
- newjersey 10y agoIt 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.
- leesalminen 10y agoHave 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.
- deleted 10y ago[deleted]
- jlgaddis 10y agoEvery Linux machine knows when you last changed your password, too. $ passwd --status
- emmelaich 10y agoOnly root can do that.
- Dylan16807 10y agoI'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.
- emmelaich 10y agoThat 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.
- nadaviv 10y agoObligatory xkcd: https://xkcd.com/792/ https://xkcd.com/792/
- alexk 10y agoI 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 https://github.com/gravitational/teleport ( I work on this one with our team) and https://github.com/Netflix/bless https://github.com/Netflix/bless (heard great things about it, especially if you are using AWS)
- userbinator 10y agoI 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.
- deleted 10y ago[deleted]
- eli 10y agoIf someone is able to steal my private key file, then they have probably compromised my computer and could just as well install a keylogger.
- userbinator 10y agoConsider 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.
- 10y ago
- bluedino 10y agoWhat about if you sign into one with key based authentication? Does that server now know your key?
- deleted 10y ago[deleted]
- karlshea 10y agoYour public key, yes, but that shouldn't be an issue.
- Tharkun 10y agoI 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.
- arkadiyt 10y agoYes, 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.
- colemickens 10y agoI 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.
- GlennS 10y ago
- mindslight 10y agoYes. 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.
- wiml 10y agoYou 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.
- mindslight 10y agoDoh. 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.
- nroets 10y agoI'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 https://en.wikipedia.org/wiki/Socialist_millionaires
- wfunction 10y agoI think it stands for "zero knowledge" proof?
- deleted 10y ago
- acchow 10y agoThis 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.
- hackcasual 10y agoSSH predates PAKE as a widely accepted practice
- vilhelm_s 10y agoIt 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)?
- tedunangst 10y agoReally easy...
- Johnny_Brahms 10y agoI 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.
- GrinningFool 10y agoPrior 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.
- russell_h 10y agoSSH 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 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-season-4-episode-3 http://www.slideshare.net/aspyker/netflix-open-source-meetup... Facebook has their own certificate scheme: https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-with-ssh/ 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/ https://www.scaleft.com/ We're hiring if anyone is interested, my email is in my profile.
- 4ad 10y ago> 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.
- Pyxl101 10y ago> 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-secure-access-with-ssh/ https://code.facebook.com/posts/365787980419535/scalable-and... What's the best straightforward way to set up LDAP, Kerberos, etc from scratch?
- dendory 10y agoPrivate key stored in a passworded file on an encrypted disk, plus a key fob as second factor. Pretty hard to get better security.
- stuxnet79 10y agoIt 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 ...
- mercora 10y agoi 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.
- dotBen 10y agoWhile 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.
- nocman 10y ago"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?
- qwertyuiop924 10y agoAnd further more, are the rouge admins connected to the rouge angles of satin? Are these rouge admins satinic?
- alienth 10y agoThankfully, 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.
- h4nkoslo 10y agoIt's possible to set up multi-factor auth in SSH - I use both SSH keyfile & password to log into my home server.
- andersonmvd 10y agoReally 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'.
- vbernat 10y agoThere 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.
- andersonmvd 10y agoIndeed, 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.
- bengalister 10y agoThere'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.
- aaron695 10y agoCorrect answer is no, absolutly not. Except a small percentage of servers that are malicious. Security people are so pie in the sky sometimes.
- oneloop 10y agoThat is the wrong answer. The correct answer is Yes.
- GrinningFool 10y agoCorrect 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.
- rsync 10y agoWhat 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 ?
- protomikron 10y agoPlease 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).
- takeda 10y agoThe 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.
- GrinningFool 10y agoCharacter 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 https://www.ietf.org/rfc/rfc4252.txt - sections 5, 8
- xurukefi 10y agoWhy 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?
- matthiasl 10y agoTry 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.
- cyphar 10y agoJust 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?
- matthiasl 10y agoYour 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. )
- watermoose 10y agoOne of the answers mentioned: https://livesshattack.net/ https://livesshattack.net/ On which there are leaderboards for password attempts: https://livesshattack.net/leaderboards 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-wubao-and-jiamima-in-ssh-brute-force-attacks/ 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 http://www.cubieforums.com/index.php?topic=3739.0 Kippo is available here: https://github.com/desaster/kippo https://github.com/desaster/kippo
- qwertyuiop924 10y agoI 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.
- linsomniac 10y agoOf 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? :-)
- nullc 10y agoYes, because for some inexplicable reason almost no one has adopted zero-knowledge password agreement protocols (like SRP).