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 email@example.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:
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
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
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.
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.