Option to speed up SSH connection when target's key has changed

[kurt]

Consider this scenario:  my target’s SSH key changes often (but login and password remains the same).  Why it is so is another question, let’s ignore that for now.

When deploying to a target whose key has changed, the sequence goes like this:

1. Start Deploy.
2. Handshaking (20-30 second before timing out).
3. Prompt appears asking if we want to save the new key.
4. Transferring file.

For item #3, first of all, the prompt appears in the background, so user is unaware of it and is waiting minutes figuring out what is going on (can it be in the foreground?).  Next, I have found the “SuppressKeyMismatchWarning” XML tag, so that helps a bit.

For #2, is there a way to specify that “I know the key will be different for this target, just always accept it immediately”?  Or is the 30 second delay part of the SSH protocol?  Is there is a way to disable strict key checking?

[support]

Hi,

VisualGDB internally uses a lightly patched version of libssh2 to handle the SSH connections, so the “handshaking” delay must come from inside this library. Unfortunately investigating this on our side and optimizing the library is beyond what we could offer with our regular VisualGDB support, however if you managed to narrow this down to a specific change to libssh2 and send us a merge request, we would be able to integrate it into VisualGDB.

[Author]

Posts