Hi, I've noticed that JSch allows connections even when the remote host's key has been changed if StrictHostKeyChecking is "no". I'd expect it to throw a "HostKey has been changed" exception in this case. Is the current behaviour intentional?
I've written a small test program to demonstrate this behaviour - you can get it from https://lists.sourceforge.net/lists/listinfo/jsch-users. To reproduce: 1) Create a file known_hosts containing the RSA public key for a host (say "myserver"). 2) Check that you can connect with StrictHostKeyChecking="yes": francis@murr jsch-host-key-test $ java -jar target/jsch-host-key-test-1.0-SNAPSHOT-jar-with-dependencies.jar known_hosts yes myserver username password Linux myserver 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Sep 26 11:14:24 2011 from 192.168.1.133 username@myserver:~$ ^Cfrancis@murr jsch-host-key-test $ 3) Check that you can connect with StrictHostKeyChecking="no": francis@murr jsch-host-key-test $ java -jar target/jsch-host-key-test-1.0-SNAPSHOT-jar-with-dependencies.jar known_hosts no myserver username password Linux myserver 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Sep 26 11:51:55 2011 from 192.168.1.133 username@myserver:~$ ^Cfrancis@murr jsch-host-key-test $ 4) Create a file known_hosts_bad containing the RSA public key for a *different* host, but labelled as the key for myserver (i.e. the line should start with "myserver"). 5) Check that you get an error when you try to connect with StrictHostKeyChecking="yes": francis@murr jsch-host-key-test $ java -jar target/jsch-host-key-test-1.0-SNAPSHOT-jar-with-dependencies.jar known_hosts_bad yes myserver username password Exception in thread "main" com.jcraft.jsch.JSchException: HostKey has been changed: myserver at com.jcraft.jsch.Session.checkHost(Session.java:688) at com.jcraft.jsch.Session.connect(Session.java:313) at com.jcraft.jsch.Session.connect(Session.java:154) at com.bright.jsch.HostKeyCheckingTest.main(HostKeyCheckingTest.java:49) francis@murr jsch-host-key-test $ 6) Check that you get an error when you try to connect with StrictHostKeyChecking="no": francis@murr jsch-host-key-test $ java -jar target/jsch-host-key-test-1.0-SNAPSHOT-jar-with-dependencies.jar known_hosts_bad no myserver username password Linux myserver 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Sep 26 11:52:30 2011 from 192.168.1.133 username@myserver:~$ ^Cfrancis@murr jsch-host-key-test $ hmmm, it allowed me to connect even though the host key existed and didn't match! I'd expect it to fail in step 6 the same way it did in step 5. Francis ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ JSch-users mailing list JSch-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jsch-users
