Advance ssh config file - ssh

How to ssh directly to Remote Server, below is the details description.
Local machine ---> Jump1 ----> Jump2 ----> Remote Server
From local machine there is no direct access to Remote Server and Jump2 is disable
Remote Server can only be accessed from Jump2
There is no sshkegen to remote server we have to give the paswword manually.
from Local Machine we access the Jump1 with ip and port 2222 then from Jump 1 we access the Jump2 with host name default port 22.
With ssh/config file we were able to access the jump2 server without any problem. But my requirement is to directly access the remote server.
is there any possible way I don't mind entering the password for remote server.
Log
ssh -vvv root#ip address
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to ip address [ip address] port 22.
My Config file
Host jump1
Hostname ip.109
Port 2222
User avdy
Host jump2
Hostname ip.138
Port 22
ProxyCommand ssh -W %h:%p jump1
User avdy
Host remote-server
Hostname ip.8
Port 22
ProxyCommand ssh -W %h:%p jump2
User root

Set your ~/.ssh/config:
Host Jump1
User jump1user
Port 2222
Host Jump2
ProxyCommand ssh -W %h:%p Jump1
User jump2user
Host RemoveServer
ProxyCommand ssh -W %h:%p Jump2
User remoteUser
Or with new OpenSSH 7.3:
Host RemoveServer
ProxyJump jump1user#Jump1,jump2user#Jump2
User remoteUser
Then you can connect simply using ssh RemoteServer

Related

Cannot ssh to WSL from windows PC

I want to ssh to WSL on my windows PC.
The port forwarding rule has been set up properly with netsh.
ADDRESS PORT ADDRESS PORT
--------------- ---------- --------------- ----------
0.0.0.0 3333 172.19.56.231 22
The address to be connected is obtained through wsl -d "Ubuntu-22.04" hostname -I
I can ssh to WSL through ssh shflte#172.19.56.231. But I cannot ssh to WSL through ssh shflte#192.168.100.156 -p 3333(192.168.100.156 is my PC's address). So I guess the problem did not come from the WSL.
ssh message:
ssh shflte#192.168.100.156 -p 3333 -v
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Reading configuration data C:\\Users\\SH/.ssh/config
debug1: Connecting to 192.168.100.156 [192.168.100.156] port 3333.
debug1: connect to address 192.168.100.156 port 3333: Connection refused
ssh: connect to host 192.168.100.156 port 3333: Connection refused
Can anyone tell me why did I get Connection refused?
This is possibly related to a firewall problem. To verify that the firewall is allowing incoming connections on port 3333, you can do the following command in PowerShell:
netsh advfirewall firewall show rule name=all dir=in | findstr "3333"
In the case where the firewall is actually the problem, you can allow incoming connections on port 3333:
netsh advfirewall firewall add rule name="SSH_WSL" dir=in action=allow protocol=TCP localport=3333

WSL2 SSH RemoteForward connect back

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...

SSH config file works globally but not as command line parameter

I have written a ssh config file that specifies a typical jump server setting:
Host host1
HostName 11.11.11.11
User useroo
IdentityFile some/key/file
Host host2
HostName 192.11.11.10
User useroo
IdentityFile some/other/key
ProxyCommand ssh -W %h:%p host1
I can successfully connect with ssh host2 when I save this as ~/.ssh/config. However if I save the config somewhere else as xy_conf, calling ssh -F xy_conf host2 results in an error saying
ssh: Could not resolve hostname host1: Name or service not known
ssh_exchange_identification: Connection closed by remote host
Is this the expected behavior? How else can I set this config temporarily? I don't want to set it as ~/.ssh/config.
OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014
Using different location for ssh_config affects only the first call of ssh, but not the second (from ProxyCommand). You need to pass the same argument to the secondssh` too:
ProxyCommand ssh -F xy_conf -W %h:%p host1

SSH Socks Server

I'm trying to run a ssh SOCKS server on Windows 7 (listening on port 12345).
Here's the output I get on Cygwin:
$ ssh -v -D 12345 localhost
OpenSSH_6.8p1, OpenSSL 1.0.2c 12 Jun 2015
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to localhost [::1] port 22.
debug1: connect to address ::1 port 22: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: connect to address 127.0.0.1 port 22: Connection refused
ssh: connect to host localhost port 22: Connection refused
Why is it trying to connect to localhost:22?
Looks like it's trying to reach sshd running on localhost.
I thought the ssh client was enough to set up a local SOCKS server. If it isn't, why do I need sshd running?
From https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding:
"Dynamic port forwarding turns your SSH client into a SOCKS proxy server"
To explain why you need a (remote) ssh server, ssh can do three (or four) kinds of forwarding; quoting the man page:
-L Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side. This
works by allocating a socket to listen to port on the local side,
optionally bound to the specified bind_address. Whenever a con-
nection is made to this port, the connection is forwarded over
the secure channel, and a connection is made to host port
hostport from the remote machine. [...]
-R Specifies that the given port on the remote (server) host is to
be forwarded to the given host and port on the local side. This
works by allocating a socket to listen to port on the remote
side, and whenever a connection is made to this port, the connec-
tion is forwarded over the secure channel, and a connection is
made to host port hostport from the local machine. [...]
-D Specifies a local ``dynamic'' application-level port forwarding.
This works by allocating a socket to listen to port on the local
side, optionally bound to the specified bind_address. Whenever a
connection is made to this port, the connection is forwarded over
the secure channel, and the application protocol is then used to
determine where to connect to from the remote machine. Currently
the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
as a SOCKS server. [...]
-X and -Y enable forwarding for X11. This is a small but convenient variation of -R.
Note that in all cases the data is forwarded over the ssh tunnel, from the local machine to the ssh server or the reverse, and (therefore) the ssh tunnel must exist for the data to be forwarded over. The only difference between -L and -D is that -D uses SOCKS4/5 on the local end to specify where the remote end connects to.
If you want a SOCKS proxy that connects directly from the proxy to the destination, not over an ssh tunnel, you need a plain SOCKS proxy, not ssh+sshd.
Your trying to connect without a port. So port 22 is used. Once that connection is open then SSH will set up the socks proxy on the port you specified (12345)
You need to connect to a valid SSH server. You specify the port with the -p flag

Added Listen 443 in remote server's sshd_config. Why I can't ssh -p 443 / 22?

In a moment of weakness I sheepishly followed a tutorial on how to connect to my Amazon EC2 remote server bypassing a public library's Wifi ssh restriction.
So first thing I did was adding the following (last) line to my /etc/ssh/sshd_config file residing in my remote EC2 AMazon server:
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
ListenAddress 443
Then I restarted the ssh server and, in a genius move, logged out from my remote server. So when in my local machine I do this...
$ ssh -i /path/to/key.pem xxx#xx.xx.xxx.xx -p 443 -v
...I get this:
$ ssh -i /path/to/key.pem xxx#xx.xx.xxx.xx -v -p 443
OpenSSH_6.0p1 Debian-4+deb7u2, 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 *
debug1: Connecting to xx.xx.xxx.xx [xx.xx.xxx.xx] port 443.
debug1: connect to address xx.xx.xxx.xx port 443: Connection timed out
ssh: connect to host xx.xx.xxx.xx port 443: Connection timed out
If I try to ssh to default's port 22 I get this:
OpenSSH_6.0p1 Debian-4+deb7u2, 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 *
debug1: Connecting to xx.xx.xxx.xx [xx.xx.xxx.xx] port 22.
debug1: connect to address xx.xx.xxx.xx port 22: Connection refused
ssh: connect to host xx.xx.xxx.xx port 22: Connection refused
I also added the following line in my Amazon's EC2 'Security Groups'...
Custom TCP port 443
... to no avail.
Did I effectively locked me out of my remote server? I was following a tutorial on how to tunnel and then this happened. Shouldn't have just added to /etc/ssh/sshd_config...
Port 443
...instead of 'ListenAddress 443' ?
I have never had problems ssh'ing to my remote server before (which is a Debian Wheezy).
As far as I know I can still detach my volume, re-attach it into a new instance, fix the sshd_config file, etc. I hope there's an alternative to that.
So my question is: It is possible to connect to my remote server considering the line 'ListenAddress 443' in ssh_config ? If so, how? And perhaps more importantly, why is that I can't connect on Port 22 if I hadn't touched or changed anything n sshd_config besides the ListenAddress 443?
Thanks in advance!
Edit:
telnet xx.xx.xxx.xx 22
Trying xx.xx.xxx.xx...
telnet: Unable to connect to remote host: Connection refused
You can't connect because of one of three reasons:
sshd on the remote server is down because it can't parse ListenAddress 443.
sshd parsed ListenAddress 443 into an IP address ('443' can be interpreted as an IP address - an IPv4 address is represented at low levels by a 32-bit unsigned integer) but was unable to bind to the IP address represented by '443' and is down.
sshd parsed ListenAddress 443 into an IP address, successfully bound to that IP address, and is now running and listening for incoming connections on "0.0.1.187" or some similar interpretation of '443' as an IP address.