Open tt opened 4 years ago
I should mention that it's of course possible to treat ""
, "::"
and "localhost"
separately with even less potential breakage but this doesn't solve the problem of client side resolution generally which was my intention for filing this issue.
/cc @hanwen @FiloSottile
+1. I'm particularly interested in localhost
case so that I don't need to create two listeners for IPv4/IPv6.
+1 The address should be resolved by the remote host, as is where the listen() call will happen, not the originating ssh client. Please fix this!
Just adding some more information, supposing it is a multi-homed server, with multiple IP addresses, calling net. Listen () using a hostname needs to resolve the name within the remote server to figure out which interface it should bind. The current implementation doesn't allow this.
wow...this is so insurmountable....
SSH Protocol : "channel forward message address is a string" Golang: "Noooooo we think it should be a Golang IP, which we will convert to a string :)"
All the above, plus I would add that a domain might not be "resolvable" from the client side in instances where a remote forward tcpip-forward
is created. "resolvable" should not be a requirement of a domain client side.
+1 This should be resolved on the remote host and treated as a string client side to allow the remote host to preform the lookup on what hostname qualifies to access the connection
or just simply not to handle forwarded-tcpip
channel before any ListenTCP
called, so we can implement our own handling for this case
update:
i read the source code, the handleForwards
does only called once ListenTCP
or ListenUnix
is called (at least in the latest version)
Change https://go.dev/cl/599995 mentions this issue: ssh: allow to bind to a hostname in remote forwarding
Hello, can you please confirm that the above CL fixes the issue? Thank you
(*ssh.Client).ListenTCP
expects an IP address (via*net.TCPAddr
) and therefore(*ssh.Client).Listen
attempts to resolve addresses.However, section 7.1 of RFC 4254 states:
There are two consequences of the current interface:
You can only provide resolvable names. This prohibits two of the strings with special-case semantics from working (
""
, reported in #33227, and"::"
).Resolution happens client side. This changes the meaning of the string
"localhost"
from being "all protocol families supported by the SSH implementation on loopback addresses only" to being only one of those and may provide a different result for other names (AWS hostnames resolving to internal addresses inside a data center comes to mind).Outside of defining a new public interface, I think the least breaking change would be to extract an unexported
listenTCP
function taking a string address and call this fromListen
which can then drop resolution but of course if you're relying on that behavior, it will still be surprising.I'm happy to submit a pull request but I'd appreciate some thoughts on how to best evolve the interface into something that both supports the scope of the RFC and doesn't disregard current users.