
Is your SSH password revealed when you attempt to connect to the wrong server? - based2
http://unix.stackexchange.com/questions/309938/is-your-ssh-password-revealed-when-you-attempt-to-connect-to-the-wrong-server
======
alexk
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](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
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.

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

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

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

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

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

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

~~~
galdosdi
> 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)

------
russell_h
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](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...](http://www.slideshare.net/aspyker/netflix-open-source-meetup-
season-4-episode-3)

Facebook has their own certificate scheme:
[https://code.facebook.com/posts/365787980419535/scalable-
and...](https://code.facebook.com/posts/365787980419535/scalable-and-secure-
access-with-ssh/)

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
> 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
> 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...](https://code.facebook.com/posts/365787980419535/scalable-and-secure-
access-with-ssh/)

What's the best straightforward way to set up LDAP, Kerberos, etc from
scratch?

~~~
etcet
I recommend FreeIPA. You can find thorough documentation here:
[https://access.redhat.com/documentation/en-
US/Red_Hat_Enterp...](https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/introduction.html)

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.

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

~~~
GrinningFool
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](https://www.ietf.org/rfc/rfc4252.txt)
\- sections 5, 8

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

~~~
nocman
"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
And further more, are the rouge admins connected to the rouge angles of satin?
Are these rouge admins satinic?

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

~~~
ilikebits
You've just described phishing.

~~~
markcerqueira
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?

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

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

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

    
    
      $ passwd --status

~~~
emmelaich
Only root can do that.

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

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

------
watermoose
One 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-
wub...](https://ewedaa.wordpress.com/2015/07/02/what-the-heck-is-wubao-and-
jiamima-in-ssh-brute-force-attacks/)

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)

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

~~~
nroets
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](https://en.wikipedia.org/wiki/Socialist_millionaires)

~~~
wfunction
I think it stands for "zero knowledge" proof?

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

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

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

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

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

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

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

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

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

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

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

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

~~~
cyphar
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?

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

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

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

Pretty hard to get better security.

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

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

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

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

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

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

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

------
aaron695
Correct answer is no, absolutly not.

Except a small percentage of servers that are malicious.

Security people are so pie in the sky sometimes.

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

