Connect with explicit options

ssh [email protected] looks like it says everything. It does not. The port came from a default. The key came from whatever ssh found in ~/.ssh or in your agent. Later, aliases in ~/.ssh/config will add more hidden inputs.

When a connection fails, those hidden choices are where the bug hides. So the first version of any connection should say everything out loud:

ssh -p 22 -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes [email protected]

-p is the port, -i the private key, and IdentitiesOnly=yes tells SSH to offer only that key and nothing else from the agent. Once this works, you know exactly which four inputs made it work.

Where each option comes from

SSH builds the final settings from three layers, in this order: command-line options, then ~/.ssh/config, then /etc/ssh/ssh_config. For most settings the first value found wins. You can see the merged result without connecting:

ssh -G [email protected]

user deploy
hostname 203.0.113.10
port 22
identitiesonly yes
identityfile ~/.ssh/id_ed25519
...

I run ssh -G before I start changing anything. It has saved me from “fixing” a config file that was not even being used.

Make each layer fail on its own

Now break one input at a time, and only one. Wrong user first:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes [email protected]

[email protected]: Permission denied (publickey).

The host key was accepted, so the transport and the server identity are fine. Authentication is the failing layer.

Wrong port:

ssh -p 2222 [email protected]

ssh: connect to host 203.0.113.10 port 2222: Connection refused

Nothing accepted the TCP connection. Keys had no part in this.

Wrong identity, with verbose output so you can watch it happen:

ssh -v -i ~/.ssh/some_other_key -o IdentitiesOnly=yes [email protected]

debug1: Offering public key: /Users/flavio/.ssh/some_other_key ED25519 SHA256:...
debug1: Authentications that can continue: publickey
[email protected]: Permission denied (publickey).

The verbose log shows the exact key that was offered and rejected. Compare its fingerprint with what the server has in authorized_keys and the mystery is over.

Change one thing at a time

The habit to avoid is flipping several client and server settings until something connects. It often works, and then you cannot say which change mattered. Next time it breaks you start from zero.

Explicit command first, ssh -G to confirm the inputs, -v to find the failing layer, then one change. Write down the three failures above with their exact error lines. Later in the course, when you read server logs, you will match those client messages to what sshd recorded on the other side.