SSH host keys

The first time ssh reaches a server it has never seen, it stops and asks whether the key that server presented really belongs to it. In a terminal you answer the question yourself. An operation started from Innesta has no terminal to answer it in — so Innesta answers no, and then shows you the question.

Everything that reaches a remote arrives here: cloning, fetching, pulling, pushing, tags, and the GitFlow operations that finish on the server.

The sheet

Verify SSH Host Key shows the four things the answer turns on — Host, Port, Key Type and Fingerprint — and the fingerprint is selectable, so it can be copied and compared rather than read across.

Trust and Retry stays unavailable until you tick I compared this fingerprint with a trusted source, which is the whole of the decision. A trusted source is the list your provider publishes, or the person who administers the server. It is not the connection in front of you: a server that is not the one you meant presents its own fingerprint just as readily.

Trusting retries the operation that failed, once, and for exactly the host, port, key type and fingerprint on the sheet. A prompt for anything else is answered no, as the first one was.

What is saved, and by whom

The key is saved by OpenSSH, in the known_hosts file your own configuration names, under your own SSH settings. Innesta does not write that file, does not edit ~/.ssh/config, does not run ssh-keyscan, and does not load keys into ssh-agent. Your approval is not stored either: it is not a Keychain item, and it does not outlive the retry it authorised.

So there is nothing to see the second time. A host already in known_hosts connects without a word from Innesta — and so does a new one if your own configuration says StrictHostKeyChecking=accept-new, which accepts the key before the question ever reaches the app.

The passphrase, if the key has one

Trusting the host settles who the server is, not who you are. If the key you authenticate with then wants its passphrase, Unlock SSH Key follows immediately and the same operation is retried again. Cancelling either sheet during a clone puts the clone back as you left it, with its URL, destination and account still filled in.

When there is nothing to trust

Two more cases end in guidance rather than a button:

• Your configuration requires strict checking. With StrictHostKeyChecking=yes the sheet would be a way round your own policy, so there is none: SSH host key verification blocked asks you to add the verified key the way you normally administer SSH, and then retry.
• The question is not one Innesta can read. An authenticity prompt it cannot parse in full is answered no rather than guessed at, and you are asked to verify and add the key yourself.