ssh -L (error: bind: Address already in use)

Question

Pretty simple, I know that this has happened to me before. Couldn't find a good answer on AU.

I was running an ssh session with ports bound:

ssh -L 3000:<server_name>:22

I just lost my connection. When I try to reconnect using the same command, I get the following error:

bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 3000

How do I reset ssh on my machine to allow the port to be bound again? Resetting the local machine works.

Solution 1

Couldn't you just kill whatever is using that port?

 lsof -ti:5901 | xargs kill -9

lsof -ti:5901 to find whatever is using port 5901.

Pass the whole thing to kill -9 to kill whatever was using port 5901.

Replace with the port you want to open up again.

Solution 2

I suppose you have still something connected to local port 3000.

You can find it with

netstat -tulpn | grep 3000 

and then dispose of it. For example in my machine:

[:~] % netstat -tulpn | grep 5900
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      2547/vino-server
tcp6       0      0 :::5900                 :::*                    LISTEN      2547/vino-server

correctly identifies the process waiting and connected on port 5900 (vnc server).

Another useful command is

fuser 3000/tcp 

...all of them may need to be run with sudo if you do not own the process which is opening the port.

Solution 3

I was able to recreate and fix it by doing the following:

• Open up something that will list your processes (ps -ae)
• Kill the process called sh (kill <proc_number>)

Then reopen the ssh connection

Alternatively, I have had success with:

killall ssh

In the terminal on the local machine

Solution 4

one more contender: ss

it can be used like this: ss -ltp | grep 3000 to find the program listening on port 3000

View more solutions

Comments

[kbuilds]

Thanks for the answer. I will have to dig into it to see if I can recreate the issue. The only possible application that could have been listening on port 3000 was the old ssh session that was disconnected. My user owned the process, so I assumed I would be able to run a killall ssh and have it die. Guess that's not the case

[kbuilds]

Yes, you could change the port number to whatever port is being blocked. I am going to mark this as the answer.

[ACV]

Thanks for the reminder to use sudo - that's what I was missing.

[octern]

If you are cautious and/or forgetful like me, you may wish to run lsof on its own and find out what the process is before killing it. lsof -ti:5901 will return a process number, which you then pass to kill -9

[Michael]

what if nothing is using port 5901 (or whatever local port you are specifying)?

[rich remer]

Try sudo if the process isn't coming up with lsof

[Joseph Garvin]

I see no processes even with sudo.

[TheDudeAbides]

There is no reason to kill -9 unless the program is completely unresponsive. Killing a process with signal #9 (SIGKILL) terminates it immediately without giving the process a chance to flush buffers, close filehandles and sockets, remove temporary files, etc., all of which the process can do if you use kill (defaults to SIGTERM), followed by kill -1 (SIGHUP; hangup) and kill -2 (SIGINT; what Ctrl+C sends) if that doesn't work, and finally kill -9 if nothing else works.

[Boson Bear]

indeed kill -9 could cause unexpected exit of processes