I'm using SSH port forwarding to get to a DB behind a firewall. I use the following command (forwards remote 5432 port to local 5430):
ssh -i privatekey -v -N -A \
ec2-user#host -fNT -4 -L \
5430:rds-endpoint.us-west-2.rds.amazonaws.com:5432
This command always returns exit code 0, but approx. once in ten cases it doesn't actually open the tunnel and I get connection refused error when I try to connect to localhost:5430.
I've checked the debug output and noticed that there's one difference. The unsuccessful runs' debug output ends with this:
debug1: channel 0: new [port listener]
debug1: Requesting no-more-sessions#openssh.com
debug1: forking to background
while the successful runs have 3 more lines after the forking to background line:
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00#openssh.com want_reply 0
So I assume SSH fails to "enter interactive session". Is there a way to fight this bug and make the port forwarding command reliable?
Related
I have created a Virtual Machine with multipass, I am trying to connect to this instance over ssh, with the command:
ssh -vvv -i back_key ubuntu#10.136.38.199
At first, I tried to connect to my instance from a Github Action, but I got a timeout error, I thought that it may have been a Github issue.
But with a second computer, I couldn't connect to the VM either.
The error I got:
ubuntu#laptop-number2:~$ ssh -vvv -i back_key ubuntu#10.136.38.199
OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f 31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 10.136.38.199 is address
debug2: ssh_connect_direct
debug1: Connecting to 10.136.38.199 [10.136.38.199] port 22.
debug1: connect to address 10.136.38.199 port 22: Resource temporarily unavailable
ssh: connect to host 10.136.38.199 port 22: Resource temporarily unavailable
Wheither it's from Github Action or from a second computer, I can't connect to the multipass instance over ssh.
But, I can connect to instance with the host computer.
I thought it may be a Firewall issue, so I disabled it with:
sudo systemctl stop ufw
I did this in the VM and the host machine, then I restarted ssh inside the instance.
The reason: I got those issues was the network I was working on. The ssh port for the server couldn't be reached.
I knew that by using nmap:
nmap -Pn -p 22 <IP_OF_SERVER>
The result was: The port is filtered.
Working with a mobile network didn't solve it either, since my ISP block this port. The solution was using the network from my house for the ssh server.
So I've managed to cut off the branch I was standing on so to speak. I was connected to a server and I ran sudo pkill where the PID was a process I thought I wanted to kill and and I think I killed the ssh process that was listening on port 22.
Here is what happens when I try to connect now:
<computer>:~ <user>$ ssh -p 22 -v <user>#<ipaddress>
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: /etc/ssh/ssh_config line 51: Applying options for *
debug1: Connecting to <ipaddress> [<ipaddress>] port 22.
debug1: connect to address <ipaddress> port 22: Connection refused
ssh: connect to host <ipaddress> port 22: Connection refused
Is there anyway I can connect via SSH? Or am I out of luck until I can login to the machine itself and restart the SSH server?
Try first a curl -v telnet:<user>#<ipaddress>:22
If it does not display a "Connected" message... there is no listener on port 22, which means the SSH daemon has been terminated.
You would then indeed wait for the opportunity to log on again, and restoart the SSH daemon.
I'm trying to use rsync on my dev server to download files to my local machine after checking out a branch on the dev server.
Before using wsl2, I used to be able to do the following:
Remote server
rsync -ave "ssh -p 22001" --delete --exclude-from ~/rsync_exclude_list.txt ~/as/ alex#localhost:/home/alexmk92/code/project
Local SSH config
Host dev-tunnel
HostName dev.sever.co.uk
User as
ControlMaster auto
ControlPath ~/.ssh/sockets/%r#%h:%p
RemoteForward 22001 localhost:22
Host dev
HostName dev.server.co.uk
User as
RequestTTY yes
RemoteCommand cd as; bash
I can then run these with ssh dev and ssh -fvN dev-tunnel if from the remote server I type ssh -p 22001 alex#localhost then I get:
debug1: remote forward success for: listen 22001, connect localhost:22
debug1: All remote forwarding requests processed
debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 22001, originator 127.0.0.1 port 34472
debug1: connect_next: host localhost ([127.0.0.1]:22) in progress, fd=5
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connection failed: Connection refused
connect_to localhost port 22: failed.
debug1: channel 1: free: 127.0.0.1, nchannels 2
I'm guessing this is because WSL2 no longer runs on localhost, and is instead isolated within Hypervisor. Which probably means windows is receiving this request on localhost:22 (where no SSH server is running) and then hangs up the connection.
How can I forward the request to my WSL2 SSH process?
It is possible to add a port mapping to WSL2 machines, using the following WSH script:
$port = 3000;
$addr = '0.0.0.0';
$remoteaddr = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteaddr -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';
if( $found ) {
$remoteaddr = $matches[0];
} else {
echo "Error: ip address of WSL 2 cannot be found";
exit;
}
Invoke-Expression "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr"
Invoke-Expression "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteaddr"
echo "Success: Port mapping added!";
Of course, you need to change to port and maybe the IP address (first two lines)
Maybe you need to run the script as admin...
I mount a SSH port forwarding tunnel to a remote server RemoteServerSSH and forward the 55555 port to a non-existing equipment (this is what I try to test).
$ hostname
MyMachine
Setting the forwarding tunnel
$ ssh -q -N -p 22 -vvv \
-i ~/.ssh/MyKey \
-o Compression=yes \
-o ServerAliveInterval=3 \
-o serverAliveCountMax=3 \
-L *:55555:RemoteDownItem:9100 user#RemoteServerSSH
Testing the tunnel
When I telnet the device directly I got the correct behavior (not connected). However, when I try to reach it through the tunnel, telnet says it's connected:
$ telnet RemoteDownItem 9100 # Not Connected = OK
$ telnet MyMachine 55555 # Connected! Why? should be same as above
When I measure the telnet time connection, it is instantaneous (1ms!).
It is the SSH client that answers me, it does not cross the ssh tunnel! Why ?
Verbose
...
debug1: Local connections to *:55555 forwarded to remote address 10.220.9.183:9100
debug3: channel_setup_fwd_listener: type 2 wildcard 1 addr NULL
debug1: Local forwarding listening on 0.0.0.0 port 55555.
debug2: fd 4 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: channel 0: new [port listener]
debug3: sock_set_v6only: set socket 5 IPV6_V6ONLY
debug1: Local forwarding listening on :: port 55555.
debug2: fd 5 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 1: new [port listener]
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: Connection to port 55555 forwarding to 10.220.9.183 port 9100 requested.
debug2: fd 6 setting TCP_NODELAY
debug2: fd 6 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK
debug1: channel 2: new [direct-tcpip]
Question
Is there an SSH parameter to forward the telnet connection directly to the endpoint?
Project Related Question
Telnet connect to non-existing adress
Consider how a tunnel works. When you run something like ssh -L *:55555:RemoteDownItem:9100 user#host, the port forward is handled like this:
The local ssh instance binds to TCP port 55555 and listens for connections.
An "originator" connects to port 55555 on the local system. The local ssh instance accepts the TCP connection.
The local ssh instance sends a "direct-tcpip" request through the SSH connection to the remote ssh server.
The remote ssh server attempts to connect to host "RemoteDownItem" port 9100.
At step 4, if the ssh server is able to connect to the target of the tunnel, then the ssh client and server will each relay data between the originator and the target through the direct-tcpip channel.
Alternately, at step 4, the server may not be able to make the TCP connection to the target. Or the server may be configured not to permit forward requests. In either case, it will respond to the client with an error (or a message saying the channel is closed).
At this point, the only thing that the local ssh instance can do is to close the TCP connection to the originator. From the perspective of the originator, it successfully connected to a "server" (the ssh client), and then the "server" almost immediately closed the connection.
The OpenSSH software doesn't contain any logic to handle this in a more sophisticated way. And handling it in a more sophisticated way may be difficult. Consider:
The remote SSH server has no idea whether it can connect to "RemoteDownItem" port 9100 until it tries. So it's problematic for ssh to figure out in advance that the port forward won't work.
Even if one attempt to connect to the target fails, the next attempt might succeed. So it's problematic for ssh to assume the port forward won't work, just because one attempt failed.
The remote SSH server could successfully connect to the target, and then the target could immediately close the TCP connection. So the ssh server, ssh client, and originator all have to handle this behavior anyway.
So I'm on my local machine, and I'm sshing into a google compute server.
From this google compute server, I'm trying to establish an ssh tunnel to a third party server ($host) using the following command:
ssh username#$host -L 3306:127.0.0.1:3306 -N
And after hanging for 20-30 seconds, I get:
ssh: connect to host $host port 22: Connection timed out
I can use the exact same command on my local machinet to the third party server and it works fine.
I've killed anything using the 3306 port on the google compute server.
I've opened port 22 and 3306 on the google server through the interface (through I can't tell if this applies to outbound connections also).
Not sure where to go from here, any help would be appreciated.
Edit1: The google server can successfully ping the third party server.
Edit2: Just tried it from the company server, it doesn't work there either. Both he google-compute and the company server are linux (Deb Wee and Ubuntu respectively) and the local machine is windows. The fact that I'm sshing into them shouldn't make a difference should it?
Edit3: Changed the default SSH port on the google server to 22222 and connected to it using that instead. Trying to connect to third party now with:
sudo ssh -p 22 username#$host -L 3306:127.0.0.1:3306 -N -v -v -v
Debug output is:
OpenSSH_6.6.1, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to $host [$host] port 22.
And after that it just hangs.
Debug output on local machine using same command is is:
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug2: ssh_connect: needpriv 0
debug1: Connecting to $host [$host] port 22.
debug1: Connection established.
*other junk*
Turns out the third party server had ssh blocked from anywhere outside Australia
-_-