MFT Gateway is a hosted Software as a Service (SaaS) solution that enables file exchange over the AS2 or SFTP protocol, without the need to install or maintain.
Learn how to set up SFTP with public key authentication for secure, password-less file transfers. Perfect for developers, sysadmins, and automated workflows.
Lahiru Ananda
Published: 09 Jul 2025
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.
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.
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.
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:
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.
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.
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:
This command will require the following inputs. When prompted:
After that, your key pair is created! Now you’ll have:
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:
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.
Log in to your server using ssh:
ssh <username>@<your.server.hostname>
Create the .ssh directory (if it doesn’t exist):
mkdir -p ~/.ssh && chmod 700 ~/.ssh
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
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.
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.
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.
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:
File/Folder | Command | What It Means |
---|---|---|
~/.ssh/ |
chmod 700 ~/.ssh |
Only you can read, write, and enter the folder. |
authorized_keys |
chmod 600 ~/.ssh/authorized_keys |
Only you can read/write the file. |
Your private key | chmod 600 ~/.ssh/id_rsa |
Protects your private key from other users. |
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.
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:
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?
eval "$(ssh-agent -s)"
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.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 systemssudo service ssh restart
# On some older systemsImportant Note: Don’t disable password authentication until you’ve confirmed that key*based login is working—otherwise, you could lock yourself out.
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
PasswordAuthentication no
PermitRootLogin no
Use Strong Key Pairs
Use a Passphrase-Protected Private Key
Manage Keys Per User
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.
Join hundreds of organizations already taking full control of their B2B AS2 communications with our trusted solutions. Contact us today to tailor a solution that fits your specific AS2 EDI needs.
No commitment, all value. Try the AS2 Solution Risk-Free and discover how our solutions can transform your business workflows. No credit card required.
See how our AS2 and EDI solutions can simplify your integrations, boost efficiency, and keep you compliant—request a personalized demo today.