Skip to content

Verify SSH Access Before Restricting It

Do not disable a working login method until you have proved the replacement works and have an independent way back in. An existing terminal may remain connected even when a new connection would fail.

Outcome: verify a new key-authenticated connection and record your recovery route. You need a working SSH connection, a public key already installed for the intended account, the matching private key on your client, and local recovery access before any later restriction. This lesson does not alter the SSH server.

Separate the two identities

The server host key helps your client identify the Pi. Your user key helps the Pi authenticate you. A private-key passphrase unlocks your local key; it is not the Pi account's password.

Verify a new or changed host fingerprint through a trusted local console or another independently trusted channel. For the Pi's Ed25519 host key, this read-only command on the Pi shows its public fingerprint:

1
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Match the key type and fingerprint displayed by the client. A different negotiated host-key type has a different fingerprint; do not compare unlike types. Do not copy private host keys to your client, disable host-key checking, or delete all of known_hosts merely to suppress a warning. A changed key may be a legitimate reinstall or an unexpected machine; investigate first.

Open an independent connection from the client

Keep the working session open. In a second terminal on your client computer, replace user@pi-hostname with the actual account and host. Use an OpenSSH client, not a terminal already inside the Pi:

1
2
3
4
ssh -o ControlMaster=no -o ControlPath=none \
    -o PubkeyAuthentication=yes -o PreferredAuthentications=publickey \
    -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no \
    user@pi-hostname

These options affect this client invocation only. They avoid reusing an existing multiplexed connection and request public-key authentication without password/keyboard-interactive fallback. They do not disable password login on the server. A local key-passphrase prompt may still be necessary if the key is not unlocked in your agent.

If you use a nondefault identity file, add -i with its reviewed path. Use your existing client configuration for a required nonstandard SSH port or jump host. Do not copy a private key onto the Pi to make the test pass. OpenSSH documents the connection and authentication behavior in ssh(1) and ssh_config(5).

Inside the new session, run:

1
2
id
hostname

Confirm the intended account and machine, then perform a harmless action your workflow needs. Keep the original terminal open until the new connection and any planned permitted access have been verified.

What if the second connection fails?

Stop before changing the server. Read the error: name resolution, connection timeout, host identity, key selection and authorization are separate failure stages. A timeout is not solved by making authorized_keys world-writable. Permission denied (publickey) is not a reason to disable host-key checks.

Use the working session to inspect the intended account and the public-key setup. Review the dedicated SSH hardening guide before editing policy or file permissions. Avoid posting verbose client logs without reviewing hostnames, usernames, paths and key identifiers first.

Prepare for a failure that disconnects both terminals

Two SSH connections through the same network route are not independent recovery. Write down:

  • Where the Pi is and who can reach a local console.
  • Which account can log in locally, and how required credentials are recovered.
  • Which exact configuration/permission would be restored after a planned change.
  • Which network, storage and power dependencies your remote route needs.
  • How to stop the experiment before losing the only administrative path.

Check the local recovery method during a planned session, not for the first time after a lockout. This lesson does not ask you to disconnect a live interface or reboot a shared Pi as a test.

Decide whether a restriction is justified

Only after the checks above should you consider changing server authentication or firewall policy. Follow the existing hardening guide's validation and rollback sequence rather than applying unrelated changes together. sudo, a Docker management socket and a service's own credentials also deserve separate permission reviews; SSH key login is not the whole security model.

An independent existing-key connection was checked without weakening the verification Pi's server. No new key, account, authentication policy or firewall rule was created; see the verification scope. A successful key-only connection does not prove password authentication is disabled server-side.

Checkpoint: why might a still-open SSH window hide a broken new-login configuration? Why does the command above not prove the server rejects passwords from other clients?

Next: inspect service exposure before opening or closing ports. Return to Security.

Donate