0

I have a Linux server running xtightvnc on Ubuntu 18.04. Using my laptop, I am able to establish an SSH tunnel connection using PuTTY on Windows and establish a connection to vnc through localhost:5901. This works without issue. On the same laptop, if I boot into Debian 9 to try to replicate the connection using:

ssh -L 5901:127.0.0.1:5901 -N -f -l username server_ip_address

I receive an error:

bind: Cannot assign requested address

Running the same command with the verbose option:

ssh - v -L 5901:127.0.0.1:5901 -N -f -l username server_ip_address

Gives the following output (I have shortened the output):

debug1: Local connections to LOCALHOST:5901 forwarded to remote 
address 127.0.0.1:5901
debug1: Local forwarding listening on 127.0.0.1 port 5901.
bind: Address already in use
debug1: Local forwarding listening on ::1 port 5901.
bind: Cannot assign requested address
channel_setup_fwd_listener_tcpip: cannot listen to port: 5901
Could not request local forwarding.
debug1: Requesting no-more-sessions@openssh.com
debug1: forking to background
debug1: Entering interactive session.
debug1: pledge: network

I'm not sure what this means, but it sounds as though the previous connection I opened under Windows is still active somehow?

I also tried to tunnel on Debian using PuTTY and the same settings I have under Windows. It seems I am able to connect using the same settings, and I can connect to vnc, though this wasn't working earlier. (Perhaps there is some sort of cool down setting I am not aware of after a connection has been closed out that still keeps the connection open/address assigned?)

edit: This is the error I receive using PuTTY on Linux if the address hasn't reset yet:

vnc error

The main issue here is perhaps that when I close PuTTY, the connection is still active (I just tested this, as I was still able to connect to vnc using localhost:5901). I exit my PuTTY sessions using exit.

The out put of netstat -tulpn might also be relevant:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
PID/Program name    
tcp        0      0 127.0.0.1:6342          0.0.0.0:*               LIS 
TEN      
21618/megasync      
tcp        0      0 127.0.0.1:5901          0.0.0.0:*               
LISTEN      
21527/Xtightvnc     
tcp        0      0 0.0.0.0:6001            0.0.0.0:*               
LISTEN      
21527/Xtightvnc     
tcp        0      0 127.0.0.53:53           0.0.0.0:*                 
LISTEN      
796/systemd-resolve 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               
LISTEN      
874/sshd            
tcp6       0      0 :::22                   :::*                    
LISTEN      
874/sshd            
udp    33024      0 127.0.0.53:53           0.0.0.0:*                           
796/systemd-resolve 

Update:

It seems that everything is functional, but that there is a cool down period after I close my connection with PuTTY before I can establish another connection from a different instance of Windows or Linux. If anybody knows a way to speed up the process, I would be grateful to hear the solution.

Update 2:

Under linux it seems I can effectively kill the ssh tunnel, e.g. by using pkill ssh (to kill all current ssh connections). It therefore seems that PuTTY appears to have the tendency to not properly close the tunnel to the server upon logout.

0

Looks like you have some process that is already listening on 5901. You can use another port:

ssh -L 15901:127.0.0.1:5901 login@host

This command will forward your local port 15901 to remote port 5901. So you need to connect to 127.0.0.1:15901 with your VNC client.

  • ssh -L 15901:127.0.0.1:5901 -N -f -L user server_address also gives an error, but it is slightly different: debug1: Local connections to LOCALHOST:15901 forwarded to remote address 127.0.0.1:5901 debug1: Local forwarding listening on 127.0.0.1 port 15901. debug1: channel 0: new [port listener] debug1: Local forwarding listening on ::1 port 15901. bind: Cannot assign requested address debug1: Requesting no-more-sessions@openssh.com debug1: forking to background debug1: Entering interactive session. debug1: pledge: network ipv6 issue here? – insideman Jun 12 '18 at 15:15
  • Look at parameters you've used: -L means "listen on port and forward to port", -l (small letter L) means "login". Command, you have executed has second -L instead of -l. Also, IMHO, it's simplier to use syntax user@host than -l user host. – Krzysztof Sawicki Jun 12 '18 at 15:18
  • Yes, sorry the second 'l' was a typo. I did use a lower case 'l' when I tried it. It seems there is indeed some sort of cool down mechanism when I establish a connection through an ssh tunnel. I just tried my original command 'ssh -L 5901:127.0.0.1:5901 -N -f -l user server-ip' and can connect to 'localhost:5901' using a vnc viewer. I guess my question then is, how do I speed up this process. My solution is functional, but it can be inconvenient at times to wait 1+ hour to be able to connect using a different instance. – insideman Jun 13 '18 at 3:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.