Hello Team, I found something weird today, i tried to ssh into a box with the below command, instead of throwing an error it filled the middle to octet with zeros. Looks like ssh is greed and tries to left-pad everything with zero until it gets 4 octets. See the below two examples 1. hostname $/usr/local/bin/ssh -v 172.10 OpenSSH_7.3p1, OpenSSL 1.0.2j 26 Sep 2016 debug1: Reading configuration data /Users/name/.ssh/config debug1: /Users/name/.ssh/config line 2: Applying options for * debug1: Reading configuration data /usr/local/etc/ssh/ssh_config debug1: Connecting to 172.10 [172.0.0.10] port 22. ^C hostname $ 2. hostname $ssh -v 172 OpenSSH_6.9p1, LibreSSL 2.1.8 debug1: Reading configuration data /Users/name/.ssh/config debug1: /Users/name/.ssh/config line 2: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to 172 [0.0.0.172] port 22. debug1: connect to address 0.0.0.172 port 22: No route to host ssh: connect to host 172 port 22: No route to host
This is a feature of gethostbyname and earlier gethostbyaddr interfaces: class.hostnum and the 32bit integer equivalent are deprecated but still valid representations of an IP address. Compare: $ telnet 172.10 Trying 172.0.0.10... $ telnet 1.512 Trying 1.0.2.0... $ perl -le 'print 2**31+1' 2147483649 $ telnet 2147483649 Trying 128.0.0.1... If you really want something to complain about, try this: $ telnet 172.010 Trying 172.0.0.8... That all said, it's not something that OpenSSH has anything to do with. Also: hardware=68k? for real?
(In reply to Darren Tucker from comment #1) > This is a feature of gethostbyname and earlier gethostbyaddr err, those are both the earlier ones. The current one is getaddrinfo.
Looks like this behaviour originated in inet_aton() in 4.2BSD. https://en.wikipedia.org/wiki/Dot-decimal_notation
closing resolved bugs as of 8.6p1 release