ssh can connect to a specific IPv6 address when the bare address ('2001:db8:1234::1') is specified on the command line. However, various applications (e.g., scp) use the convention of enclosing the IPv6 address in brackets as delimiters: '[2001:db8:1234::1]:/tmp/file'. Currently, ssh cannot handle the bracket-delimited addresses passed by client applications such as Subversion; instead, it tries to look up the address as a hostname and predictably fails. Interpreting IPv6 addresses in brackets would be more consistent internally and more compatible with applications that use SSH transport. Steps to reproduce: 1) SSH to an IPv6 address: '# ssh 2001:db8:1234::1' => successful 2) SSH to address with brackets: '# ssh [2001:db8:1234::1]' => 'ssh: Could not resolve hostname [2001:db8:1234::1]: Name or service not known'
Some day, someone somewhere will get too tired of re-implementing / duplicating for the Nth million time the same silly bracket parsing/restoring code. Like for instance this recent one: https://chromium-review.googlesource.com/#/c/312719/3/server/base_utils.py Then he or she will fix this ssh issue and get a medal. In the meantime, let's all keep duplicating ugly and buggy parsing code in all our scripts :-(
I don't think we want to do this at the moment. Bracketed IPv6 addresses are mostly used when suffixed by port numbers or when the address boundaries could be otherwise confused with adjacent text (e.g. "scp [::1]:/bin/ls /tmp"), but ssh doesn't support host:port-style destinations and the only potentially adjacent characters are the "user@" prefix. If this changes then we'll certainly revisit this.
Damien, this feature request is not about any "advanced" syntax like [aa::bb]:42, it's only about the basic [aa:bb] syntax. I think the start of the description misled you. There are many other tools/scripts which support only the basic syntax. AFAIK only ssh has "special needs" for even the most basic [aa:bb] syntax. This request is about saving every single automation script in the universe the ssh-specific hacks required for these special needs - for even the most basic [aa::bb] syntax. To close please provide a reason that doesn't refer to any advanced syntax. Possible reasons: "no one will ever have the time", "we don't automate ssh",... PS: happy 10 years anniversary to this request! A lot has changed: https://www.google.com/search?q=ipv6+stats
We don't plan on changing this for plain hostnames, but ssh does now support the ssh: URI scheme that supports square-bracket delimited hostnames. So you can prefix your [hostnames] with "ssh://" and be good.
> ssh does _now_ support... Could you be a bit more specific wrt the exact feature and timing? Ideally refer to some changelog, commit, release note etc.? > ... the ssh: URI scheme that supports square-bracket delimited hostnames. I don't understand how hostnames matter to this feature request 1602. It was very specifically about literal IPv6 addresses. For hostnames I expect ssh to merely invoke getaddrinfo and follow the system policy in gai.conf or equivalent. Forcing IPv4 or IPv6 can already be done with -4 or -6 so I hope hostname syntax is irrelevant to IPv4/v6. > We don't plan on changing this for plain hostnames, Why would ssh treat plain hostnames differently from FQDNs? For anything, not just IPv6. I see this has been closed as "WONTFIX" again so I'm not going to re-open it again but I'm afraid I really don't understand the newer rationale(s) either.
Just did some more testing with OpenSSH_8.1p1 Apr 2020. It looks like someone did the work to implement a new ssh://[brackets] syntax except in the case where brackets are actually needed. Baffling. So these now work: ssh ssh://[host.local]:23 ssh ssh://[192.168.1.1]:22 Nice, but apparently pointless because no idea why anyone would use brackets with IPv4 or hostnames. These work too: ssh ssh://host.local:23 ssh ssh://192.168.1.1:22 Back to this bug, all these fail with the usage message: ssh ssh://[2001:db8:1234::1] ssh ssh://[2001:db8:1234::1]:22 ssh ssh://2001:db8:1234::1 As before, these all fail with "Name or service not known" ssh [2001:db8:1234] ssh [2001:db8:1234]:22 https://tools.ietf.org/html/rfc2732 Format for Literal IPv6 Addresses in URL's
> I see this has been closed as "WONTFIX" again so I'm not going to re-open it again This was about not supporting this: ssh [2001:db8:1234::1] I'm tentatively re-opening now because I really can't find any reason not to support this: ssh ssh://[2001:db8:1234::1]
Fun fact: ssh _does_ produce brackets for IPv6 addresses in .ssh/known_hosts: [review.openstack.org]:29418,[104.130.246.32]:29418 ssh-rsa AAAAB3NzaC1yc2... [review.openstack.org]:29418,[2001:4800:7819:103:be76:4eff:fe04:9229]:29418 ssh-rsa AAAAB3Nza... But it can't parse back what it printed itself: ssh ssh://[review.openstack.org]:29418 OK ssh ssh://[104.130.246.32]:29418 OK ssh ssh://[2001:4800:7819:103:be76:4eff:fe04:9229]:29418 FAIL with usage message OpenSSH_8.2p1, OpenSSL 1.1.1g 21 Apr 2020 Digression: with many operating systems using randomized IPv6 addresses by default for privacy reasons, using ssh to .local systems on the same LAN causes uncontrollable .ssh/know_hosts growth.
(In reply to Marc Herbert from comment #8) > Digression: with many operating systems using randomized IPv6 > addresses by default for privacy reasons, using ssh to .local > systems on the same LAN causes uncontrollable .ssh/know_hosts growth. You can set CheckHostIP=no for those hosts, eg Host *.local CheckHostIP no