142

I've just tried logging into a Fedora (release 13 Goddard) server using SSH (PuTTY, Windows). For some reason the Enter after typing my username didn't go through and I typed in my password and hit Enter again. I only realized my mistake when the server greeted me with a happy

myusername MYPASSWORD@server.example.com's password:

I broke off the connection at this point and changed my password on that machine (through a separate SSH connection).

... now my question is: Is such a failed login stored in plain text in any logfile? In other words, have I just forced my (now-outdated) password in front of the eyes of the remote admin the next time he scans his logs?

Update

Thanks for all the comments about the implied question "what to do to prevent this in the future". For quick, one-off connections I'll use this PuTTY feature now:

enter image description here

to replace the where-was-it-again "auto-login username" option

enter image description here

I'll also start using ssh keys more often, as explained in the PuTTY docs.

Jonas Heidelberg
  • 1,184
  • 1
  • 7
  • 14
  • 4
    This is a really good question. I think we've all accidentally typed UsernamePassword into some sort of service at some point in time. It's far too easy to do. – user606723 Oct 19 '11 at 13:58
  • 2
    Yet another good reason to change the password with reasonable regularity. – Jonas Oct 19 '11 at 14:14
  • 26
    You can avoid this by telling your ssh client to connect to username@server.example.com. Then you'll only be prompted for the password, making an accident like this impossible. Even better, though, would be to just use public/private keys. – Kevin Oct 19 '11 at 15:29
  • 1
    @Iceman thanks for that hint - since I knew PuTTY hides the username under `Connection/Data/Login details/Auto-login username` it never occurred to me that the "Host name (or IP address)" field could also accept username@hostname like a proper command line ssh client. – Jonas Heidelberg Oct 19 '11 at 15:36
  • 4
    Use key-based authentication. – Zoredache Oct 19 '11 at 19:22
  • @Zoredache: Also true, if you use a client-host combination often... – Jonas Heidelberg Oct 19 '11 at 19:27
  • @JonasHeidelberg who doesnt ;D. I was going to sy what Zore said –  Oct 20 '11 at 08:38

4 Answers4

149

In short: yes.

# ssh 192.168.1.1 -l "myuser mypassword"
^C
# egrep "mypassword" /var/log/auth.log
Oct 19 14:33:58 host sshd[19787]: Invalid user myuser mypassword from 192.168.111.78
Oct 19 14:33:58 host sshd[19787]: Failed none for invalid user myuser mypassword from 192.168.111.78 port 53030 ssh2
the-wabbit
  • 40,319
  • 13
  • 105
  • 169
21

If i remember well, it is indeed registered in log if the log level is set to DEBUG or TRACE.

EDIT : It is confirmed, i tried to log into my server and found this in my logs. 

Oct 19 14:34:24 sd-xxxx sshd[26563]: pam_unix(sshd:auth): authentication failure; logname=     uid=0 euid=0 tty=ssh ruser= rhost=xxx-xxx-xxx-xxx.rev.numericable.fr 
Oct 19 14:34:26 sd-xxxx sshd[26563]: Failed password for invalid user toto from xxx.xxx.xxx.xxx port 56685 ssh2

Note : IP's are hidden

Zenklys
  • 533
  • 2
  • 5
  • 14
10

Or for both additional safety and convenience, you should really consider setting up SSH keys...

# ssh-keyget -t rsa
(accept all defaults)

and you get...

~/.ssh/id_rsa
~/.ssh/id_rsa.pub

Side-Note: you can rename your key files if you add ~/.ssh/config with something like the following contents:

# cat ~/.ssh/config
Host *
IdentityFile ~/.ssh/ddopson_employer_id_rsa

Cat the contents of your public key (will be a single line):

# cat ~/.ssh/id_dsa.pub
ssh-rsa AAAAB3NzaC1kc3MAAACBAOOVBqYHAMQ8J ... BbCGGaeBpcqlALYvA== ddopson@hostname

Now log into the target box and paste that line into ~/.ssh/authorized_keys.

Side-Note: the pubkey line ends in a human readable string like "ddopson@hostname". You can change this to be more descriptive of the key you are using (eg, if you have lots of keys). That string is NOT used as a part of authentication, and is only to describe the key to other human beings.

That's it. Now when you ssh to the host, you won't even be prompted for a password.

If you are worried about storing your private key (id_rsa), you can add a passphrase to the key itself (see ssh-keygen), protecting it from use by anyone who has access to your files. You can then use ssh-agent to decrypt the key and securely store it in memory so it can be used for multiple SSH connections.

Carey
  • 133
  • 6
Dave Dopson
  • 241
  • 1
  • 4
  • I should have probably added a `windows-clients` tag to my question. [This howto](http://linux-sxs.org/networking/openssh.putty.html) explains how to make ssh keys usable with PuTTY. – Jonas Heidelberg Oct 20 '11 at 09:54
  • you can do the exact same thing with PuTTY. You can add keys into PuTTY, or use PuTTYgen to generate the keys. Same story, different commands. (I think it's in the authentication tab of the connection params). – Dave Dopson Oct 21 '11 at 01:14
0

The password was encrypted when transmitted. Yes, it's possible that your password was compromised because it was printed in the log on the destination server. However, I would also say that every time you enter your password on your computer it may be compromised since there may be spyware software on your computer or a keylogger attached to your computer.

If you are the only administrator of that system and you believe that that system has not been compromised then you can with relative certainty assume that your password has not been compromised just as you normally assume that there's no spyware on your computer because you haven't witnessed anything suspicious. You can edit the log on that server and remove the reference to your password.

This incident is one reason why using SSH keys instead of passwords is better. Then, even if somebody gets the password you enter on your computer to decrypt the private key on your computer they still won't be able to access the remote server; they need the private key file itself as well. Security is all about layers. Nothing is perfect, but if you add enough layers then it's difficult enough that the attacker will just move on or you'll catch them because it takes more time.

I wouldn't do the above if your password protects very sensitive information or critical resources. It depends on how sensitive your password is.

sjbotha
  • 305
  • 4
  • 8