SSH Remote Port Forwarding Specify Interface - ssh

I use this for remote port forwarding over SSH tunnel:
ssh root#X.X.X.X -R 443:127.0.0.1:443
this binds to 0.0.0.0:443 and forwards to 127.0.0.1:443 .
The remote server has multiple IPs. Is it possible to specify the IP I want to bind to, for instance 10.10.10.1:443, instead of binding to all interfaces?
iptables is not available on the remote server.

I managed to solve it.
On the remote server I set in sshd_config:
GatewayPorts clientspecified
Then I changed the arguments on the client like this:
ssh root#X.X.X.X -R 10.10.10.1:443:127.0.0.1:443
Now it works as expected, SSH binds to port 443 on interface 10.10.10.1 and forwards all traffic over the tunnel to localhost:443 .

Related

Rsync through bastion host using different port on destination server

I'm trying to run an rsync through a bastion host onto an SSH server that listens on a non-standard port, like this:
Source Host -> Bastion Host -> Destination Host (sshd on non-standard port)
I can get onto the destination host via the Bastion box using this:
ssh -o ProxyCommand="ssh -W %h:%p admin#bastion-host" user#destination-host
But this gets me onto the "default" SSH server, running on port 22, and not the one I want to get to, which, for sake of argument, is running on port 12345.
If I want to rsync using the non-standard port, the examples I can find, like this for example:
https://www.tecmint.com/sync-files-using-rsync-with-non-standard-ssh-port/
Indicate I should use -p, but that wouldn't work since I need port 22 all the way through the tunnel until the end.
How can I rsync to/from this destination server on port 12345, via a tunnel through the bastion server on the standard port 22?
Source Host (22) -> Bastion Host (22) -> Destination Host (12345)
Ah, I think I figured it out. My destination server was only allowing port 22 from the bastion host, and not the non-standard port.

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

Is it possible to do multiple port forwarding with one ssh connection?

I can now forward one port 8080 to the remote port 80 by ssh -L 8080:localhost:80 user#host.com, Is it possible to do multiple port forwarding with one ssh connection?
Yes, use -L option for each port to be forwarded.
Example:
ssh -L 8080:localhost:80 -L 7070:localhost:70 user#host.com
That is called dynamic port forwarding and if both the SSH server and SSH client support this, you configure your clients to use the SSH client as a SOCKS proxy and the SSH does the rest. In this case one "SSH connection" (in fact SSH connection carries multiple independent channels "inside") is used to connect to multiple destinations.

how should I test if port forwarding is working?

I am doing a local forwarding to the remote port at 80 which the apache2 is listening on like this ssh -L 80:localhost:80 user#host.com , so it connects me to the remote server, however I find I can still do mkdir rm and such commands. Isn't it so that I am only forwarded to application listening on port 80? so what's the difference to this command ssh -p 22 host.com ? Is there a way to test if this port forwarding is working?
Yes, you can Test as follows:
You should use a Client program on one Side and A Server Program on the other remote side.
Try to connect your client to your server according to ports and IP's used in your port forwarding by Netsh Cmd.
If connection succeed , that is it, if connection fails, that means port forwarding command was failed, or your ip and port configuration of your client and server is wrong.
More over if you send a text file to the server, you should receive it.
I hope that this will help.
Thanks.
You can listen on port 80 with netcat like this on the host ...
nc -l -p 80
... and then either send something back with netcat ...
nc host.com 80 <<< hello
... and see if you get a "hello" on the server, or use nmap :
nmap host.com -p 80
You can also use nmap the same way if you already have a server listening on port 80, like apache.
Just note that nmap will say it's closed unless there is something listening on that port.

how to get remote IP addresses from reverse ssh tunnel

I have an Apache webserver running on a local machine through reverse ssh tunnel, i.e.:
ssh -R *:80:local_machine:8080 username#gateway_machine
In other words, all traffic from port 80 on gateway_machine
is sent to port 8080 on local_machine.
For monitoring purposes, I wish to know IP addresses of the remote clients
connected to gateway_machine. However my local Apache server sees
all traffic coming from the IP address of gateway_machine.
My question: Is there any way to setup ssh server running on gateway_machine such that
it sends all traffic to local_machine with actual remote IP addresses ?
The SSH protocol uses a channel type called "direct-tcpip" for forwarding a TCP connection. The protocol message for opening one of these channels includes the address and port of the client whose connection is being forwarded. So the information that you want is available to the ssh client (which in your case is opening the connection to the target of the forward).
The OpenSSH ssh client logs the originator address and port in a debug level message, so you can see it if you run ssh with the -v option:
$ ssh -v -R 2000:localhost:1000 localhost
...
debug1: client_request_forwarded_tcpip: listen localhost port 2000, originator ::1 port 51101
Here the originator address was ::1 (IPv6 localhost) and port 51101. The ssh utility doesn't do anything else with the information.
So, depending on your needs, you have three approaches to collect this information:
Invoke the ssh process which creates these forwards with the -v option, and arrange to collect and parse the relevant debug information.
Make source code changes to ssh to make it do what you want it to do with the information.
Write your own ssh client which does what you want. SSH client libraries are available for most modern programming languages.