SSHServiceImpl vs StrictHostKeyChecking

[jmettraux]

https://twitter.com/mik235/status/585040681036488704
https://twitter.com/mik235/status/585040826067058688

[therealmik]

To clarify, setting StrictHostKeyChecking=no will still allow connections even if the host key has changed, so it's the SSH equivalent to SSL_VERIFY_NONE in Jsch.

[octavian-h]

So to understand, you want the SSH connection to fail if you set the policy=KNOWN_HOSTS_ADD and the thumbprint is already used for a different host?

[therealmik]

Not quite - if the policy is add and:

• we don't have the key: Add and Proceed
• we have the key and it's unchanged: Proceed
• we have the key and it's changed: Fail and print a useful error message (with remediation steps if they know why it's changed)

This is IMO a Jsch bug, but the author doesn't accept it as such.

See the slides from my Ruxcon talk last year:
https://ruxcon.org.au/assets/2014/slides/Bolt%20on%20some%20Crypto.pdf

[octavian-h]

The problem is that the Jsch library will ask for user prompt if:

• we don't have the key
• we have the key and it's changed

Otherwise it will fail with an exception:
throw new JSchException("HostKey has been changed: "+chost); // line 757 in Session.java
throw new JSchException("UnknownHostKey: "+host+". "+key_type+" key fingerprint is "+key_fprint); // line 787 in Session.java

So I don't have a way to know if the host key was changed or doesn't exist if I use StrictHostKeyChecking=no in Jsch library.

[therealmik]

Yeah, it's tricky - some people handle it with a custom UserInfo class, but that usually goes even worse...

The best way (although not easy - especially if you already have a userbase) is to handle host keys separately and always do StrictHostKeyChecking=yes

[lrevnic]

Hi Michael,

Thank you for raising this. We'll have a look on how to solve this in the future.

Best regards,
Lucian