How to ssh between two linux computers without needing a password

— ny_wk

Passwordless SSH lets you log in from one Linux computer to another without typing a password by using a cryptographic key pair instead of a secret you remember. The setup takes about three minutes: generate a key pair on your client machine, copy the public half to the server, fix the file permissions, and you are done.

If you connect to the same Linux box several times a day, retyping your account password every single time is tedious and, more importantly, weaker than it feels. SSH key-based authentication replaces that ritual with a private key that stays on your machine and a matching public key that lives on the server. Once paired, the two computers prove your identity to each other automatically and securely, no password prompt required. This guide walks through the whole process end to end, with the exact commands, the correct permissions, the modern ed25519 key type, troubleshooting for the usual failures, and the hardening steps that turn convenience into real security.

Why use SSH keys instead of a password

A password is a single shared secret that can be guessed, brute-forced, phished, or captured by a keylogger. A key pair works on a fundamentally stronger principle: asymmetric cryptography. You generate two mathematically linked files. The private key never leaves your computer, and the public key is the part you hand out freely.

• Far harder to break. A 256-bit ed25519 key (or a 3072-bit+ RSA key) is effectively impossible to brute-force, unlike a typical human password.
• Nothing secret crosses the wire. The server challenges your client to prove it holds the private key; the key itself is never transmitted.
• No more typing. Once configured, every login, scp, rsync, and git pull over SSH just works.
• Automatable. Cron jobs, deployment scripts, and CI runners can connect non-interactively, which is impossible with a manual password prompt.
• Revocable per machine. Lose a laptop? Delete that one public key from the server and that device is locked out, without disturbing anyone else.

For this guide we will call your starting machine the client (the computer you sit at) and the destination the server (the machine you want to reach). The flow is always the same direction: the public key goes onto the server, the private key stays on the client.

Step-by-step: set up passwordless SSH login

Step 1 — Generate a key pair on the client

On the computer you connect from, create the key pair. The modern, recommended algorithm is Ed25519: it is fast, compact, and considered very secure. Run:

1. ssh-keygen -t ed25519 -C "you@your-laptop"

The -C flag just adds a human-readable comment (often your email or a machine label) so you can tell keys apart later. You will be asked a few questions:

• File location — press Enter to accept the default ~/.ssh/id_ed25519 for the private key and ~/.ssh/id_ed25519.pub for the public key. Only change this if you are keeping multiple keys.
• Passphrase — type a strong passphrase (highly recommended) and confirm it. You can leave it empty for fully unattended logins, but a passphrase encrypts the private key on disk so a stolen key file is useless on its own.

A typical session looks like this:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/you/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/you/.ssh/id_ed25519
Your public key has been saved in /home/you/.ssh/id_ed25519.pub

If you must support very old servers that lack ed25519, generate a strong RSA key instead: ssh-keygen -t rsa -b 4096. Otherwise prefer ed25519.

Step 2 — Use ssh-agent so you only unlock the passphrase once

A passphrase-protected key would normally prompt you for the passphrase on every connection, which defeats the purpose. The ssh-agent solves this: it holds your decrypted key in memory for the session, so you unlock it once and reuse it freely.

1. Start the agent (most desktop sessions already run one): eval "$(ssh-agent -s)"
2. Add your key to it: ssh-add ~/.ssh/id_ed25519

You will be prompted for the passphrase once; after that the agent answers on your behalf. To confirm the key is loaded, run ssh-add -l, which lists the fingerprints currently held. On macOS you can store the passphrase in the keychain with ssh-add --apple-use-keychain ~/.ssh/id_ed25519.

Step 3 — Copy the public key to the server (the easy way)

The cleanest method is ssh-copy-id, a helper that appends your public key to the server's authorized list and sets the correct permissions for you. From the client, run:

1. ssh-copy-id you@server

It will ask for your server password one last time to install the key. If your key has a non-default name or you keep several keys, point at the right one explicitly: ssh-copy-id -i ~/.ssh/id_ed25519.pub you@server. If the server listens on a non-standard port, pass it: ssh-copy-id -p 2222 you@server.

Behind the scenes, ssh-copy-id creates ~/.ssh on the server if needed, appends your public key to ~/.ssh/authorized_keys, and locks down the permissions. That is the whole job.

Step 4 — Copy the public key manually (when ssh-copy-id is unavailable)

Some minimal or appliance systems do not ship ssh-copy-id. You can install the key by hand. First, view your public key on the client and copy the entire single line:

1. cat ~/.ssh/id_ed25519.pub

It looks like one long line beginning with ssh-ed25519 AAAA... and ending with your comment. Critical: it must stay on a single line. A line break pasted into the middle of the key will silently break authentication.

A reliable one-liner pipes the key straight in and sets everything up in one shot:

1. cat ~/.ssh/id_ed25519.pub | ssh you@server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Prefer to do it interactively? Log into the server and edit the file yourself:

1. ssh you@server
2. mkdir -p ~/.ssh
3. chmod 700 ~/.ssh
4. nano ~/.ssh/authorized_keys — paste the public key as one unbroken line, then save
5. chmod 600 ~/.ssh/authorized_keys

Use >> (append), never > (overwrite), if the file might already contain other people's keys. Overwriting would lock them out.

Step 5 — Test the passwordless login

Back on the client, simply connect:

1. ssh you@server

You should land at the server's shell without any password prompt (the agent may still ask for your key passphrase the first time per session, which is expected). If it still asks for the account password, jump to the troubleshooting section below. To see exactly what is happening during the handshake, run with verbose output: ssh -v you@server. The lines about "Offering public key" and "Server accepts key" tell you whether the key was used.

Correct permissions (this is where most setups fail)

OpenSSH deliberately refuses to use keys if the files are readable by other users. If your permissions are too loose, the server quietly ignores your key and falls back to a password prompt. These are the exact modes it expects:

To fix permissions in one pass on the server:

1. chmod 700 ~/.ssh
2. chmod 600 ~/.ssh/authorized_keys
3. chown -R $USER:$USER ~/.ssh

Note the last point: even a group-writable home directory can make SSH reject your key. If you fixed the .ssh permissions and it still fails, check ls -ld ~ on the server.

Troubleshooting and common pitfalls

When passwordless login "doesn't take," the cause is almost always one of a short list. Work through these in order.

1. Wrong permissions

As above, this is the number-one cause. Re-run the chmod commands and confirm the home directory itself is not writable by group or other.

2. SELinux contexts (RHEL, CentOS, Rocky, Fedora, Alma)

On SELinux-enabled systems, files created or moved into ~/.ssh can carry the wrong security context, and SSH will refuse them even when the Unix permissions are perfect. The fix is restorecon, which resets the context to the policy default:

1. restorecon -R -v ~/.ssh

This is easy to miss because ls -l looks fine; use ls -Z ~/.ssh to see the SELinux context and confirm authorized_keys shows ssh_home_t.

3. The agent isn't running or the key isn't loaded

If you get prompted for the key passphrase constantly, or the key seems ignored, check the agent with ssh-add -l. "The agent has no identities" means you need to run ssh-add ~/.ssh/id_ed25519 again. A fresh terminal or a rebooted machine clears the agent's memory.

4. A broken or multi-line key in authorized_keys

If you pasted the public key and it wrapped onto two lines, the server cannot parse it. Open ~/.ssh/authorized_keys on the server and make sure each key is exactly one line starting with ssh-ed25519 or ssh-rsa.

5. SSH is offering the wrong key, or none

If you have several keys, SSH may try the wrong one first. Force the right one with ssh -i ~/.ssh/id_ed25519 you@server, or pin it permanently in ~/.ssh/config:

Host server
  HostName server.example.com
  User you
  IdentityFile ~/.ssh/id_ed25519

After that, just ssh server uses the right identity, user, and host automatically.

6. Diagnose with the logs

Run ssh -vvv you@server on the client for a blow-by-blow handshake, and on the server check the auth log: sudo tail -f /var/log/auth.log (Debian/Ubuntu) or sudo journalctl -u sshd -f (systemd). These messages name the exact reason a key was rejected, such as "Authentication refused: bad ownership or modes."

Security: protect the private key and lock down the server

Passwordless does not mean careless. A few habits keep key-based auth genuinely strong:

• Guard the private key. It is the one file that grants access. Never email it, never commit it to git, never copy it onto shared machines. Keep its mode at 600.
• Always use a passphrase. Combined with ssh-agent, a passphrase costs you nothing day to day but makes a stolen key file worthless.
• One key per device. Generate a separate key on each laptop or workstation. Then revoking one machine means deleting one line from authorized_keys.
• Disable password authentication once keys work. This is the big win: it shuts down password brute-force attacks entirely.

Only after you have confirmed key login works, harden the server's SSH daemon. Edit /etc/ssh/sshd_config (as root) and set:

1. PasswordAuthentication no
2. PermitRootLogin prohibit-password
3. PubkeyAuthentication yes

Then validate and reload the configuration without dropping your current session:

1. sudo sshd -t — tests the config for syntax errors
2. sudo systemctl reload sshd — applies it (use service ssh reload on older systems)

Keep your existing session open while you test a brand-new connection in a second terminal. If something is wrong, you still have a working shell to undo the change. Locking yourself out of a remote server because you disabled passwords before keys worked is a classic, painful mistake.

Verification checklist

Before you call it done, confirm each of these:

• ssh you@server connects with no account-password prompt.
• ssh -v you@server shows "Server accepts key" / "Authentication succeeded (publickey)."
• ssh-add -l lists your key (if you use a passphrase + agent).
• On the server, ls -l ~/.ssh shows 700 on the directory and 600 on authorized_keys.
• After hardening, a password login attempt is refused, and sudo sshd -t reports no errors.

That is the complete loop: a strong key pair on the client, its public half installed and correctly permissioned on the server, the agent handling your passphrase, and password auth switched off for good measure. From here, scp, rsync, and git over SSH all inherit the same effortless, secure login.

Key Takeaways

• Generate once, copy once. Create an ed25519 key pair with ssh-keygen -t ed25519, then push the public half to the server with ssh-copy-id you@server.
• Permissions make or break it. ~/.ssh must be 700, authorized_keys must be 600, and the home directory must not be group/world-writable, or SSH silently ignores your key.
• Use a passphrase plus ssh-agent. You unlock the key once per session with ssh-add and never type it again, getting both convenience and at-rest protection.
• On Red Hat-family systems, remember restorecon -R ~/.ssh to fix SELinux contexts when permissions look right but login still fails.
• Harden last, never first. Set PasswordAuthentication no only after key login is verified, and keep a second session open while you reload sshd.

Frequently Asked Questions

Should I use ed25519 or RSA keys?

Use ed25519 for new setups. It produces shorter keys, is faster, and offers excellent security. Only fall back to ssh-keygen -t rsa -b 4096 if you must connect to a legacy server that does not support ed25519.

Why does SSH still ask for a password after I copied my key?

The server is rejecting your key, almost always because of permissions. Confirm ~/.ssh is 700 and authorized_keys is 600, that your home directory is not group-writable, and on SELinux systems run restorecon -R ~/.ssh. Run ssh -v you@server and check the server's auth log to see the exact rejection reason.

Can I use one key pair on several computers?

You can, but it is better to generate a separate key on each device and add each public key to the server's authorized_keys. That way, if one machine is lost or compromised, you delete just that key's line to revoke it without affecting your other devices.

Is it safe to leave the passphrase empty?

An empty passphrase is convenient for automated scripts and cron jobs, but if that private key file is ever stolen it grants instant access. For interactive use, set a strong passphrase and let ssh-agent remember it for the session, so you get the convenience without the exposure.

Found this useful? Subscribe to @explorenystream on YouTube for more.