SSH Into a Remote Server: The Hosting Admin Checklist

Safe hardening sequence after the first successful SSH login

This section applies after you have already reached the server once and copied a public key. Before tightening SSH policy, keep a break-glass path open: provider console, WHM terminal, IPMI/KVM, or an existing root-capable SSH session that you do not close. The goal is to prove key login and configuration syntax before disabling password fallback.

Target system: client workstation with OpenSSH

ssh -o PreferredAuthentications=publickey 
  -o PasswordAuthentication=no 
  -i ~/.ssh/id_ed25519 
  [email protected] 'whoami; hostname; id'

This test intentionally refuses password authentication. If it prompts for a password, the key path is not working yet. Fix that before editing server policy. Common causes are copying the private key instead of the .pub file, logging in as the wrong Unix user, using the wrong port, or server-side permissions that cause OpenSSH StrictModes checks to reject the key. The OpenSSH ssh manual documents identity files and authentication options. OpenSSH ssh(1)

Target system: remote Ubuntu/Debian SSH server before changing policy

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%Y%m%d-%H%M%S)
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin|pubkeyauthentication|allowusers)'

Target system: remote RHEL-family or cPanel/WHM SSH server before changing policy

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%Y%m%d-%H%M%S)
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin|pubkeyauthentication|allowusers)'

sshd -t checks syntax. sshd -T prints the effective configuration after defaults and includes are applied. If either command fails, stop and fix the configuration before reload. On cPanel/WHM servers, account-level SSH keys and root SSH policy are separate concerns; cPanel documents account SSH Access and WHM documents root-key and password-authorization controls. cPanel SSH Access WHM Manage root SSH keys WHM SSH Password Authorization Tweak

Config target: /etc/ssh/sshd_config or /etc/ssh/sshd_config.d/ include

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
AllowUsers admin

Use AllowUsers only when you know every account that must retain access. A typo there can lock out valid keys. If you need root access for automation, prefer a named admin account with sudo and document the escalation path instead of allowing routine root SSH. The OpenSSH sshd_config manual is the authoritative reference for these directives. OpenSSH sshd_config(5)

Target system: Ubuntu/Debian SSH server after policy change

sudo sshd -t
sudo systemctl reload ssh

Target system: RHEL-family or cPanel/WHM SSH server after policy change

sudo sshd -t
sudo systemctl reload sshd

Do not close the original session yet. Open a new terminal and repeat the public-key-only login test. If it fails on Ubuntu/Debian, check journalctl -u ssh -n 50 --no-pager. If it fails on RHEL-family systems, check journalctl -u sshd -n 50 --no-pager. For permission-related failures, verify the remote account has a private home directory layout OpenSSH will accept.

Target system: remote user account on the SSH server

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Target system: RHEL-family server with SELinux enforcing and keys still rejected

restorecon -Rv ~/.ssh

The successful finish line is specific: a new session logs in with the intended key, password authentication is refused, root login follows the policy you chose, and you still have console access if the next change goes wrong.

Client-side SSH hygiene for multiple hosting accounts

Many lockouts and wrong-server mistakes start on the client, not on the remote server. If you administer several VPS, cPanel, or CloudLinux accounts, put host-specific settings in ~/.ssh/config instead of typing long commands from memory. This keeps usernames, ports, identity files, and jump hosts tied to a named target.

Target system: admin workstation using OpenSSH client

# ~/.ssh/config
Host sxz-prod
    HostName example.com
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_sxz
    IdentitiesOnly yes
    ServerAliveInterval 30

After adding the host block, connect with ssh sxz-prod. IdentitiesOnly yes is useful when the client has many keys loaded in an agent; it tells OpenSSH to try the intended key instead of spraying unrelated identities at the server until the server refuses more attempts. Use separate keys for unrelated hosting accounts so one compromised workstation key does not become universal access.

Target system: admin workstation verifying the remote fingerprint

ssh-keygen -l -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=accept-new sxz-prod

For first login to a new server, compare the fingerprint shown by SSH with the provider console or a trusted out-of-band source when available. If a known host key changes unexpectedly, stop and investigate before accepting it. Legitimate rebuilds and IP reassignments can change host keys, but so can interception or DNS mistakes. Treat host-key verification as part of the checklist, not a cosmetic warning.