Created at:

Modified at:

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

Where:

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

(2009-07-15)

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

(2014-03-02)

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

How to make an SSH tunnel publicly accessible?

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:

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

    /etc/hosts.allow
    /etc/hosts.deny

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

(2012-07-05)

When logging in, ssh may have a delay. sshd_config man page 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''.

ssh_config man page

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

Troubleshooting

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

(2013-10-01)

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

Someone in the team, 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.

(2013-10-01)

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

Linux X11 Connection Rejected Because of Wrong Authentication Error and Solution

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

(2014-03-04)

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

(2014-08-30)

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

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

OpenSSH server refuses to accept key authentication

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, that you can see in the following link:

NFS trouble shooting

debug3: mm_answer_keyallowed: publickey authentication test: RSA key is not allowed

(2022-03-08)

Your key-based ssh authentication stopped to work for recently installed operating systems?

You might want to enable logs for sshd to see what is happening. If you have already done that, you might see an error message like this one: 

debug3: mm_answer_keyallowed: publickey authentication test: RSA key is not allowed

It seems that RSA scheme is disabled in new OpenSSH server. See links below.

linux - RSA key is not allowed - Stack Overflow

OpenSSH 8.7 release notes

As the first link pointed, the solution was to generate a new pair of keys, using a more secure algorithm: 

$ ssh-keygen -t ed25519

Using the new key pair worked.

TODO: it seems deprecation of ssh-rsa scheme only happened for OpenSSH 8.8 or newer. The server operating system still used OpenSSH 8.0p1. Why did I see this problem? Can it have a different reason? For the record: the server is Rocky Linux 8.5 OpenSSH 8.0p1 and the client is NetBSD 9.2 OpenSSH 8.0.