On this page
SSH first login on a new VPS is a short, careful sequence. You connect once with the credentials we mailed, confirm the host fingerprint, install your public key, and prove the key works in a second session before you turn password logins off. Doing those steps in order keeps you from locking yourself out and from training yourself to ignore fingerprint warnings forever.
Use the password or temporary access from the welcome mail for that first connection. If you already rotated the password in the panel, use the new one rather than the mailed value. Change a mailed password as soon as you are in. Then place your public key on the server, open a second SSH session that authenticates with the key, and only after that session works disable password authentication. The fingerprint in the welcome mail must match what your client prints. If the SHA256 hash does not match, stop and contact us instead of typing yes.
Match the host fingerprint once
Your SSH client caches the server host key after you accept it the first time. A mismatch on a later login means the key on the box changed, or you are not reaching the machine you expect. Take a moment on the first prompt, compare the hash to the mail, and answer yes only when they agree. That single check is the whole point of the warning.
ssh -o StrictHostKeyChecking=ask USER@SERVERStrictHostKeyChecking=ask is the usual default on most desktops; setting it here simply keeps the prompt visible. You should see the key type, often ED25519 or ECDSA, a SHA256 fingerprint, and a yes or no choice. Compare that fingerprint to the welcome mail. After you accept, the client stores the entry in ~/.ssh/known_hosts. A later warning is not a routine reboot message. It means a different host key is being offered.
Install your key, then disable passwords
Copy your public key into ~/.ssh/authorized_keys for the account you will use. The .ssh directory should be mode 700 and the file mode 600. Open a second SSH session that logs in with the key while you leave the first session connected. When the key session works, set PasswordAuthentication no in the sshd configuration and reload sshd from the still-open first session. If something is wrong with the key path, you still have a working shell.
If you prefer a named account instead of working only as root, create that user and grant sudo before you disable root password logins. That work is covered in our guide to users, groups, and sudo, and it fits on the same afternoon as this checklist. A LogicWeb VPS arrives with SSH available; the rest of the hardening steps are yours to apply.
Shared hosting and known_hosts cleanup
On shared hosting the same idea appears in cPanel under SSH Access. You do not get root on shared plans, and you should not expect it. You still match the fingerprint the first time the client asks. After that, keys are how you sign in within the jailed account CloudLinux provides.
If you already accepted a fingerprint without checking it, run ssh-keygen -F server against your known_hosts file and compare the stored hash to the welcome mail. When they differ, stop using that session and write in if you are unsure. A changed key on a VPS you just rebuilt is expected: remove the old known_hosts line and match the new mail. A changed key on a VPS nobody rebuilt is a signal not to enter a password or accept the new key until we confirm what happened.
Tagged
Was this article helpful?
Be the first to rate this article.
