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
Related
I'm trying to establish a remote port forwarding to my Mac (target 4004) via a bastion host and Server-A to a Port (1555) on Server B.
So the whole connection is:
Mac:4004 => Bastion:22 => A:22 => B:1555
And the target is my Mac should have a Port 4004 forwarded from B:1555.
What is working so far?
I can connect to Server A with the command ssh user-bastion#user-A#server-A#server-bastion
On Server A I can establish a connection e.g. telnet to B:1555
On my windows client I can remote forward the port B:1555 to my local machine via Putty.
I'm now looking for the ssh command to establish this connection on my Mac.
Commands I tried:
Of course I have already searched for it and I've already tried different versions.
e.g.
ssh -fNT -R 1555:localhost:4004 -J user-bastion#user-A#server-A#server-bastion server-B
ssh -N user-bastion#user-A#server-A#server-bastion -R server-B:1555:localhost:4004
I always receive message like "Warning: remote port forwarding failed for listen port 1555"
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.
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.
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 .
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.