Score:0

How to clear local ssh port for forwarding to remote?

sd flag

I'm using ssh forwarding local port to a bastion server(10.20.30.40), connect to remote RDS database.

ssh -i ~/.ssh/id_rsa -f -N -L 5432:db1.cluster-1.region.rds.amazonaws.com:5432 10.20.30.40 -v
...
Authenticated to 10.20.30.40 ([10.20.30.40]:22).
debug1: Local connections to LOCALHOST:5432 forwarded to remote address db1.cluster-1.region.amazonaws.com:5432
debug1: Local forwarding listening on ::1 port 5432.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 5432.
debug1: channel 1: new [port listener]
debug1: Requesting [email protected]
debug1: forking to background
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0

The 5432 on local port will be used. If create a new forwarding

ssh -i ~/.ssh/id_rsa -f -N -L 5433:db1.cluster-1.region.rds.amazonaws.com:5432 10.20.30.40 -v

The 5433 port will be used.

If start 5432 in a new terminal, it will be failed because already in use.

Authenticated to 10.20.30.40 ([10.20.30.40]:22).
debug1: Local connections to LOCALHOST:5432 forwarded to remote address db1.cluster-1.region.rds.amazonaws.com:5432
debug1: Local forwarding listening on ::1 port 5432.
bind [::1]:5432: Address already in use
debug1: Local forwarding listening on 127.0.0.1 port 5432.
bind [127.0.0.1]:5432: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 5432
Could not request local forwarding.
debug1: Requesting [email protected]
debug1: forking to background
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0

How to release these ports connection?

in flag
Close the previous connection.
uotn avatar
sd flag
@GeraldSchneider How to close the connection? Can it list all the ssh connection items?
in flag
list the running processes with `ps` and `kill` the process.
uotn avatar
sd flag
@GeraldSchneider Thank you! If you can write it down as an answer. I will accept it.
Score:0
in flag

The port is going to be blocked as long as your SSH session is active. If you weren't spawning it into the background with the -f parameter you could just log out or hit ctrl-c, you can't do that with the session in the background.

You can list running processes with ps. Then you kan kill the process.

$ ps  -af |grep ssh
username    2113    1822  0 10:19 pts/0    00:00:00 ssh -L 5433:db1.cluster-1.region.rds.amazonaws.com:5432 host
$ kill 2113
Score:0
it flag
RVT

As others have said in-comments... that port is bound to the process that launched it. It will stay open until that process exits.

You can use the -p argument to netstat to see what processes are holding which ports open. I'd highly suggest you limit that to only TCP ports with the -t flag, as well... and finally, turn off DNS lookups with the -n flag.

So, you're looking at something like:

netstat -npt

That should "list" all ports currently in the state table, along with the process ID or program name. That last part will likely require privilege escalation through something like sudo (or Cygwin "Run as Administrator")

For example:

$ sudo netstat -npt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:8651          127.0.0.1:50644         TIME_WAIT   -
tcp        0      0 127.0.0.1:8649          127.0.0.1:53761         TIME_WAIT   -
tcp        0      0 127.0.0.1:80            127.0.0.1:58488         TIME_WAIT   -
tcp        0    348 172.16.XXX.YYY:22       172.16.XXX.ZZZ:54272    ESTABLISHED 21020/sshd: russell
...
RVT avatar
it flag
RVT
Note that you can also add `-l` for "listening ports only."
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.