Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
1  
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 '11 at 16:52

9 Answers 9

up vote 7 down vote accepted

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 don't have ssh-agent running that 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.

share|improve this answer

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.

share|improve this answer

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)

share|improve this answer
    
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 '13 at 12:37
1  
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. –  Score_Under Aug 24 '13 at 13:26
1  
And to the answerer: You needn't use truecrypt, openssh private keys come with their own optional password-based encryption. –  Score_Under Aug 24 '13 at 13:27

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.

share|improve this answer

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
share|improve this answer
1  
that's a super handy tip. i've got a few servers that i could do with this on. –  Sirex Nov 24 '11 at 13:41

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.

share|improve this answer

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.

share|improve this answer
    
Very very useful tip. –  Sachin Divekar Nov 24 '11 at 14:15
3  
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 –  Vangel Nov 24 '11 at 16:23
3  
Two very useful tips about SSH authentication, but really doesn't answer the question for me... –  MikeMurko Dec 2 '11 at 16:12

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.

share|improve this answer
    
but using a key file adds the issue of losing the pen drive, or whatever storage you're using. –  João Portela Nov 24 '11 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. –  SplinterReality Nov 25 '11 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 '12 at 14:07
1  
@finnw Correct Horse Battery Staple :-) security.stackexchange.com/q/6095/485 –  Rory Alsop Feb 5 '12 at 16:17

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

share|improve this answer
3  
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 '11 at 12:34
2  
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. –  Nick Downton Nov 24 '11 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. –  eldering Nov 24 '11 at 15:51
15  
@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. –  Mark Henderson Nov 25 '11 at 1:36
2  
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 '11 at 8:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.