Passwords vs. SSH keys – what’s better for authentication?

Passwords vs SSH keys blog image

Banner ad for SFTP Gateway Version 3.0

Both SSH key and password authentication have their pros and cons. Understand them to make the right choice for your company.

Which is better for user authentication on an SFTP server – SSH keys or passwords?

This has been a debate for decades. Both have their pros and cons, and companies vary in their usage of both authentication technologies.

We use SSH keys as the default method of authentication for SFTP Gateway for AWS and SFTP Gateway for Azure, but we have customers who use password authentication, and we recognize that every situation is different.

So we thought that an overview and comparison of both authentication methods would be helpful. In this post, we’ll review how each authentication method works, and their pros and cons.

Let’s go.

Passwords vs SSH keys blog image

Password authentication

How password authentication works

C’mon, you know how passwords work.

You have a username and password combination that you use to login to your SFTP server. When you try to log in, the server checks whether your username and password are both correct and if so, approves your request.

Pros of password authentication

The first pro of password authentication is convenience for users.

Usernames and passwords are easily remembered, and if web login is possible, browsers can auto-fill these fields, making it even easier to log in.

And everyone knows how to log in using passwords, so there’s no barrier to adoption.

The next benefit is that administrators can increase username and password security by creating policies such as:

  • Setting a maximum number of attempts to access your account within a certain timeframe (e.g. 5 times within 15 minutes) before the account is locked
  • Requiring a certain amount of capitalized letters, numbers, and symbols in the password
  • Forcing users to reset their passwords periodically (e.g. every 90 days)

Cons of password authentication

Did you know that the most popular password of 2017 is “123456”?

If that’s your password for any of the apps you use, go change it. Right now. Seriously.

It’s human nature for people to create passwords that are easily remembered. But simple passwords make these accounts extremely susceptible to intrusion.

And if these simple passwords are used across multiple apps, the potential for a breach increases massively.

Another con of password authentication is that usernames and passwords have to be directly transmitted to the server being logged into, thus making this method more prone to hacking.

There are a couple of ways this can go terribly wrong. First, you can mistakenly log into the wrong server or website, and now that server or website has your password. Hackers love making clones of popular websites to scam users out of their login credentials.

Fake PayPal site
Hackers are tricky. Image courtesy of The SSL Store.

Next, companies could store your password in clear text in their database. Their system administrators can see your password at any time, and if hackers breaks in, they can see your password as well. Even if the password is salted and hashed, a hacker could steal all the passwords, brute force the salt and hash, and see if you used that same password for other apps and websites.

A final con is that employees may get frustrated by password policies set by IT administrators to increase security.

It may be difficult for me to think of a password that requires at least 8 characters, both upper and lowercase letters, at least one number, a symbol that can’t be !, @, $, or %, and a hieroglyphics character.

Now I have to remember it and think of another one every 90 days? Ugh.

As you can see, password authentication has its benefits and drawbacks.

Let’s now check out the pros and cons of SSH key authentication.

SSH key authentication

How SSH key authentication works

Authentication with SSH keys can be a little more complex, but helps increase security when logging into an SFTP server.

Here’s the quick and dirty on how SSH keys work for authentication:

  1. An SSH key pair, which includes a public and private cryptographic key, is generated by a computer.
  2. The public key is stored on the server that you log into, while the private key is stored on your computer.
  3. When you attempt to log in, the server will check for the public key and then generate a random string and encrypt it using this public key. This encrypted message can only be decrypted with the associated private key.
  4. The server will send this encrypted message to your computer. Upon receipt of the message, your computer will decrypt it using the private key and send this message back to the server. If everything matches up, you’re good to go.

A bit more involved than password authentication, no?

Pros of SSH key authentication

The first pro is that SSH keys are more difficult to hack than passwords and thus are more secure.

SSH keys can be up to 4096 bits in length, making them long, complex, and difficult to brute-force hack. These keys are typically at least 1024 bits long, which is the security equivalent of a password that is at least 12 characters.

I don’t know many people who have passwords that are 12 characters long. And “123456789101112” is not a good password, regardless of how long it is.

SSH key and password length graph
Security levels of passwords compared to private keys. Graph courtesy of Webernetz.

Additionally, SSH keys aren’t human generated, so you’ll avoid having easy-to-guess keys like “123456” or “password”.

And unlike passwords, your private SSH key isn’t sent to the server. So even if malicious actors hack into the server, they still can’t access your account.

Also, the SSH connection can only come from the computer where the private key resides. You can log in using a password from any computer, even a shared desktop at your local library. Hopefully hackers aren’t hanging out in the science fiction section!

Finally, you can add a password to your SSH key authentication (multi-factor authentication) to increase security even further.

Cons of SSH key authentication

The first con of using SSH key authentication is that the private key needs to be stored on the device with which you’re logging in. These devices, such as laptops and mobile phones, can be lost or stolen. And if they’re not protected properly, hackers can gain access to the private key and eventually the server.

Also, SSH keys take a bit more work to set up.

A system administrator can assign initial usernames and passwords and distribute them to employees easily. And employees can change these passwords so that only they know what they are. The sysadmin will no longer have access to employee’s passwords

On the other hand, distribution of public keys and education of staff on how to use SSH keys can be more cumbersome. If the sysadmin provides an employee with a private key, he still has access to said private key and can log into the employee’s account.

Even though SSH keys are more secure, there are still potential barriers to their usage.


We understand why you’d want to use password authentication. It’s convenient to set up and everyone knows how to log in with usernames and passwords.

SSH key authentication is much more secure. And when you’re transferring your sensitive files and data to the cloud, security is paramount. That’s why we use SSH keys as the default method of authentication for SFTP Gateway for AWS and SFTP Gateway for Azure.

Do you use passwords or SSH keys for authentication? Why? We’d love to hear from you.

Like this post? It likes you too. 🙂 Please share it using the share buttons to the left. Then join our mailing list below, follow us on Twitter @thorntech, and join our Facebook page for future updates.

Get insights on SFTP Gateway, cloud computing and more, in your inbox.

Get smarter about all things tech. Sign up now!

Scroll to Top