strange handling of ~/.ssh/known_hosts ?

[GoogleCodeExporter]

Details to follow

Original issue reported on code.google.com by grahampe...@gmail.com on 10 May 2007 at 10:41

[GoogleCodeExporter]

Consider issue-38 and issue-59 alongside each other.

I wonder whether known_hosts strangeness relates to 
flie locking/unocking
or the times at which changes are written to 
known_hosts

Original comment by grahampe...@gmail.com on 11 May 2007 at 1:29

[GoogleCodeExporter]

Cross-reference issue-27 and issue-59

Original comment by grahampe...@gmail.com on 11 May 2007 at 1:35

[GoogleCodeExporter]

issue-27 =
host key verification failure
(arising from reconfiguration of server) 
which in my experience usually requires 
*removal* of the offending key from known_hosts

issue-59 =
*addition* of an acceptable key to known_hosts

Issues may be duplicates but for the moment I'll treat them as separate.

Original comment by grahampe...@gmail.com on 11 May 2007 at 1:40

[GoogleCodeExporter]

Briefly, messily, to the best of my recollection:

For my *good* favourite for ndrive — which specifies a valid path on server 
(ideally it should not, but if path is omitted the connection defaults to a 
lesser path — a separate issue)

Following the update to 1.1 b2 of MacFusion, mount failure occurred. 

If I removed 
~/.ssh/known_hosts
then mount was successful. 

If I left MacFusion running
then launched CyberDuck
and connected to the same service
then Cyberduck would prompt me to accept the key (expected/OK)
and connect successfully

but a review of 
~/.ssh/known_hosts 
showed that it was zero bytes

^^^ zero bytes made me wonder vaguely whether something other than Cyberduck 
(MacFusion, maybe?) had 
an inappropriate lock on the file

Scattered around my Desktop and at 
~/.ssh
I have three or more versions of 
known_hosts
to consider. 

Original comment by grahampe...@gmail.com on 11 May 2007 at 3:56

[GoogleCodeExporter]

I wondered whether it's appropriate to share obscurely at 
http://pastie.textmate.org/
the different versions of known_hosts but re
http://www.eweek.com/article2/0,1759,1815795,00.asp 
and the like I see that this could be bad practice.

I might share these with Michael in some other way, maybe OTR chat in Adium. 

OTOH, at a glance I couldn't see any problem with the keys stored in any one of 
the files. 

Cyberduck was certainly happy with each one of the files, and the keys therein 
(although there *was* that 
curiosity of the zero byte file after I allowed Cyberduck to accept a key for 
the first time). 

I still wonder whether there's an issue with the way that 
known_hosts 
is handled by MacFusion 
or by MacFusion in combination with other software that might use the 
known_hosts file.

Original comment by grahampe...@gmail.com on 11 May 2007 at 10:17

[GoogleCodeExporter]

> If I left MacFusion running
> then launched CyberDuck
> and connected to the same service
> then Cyberduck would prompt me to accept the key (expected/OK)
> and connect successfully
> 
> but a review of 
> ~/.ssh/known_hosts 
> showed that it was zero bytes

I realise now that Cyberduck defaults to allow (but not always) and only if I 
opt for *always* does it write to 
the known_hosts file. 

(A test today confirms that MacFusion running does _not_ prevent Cyberduck from 
writing to known_hosts.)

Original comment by grahampe...@gmail.com on 19 May 2007 at 6:08