I want to setup a reverse udp tunnel, because I need to connect to my openvpn server from remote and the openvpn server is behind a NAT. For this I use socat and ssh. The tcp tunnel command:
socat exec:"ssh removeserver \"socat tcp-listen:10000,fork -\"" tcp-connect:localhost:22
does work correctly and I'm then able to buildup a ssh connection to remoteserver:10000.
But when I want to do the same with udp:
socat exec:"ssh removeserver \"socat udp-listen:10000,fork -\"" udp-connect:localhost:1194
and then try to buildup the openvpn connection, I get the following error:
2011/12/23 13:27:43 socat[28241] E read(3, 0x80c3b08, 8192): Connection refused
The tunnel at first seems to work, becaues both logfiles (server and client) have entries for the connection attempt. But the connection can't be established.
I have just tried this and I believe the reason it fails is because the ssh part of the tunnel doesn't preserve the UDP datagram sizes. Ie. a 14 byte datagram and a 22 byte datagram get combined on the other end into a 26 byte datagram. Openvpn doesn't work in this scenario.
I have had proof-of-concept success with a similar construct as this, but where there is a program which reads the UDP datagrams and turns them into tcp stream with 16-bit length prefixes (i.e. a stream of length,bytes,length,bytes etc) and obviously does the reverse as well.
With this I was able to tunnel openvpn .
Related
How does SSH dynamic forward (-D) function under the hood?
I understand that SSH dynamic forward opens a SOCSK4 proxy on the local host, and that each connection to the SOCK4 proxy is forwarded over the SSH tunnel to the remote destination.
Does SSH intercept the connections to the SOCKS4 proxy? I mean, it cannot be a "normal" SOCKS4 proxy, because then it would directly proxy the connections to the remote hosts.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
When the -D flag is given, the SSH client will start a built-in SOCKS4/5 proxy. (note: "SOCKS", not "SOCK").
-D [bind_address:]port
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.
When another application wishes to connect to a proxied service, they will establish a connection via this SOCKS server. The SOCKS protocol is a little bit of negotiation that occurs at the beginning of a connection, something like this: (inspired by the wiki page)
ssh -D 1234 user#remote is execute, the SSH client starts a SOCKS proxy server listening on port 1234.
A local application wishes to communicate with a service via the SOCKS proxy, so connects to port 1234.
The SOCKS client asks for a connection to a particular IP address and port - e.g: 66.102.7.99, port 4321.
The SOCKS server, in this case the SSH client, will negotiate to establish this onward connection with it's server (remote, from above). This may fail.
The SOCKS serve will respond to the client with success / failure information.
If successful, all data passed through this socket will now be forwarded appropriately:
From the local application, to the SSH server (remote), and then onto 66.102.7.99.
From 66.102.7.99 to the SSH server (remote), and then onto the local SSH client, and ultimately the local application.
Does SSH intercept the connections to the SOCK4 proxy?
No, the SSH Client is the SOCKS proxy.
I mean, it cannot be a "normal" SOCK4 proxy, because then it would directly proxy the connections to the remote hosts.
I suppose it's not really - the SSH Client and Server act together to achieve the function of a "normal" SOCKS proxy. The high-level result is that the proxy listens on one host, but forwards data from another host, with a magical link in between.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
TCP is a connection-oriented method of communication. That is to say that once a connection is established, data can flow in both directions, and is reliably identified as "related to that connection". With this information it is trivial to associate the data with arbitrary rules such as "forward to the SSH server, who will forward to 66.102.7.99".
When I connect to SSH I use port 22 as destination, but when the reply comes back, does it come in on port 22 as well? Or is the client source port randomly assigned as in other TCP communication?
If set up a firewall allowing outbound traffic to port 22 - Do I also need to allow incoming traffic on port 22?
The client SSH port is randomly assigned, as in most client/server systems over TCP/IP.
Were the client port fixed, you would not be able to open multiple SSH connections from the same client IP address, as the connections would be indistinguishable on an IP protocol level. The client port number is the only piece that makes the connection unique (client IP, server IP and server port being the same).
You do not need to allow the incoming traffic though. There is only one outgoing connection in SSH (the responses from the server come over an existing connection).
I SSH into my workstation, which is a mac running OS X Yosemite, daily. Unfortunately, I noticed a while back that enabling remote login into my machine has put it under the fire of many automated dictionary attacks trying to log in using the default port, 22.
To make my machine more secure, I changed the SSH port. To do so, I edited the /etc/services file, and changed the following two lines:
ssh 2123/udp # SSH Remote Login Protocol
ssh 2123/tcp # SSH Remote Login Protocol
That greatly reduced the number of dictionary attacks, but now when I try to SSH from my workstation to other machines, I always need to specify the port (which is usually port 22).
This is easy enough for most simple tasks, just specify the port when SSHing in:
ssh -p22 me#another.computer.com
It becomes a pain for more complicated tasks where specifying the port is not an option, but it can still be done by adding an entry in ~/.ssh/config:
Host github.com
Hostname ssh.github.com
Port 443
Between these two options, I could always connect to any machine I wanted to connect to. However, I'm now writing a script that will connect to machines that will have different IP addresses (and domain names), and there is no optional argument to specify the port number.
I have also been getting frustrated that it does not default to port 22 for outgoing connections, but I do not want to change my incoming port back to 22.
Is it possible to change the incoming SSH port, but still have the default outgoing SSH port? That is, can I only allow people to login to my workstation using port 2123, but when I try connecting to other machines, the default port it tries to use is port 22?
I'm running OS X 10.10.2 Yosemite.
Change the ssh port back in `/etc/services' - that sets the defined port for the ssh protocol.
Then change the port that sshd listens on. On OS-X this is more complicated than it need be. See https://serverfault.com/questions/18761/how-to-change-sshd-port-on-mac-os-x
I am trying to monitor a remote IP port for outgoing data.
At the minute I have a TCP port connected which is stuck in a deliberate (almost) infinite loop.
This works, until the tcp connection is broken for any reason.
It just feels better to monitor the remote port for outgoing data, but all the classes/functions I find are for receiving data on a particular port.
Any ideas?
On Linux, when I connect from telnet from one server (client telnet) to another (there isn't telnet server) I can connect on port, which I specify (not default for telnet 23 port). I get:
Connected to myserver (ip adress).
Escape character is '^]'.
Why, despite I haven't telnet server, I can connect with telnet client?
You can telnet to any opening TCP port, because that only means a normal TCP connection initiation work has done.
And your input will be treated as raw data, what happens to the data depends on the program which opened that TCP port, normally as soon as it determined the client side is not sending correct data it will disconnect.