BSD Adventures

How to Create a Super Secure SSH Server Tunnel With FreeBSD

 Print This Post

Secure SHell, abbreviated SSH, is a versatile and secure tool. The most popular implementation, OpenSSH, was created by the OpenSSH project which is a cousin of FreeBSD. This guide uses FreeBSD as an OS because it’s a bit more user friendly. Although FreeBSD isn’t known to be as secure as OpenBSD, it’s still a very good bet.

This guide assumes that FreeBSD has been installed (see my guide here) and hardened (see how to do this here). If you can spare it this server should be solely dedicated to remote access. It will potentially be connected to the internet and the fewer services running the better to reduce the attack surface. It’s especially critical to patch and monitor any server that’s exposed to the internet. You’ve been warned.

FreeBSD has an SSH server and client out of the box, it just needs to be enabled. Virtually every other OS has at least an SSH client available. Linux and macOS have one built in. Windows users need a third-party client – PuTTY is one of the more popular ones.

Some of the things you can do with an SSH server are:

– Connect to your home network remotely and check on your machines. From the FreeBSD shell you can ping other computers to see if they’re up and even ssh into them.
– Tunnel HTTP traffic The most popular usage of this is setting up a web proxy. If configured correctly it allows you to securely tunnel your web browsing from anywhere in the world. The traffic will go from your client, through the internet, and come out from your home internet connection. This guide will show you how to do this easily and securely. Great for secure browsing in insecure settings!
– Tunnel RDP/VNC traffic. If a computer on your home network has RDP or VNC you can tunnel the traffic and administer your computers remotely and securely.
– Transfer files. By default OpenSSH allows the use of the SFTP/SCP protocol. Any files that your FreeBSD server can see can be transferred to the client.

Configuring sshd

A word of caution – the root account should NEVER have SSH access. If somehow someone breaks into the SSH server they would have administrative access. When a normal account is used the damage they can do will be limited. Administrative access can always be obtained by using su and entering the root password – which should be different from the user’s password!

Before we turn the SSH server on in FreeBSD let’s configure it. The configuration file is located at etc/ssh/sshd_config. Open that up with a text editor. You’ll need elevated credentials to edit it. The file is pretty well documented. Settings that are commented out are the defaults. You only need to uncomment a line if you want to change its setting. In this guide we’ll leave most of the defaults as is. I’ll be showing and explaining each additional line or change that I recommend.

Some guides recommend changing the port that sshd (the SSH daemon, or server) listens on. You can certainly do this but it has almost no effect on security. Even the most casual intruder will find out you’re running an SSH server no matter what port it’s using. We call something like this ‘security through obscurity’ and it should not be relied upon to improve your system’s security.

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr
KexAlgorithms ecdh-sha2-nistp521,ecdh-sha2-nistp384,curve25519-sha256@libssh.org
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-512,hmac-sha2-256-etm@openssh.com,hmac-sha2-256

Add these lines somewhere in the file. They restrict the ciphers and algorithms that the server uses to communicate with clients. By default OpenSSH uses some insecure ciphers. These lines include only the strongest algorithms. AES, ChaCha20-Poly1305, ECDH, and SHA2 are strong algorithms according to current research. These selections are also pretty compatible. Modern versions of Linux, PuTTY, and macOS will still be able to connect. If you’re using an older SSH client to connect which doesn’t support any of these algorithms it’s recommended that you upgrade anyway because there could be other security flaws. SHA2 and 3DES should be the weakest algorithms that your server should support if you’re concerned about maximum security. By restricting which ciphers can be used, not only will your traffic be more difficult to intercept but some common hacking tools will be thwarted from even trying to authenticate. My logs show countless attempts to connect to my SSH server but are rejected from even getting to enter a username because their tool does not support the chosen algorithms.

The line
MaxAuthTries

should be limited to something like 3 or 5. For example MaxAuthTries 5

This is the number of times a client can attempt to connect before it’s rejected. This slows down brute-force attempts.

Change the following lines to restrict some possible attack vectors:

AllowAgentForwarding no
AllowX11Forwarding no

If you don’t plan to use SFTP/SCP to transfer files you should disable it. If for some reason someone did break into your FreeBSD server, this could be used to exfiltrate files. Do this by commenting out the line that starts with Subsystem sftp.

That’s it for configuration changes. Save and close the file. Restart the sshd service by typing service sshd restart

If you made any typos the service will refuse to start and tell you where you messed up.

It’s strongly recommended that you enable the fail2ban service. This will ban people who attempt to brute-force your SSH server. Check out this great guide to set it up.

Creating a key pair

The next step is to create a public/private key pair. Two files will be created that act like a lock and key for the SSH server. One of the files, the public key, is put on the SSH server and acts like a lock. It will only accept keys that you specify to use the SSH server. The other file, the private key, is the key that you need to keep safe. If someone gets ahold of that key, they may be able to get into the SSH server.

You can create the keypair right on the FreeBSD machine. As the user you want to be able to log in (NOT ROOT), just run:

ssh-keygen -t ed25519

This creates a key pair using the Ed25519 scheme. This is a modern algorithm that is one of if not the most secure options available in OpenSSH. If for some reason your SSH client does not support Ed25519 you can also create one with ECDSA:

ssh-keygen -t ecdsa -b 521

ECDSA with a long key is likely just as secure as Ed25519 for the time being and is more broadly used.

You’ll see something like the image above. It’s highly recommended to set a strong passphrase for the private key. This way even if someone manages to get ahold of the file they’d still need to know the passphrase. It’s sort of like two factor authentication (something you have and something you know). Your public key is saved in the hidden .ssh folder in your home directory and will be called id_cipher.pub. This stays on the server. The other file is just called id_cipher. This is your private key. Keep it very safe! Transfer it to any clients that will connect to the server. This process needs to be repeated by every user that will use SSH.

If you plan to use PuTTY as an SSH client you need to change the private key’s format. Follow this guide to see how to do it.

Enabling the SSH server and connecting

Your SSH server is now fully configured. It’s time to turn it on and connect to it! Add the following line to /etc/rc.conf:

sshd_enable = "YES"

You can either reboot at this point or start the service manually with:

service sshd start

Now you’re in business! On a client on the same network as the server log into the SSH server with the private key you created. If you see your familiar FreeBSD shell it worked!

The last step is to open the server up to the internet if you want to be able to access it anywhere. You just need to forward port 22 on your firewall or router to the SSH server. Some ISPs may block port 22 so you can change it to another port like 2222 or even 22222 if you’re feeling frisky. There are plenty of guides out there on how to do this. You need to follow directions for your devices. If you do not own the connection make sure you ask permission. Especially if you’re at work you need a cognizant authority to understand that your network is being opened up. By following this and other guides you can be pretty sure that you’ll be in good shape, but no computer can be completely secure.

If you want to tunnel your web browsing or other protocols there are also plenty of guides on Google. Typically you connect to the server with some additional parameters then you tell your web browser to use a proxy. This is a great guide that shows how to do it on multiple operating systems.