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:
8080
is the port on your local machine that will run as the proxy3128
is the port squid is running on the remote machineremote_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
(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''.
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:
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
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.