home | codereading | contact | github | math | misc | notes | patches | tech | README

SSH notes

External proxy with ssh and squid

Once you have squid configured and running in a remote machine that have full access to the internet, type the following commands on the limited access machine:

$ ssh -N -C -v -L 8080:localhost:3128 remote_machine_address.net


  • 8080 is the port on your local machine that will run as the proxy
  • 3128 is the port squid is running on the remote machine
  • remote_machine_address.net is the address of the remote machine that have full access to the internet. It can be a valid IP address too.

Then configure your programs to use the localhost:8080 address as proxy. With the command above ssh will listen to the port 8080, encrypt information, pass it to the remote machine through port 22 (or whatever port you run sshd) where it is passed to squid though port 3128. See that the only port that need to be free from the local computer and the remote one is 22.

As an example, let's see how you can listen to a good electronic music radio using mplayer:

$ mplayer http_proxy://localhost:8080/http://scfire-nyk-aa04.stream.aol.com:80/stream/1065

See that we specify the proxy address before the streaming address. Each program might have a different configuration.

ssh reverse tunnel

To make a reverse tunnel with ssh, type:

$ while :; do ssh -N -v -R 2222:localhost:22 <remote-machine>; done

Now, to get connected to your machine from remote-machine, type in remote-machine:

$ ssh -p 2222 localhost

Connecting two hosts of different networks with a third host on the internet

Say you have two hosts, alice and bob, behind two different private networks, alice want to connect to bob as if it were accessible on the internet. If you have a third server, here called gtw, acessible to both (for instance, on the internet) you can use a ssh reverse tunnel. In bob, do:

(in bob:)
$ ssh -g -N -v -R 2222:localhost:22 gtw

This will make gtw listen to the port 2222 so, whenever somebody try to connect to the port 2222 of it, it will be redirected to bob. This redirection works only if there is the -g flag, which is valid only if the server defined the GatewayPorts option, which is not enabled by default (see this link).

So, we still have access to the gtw server, although it doesn't have the GatewayPorts option set to allow the use of the -g flag and we don't have admin rights to change it. To summarize, let's make the following diagram:

+-------+   +-----+   +-----+
| alice |-->| gtw |-->| bob |
+-------+   +-----+   +-----+

One thing we can count on is that the -g flag doesn't depend on the GatewayPorts configuration for the -L flag! So, we can play with tunnels stuff on the bob and gtw hosts.

First, create a reverse tunnel in bob that listens on the port 2222 of gtw to connect to port 22 of bob:

(in bob:)
$ ssh -N -v -R 2222:localhost:22 gtw

See we didn't put the -g flag, since it doesn't matter in this case.

Then, create a tunnel (with -L, not -R) in gtw:

(in gtw)
$ ssh -N -v -g -L 2223:localhost:2222 localhost

What does it do? Listens to local port 2223 (with option -g, which allows external connections) and redirect them to the same machine, but port 2222. But what is port 2222? Just a redirection to bob in port 22! Now alice can connect to bob just connectin in gtw, port 2223:

(in alice)
$ ssh -p 2223 gtw

In summary, the connection procedure is:

  1. alice connects to gtw, port 2223.
  2. gtw sees it is just a redirection to localhost, port 2222.
  3. localhost port 2222 in gtw is just a redirection to bob port 22.
  4. Therefore, alice gets connected in bob.

What can block ssh

This files store information about the path of the files sshd looks to that can block the connection, in NetBSD:


Here are configuration files of programs that can also block the connection:

/etc/pf.conf        # PF (Packet Filter) configuration file

Getting rid of ssh delay when login

When logging in, ssh may have a delay. sshd_config(5) explains why:

UseDNS  Specifies whether sshd(8) should look up the remote host name and
        check that the resolved host name for the remote IP address maps
        back to the very same IP address.  The default is ``yes''.

So, in order to get rid of the delay, set UseDNS no in /etc/ssh/sshd_config at the server side.


$DISPLAY is unset when using -X of -Y option of ssh

After login in a machine with the -X or -Y options of ssh, the $DISPLAY variable should be set. If it is unset, there can be some reasons. Let's analyze one situation:

I logged in a machine with ssh -v -X hostname. -v enables basic debug output. Soon, we see:

debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Remote: No xauth program; cannot forward with spoofing.

Ok. The ssh server (sshd) is not finding xauth. But if we type xauth we find it. Why are we having a problem? Let's take a look at /etc/ssh/sshd_config (the server configuration file). After opening it, we see the following line:

XAuthLocation /tmp/xauth

Some idiot, for some reason (we don't have a configuration management system here at work), changed default setting. I just deleted this line and everything worked.

Error X11 connection rejected because of wrong authentication.

There can be several reasons. There is a nice page here with different solutions for this problem.

In my case, the problem was that I needed to change ForwardX11 option in /etc/ssh/ssh_config to:

ForwardX11 yes

Error X11 connection rejected because of wrong authentication.

Now, when running xev, I got this error:

X11 connection rejected because of wrong authentication.
xev:  unable to open display 'localhost:41.0'

There was a wrong configuration regarding xauth location in /etc/ssh/ssh_config (the client configuration file):

XAuthLocation /tmp/xauth

Just deleted it.

Stall in debug1: identity file .../.ssh/id_ecdsa-cert type -1

If your ssh connection stalls with this error, that can have different reasons. One of them that happened to mine was that I was trying to do a reverse tunnel to another host on the internet, like this:

$ ssh -N -v -g -R 2222:bob:22 alice

With this configuration, alice would listen connections of port 2222 and redirect them to host bob, port 22. But, when doing ssh -vvv -p 2222 alice from a third host, I got the following log:

OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data .../.ssh/config
debug1: .../.ssh/config line 1: Applying options for red
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 alice [XXX.XXX.XXX.XXX] port 2222.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load ".../.ssh/id_rsa" as a RSA1 public key
debug1: identity file .../.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file .../.ssh/id_rsa-cert type -1
debug1: identity file .../.ssh/id_dsa type -1
debug1: identity file .../.ssh/id_dsa-cert type -1
debug1: identity file .../.ssh/id_ecdsa type -1
debug1: identity file .../.ssh/id_ecdsa-cert type -1

And hangs.

When checking in alice, the firewall of the switch was redirecting all connections of port 2222 to another host running other service that was not ssh, therefore causing the connection to hang at this point and later failed.

Cannot connect with key authentication

Even though you have configured key authentication correctly, you have to pay attention to other stuff like permission and ownership of your home nad ~/.ssh directory and files. See this page for more information. Information about wrong ownership might be found in the ssh server logs, in strings like this:

Authentication refused: bad ownership or modes for file ...

In my case I got a very strange problem: /home was mounted by NFS, but permissions in server was getting messed up by setting id of 4294967294. This lead us to our problem on NFS, which is NFS messing ownership to 4294967294.