SSHトンネルを使用してVNCサーバーに接続できない

Ubuntu 18.04でxtightvncを実行するLinuxサーバーがあります。私のラップトップを使用して、WindowsでPuTTYを使用してSSHトンネル接続を確立し、localhost：5901を介してvncへの接続を確立できます。これは問題なく動作します。同じノートブックからDebian 9で起動し、次を使用して接続をコピーしようとすると：

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

エラーが発生します。

bind: Cannot assign requested address

verbose オプションを使用して同じコマンドを実行します。

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

次の出力を提供します（出力を短縮しました）。

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

これが何を意味するのかはわかりませんが、以前にWindowsで開いた接続がまだアクティブなようです。

また、Windowsと同じ設定を使用してPuTTYを使用してDebianでトンネルを設定してみました。以前は動作しませんでしたが、同じ設定を使用して接続でき、vncに接続できるようです。 （おそらく、私が知らないどんな種類の冷却設定がまだ接続を開いたままにしたり、接続が閉じられた後でもアドレスを割り当てるのでしょうか？）

編集：アドレスがまだリセットされていない場合、LinuxでPuTTYを使用したときに発生するエラーは次のとおりです。

ここで最大の問題は、おそらくPuTTYを閉じたときに接続がまだアクティブであるということです（localhost：5901を使用してvncに接続できたため、テストしました）。 PuTTYセッションを終了するために使用しますexit。

次の出力もnetstat -tulpn関連があるかもしれません。

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 

修正する:

すべてがうまく機能しているようですが、PuTTYへの接続を閉じた後、別のWindowsまたはLinuxインスタンスで別の接続を確立するのに時間がかかります。このプロセスをスピードアップする方法を知っている人がいる場合は、解決策を教えてください。

アップデート2：

Linuxでは、pkill ssh（現在のすべてのssh接続を終了）を使用してsshトンネルを効果的にシャットダウンできるようです。したがって、PuTTYはログアウト時にサーバーへのトンネルを正しく閉じない傾向があるようです。