| |||||||||||||
Merry Christmas from FreeBSDMerry Christmas from FreeBSDPosted Jan 6, 2012 13:50 UTC (Fri) by wookey (subscriber, #5501)Parent article: Merry Christmas from FreeBSD
I've had quite a recent situation where telnet did the job and ssh didn't:
Connecting to a newly-imaged board as part of the programming process.
You can do it for one board with ssh using a pre-generated key in the image, but then each subseqent board generates a 'Help the other end of the connection has changed - refusing to connect'. So far as I could tell there is no way to tell ssh not to do that, so it was entirely useless.
Telnet just worked, and in this case was being used on an internal wired network, firewalled by the programming machine so the use of cleartext logins really didn't matter.
And telnet is still a really useful testing tool for checking out if a port/service does what you expect. Sometimes nc will do instead but telnet is generally more convenient.
(Log in to post comments)
Merry Christmas from FreeBSD Posted Jan 6, 2012 14:06 UTC (Fri) by amonnet (subscriber, #54852) [Link]
Theses ssh options might help :
-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
+++
Merry Christmas from FreeBSD Posted Jan 6, 2012 14:19 UTC (Fri) by wookey (subscriber, #5501) [Link]
Realy? That's it? I tried the NoStrictHostKeyChecking thing, but not the null hosts file. You wouldn't believe how many hours I wasted not-discovering that, when all I had to do was wait a couple of years for an opportunity to ask on LWN :-)
Merry Christmas from FreeBSD Posted Jan 6, 2012 16:39 UTC (Fri) by raven667 (subscriber, #5198) [Link]
You should also be able to just remove the cached key entries from ~/.ssh/known_hosts or make the known_hosts file read-only so that new public keys aren't cached. That's what I've done before to handle provisioning networks where one sees new host keys for the same IPs all the time.
|
|||||||||||||