SSH provides an encrypted connection for running commands on a remote server. A secure connection has two separate checks: the server’s identity and the user’s authorization. The server host key and your user key are different keys. Your user private key stays on your own device.
Before you connect
This guide uses OpenSSH on Linux, macOS or Windows to reach a server you are authorized to access. Obtain the server address, existing SSH port, assigned username and accepted authentication method from the administrator. Replace server.example.com, deploy and 22 with your own values.
The SSH service must be running, your account must permit login and network rules must allow your source address. Having a cloud server does not automatically create an SSH account. Use an individual or task-specific account with only the required privileges instead of a shared root login. Verify access to the provider’s recovery console before initial setup or access changes.
Check your client:
ssh -VOn Windows, run this in PowerShell or Windows Terminal. If OpenSSH is unavailable, install the operating system’s supported OpenSSH Client component. PuTTY users must perform the same host-identity check; do not automatically accept an unknown key.
Step-by-step explanation
- Identify: Verify the server host-key fingerprint.
- Keep: The user private key stays on the client.
- Sign: The client proves possession of its key.
- Verify: The server checks the authorized public key.
Verify the server fingerprint on the first connection
Obtain the SSH fingerprint through the provider’s trusted console or an independently verified administrator channel. If the server uses an Ed25519 host key, an administrator can inspect its fingerprint from the server console with this read-only command:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256If the server offers a different key type, compare the fingerprint for that same algorithm. Forcing an unsupported algorithm or disabling client warnings is not a solution.
Connect from your computer:
ssh -o StrictHostKeyChecking=ask -p 22 [email protected]Accept the key only when its type and SHA256 fingerprint match the value obtained through the trusted channel. Stop if they differ. A key obtained from the same unverified connection or collected only with ssh-keyscan does not independently establish the server’s identity.
The accepted key is saved in your local known_hosts file. The next prompt may ask for your account password or your user-key passphrase. These are different from the host-fingerprint check.
Create a user key and authorize only its public half
Do not overwrite an existing file with the same name. If your policy and server support Ed25519:
ssh-keygen -t ed25519 -f "$HOME/.ssh/fibacloud_ed25519" -C "deploy workstation"Set a strong key passphrase when prompted. fibacloud_ed25519 is the private key; fibacloud_ed25519.pub is the shareable public key. Do not upload the private key to the server, a repository or a support request.
On Linux/macOS with ssh-copy-id installed, add the public key to your authorized account after verifying the host fingerprint:
ssh-copy-id -i "$HOME/.ssh/fibacloud_ed25519.pub" -p 22 [email protected]This uses your existing authorized login. If password login is disabled or your Windows client lacks ssh-copy-id, send the public key to the authorized administrator through a trusted channel. The administrator should add it to the correct account’s authorized_keys file without deleting existing keys.
Test the new key in a separate terminal:
ssh -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes \
-i "$HOME/.ssh/fibacloud_ed25519" -p 22 [email protected]This requires the host key to have already been verified and recorded. Keep the existing recovery session open until the new session works.
Configure repeat connections
Add a separate Host section to ~/.ssh/config without replacing existing settings:
Host fibacloud-test
HostName server.example.com
User deploy
Port 22
IdentityFile ~/.ssh/fibacloud_ed25519
IdentitiesOnly yes
StrictHostKeyChecking yesOn Linux/macOS, restrict file permissions. On Windows, configure the files’ NTFS permissions for your account.
chmod 700 "$HOME/.ssh"
chmod 600 "$HOME/.ssh/config" "$HOME/.ssh/fibacloud_ed25519"
ssh -G fibacloud-test
ssh fibacloud-testssh -G displays effective client settings without connecting. After login, use whoami and hostname to check the account and machine. Use exit to close the session when finished.
Separate connection failures
| Symptom | Check first |
|---|---|
Connection timed out |
Address, existing port, client network and rules allowing your source IP. Changing credentials will not repair network reachability. |
Connection refused |
Destination address/port and whether SSH is listening. Investigate through the recovery console. |
Permission denied (publickey) |
Username, selected private key and the public key authorized for that account. |
REMOTE HOST IDENTIFICATION HAS CHANGED |
Reinstallation, approved key rotation or the wrong server. Independently verify the new fingerprint before removing an old record. |
Too many authentication failures |
The intended IdentityFile and IdentitiesOnly yes; the agent may be offering too many keys. |
ssh -v fibacloud-test provides client diagnostics. Review addresses, usernames and local paths before sharing logs. Do not hide errors with StrictHostKeyChecking=no.
Make changes without losing access
This guide does not change the server’s SSH port or login policy. Changing a port is not a sufficient access-security measure. Before later disabling password login or changing network rules, verify a second key-authenticated session and recovery-console access. The administrator should run the configuration test before restarting the service.
If the new key fails, preserve the working login. For rollback, remove only the client Host section or public-key line added in this procedure; do not delete entire authorized_keys or known_hosts files. If a key may be exposed, revoke its public-key authorization and generate a replacement.
Sources
- OpenSSH — ssh: connections, authentication and host keys
- OpenSSH — ssh_config: StrictHostKeyChecking, IdentityFile and IdentitiesOnly
- OpenSSH — ssh-keygen: keys and fingerprints
Technical content and sources reviewed on October 4, 2026. Recheck the relevant official documentation when a version or provider changes.
Leave a Reply