Hello, we are trying to connect several devices to one master node in the mid. For this szenario we need some remote forwardings by ssh where each satellite node should establish a socket on another 127.0.0.0/8 address but each time the same port. Now it looks like we are going to be forced to 127.0.0.1 as long as we have GatewayPorts set to "no" by default. More explainations: client A is going to open a channel by: autossh -i privkey -R 127.0.0.2:2222:127.0.0.1:22 user@host client B is going to open a channel by: autossh -i privkey -R 127.0.0.3:2222:127.0.0.1:22 user@host client C is going to open a channel by: autossh -i privkey -R 127.0.0.4:2222:127.0.0.1:22 user@host But none of this clients is going to work this way as sshd is going to force each socket to 127.0.0.1. This works well if I set GatewayPorts to clientspecified. The documentation states: GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. tl;dr; Is it supposed by you to have sshd going to refuse a listening socket on other lo addresses than 127.0.0.1? Best regards, Florian
I have concerns about security with set GatewayPorts to other settings than no. So I am going to increase the importance on this issue.
Created attachment 2720 [details] add GatewayPortsAddresses option Maybe we could provide a filter to take a list of allowed bind addresses. E.g. GatewayPorts clientspecified GatewayPortsAddresses 127.0.0.0/8,2033::/24 untested patch attached.
I have tested this patch against the version of OpenSSH distributed in Ubuntu 16.04 (7.2p2). It works quite well, but I had to make some small changes: On line 1353, I believe it should be: if (arg == NULL || *arg == '\0') instead of: if (arg == NULL || *arg != '\0') I was also wondering why we cannot enforce these limitations for the loopback addresses as well? if (type == SSH_CHANNEL_RPORT_LISTENER && !is_loopback && fwd_opts->gateway_ports_explicit != NULL && addr_match_cidr_list(ntop, fwd_opts->gateway_ports_explicit) != 1) {
Hello, Wanted to comment that I too have found this bug. It still exists in the most recent sshd servers I have available to me to try this on (at work). Unfortunately, recompiling the server from edited source code isn't an option for me - nor is editing the server's config file (work's security restrictions). It seems like Gerik has a solution that could be included in future releases. Is there any chance this could get assigned to someone [much more competent/capable than I] so it could be pulled into future releases? I have to end by saying: Holy cow you guys are awesome for coding/developing sshd so well! Thank you so much!