74

Most guides for OpenSSH configuration advise to disable password authentication in favor of key-based authentication. But in my opinion password authentication has a significant advantage: an ability to connect from absolutely anywhere without a key. If used always with a strong password, this should not be a security risk. Or should it?

1
  • 4
    Passwords are one-factor authentication which can be sniffed, guessed and replayed. Keys are (possibly) two-factor. Being able to log in from anywhere with just one factor is unacceptable on some systems.
    – Alex Holst
    Dec 2, 2011 at 16:52

11 Answers 11

27

There are pro's and con's for either pw or key-based authentication.

In some cases, for example, key-based authentication is less secure than password authentication. In other cases, its pw-based that's less secure. In some cases, one is more convenient, in others, less.

It all boils down to this: When you do key-based authentication, you must secure your key with a passphrase. Unless you have ssh-agent running (ssh-agent frees you from entering your passphrase every time), you've gained nothing in terms of convenience. Security is disputable: the attack vector now shifted from the server to YOU, or your account, or your personal machine, (...) - those may or may not be easier to break.

Think outside of the box when deciding this. Whether you gain or loose in terms of security depends on the rest of your environment and other measures.

edit: Oh, just saw that you're talking about a home server. I was in the same situation, "password" or "USB stick with key on it" always with me? I went for the former but changed the SSH listening port to something different than 22. That stops all those lame script kiddies brute forcing whole network ranges.

1
80

Using ssh keys do have one unique feature compared to password login: you can specify the allowed commands. This can be done by modifying ~/.ssh/authorized_keys file at the server.

For example,

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

would allow only the command `/usr/local/bin/your_backup_script.sh" with that particular key.

You can also specify the allowed hosts for the key:

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

Or combine the two:

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

With keys you can also grant temporary access to some user (say, a consultant) to a server without revealing the password for that particular account. After the consultant has finished his/her job, the temporary key can be removed.

5
  • Very very useful tip. Nov 24, 2011 at 14:15
  • 4
    Further to that using Keys is like having a long 2000 character password (well technically its even more strength) as compared to what you can key in manually in a terminal :D Nov 24, 2011 at 16:23
  • 3
    Two very useful tips about SSH authentication, but really doesn't answer the question for me...
    – MikeMurko
    Dec 2, 2011 at 16:12
  • 1
    If you want to force a password-authenticated user to go through a specific command, change his login shell. Also, "granting temporary access without revealing the password" is a very bad idea. There are hundreds of different ways to keep the access for later.
    – b0fh
    May 21, 2015 at 6:52
  • The last paragraph alone answers the question IMO - keys allow for granular revocation, while with passwords you need to inform everybody that you're changing it.
    – Riking
    Feb 21, 2017 at 1:24
48

You can get the best of both worlds by only allowing password authentication from within your network. Add the following to the end of your sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes
0
10

When you log in with a password you transmit your password to the server. This means that the operator of the server can modify the SSHD to get access to your password. With public key authentication, they cannot obtain your private key as only your public key every goes to the server.

2
  • 4
    This is especially relevant when you connect to the wrong server because of a typo. For instance, at some point in time, .cg was a wildcard pointing to a single machine with ssh enabled. Anytime you would mistype .cg for .ch, you would end up connecting to that box and leaking your password...
    – b0fh
    May 21, 2015 at 6:59
  • 1
    @b0fh indeed. As far as I can tell, this is the only real vulnerability introduced by using passwords with ssh. If someone already owns the server you're connecting to, or can spoof the IP addresses you're connecting to (MITM), you've already lost.
    – hobs
    Jul 19, 2019 at 17:08
8

ssh keys prevent man in the middle based attacks on your password.

when you attempt to login with a key the server will construct a challenge based on your public key and send it to your client. which will decrypt it and construct an appropriate response to send.

Your private key never gets sent to the server and anyone listening in is unable to do anything except intercept that single session.

with a password they would have your credentials.

My solution is to have a portable ssh key in suitable formats on an encrypted partition on a usb key. this allows me to:
easily retract that key in the event of it being lost.
restrict which servers it allows me access to
and still carry it around

though installing the mount software is a pain (truecrypt)

3
  • 1
    This is wrong. As soon as you know the server's public key (which you do if you added it to your cache and did not get MITM'd on the first connection) you are immune to MITM attacks. Key/password-based authentication has nothing to do with it. The password is never sent in clear over the wire, a secure connection at machine-level authentication (what's your/my public key) is always set up before user-level authentication (what's your password/prove to me this public key is yours).
    – Thomas
    Jul 23, 2013 at 12:37
  • 4
    Thomas, in reality many people ignore the warning about a fingerprint change. Pubkey auth guarantees MITM protection even if the server's private key somehow gets compromised or a human types "yes" absentmindedly: The attacker has to choose between not being able to see the traffic and sending a public key that will not log in, which is a win. Aug 24, 2013 at 13:26
  • 6
    And to the answerer: You needn't use truecrypt, openssh private keys come with their own optional password-based encryption. Aug 24, 2013 at 13:27
7

You have partially responded to your question - the more places attacker can connect from, the more possibilities he has to break into your server by bruteforcing (consider DDoS).

Also compare the length of your password with the key size (usually thousands of bits).

10
  • 4
    96-bits of entropy means an 80-character password, if it's written English; 15 characters if it's random gibberish from the printable character set. are you quite sure that your ssh passwords are that long/strong?
    – MadHatter
    Nov 24, 2011 at 12:34
  • 3
    If you have multiple passwords with 96-bits of entropy which aren't going to be vulnerable to Dictionary attacks, you are probably going to need to use some sort of password management software anyway, so you effectively lose the accessible everywhere element of using passwords. Nov 24, 2011 at 13:31
  • 5
    @SachinDivekar that's 96 bits of entropy only if using random passwords from the set [a-zA-Z], not if it is English words. Nov 24, 2011 at 15:51
  • 16
    @NickDownton - You can have a nice long password without resorting to keypass software. Something like mywifesnameisangelaandshehasanicebutt is invunlerable to dictionary attacks, is very strong, and very simple to remember, but impossible to guess. And it comes with the bonus if brownie points if you ever need to give your password to your wife. Nov 25, 2011 at 1:36
  • 9
    Sorry, Mark, but that's wrong. The passphrase you give has 37 characters and therefore roughly 44 bits of entropy, which is weaker than 7 random printable characters, and eminently attackable. Read Wikipedia's article on the work of Claude Shannon for details, but the upshot is that written English is highly predictable - eg, after "mywifesname", the word "is" is nearly guaranteed. For strong passwords involving words, four random words strung together from a dictionary will give you some 10**23 possibilities, which is about 77 bits of entropy; still not great, but not bad.
    – MadHatter
    Dec 1, 2011 at 8:38
5

It is a trade-off, as @MartinVejmelka says.

The reason you use key based auth is that the key is so far above current or near future brute forcing that you need to be either coming from your own PC, or have the key on a USB stick or similar.

A password has the following issues:

  • If it is short it can be brute forced
  • If it is long it is easily forgotten
  • It could be shoulder surfed

A key is orders of magnitude longer, and is not displayed at any point so it avoids these three issues.

4
  • but using a key file adds the issue of losing the pen drive, or whatever storage you're using. Nov 24, 2011 at 16:59
  • 1
    at which point the lost key can be removed, and a new key added. With passwords (especially shared passwords) this can me a MAJOR pain, and involves a lot of groaning. Nov 25, 2011 at 3:19
  • One of my (recently-retired) passwords: 08Forging2?seminal*^Rajas-(Posed/|. It's randomly-generated but I have no trouble remembering it. And good luck shoulder-surfing or brute-forcing it.
    – finnw
    Feb 5, 2012 at 14:07
  • 1
    @finnw Correct Horse Battery Staple :-) security.stackexchange.com/q/6095/485
    – Rory Alsop
    Feb 5, 2012 at 16:17
2

Good points mentioned here already.

What I consider the biggest risk, given you have taken care of the basics with a strong password, is that a lot of computers have keyloggers installed without the user realizing it. There are even people creating entire sites of useful utilities that contains trojans, so it can happen to the best of us. A keylogger would for example email the login details to a hacker which then easily could access the server.

I recently was warned by Norton about downloading Zombee Mod installer (not the jar, the installer) for adding flight to the Minecraft jar. I looked at the details and Norton listed a lot of utilities on this site that was marked as containing a trojan. I don't know if this is correct or not, but it was pretty specific with filenames. It is also a known fact that trojans are put into (some) warez before they are distributed.

2

One potential benefit of SSH over passwords is that if you don't specify an SSH passphrase, then you never have to type in a password again ... your computer is intrinsically trusted on the server because it has the key. That said, I usually always use an SSH passphrase so I rule that benefit out.

I find the best answer for why user guides often recommend SSH over password authentication comes from the Ubuntu manual for SSHOpenSSHKeys. I quote,

If you don't think it's important, try logging all of the malicious login attempts you get for the next week. My computer - a perfectly ordinary desktop PC - had over 4,000 attempts to guess my password and almost 2,500 break-in attempts in the last week alone. How many thousand random guesses do you think it will take before an attacker stumbles across your password?

Essentially if you have a rock solid high-length password with punctuation, upper and lower case, and numbers ... you will probably be OK with password authentication. Also if you plan to monitor your logs, and aren't doing "super secure" stuff across the network anyways ... i.e. using it for a home server. Then by all means, a password works well.

1

Passwd auth method is really insecure (imho). With this mechanism the password will be transmitted to the sshd server (like @ramon has already said). This means that some individuals could modify the sshd server to retrieve the password. With a Man-In-The-Middle attack this is very easy to accomplish inside a local network.

You can just patch the sshd server by installing this patch (https://github.com/jtesta/ssh-mitm). Use arpspoof and iptables to put your patched server between the client and the authentic sshd server.

Please disable password auth: open the config file /etc/ssh/ssh_config and add the line PasswordAuthentication no.

3
  • Doesn't SSH client check server for RSA fingerprint? After you've sshed to this particular server at least once, it's fingerprint would be remembered, so in the case of possible MITM attacks SSH would light up a warning, wouldn't it?
    – Septagram
    May 21, 2017 at 14:29
  • 1
    Yeah. The warning appear but beacause 99% of time this is caused by os reinstallation, config changed ecc, most users will ignore the warning and go on.
    – Pioz
    May 21, 2017 at 14:32
  • @Septagram Many shell account providers aren't in the habit of posting the current server key fingerprint for new subscribers, for migration of user accounts to new servers, etc. Jan 16, 2018 at 14:24
-3

You can bypass the with the -o StrictHostKeyChecking=no option. This is very useful when using ssh in a shell script.

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .