SSH Without a Password — A Few Simple Steps

Passwordless SSH is a time-saver and a near-requirement for automated scripts that copy files or transfer data between servers. Setting it up can feel fiddly, but it’s four steps once you’ve done it once. This guide walks through a real example, with a troubleshooting section at the end.

Because SFTP authenticates over SSH, configuring passwordless SSH gives you passwordless SFTP at the same time.

Before you start: confirm it currently asks for a password

[web@localhost ~]$ ssh james@devserver
james@devserver's password:

[web@localhost ~]$ sftp james@devserver
james@devserver's password:

As expected, both prompt for a password. That’s what we’re eliminating.

Step 1 — Generate a key pair

Generate a public/private key pair on the local host. Press Enter to accept the default filename, and (for unattended scripts) leave the passphrase empty:

[web@localhost ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/web/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/web/.ssh/id_rsa.
Your public key has been saved in /home/web/.ssh/id_rsa.pub.

You can run ssh-keygen from any directory — the keys are always written to the .ssh directory in your home folder.

Step 2 — Find your keys

Change into your .ssh directory. You’ll see two files: id_rsa (the private key — never share it) and id_rsa.pub (the public key — safe to distribute):

[web@localhost ~]$ cd /home/web/.ssh
[web@localhost .ssh]$ ls -la
total 32
-rw-------  1 web web 1675 Dec 7 22:05 id_rsa
-rw-r--r--  1 web web  407 Dec 7 22:05 id_rsa.pub
-rw-r--r--  1 web web  391 Dec 7 22:03 known_hosts

Check the timestamps to be sure these are the keys you just generated.

Step 3 — Copy the public key to the remote host

The public key needs to land in the remote user’s ~/.ssh/authorized_keys file. The simplest, least error-prone way is ssh-copy-id:

[web@localhost .ssh]$ ssh-copy-id james@devserver
james@devserver's password:
Number of key(s) added: 1

You’ll enter the remote password one last time. ssh-copy-id handles creating the .ssh directory, setting the right permissions, and appending the key — which is exactly where manual copies tend to go wrong.

Step 4 — Verify it works

Test the connection. It should drop you straight in, no password prompt:

[web@localhost .ssh]$ ssh james@devserver
[james@devserver ~]$

SFTP now works passwordlessly too:

[web@localhost .ssh]$ sftp james@devserver
sftp>

That’s it — passwordless SSH and SFTP are configured.

Troubleshooting

If it still prompts for a password, the cause is almost always permissions on the remote host. SSH deliberately refuses to use keys when the files are too permissive. On the remote, they must be:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Other things to check:

• Ownership. The .ssh directory and authorized_keys must be owned by the remote user, not root.
• The right public key. Confirm the key in authorized_keys matches the .pub file you generated.
• Verbose output. Run ssh -v james@devserver to see exactly where the handshake fails — it will tell you whether the key was offered and rejected.
• Home directory permissions. If the remote home directory is group- or world-writable, SSH may refuse the key. chmod 755 ~ (or stricter) fixes it.
• SELinux. On RHEL-family systems, a restored-from-backup .ssh can have the wrong SELinux context. restorecon -Rv ~/.ssh repairs it.

Why key-based auth, not just a saved password

Beyond convenience, key-based authentication is more secure than passwords: keys are effectively impossible to brute-force, they’re never transmitted over the wire, and you can revoke a single key without changing anything else. For production servers, the standard hardening step is to disable password authentication entirely once keys are working — set PasswordAuthentication no in /etc/ssh/sshd_config and reload the SSH daemon.