Eu tenho um servidor Linux rodando o xtightvnc no Ubuntu 18.04. Usando meu laptop, posso estabelecer uma conexão de túnel SSH usando o PuTTY no Windows e estabelecer uma conexão com o vnc por meio do host local: 5901. Isso funciona sem problema. No mesmo laptop, se eu inicializar no Debian 9 para tentar replicar a conexão usando:
ssh -L 5901:127.0.0.1:5901 -N -f -l username server_ip_address
Eu recebo um erro:
bind: Cannot assign requested address
Executando o mesmo comando com a opção detalhada:
ssh - v -L 5901:127.0.0.1:5901 -N -f -l username server_ip_address
Dá a seguinte saída (encurtei a saída):
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 protected]
debug1: forking to background
debug1: Entering interactive session.
debug1: pledge: network
Não tenho certeza do que isso significa, mas parece que a conexão anterior que abri no Windows ainda está ativa de alguma forma?
Eu também tentei encapsular no Debian usando o PuTTY e as mesmas configurações que eu tenho no Windows. Parece que consigo me conectar usando as mesmas configurações e posso me conectar ao vnc, embora isso não estivesse funcionando antes. (Talvez haja algum tipo de configuração de resfriamento que não conheço depois que uma conexão foi fechada e ainda mantém a conexão aberta / endereço designada?)
edit: Este é o erro que recebo usando o PuTTY no Linux se o endereço ainda não foi redefinido:
O principal problema aqui é que quando eu fecho o PuTTY, a conexão ainda está ativa (eu acabei de testar isso, pois ainda consegui me conectar ao vnc usando localhost: 5901). Eu saio das minhas sessões do PuTTY usando exit
.
A saída de netstat -tulpn
também pode ser relevante:
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
Atualização:
Parece que tudo está funcional, mas há um período de esfriamento depois que eu fecho minha conexão com o PuTTY antes de estabelecer outra conexão a partir de uma instância diferente do Windows ou Linux. Se alguém souber uma maneira de acelerar o processo, eu ficaria muito grato em ouvir a solução.
Atualização 2:
No linux parece que posso efetivamente matar o túnel ssh, por exemplo usando pkill ssh (para matar todas as conexões ssh atuais). Parece, portanto, que o PuTTY parece ter a tendência de não fechar corretamente o túnel para o servidor após o logout.