Your first SSH connection, keys and scp (from zero)
How to actually connect: generating a key pair, the first login, the known_hosts warning explained, scp and sftp for moving files, and the copy-paste mistakes to avoid.
Every server guide starts with SSH and most tutorials skip the explanation. This one does not: what a key pair is, how the first connection works, why known_hosts warns you, and how to move files without a GUI. Fifteen minutes here pays back on every future task.
Key pairs, in one paragraph
You generate a pair: a private key that stays on your machine and a public key you give to the server. The server stores the public key in authorized_keys. When you connect, the server sends a challenge, your private key signs it, and only the holder of that key can answer — which is why password guessing stops mattering.
Note · The public key is safe to share. The private key is not — anyone with it has your login. Never email it, never paste it into a chat, never commit it.
Generate the key
Ed25519 is the modern default: small, fast and strong. RSA-4096 still works if something forces it.
ssh-keygen -t ed25519 -C 'you@example' — press Enter through the path, or set one like ~/.ssh/id_vps. Then look at the public half: cat ~/.ssh/id_ed25519.pub. That is the string you give the server.
Copy the public key to the server
ssh-copy-id root@YOUR_SERVER_IP is the one-liner that does it for you, installing the key into ~/.ssh/authorized_keys with correct permissions. If the image already took a key at deploy time, this is how you add a second one.
The first connection and the known_hosts warning
On first connect you will see a fingerprint prompt. It is asking whether this is really your server. For a fresh VPS the IP is new, so yes — verify with your provider if you want to be sure, then type yes. The fingerprint is stored in ~/.ssh/known_hosts so that any future change is flagged.
A changed fingerprint later means either the server was rebuilt or someone is intercepting. Investigate before accepting it. Deleting the line in known_hosts is only correct if you know you rebuilt the machine.
Useful variations
| Command | What it does |
|---|---|
| ssh -i ~/.ssh/id_vps root@IP | Connect with a specific key |
| ssh -p 2222 root@IP | Connect on a non-standard port |
| scp file root@IP:/tmp/ | Copy a file to the server |
| scp -r dir root@IP:/tmp/ | Copy a directory |
| scp root@IP:/tmp/file . | Pull a file back |
| sftp root@IP | Interactive two-pane file transfer |
| ssh -L 8080:localhost:80 root@IP | Local port forward for a remote service |
Common first mistakes
- ▹Pasting a private key instead of the public one — the .pub file is the one you copy.
- ▹Accepting a changed known_hosts fingerprint without asking why.
- ▹Running services that bind to 0.0.0.0 when you meant 127.0.0.1 — check with ss -tulpn.
- ▹Leaving password login on because keys were confusing — turn it off, see the SSH hardening guide.
Then move to keys-only
Once key login works, disable passwords. That single change removes the class of attack that takes down most fresh servers. The hardening checklist covers it in the right order, including the verification step that prevents lockouts.
FAQ
QWhat is the difference between the two keys?
AThe public key goes on the server and is public. The private key stays on your machine and must never leave it. They are a matched pair.
QCan I have multiple keys?
AYes — put each public key in authorized_keys on your own line. Useful for a separate key per device so you can revoke one without losing access.
QHow do I fix a permissions error?
Achmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys on the server. SSH refuses keys that are group- or world-readable.