How to configure an SSH proxy server with Squid

Sometimes you can’t connect to an SSH server from your current location. Other times, you may want to add an extra layer of security to your SSH connection. In these cases connecting to another SSH server via a proxy server is one way to get through.

Squid is a full-featured proxy server application that provides caching and proxy services. It’s normally used to help improve response times and reduce network bandwidth by reusing and caching previously requested web pages during browsing.

However for this setup you’ll configure Squid to be used as an SSH proxy server since it’s a robust trusted proxy server that is easy to configure.

Installation and configuration

Install the squid package using sudo:

$ sudo dnf install squid -y

The squid configuration file is quite extensive but there are only a few things we need to configure. Squid uses access control lists to manage connections.

Edit the /etc/squid/squid.conf file to make sure you have the two lines explained below.

First, specify your local IP network. The default configuration file already has a list of the most common ones but you will need to add yours if it’s not there. For example, if your local IP network range is 192.168.1.X, this is how the line would look:

acl localnet src 192.168.1.0/24

Next, add the SSH port as a safe port by adding the following line:

acl Safe_ports port 22

Save that file. Now enable and restart the squid proxy service:

$ sudo systemctl enable squid
$ sudo systemctl restart squid

4.) By default squid proxy listens on port 3128. Configure firewalld to allow for this:

$ sudo firewall-cmd --add-service=squid --perm
$ sudo firewall-cmd --reload

Testing the ssh proxy connection

To connect to a server via ssh through a proxy server we’ll be using netcat.

Install nmap-ncat if it’s not already installed:

$ sudo dnf install nmap-ncat -y

Here is an example of a standard ssh connection:

$ ssh user@example.com

Here is how you would connect to that same server using the squid proxy server as a gateway.

This example assumes the squid proxy server’s IP address is 192.168.1.63. You can also use the host-name or the FQDN of the squid proxy server:

$ ssh user@example.com -o "ProxyCommand nc --proxy 192.168.1.63:3128 %h %p"

Here are the meanings of the options:

  • ProxyCommand – Tells ssh a proxy command is going to be used.
  • nc – The command used to establish the connection to the proxy server. This is the netcat command.
  • %h – The placeholder for the proxy server’s host-name or IP address.
  • %p – The placeholder for the proxy server’s port number.

There are many ways to configure an SSH proxy server but this is a simple way to get started.

FAQs and Guides For System Administrators

7 Comments

  1. Nachfuellbar

    Why wouldn’t you just use ProxyJump and use another sshd as Proxy
    Would probably be more secure than a unsecured squid

  2. Joao Rodrigues

    Or… If you already have sshd running on your proxy server (192.168.1.63) you could ditch squid and use ssh’s ProxyJump option like this:

    ssh -J proxyserveruser@192.168.1.63 user@example.com

    You could even save it on your ~/.ssh/config:

    Host: 192.168.1.63
    User: proxyserveruser

    Host: example.com
    User: user
    ProxyJump: 192.168.1.63

    And next time you want to connect you just type “ssh example.com”.

    You can even set up multiple jumps:

    $ ssh -J userA@serverA.example.com,userB@serverB.example.com user@example.com

    This will establish a connection to serverA.example.com, that in turn will connect to serverB.example.com and finally connect to example.com

  3. Mohammed El-Afifi

    I think %h and %p in the command string to ProxyCommand denote the host and port of the remote ssh server respectively, not those of the proxy.

    • Curt Warfield

      You are correct the %h:%p arguments specify to forward standard in and out to the remote host (%h) and the remote host’s port (%p).

  4. yukyu

    better way are tox communicator proxy/ssh

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions