Why is SSH password authentication a security risk?

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.

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

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.

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.

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)

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

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.

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.

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.

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.