How to Setup SFTP Public Key Authentication

SFTP, also known as SSH File Transfer Protocol, is one of the best and most reliable ways for transferring files between systems securely. Most of the time, people log in with a password, but if security and ease of use are a concern, the public key authentication adds an extra layer of security and convenience, especially for automated or recurring transfers.
This article aims to serve as a step-by-step walkthrough on setting up SFTP public key authentication. Whichever line of work you might be in-whether a developer, a sysadmin, or a budding server guru-this will be a guide to your more secure, automated SFTP setup.

What is SFTP and Why Use Public Key Authentication

The SFTP (Secure File Transfer Protocol), is a secure client-server protocol similar to FTP but running under SSH, and it encrypts commands and data during file transfers. It is usually used for the uploading and downloading of files to a remote server, providing a secure interface over insecure networks in such environments as cloud infrastructure, automated workflows, or enterprise systems.

By default, SFTP supports password authentication, but for long-term use, it is far better to use public key authentication. The user authenticates using a pair of cryptographic keys: private (stored in his or her device) and public (stored on the server), rather than having to enter a password every single time. Thus, connections made in this manner become fluid, secure, and scalable.

Why Use Public Key Authentication?

Stronger Security

• Keys are nearly impossible to brute-force or guess, unlike passwords.
• Ensures that nobody gains access without authorization, just because they know your username.

Ideal for Automation

• Scripts, backups, and CI/CD pipelines can be executed unattended with no manual login required.
• Great for scheduled file transfers using cron jobs or deployment tools.

Faster Login Experience

• Every time you connect, you would not require to type your password again and again.
• Especially helpful when you are working with multiple servers.

Easy to Manage at Scale

• Public keys can be distributed or revoked without having to change server passwords.
• Organizations can assign different keys to different users or services.

Reduces Human Error

• No way someone can misspell or unintentionally share a password.
• Lower chances of getting phished or social-engineered.

Limits Attack Surface

• You can disable password-based logins entirely to block any brute-force attacks via SSH.
• Public key auth hence serves to narrow the entry points available to bad actors.

In summary, public key authentication can make secure enough SFTP connection to “rock-solid,” making it a best practice for developers, sysadmins, and anyone handling sensitive data over the network.

How Public Key Authentication Works?

Public key authentication is based on the concept of asymmetric encryption within the framework of cryptography. Unlike a single password shared between the client and server, asymmetric encryption works with two keys which are mathematically linked: a public key and a private key.

Here’s how public key authentication works:

• The client generates a key pair using a tool like ssh-keygen.
• The public key will then be copied by the client onto the server, where it will be stored in a file named authorized_keys located in the home directory.
• The private key must stay with the client on his/her local machine and should not be shared or exposed under any circumstances.
• When the client attempts to connect to the server via SFTP or SSH, the server checks if the client’s public key exists, then challenges the client to prove that it has the corresponding private key.
• The client responds with a signature created by using the private key on the challenge. If the signature proves true, access gets granted by the server.

What makes this public key based authentication powerful is that the client’s private key never leaves their local machine. This way, the security gets enhanced than just sharing a simple password on an unsecured network. It not only provides greater security but allows for automated, password-less-login processes.

Setup SFTP Public Key Authentication

What You’ll Need

Before we dive in, let’s quickly make sure you’ve got everything ready. Setting up SFTP with public key authentication doesn’t require a huge toolbox—just a few basics:

• A remote server
  This could be a VPS, a cloud server (like AWS EC2), or any Linux-based machine you can access remotely.

• A user account on that server
  You’ll need to be able to log in via SSH. If you’ve ever used ssh user@server you’re good to go.

• Your local computer (Mac, Linux, or Windows)
  macOS and most Linux distributions already have SSH tools built in.
  On Windows, you can use PowerShell with OpenSSH (pre-installed in modern versions) or third-party tools like PuTTY.

• A terminal or command line
  If you’re comfortable typing a few commands, you’re all set. No advanced skills required.

Step 1: Generate Your SSH Key Pair:

Before you can configure and log in using public key authentication, you need to create your own SSH key pair. Think of this as making your own digital ID badge, the private key is your secret pass, and the public key is what you hand to the server so it knows who to trust.

Here’s how to do it: Open your terminal and run following command:

sh-keygen -t rsa -b 4096 -C "your_email@example.com"

Let’s break down above command:

• ssh-keygen is the tool that creates your keys.
• -t rsa tells it to use the RSA algorithm (very secure and widely supported).
• -b 4096 sets the key length to 4096 bits, stronger than the default 2048.
• -C adds a comment to help you identify the key later (often your email or purpose).

This command will require the following inputs. When prompted:

• File location? Just press Enter to accept the default: ~/.ssh/id_rsa (private) and ~/.ssh/id_rsa.pub (public).
• Passphrase? Optional, but recommended. It encrypts your private key with a password, so even if someone gets it, they can’t use it.

After that, your key pair is created! Now you’ll have:

• id_rsa: your private key (keep this safe and never share it!)
• id_rsa.pub: your public key (this one will go on the server)

Step 2: Send Your Public Key to the Server:

Now that you’ve created your SSH key pair, it’s time to let your server know about it. You can do that by saving your public key in the server, so it can recognize and trust your private key when you connect.

Think of it like giving your name to the front desk at a secure building. Later, when you show up with your ID (your private key), building security lets you in without asking for your password.

There are two main ways to do this:

Option 1: The Easy Way – Use ssh-copy-id

If your local machine has the ssh-copy-id tool (most Linux and macOS systems do), run following command:

ssh-copy-id <username>@<your.server.hostname>

Replace username with your actual server username and your.server.hostname with the server’s IP or hostname.

This command:

• Connect to your server using your password.
• Creates the ~/.ssh directory on the server if it doesn’t exist.
• Append your public key to the authorized_keys file.
• Sets the right permissions for you (no manual setup!).

Option 2: Manual Method (if ssh-copy-id isn't available)

If you’re on a system that doesn’t support ssh-copy-id (like some Windows setups), no need to worry, you can still copy the key manually.

1. Log in to your server using ssh: ssh <username>@<your.server.hostname>

2. Create the .ssh directory (if it doesn’t exist): mkdir -p ~/.ssh && chmod 700 ~/.ssh

3. From your local machine, print your public key using following command and copy the full line of text that appears.: cat ~/.ssh/id_rsa.pub

4. Now go back to your server, paste it into the authorized_keys file: echo "your-public-key" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

Make sure you’re pasting one full line, no line breaks. You can also use a text editor like nano ~/.ssh/authorized_keys if you prefer.

And that’s it! Your server now knows to trust your key. The next time you try to connect, it’ll look for your matching private key and let you in and no password is required anymore.

Step 3: Test the Connection

You’ve generated your key pair, added the public part to the server. Now we have completed all the required configurations and here comes the exciting part. Let’s see if your setup lets you log in without your password.

Try connecting with SFTP; on your local machine, run following command: sftp <username>@<your.server.hostname>

Make sure to replace username and your.server.hostname with your actual server information. If everything is set up correctly, you should see something like this: Connected to <your.server.ip> sftp>

Boom. You’re in! There was no request for a password because the server recognized your private key and let you through.

Time to test the connection further. Let’s upload and download a file. At the sftp> prompt, try: put test.txt # Upload a file to the server get test.txt # Download it back

These confirm that the SFTP connection is working smoothly and securely.

What If It Doesn’t Work?

Followed all the steps and still being asked for a password, or worse, locked out completely? Don’t worry; it’s common to encounter a problem or two when setting up SSH key authentication. Here’s a guide to the most common issues and how to resolve them.

Wrong File Permissions (Most Common Issue):

SSH is very strict about file and folder permissions. If your key files or .ssh directory are too open, SSH will refuse to use them for security reasons, even if everything else is correct.

Why is that? Loose permissions mean someone else on the server could possibly read or alter your keys, so SSH simply shuts it down.

Here’s what the correct permissions should be:

You can check current permissions by running: ls -ld ~/.ssh and ls -l ~/.ssh/authorized_keys. If you see anything like an output like drwxrwxrwx or -rw-r–r–, that’s too open—and it’s likely why your key isn’t working.

Fixing permissions is often the most important step in getting SSH key authentication to work. If you’re stuck, double-check this before anything else.

The Public Key Is Not Installed Properly:

Even if your key has indeed been generated correctly and has the permissions set right, it won’t work unless the public key is placed in the right directory on the server and has the right format. It is extremely easy to go wrong at this point, particularly if you are doing it manually.

Common mistakes:

• Line breaks in the key when pasted from a terminal or email
• Missing characters at the beginning (like ssh-rsa) or the end
• Accidentally putting it in the wrong file (like authorized_key instead of authorized_keys)
• Copying the private key by mistake instead of the public one
• Using the wrong user account on the server

The Wrong Key Is Being Used:

Sometimes, your connection fails not because the key is forged but because your computer is trying to use the wrong one. If you’ve ever made multiple SSH keys for different servers, GitHub, or cloud services, then your system might be defaulting to the wrong one while you log in.

How does this happen?

When you run a command like: sftp <username>@<your.server.hostname>, SSH looks through a list of available private keys, often stored in ~/.ssh/, and tries them in order. If it doesn’t find the right one, the server says “no thanks,” and you are asked for a password instead.

How to fix it:

Option 1: Explicitly specify the key file

If you know the correct private key, you can force SSH/SFTP to use it: sftp -i ~/.ssh/id_rsa <username>@<your.server.hostname>

This skips all the guessing and uses exactly the key you specify.

Option 2: Set up a custom SSH config (the recommended way)

You can tell SSH which key to use for each server, so you don’t have to remember flags. Open (or create) the SSH config file on your local machine: nano ~/.ssh/config

Add an entry like this:

Host myserver HostName your.server.ip User username IdentityFile ~/.ssh/id_rsa

Now, instead of typing a long command, you can just run: sftp myserver

SSH will automatically use the correct key!

Getting your system to use the right key can save you tons of headaches—especially if you’re managing multiple projects or servers. A few lines in your SSH config file can make all your connections just work.

What is the SSH agent, anyway?

SSH agent is basically an encrypted keyring. Instead of requiring you to enter your passphrase every time you connect, it stores the unlocked key in memory until you reboot or log out. Super handy for developers and DevOps folks who jump between servers all day long.

How do I check my key is loaded?

You can check what keys are available to the agent by running: ssh-add -l If it says “The agent has no identities,” your key is not loaded.

How to load your private key into the agent?

1. Start the agent (if it isn’t already running): eval "$(ssh-agent -s)"
2. Add your key: ssh-add ~/.ssh/id_rsa You’ll be prompted to enter your passphrase (not your server password). Once entered, your key is unlocked and ready to go.

Server-Side SSH Config Blocks Keys:

Sometimes everything is well aligned on your side—you have got your keys, permissions are all right, and the agent runs smoothly. But still, you get locked out. What could possibly be the problem?

It might just be a problem on the server-side. If the SSH server isn’t configured to allow public key authentication, then it just won’t accept your key, irrespective of how valid it may be.

What to Check on the Server?

The SSH configuration file on the server side is usually located at: /etc/ssh/sshd_config You will need sudo/root privileges to edit this file.

Important settings to verify:

Open the file with your preferred editor: sudo nano /etc/ssh/sshd_config Verify these lines are there and not commented out (no # at the beginning):

PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys

If “PubkeyAuthentication yes” is not there, then that’s probably why your key isn’t working.

You might want to check the following settings as well:

PermitRootLogin no # Optional but good for security PasswordAuthentication no # Optional — only if you’re confident key auth works ChallengeResponseAuthentication no

Save & Restart the SSH Service

After making changes, save the file and restart the SSH daemon:

• sudo systemctl restart ssh # Most modern systems
• sudo service ssh restart # On some older systems

Important Note: Don’t disable password authentication until you’ve confirmed that key*based login is working—otherwise, you could lock yourself out.

Best Practices for SFTP Security

Setting up public key authentication is a great step—but don’t stop there. To truly secure your SFTP server and keep your data safe, consider applying these best practices:

Harden Your SSH Configuration

• Disable password authentication after confirming key*based login works: PasswordAuthentication no
• Disable root login to reduce risk from brute*force attacks: PermitRootLogin no

Use Strong Key Pairs

• Always use at least a *2048bit RSA key** (4096*bit is better).
• Avoid older or less secure algorithms (like DSA).

Use a Passphrase-Protected Private Key

• A passphrase adds an extra layer of protection in case your private key file is ever stolen

Manage Keys Per User

• Avoid sharing accounts or private keys.
• Assign individual keys to users and revoke them when no longer needed.

In Conclusion

SFTP with public key authentication is a simple, powerful upgrade that makes file transfers more secure and easier. When you use cryptographic key pairs to replace password authentication, you’ve removed one of the most common weaknesses, the human error. If you’re a developer, sysadmin, or just automating some workflow with the server, switching on key-based SFTP authentication is something you have to do. When it’s suitable to use, it works without a hitch and saves countless hours every single day. With proper consideration given to setup, permissions, and sane security practices, a well-tuned SFTP environment should turn out to be fast, reliable, and maintainable over the long term. So, just toss that password and relish the relief that comes from secure key-based access.