ssh 3.3p1 and 3.4p1 both exhibit this problem on a Tru64 5.1 box. When attempting to ssh to another host: Name does not resolv to supplied parameters; neither nodename nor servname were passed. Doesn't matter what host I try to ssh to, same result. My DNS works properly, same result for hosts listed explicitly in /etc/hosts.
I'm not seeing this on Tru64 4.0G or 5.1A with OpenSSH 3.4p1. What does "rsh [server]" say? Are you using IPv6?
rsh <host> works fine for the one host I can test it for. I am not using IPv6. Tru64 machine is running in Enhanced Security mode (SIA), but I don't see how that should matter here. I see this in debug output: [jakari@poptart ~] ssh -v -v frogstar OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 ssh: frogstar: Name does not resolv to supplied parameters; neither nodename nor servname were passed.
That is the error I get if I try to ssh to something that doesn't resolve: $ ssh xyzzy ssh: xyzzy: Name does not resolv to supplied parameters; neither nodename nor servname were passed. $ but ssh to hosts that resolve works fine.
I get the same error either way. Looks like address reolution is broken somewhere. I still have the 2.9p2 binaries and they work fine. [jakari@poptart ~] host frogstar frogstar.bithose.com. has address 192.168.1.72 [jakari@poptart ~] ssh frogstar ssh: frogstar: Name does not resolv to supplied parameters; neither nodename nor servname were passed. [jakari@poptart ~] host foobar Host foobar. not found: 3(NXDOMAIN) [jakari@poptart ~] ssh foobar ssh: foobar: Name does not resolv to supplied parameters; neither nodename nor servname were passed.
I had the same problem, but I figured out that getaddrinfo(host, strport, &hints, &aitop) (in ssh_connect) returns EAI_NONAME if hints.ai_family is AF_UNSPEC, even if both host and strport is valid. If I run configure with --with-ipv4-default then family is set to AF_INET and everything seems to work.
Confirmed that ./configure --with-ipv4-default fixes the problem, thanks.
Mass change of RESOLVED bugs to CLOSED