Option -g notworking properly

Bug #61414 reported by Guillermo Pérez
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openssh (Debian)
New
Unknown
openssh (Ubuntu)
Triaged
Wishlist
Unassigned

Bug Description

Binary package hint: openssh-client

When you try to make a ssh-tunnel with the -g option it doesn't work.

ssh -g -L 1433:remote_host:1433 root@another_host 'while true; do sleep 18000; done'

This should open local port 1433 and redirect the connection via a ssh tunel to "another_host". Then send from this machine to "remote_host". It was working perfectly in an old machine.

If you try using the -g option (allow remote conections on local port) it binds to 0.0.0.0 (all interfaces) on the machine, but dumps this error:

bind: Address already in use

And it's oppening and using the port but not forwarding connections. An strace shows that it's traying to open the socket ¿twice?:

socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1433), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33047), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
close(4) = 0
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(4, {sa_family=AF_INET6, sin6_port=htons(1433), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
listen(4, 128) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfb716b8) = -1 EINVAL (Invalid argument)
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfb716b8) = -1 EINVAL (Invalid argument)
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl64(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(5, {sa_family=AF_INET, sin_port=htons(1433), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
write(2, "bind: Address already in use\r\n", 30) = 30

I solved out problem specifying the IP address to use for binding:

ssh -L LOCAL_IP:1433:remote_host:1433 root@another_host 'while true; do sleep 18000; done'

But the -g option should work anyway. I suppose it's a bug on ssh not just ubuntu but I can't check recent versions of other distros.

Revision history for this message
In , Daniel J. Priem (devel-walki) wrote : additional Information / workaround / solution?

Hello,
got the same problem today and readed some manpages
at first and used a little bit google also nerved some people on irc ;)

man ssh

-g Allows remote hosts to connect to local forwarded ports.

comment from me:
wich can be understand it is for use when doing
ssh -L (lokal) not when doing ssh -R

man sshd_config

GatewayPorts
Specifies whether remote hosts are allowed to connect to ports
forwarded for the client. By default, sshd binds remote port
forwardings to the __loopback__ address!!! ...... The
default is ``no''

So just edit /etc/sshd_config on the remote (-R) host
and type in
GatewayPorts yes

for checking if this works use
netstat -an | grep $yourportnumber
it shows something like if not written GatewayPorts....
tcp 0 0 127.0.0.1:$yourportnumber
0.0.0.0:* LISTEN

and shows
if GatewayPorts yes

tcp 0 0 0.0.0.0:$yourportnumber
0.0.0.0:* LISTEN

So all the time keep RTM :)

regards,
Daniel

--
Retrieve my key from:
www.keyserver.de
blackhole.pca.dfn.de
horowitz.surfnet.nl
keyID 7B196671
or send email with subject "fetch key"

Revision history for this message
In , Daniel Webb (public-danielwebb) wrote : Still a bug

This should still be at least a wishlist to change the man page to
clarify that -g only works for -L port forwarding. In the SSH docs,
"port forwarding" is pretty much described the same for -L and -R
forwarding, so the -g description in the manual should make clear that
it is only for -L forwarding.

Either that, or it should do as it says in the manual and allow remote
hosts to connect to the forwarded port during a -R forwarded port.

Revision history for this message
In , Daniel Webb (public-danielwebb) wrote : One more issue

(Sorry for two messages instead of one)

The other issue is that with the solution above (change the sshd_config
GatewayPorts setting) it is all or nothing. With the -g option
combined with the -L option, you can choose to allow remote hosts to
access some forwarded ports but not others. With the solution above,
there is no way to do this except firewall rules.

Revision history for this message
In , Stepan Koltsov (yozh-banana) wrote : ssh: remote port forwarding (-R) binds always to locast (ignores -g)

Package: ssh
Version: 1:3.6.1p2-9
Followup-For: Bug #228064

+1 for thig bug. Fix, please, -g is very desirable option.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux banana.mx1.ru 2.4.27-2-686 #1 Fri Mar 25 11:48:59 JST 2005 i686
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R

Versions of packages ssh depends on:
ii adduser 3.51 Add and remove users and groups
ii debconf 1.4.48 Debian configuration management sy
ii libc6 2.3.2.ds1-19 GNU C Library: Shared libraries an
ii libpam-modules 0.76-14 Pluggable Authentication Modules f
ii libpam0g 0.76-14 Pluggable Authentication Modules l
ii libssl0.9.7 0.9.7c-5 SSL shared libraries
ii libwrap0 7.6-ipv6.1-3 Wietse Venema's TCP wrappers libra
ii zlib1g 1:1.2.1-2 compression library - runtime

-- debconf information excluded

Revision history for this message
In , Lars Wilke (lw-lwilke) wrote : -g in combo with -R

Package: openssh-client
Version: 1:4.2p1-7
Followup-For: Bug #228064

The problem does not occur if one uses
GatewayPorts yes (server enforces bind to any interface)
GatewayPorts no (server enforces bind to loopback device)

If using 'clientspecified' on the server (server does what client says)
and issuing (on the client:)

   ssh -g -R 1234:bla:234 blubb

ssh should bind to all interfaces on blubb, as the docs say.
But it only connects to the loopback device.

But using

   ssh -g -R :1234:bla:234 blubb

works as expected.

When using -L instead of -R this problem does not occur.

regards
   --lars

-- System Information:
Debian Release: testing/unstable
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=C, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages openssh-client depends on:
ii adduser 3.85 Add and remove users and groups
ii debconf [debc 1.4.72 Debian configuration management sy
ii dpkg 1.13.18 package maintenance system for Deb
ii libc6 2.3.6-7 GNU C Library: Shared libraries
ii libcomerr2 1.38+1.39-WIP-2005.12.31-1 common error description library
ii libedit2 2.9.cvs.20050518-2.2 BSD editline and history libraries
ii libkrb53 1.4.3-6 MIT Kerberos runtime libraries
ii libncurses5 5.5-1.1 Shared libraries for terminal hand
ii libselinux1 1.30-1 SELinux shared libraries
ii libssl0.9.8 0.9.8a-8 SSL shared libraries
ii zlib1g 1:1.2.3-11 compression library - runtime

openssh-client recommends no packages.

-- no debconf information

Revision history for this message
Guillermo Pérez (bisho) wrote :

Binary package hint: openssh-client

When you try to make a ssh-tunnel with the -g option it doesn't work.

ssh -g -L 1433:remote_host:1433 root@another_host 'while true; do sleep 18000; done'

This should open local port 1433 and redirect the connection via a ssh tunel to "another_host". Then send from this machine to "remote_host". It was working perfectly in an old machine.

If you try using the -g option (allow remote conections on local port) it binds to 0.0.0.0 (all interfaces) on the machine, but dumps this error:

bind: Address already in use

And it's oppening and using the port but not forwarding connections. An strace shows that it's traying to open the socket ¿twice?:

socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1433), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(33047), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
close(4) = 0
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(4, {sa_family=AF_INET6, sin6_port=htons(1433), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
listen(4, 128) = 0
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfb716b8) = -1 EINVAL (Invalid argument)
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfb716b8) = -1 EINVAL (Invalid argument)
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl64(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(5, {sa_family=AF_INET, sin_port=htons(1433), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
write(2, "bind: Address already in use\r\n", 30) = 30

I solved out problem specifying the IP address to use for binding:

ssh -L LOCAL_IP:1433:remote_host:1433 root@another_host 'while true; do sleep 18000; done'

But the -g option should work anyway. I suppose it's a bug on ssh not just ubuntu but I can't check recent versions of other distros.

Revision history for this message
Guillermo Pérez (bisho) wrote :

I forget to mention that It happens both on dapper and edgy.

Revision history for this message
Roman Werpachowski (roman-werpachowski) wrote :

Confirming.

Revision history for this message
Rick Clark (dendrobates) wrote :

happens on feisty as well. need to research whether this functionality was changed upstream.

Enter passphrase for key '/home/rclark/.ssh/id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: Local connections to *:1234 forwarded to remote address localhost:1234
debug1: Local forwarding listening on :: port 1234.
debug2: fd 4 setting O_NONBLOCK
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 0.0.0.0 port 1234.
bind: Address already in use
debug1: channel 1: new [client-session]
debug2: channel 1: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 1: request env confirm 0
debug1: Sending command: while true; do sleep 18000; done
debug2: channel 1: request exec confirm 0
debug2: callback done
debug2: channel 1: open confirm rwindow 0 rmax 32768
debug2: channel 1: rcvd adjust 131072

Changed in openssh:
assignee: nobody → dendrobates
Rick Clark (dendrobates)
Changed in openssh:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Evan Carroll (evancarroll) wrote :

ecarroll@x60s:~$ ssh -2gxTD 5050 localhost
ecarroll@localhost's password:
bind: Address already in use

confirmed for Intrepid

Rick Clark (dendrobates)
Changed in openssh:
assignee: dendrobates → kirkland
status: Confirmed → Triaged
Revision history for this message
Gareth WIlliams (gareth-williams-csiro) wrote :

You can avoid the problem with the ssh '-4' option to use ipv4 only.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Removing myself as assignee. Changing priority to wishlist. Linking to Debian upstream bug report.

There are numerous work-arounds quoted both in Launchpad and Debian BTS.

:-Dustin

Changed in openssh (Ubuntu):
importance: Low → Wishlist
assignee: Dustin Kirkland (kirkland) → nobody
Changed in openssh (Debian):
status: Unknown → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.