How to ssh without providing password

— ny_wk

Passwordless SSH lets you log in from one Linux server to another without typing a password by using public-key authentication: you generate a key pair once, copy the public key to the remote host, and every future ssh or sftp connection authenticates automatically. This guide shows the modern, secure way to set up passwordless SSH between two hosts, plus how to fix the most common reasons it silently fails.

Why set up passwordless SSH

Typing a password on every connection is slow, error-prone, and impossible to automate. Cron jobs, file transfers, backups, and configuration-management tools all need to connect to remote servers non-interactively. Passwordless SSH using key authentication solves this while actually being more secure than password login, because a 256-bit private key is far harder to brute-force than a human-chosen password.

The mechanism is simple. You hold a private key that never leaves your machine, and you place the matching public key in the remote account's ~/.ssh/authorized_keys file. When you connect, the server challenges you to prove you hold the private key; SSH does this cryptographically without ever transmitting the key or a password.

Before you begin: a word on key types

Older guides (and many corporate runbooks) tell you to run ssh-keygen -t dsa. Do not use DSA. DSA keys are capped at 1024 bits, are considered cryptographically weak, and have been disabled by default in OpenSSH since version 7.0 (2015). RSA keys created with the old default size are also no longer ideal.

Use one of these instead:

• ed25519 — the recommended default. Fast, compact, and very secure. Supported by every modern OpenSSH (7.0+).
• rsa at 4096 bits — use only if you must talk to a very old server that lacks ed25519 support.

Also note a detail from real multi-server setups: the home directory path can differ between hosts. For example a service account might live at /homecomm/pprftp on one server and /home/pprftp on another. That is fine — keys live under each account's own ~/.ssh directory, and the ~ shorthand resolves correctly on each host regardless of the absolute path.

The fast way: passwordless SSH with ssh-copy-id

On any reasonably modern Linux distribution this is a two-command job. Suppose you are logged in as user pprftp on the source host and want passwordless access to the same user on a host called dmspar02.

1. Generate a key pair (press Enter to accept the default location; choose whether to add a passphrase — see the security note below):
   ssh-keygen -t ed25519 -C "pprftp@dmspar01"
2. Copy the public key to the remote host. You will be asked for the remote password this one time:
   ssh-copy-id pprftp@dmspar02
3. Test it — you should land on the remote shell without a password prompt:
   ssh pprftp@dmspar02

That is the entire setup. ssh-copy-id handles every fiddly detail for you: it creates ~/.ssh on the remote host if missing, appends your key to authorized_keys without clobbering existing keys, and sets the correct permissions. The first time you connect you will see a host-key prompt like The authenticity of host 'dmspar02 (172.17.111.29)' can't be established... Are you sure you want to continue connecting (yes/no)? — type yes. That is normal and only happens once per host.

The manual way: when ssh-copy-id is not available

Some hardened or legacy environments do not ship ssh-copy-id, or only allow SFTP, not interactive SSH. You can still set up passwordless SSH by placing the public key by hand. Here is the robust, correct procedure that fixes the mistakes commonly found in older runbooks.

Step 1 — Generate the key on the source host

Logged in as pprftp on dmspar01:

1. ssh-keygen -t ed25519 -C "pprftp@dmspar01"

You will see output similar to:

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

This creates two files in ~/.ssh: the private key id_ed25519 (keep it secret, never copy it off the host) and the public key id_ed25519.pub (safe to share).

Step 2 — Get the public key onto the remote host

A critical correction to the old method: do not simply do cat id_ed25519.pub > authorized_keys on the source machine and copy that file over wholesale. If the remote authorized_keys already contains keys, overwriting it will lock out other users. Use append (>>) on the remote side instead.

If you only have SFTP, transfer the public key as a staging file, then append it on the remote host:

1. From dmspar01, open an SFTP session and upload the public key:
   sftp pprftp@dmspar02
put /home/pprftp/.ssh/id_ed25519.pub /home/pprftp/uploaded_key.pub
bye
2. Log in to dmspar02 (by password, this last time) and install the key correctly:
   ssh pprftp@dmspar02
mkdir -p ~/.ssh
cat ~/uploaded_key.pub >> ~/.ssh/authorized_keys
rm ~/uploaded_key.pub

Step 3 — Fix permissions (the #1 cause of failure)

SSH is deliberately strict: if the .ssh directory or authorized_keys file is writable by anyone other than the owner, the server silently refuses the key and falls back to asking for a password. Set permissions exactly like this on the remote host:

1. chmod 700 ~/.ssh
2. chmod 600 ~/.ssh/authorized_keys
3. chmod 700 ~ — the home directory itself must not be group/other writable

Back on the source host, lock down the private key too:

1. chmod 600 ~/.ssh/id_ed25519

Step 4 — Test the connection

1. From dmspar01: ssh pprftp@dmspar02 — should open a shell with no password.
2. Confirm SFTP too: sftp pprftp@dmspar02 — should connect with no password.

Required permissions at a glance

Common pitfalls and how to fix them

• Still prompted for a password. 99% of the time this is permissions (Step 3) or wrong file ownership. Run ssh -v pprftp@dmspar02 and read the verbose output — it will show whether the key was offered and why it was rejected.
• Overwrote authorized_keys and locked out other users. Always append with >>, never >. ssh-copy-id appends automatically.
• Used a DSA key. Regenerate with ed25519. Modern servers ignore DSA keys entirely.
• Wrong user or home directory. Remember the remote account's home may be a non-standard path. The key must land in that account's ~/.ssh, not root's.
• SELinux blocking the file. On RHEL/CentOS, if you created authorized_keys in an unusual way, run restorecon -Rv ~/.ssh to fix its security context.
• Server disabled public-key auth. Rare, but check /etc/ssh/sshd_config for PubkeyAuthentication yes and that AuthorizedKeysFile points to .ssh/authorized_keys.

Verification: confirm passwordless SSH actually works

Do not just trust that a shell opened — verify it non-interactively, the way a script would:

1. Run a single remote command and confirm zero prompts:
   ssh pprftp@dmspar02 'hostname && whoami'
2. Confirm the key (not a password) was used with verbose mode and look for the line Authenticated to dmspar02 ... using "publickey":
   ssh -v pprftp@dmspar02 exit 2>&1 | grep -i publickey
3. Test an automated SFTP transfer in batch mode, which fails immediately if a password is needed:
   sftp -b - pprftp@dmspar02 <<< 'ls'

If all three run without ever asking for a password, your passwordless SSH setup is correct and safe to use in cron jobs and automation.

Security note: passphrase vs. ssh-agent

A passphrase-less key is convenient but means anyone who steals the private key file gets instant access. The best of both worlds is to set a passphrase on the key and load it once per session into ssh-agent:

1. eval "$(ssh-agent -s)"
2. ssh-add ~/.ssh/id_ed25519 — enter the passphrase one time

After that, all connections in the session are passwordless, but the key on disk stays encrypted. For unattended service accounts that truly cannot prompt, an empty passphrase is acceptable — just guard the private key file rigorously and restrict the key in authorized_keys with options like from="172.17.0.0/16" and command="..." to limit what it can do.

Key Takeaways

• Passwordless SSH works by placing your public key in the remote account's ~/.ssh/authorized_keys; the private key never leaves your machine.
• Use ssh-keygen -t ed25519 — never DSA, which is obsolete and disabled in modern OpenSSH.
• The fastest setup is ssh-keygen followed by ssh-copy-id user@host; it appends safely and sets permissions for you.
• When copying keys manually, always append with >> and set 700 on ~/.ssh and 600 on authorized_keys — bad permissions are the top reason it silently fails.
• Verify with ssh -v (look for publickey) and a non-interactive command before trusting it in automation.

Frequently Asked Questions

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

Almost always a permissions problem. The remote ~/.ssh must be 700, authorized_keys must be 600, and the home directory must not be writable by group or others. Run ssh -v user@host to see exactly why the key was rejected.

Is passwordless SSH safe?

Yes — key authentication is more secure than passwords because the private key is far stronger than any typed password and is never sent over the network. For extra safety, protect the private key with a passphrase and load it via ssh-agent, and restrict the key's reach in authorized_keys.

Can I use the same key pair for several servers?

Yes. Generate one key pair and copy the single public key to the authorized_keys of every server you need. Many admins prefer one key per laptop/user rather than one per server, which keeps management simple while still letting you revoke access by removing the public key line.

What is the difference between ssh and sftp for passwordless login?

They use the exact same key authentication. Once your public key is installed, both ssh (interactive shell or remote commands) and sftp (file transfer) connect without a password automatically — no separate setup is needed for each.

If this guide helped, subscribe on YouTube @explorenystream for more Linux and sysadmin walkthroughs.