Interesting problem with 3.0p1 and IPv6
Gert Doering
gert at greenie.muc.de
Tue Nov 13 01:36:30 EST 2001
Hi,
I just ran into an interesting problem with 3.0p1 on FreeBSD 4.0 and
IPv6/v4 mapped addresses.
If I do "ssh -v machine", where "machine" has an IPv4 address in the
DNS, everything works fine (machine is "hilbert.space.net"):
debug1: Connecting to hilbert [194.59.182.6] port 22.
...
Warning: This may be due to an old implementation of ssh.
debug1: Received server public key (767 bits) and host key (1024 bits).
The authenticity of host 'hilbert (194.59.182.6)' can't be established.
RSA1 key fingerprint is c6:09:28:90:71:04:f8:0c:ca:6e:30:41:37:f2:76:ea.
Are you sure you want to continue connecting (yes/no)?
(I know that this machine should retire - it will, but that's not the
point). Everything is OK.
Now, if I do "ssh -v cname" where "cname" is a CNAME to the same
machnie, the following happens:
$ ssh -v hilberto
OpenSSH_3.0p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Seeding random number generator
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 0
debug1: Connecting to hilberto [::ffff:194.59.182.6] port 22.
debug1: Allocated local port 904.
(-> note the different address format!)
Warning: This may be due to an old implementation of ssh.
debug1: Received server public key (767 bits) and host key (1024 bits).
(-> so far, everything fine)
check_host_key: getnameinfo failed
debug1: Calling cleanup 0x8062b68(0x0)
*boom*.
Huh? OK. So I disable IPv6, and try again:
$ ssh -v -4 hilberto
OpenSSH_3.0p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Seeding random number generator
debug1: restore_uid
debug1: ssh_connect: getuid 0 geteuid 0 anon 0
debug1: Connecting to hilberto [194.59.182.6] port 22.
...
debug1: Received server public key (768 bits) and host key (1024 bits).
The authenticity of host 'hilberto (194.59.182.6)' can't be established.
RSA1 key fingerprint is c6:09:28:90:71:04:f8:0c:ca:6e:30:41:37:f2:76:ea.
Are you sure you want to continue connecting (yes/no)?
-> back to operation.
Unfortunately, I can't work around using CNAMEs in the specific
application ("cvs" use over SSH, and cvs-server being a CNAME onto the
actual box being used).
This leaves three interesting questions:
* why is it using IPv6/v4 mapped addresses when hitting a CNAME?
* why is this failing?
* is there a way to force "-4" from the ssh_config file? As we're not
using IPv6 on that machine *yet*, this would be fine. Recompilation
would work, but would break machine consistency ("everything from the
same source tree with the same options").
As far as I can see, there is no way to force -4 / -6 from the config
file - or did I overlook something?
The client machine is running 4.0-STABLE-20000617.
regards,
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert at greenie.muc.de
fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de
More information about the openssh-unix-dev
mailing list