problem specifying port to ssh

Don Cohen don-temp28 at
Fri Apr 7 11:47:03 EST 2006

Daniel Kahn Gillmor writes:

 > nisplus relies on a NIS+ server being present (and configured).  If
 > your workstation is looking for NIS+ information from a host that is
 > not providing it, it probably will fail.
In which case a well behaved glibc would go on to use the next method
in the list.  So I think this is a bug.

 > What does the following command show when your system is in the "does
 > not work" configuration:
 >   getent services 22
 > a normal system with glibc and a well-configured /etc/nsswitch.conf
 > should respond something like:
 > ssh                   22/tcp
It shows that in either configuration, which is what I'd expect
since that's what's in /etc/services, and files comes first.

 >  > You mean I can somehow arrange that 
 >  >  ssh -p 22
 >  > and ssh -p 2222
 >  > resolve to different IP addresses?  How?
 > it's not to different IP addresses, but rather different sockets.

How (if at all) does that affect the network traffic that goes out?

 > from man getaddrinfo (note mention of getservbyname):
 >  The getaddrinfo(3) function combines the functionality provided by
 >  the getipnodebyname(3), getipnodebyaddr(3), getservbyname(3), and
 >  getservbyport(3) functions into a single interface.  The thread-safe
 >  getaddrinfo(3) function creates one or more socket address structures
 >  that can be used by the bind(2) and connect(2) system calls to create
 >  a client or a server socket.
 > So getaddrinfo can create full socket addresses (which, for TCP or UDP
 > sockets, would contain port numbers).  Passing the string "22" to the
 > service argument to getaddrinfo() will force a lookup via the name
 > service switch (which is configured via /etc/nsswitch.conf).

This still doesn't explain why ssh -p 22 should be any different
from ssh without -p at all.  I'd expect the same underlying call
to one of the functions above, and I would expect the attempt to
resolve the host name to not depend on the port at all.

More information about the openssh-unix-dev mailing list