How does SSH key-based login work, and how do you set it up?
You generate a key pair with ssh-keygen, keep the private key on your machine and copy the public key to the server's ~/.ssh/authorized_keys with ssh-copy-id. The server then challenges you to prove you hold the private key, so no password crosses the network.
Explain it simply
A key pair is like a lock and a key. You fit the lock (public key) on the server's door as many times as you like. Only you carry the key (private key), and it never leaves your laptop.
Setup in two commands:
ssh-keygen -t ed25519creates~/.ssh/id_ed25519(private) andid_ed25519.pub(public). Set a passphrase.ssh-copy-id user@serverappends the public key to~/.ssh/authorized_keyson the server.
After that ssh user@server logs you in. During login the server sends a challenge that only the matching private key can sign.
Permissions matter: ~/.ssh must be 700 and authorized_keys 600, or sshd quietly ignores the key. Once keys work, many admins disable passwords by setting PasswordAuthentication no in /etc/ssh/sshd_config to stop brute-force attacks.
Never share or commit the private key.
Example
ssh-keygen -t ed25519 -C "amit@laptop"
ssh-copy-id amit@203.0.113.10
ssh amit@203.0.113.10
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys # on the serverWhat to say in the interview
"I generate an ed25519 key pair, copy the public key into authorized_keys with ssh-copy-id and keep the private key local with a passphrase. Then I disable password logins in sshd_config. If it fails, I first check the permissions on ~/.ssh."
Common mistakes
- Copying the private key to the server instead of the public one.
- Loose permissions on ~/.ssh causing silent rejection.