Quote:
Originally Posted by acid_kewpie
doesn't fit in with common sense, unless maybe ssh is not able to read back the contents of the file? Not sure that really makes any sense TBH, but what are the rights on the file and ~/.ssh?
|
Yeah, that was one of my first thoughts... both in terms of not making sense, and then in terms of permissions. Here they are:
Code:
Thu Oct 29 08:05:24 bchittenden@prodcbridge02:~
> ls -lad .ssh
drwx------ 2 bchittenden FooCoUsers 4096 2009-10-29 01:09 .ssh
Thu Oct 29 08:05:56 bchittenden@prodcbridge02:~
> ls -lad .ssh/known_hosts
-rwx------ 1 bchittenden FooCoUsers 1568 2009-10-29 01:58 .ssh/known_hosts
So 'bchittenden' has full access to the file. Furthermore, the known_hosts file is getting written to every time I try to log in to the other box, so I'm pretty sure that it's doing the checking under the correct owner.
Quote:
|
also what if you set StrictHostKeyChecking to yes or no?
|
It doesn't complain as loudly, but it still isn't working as I'd expect it to...
Code:
Thu Oct 29 08:18:43 bchittenden@prodcbridge02:~
> ssh -o StrictHostKeyChecking=no $cribbage
Warning: Permanently added '10.11.4.40' (RSA) to the list of known hosts.
(btw, I don't have access to /etc/hosts on prodcbridge02, hence $cribbage == 10.11.4.40 ... I think that there's a better way to do this, but it works for now).
it shouldn't have to do this: "Warning: Permanently added '10.11.4.40' (RSA) to the list of known hosts."
...plus, I don't really want to turn of StrictHostKeyChecking in an ongoing basis, just 'cause.
Quote:
|
Certainly appears to be client side, so add on a whole heap of -v's to the ssh command and read through the output too.
|
I've cut out a chunk of the results, this is the part that seems relevant:
Code:
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/bchittenden/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /home/bchittenden/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host 10.11.4.40
debug3: check_host_in_hostfile: filename /home/bchittenden/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /home/bchittenden/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 2 for host 10.11.4.40
The authenticity of host '10.11.4.40 (10.11.4.40)' can't be established.
RSA key fingerprint is 7f:b5:f6:3c:36:72:41:4d:0a:f0:f7:f2:36:50:1b:d6.
Still baffled. Could it be that the host key on $cribbage be type 1, and the ssh client on prodcbridge01 is only checking type 0 and type 2? (I'm speaking out of alternative orifices here, I don't even know what types 0 and 2 are, or if type 1 even exists).
ok... from /etc/ssh/sshd_config on cribbage:
Code:
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
Both files exist, are owned by root, and have permission 0600. I do know that corporate policy forbids use of DSA, but that shouldn't matter, given that the RSA host key exists.
Quote:
|
And this is not a networking question, it's not about routers, switches, ip addresses. moved to Linux - Software.
|
Thanks.
