If you are familiar with SSH on macOS or Linux, you’re in luck. SSH on FreeBSD works pretty much just as it does those systems (and you can use these steps to set it up on those systems).
What is SSH?
SSH stands for “secure shell.” Using SSH on FreeBSD allows you to use the command line to log into another system using the command line. Usually this is used for servers because they are often remote or not connected to a monitor. For example, I use SSH when administering the FreeBSD server that runs this website or when doing things with my home Raspberry Pi server.
The typical ssh syntax to connect to a server is ssh [user]@[ip address]. Type this into the command line, where [user] and [ip address] are replaced by the appropriate values (no brackets).
In /etc/ssh you will see your SSH files we’ll need to configure for the server. In /home/USER/.ssh/ (where USER = applicable system user), you will usually find the SSH keys we need to create/store for the client. On macOS is this found in /Users/USER/.ssh/. Note that the period in .ssh means the folder is hidden. Keys work in pairs, with a public key and a private key. I won’t get too far into the cryptography weeds (I’d be incapable of doing so, anyway), but it’s important to know that you share your public key with other systems while your private key remains on your device. A client will share its public key with a server, and then the server will store that public key. When it is matched with the appropriate private key (upon a login attempt), the client is given access to the server. In the coming steps you’ll see how this works.
Helpful man pages:
Because SSH can be used to access a machine remotely, it will be a primary target of bots and other malicious actors trying to compromise your system. When using SSH for a home network, such as to access a Raspberry Pi or home media server, you might be incline to brush aside security. By default, SSH uses a password based authentication. However, I would recommend making a habit out of setting up SSH securely using keys and using non-standard ports. Especially with a public server, if you do not take these basic precautions, you will constantly be hammered by bots.
If you are running a public server, my recommendation is to jail all your services and turn off ssh in all of your jails. For example, if you run a web server, put it in a jail without SSH enabled. You will then be forced to enter the host OS from SSH and then you can enter the web server. It’s especially useful if you get a separate IP address for your host OS and your web server jail. That way if a threat actor is trying to infiltrate your web server, SSH won’t even be available to them to attack. From the outside, it will appear as if the machine provides no remote login.
Of course you’ll want to take other standard security measures: use a proxy service to hide your IP, use a firewall, keep your system and software updated with the latest security patches, and frequently check your logs and running processes for suspicious activity. But keep in mind that SSH is the primary gateway into your server, so it will be the prime target of malicious actors.
Time needed: 5 minutes
How to Set Up SSH on FreeBSD
- On FreeBSD Server, Ensure SSHD is Running
SSH comes installed on FreeBSD and should function by default. You can check this by running this command:
root@beastie:/etc # service sshd status
sshd is running as pid 1386.
If it is not running, add the following line to /etc/rc.conf:
Now start sshd:
service sshd start
- On Client, Create SSH Key Pair
Create a key pair using ssh-keygen. It doesn’t matter what system you’re running, it’s all the same:
beastie@macbook ~ ssh-keygen
First, choose a location to save your key pair. Hit enter to use the default location. Next, select a password. Although you can leave this blank for no password, it is recommended that you add one. Note that his password is to access the key, not the server.
After you do this, you should see some neato ascii art and a message telling you the key pair was successfully created.
- On Client, Copy Public Key to Server
Now use ssh-copy-id to copy your public SSH key to the server:
beastie@macbook ~ ssh-copy-id [email protected]
note: replace USER with your username and 192.168.1.43 with your server IP address
You will be prompted for your password. Enter it and the key is successfully copied.
- On Client, Log Out and Test
Log out of the server with the exit command and log back in:
- On Server, Remove Password-Based Authentication
Although we can now login to the server using our key rather than password, other machines can still use passwords. We’ll need edit /etc/ssh/sshd_config to change this:
Remove the # to uncomment the line.
- On Server, Remove Root Login
Allowing root to login is dangerous. It is allow by default out of the necessity of setting up a machine that might not have users defined yet. Still in /etc/ssh/sshd_config, uncomment the following line:
- On Server, Change Default Port
SSH runs on port 22 by default. Since everyone knows this, bots from all over the world try to attack port 22. A simple security measure is to change the port SSH runs on. Still in /etc/ssh/sshd_config:
Uncomment the line and change the port number to a random, high digit number. This can be any number but it cannot conflict with an existing service. There are ways to check what’s currently running, but you may add software in the future. Therefore, my recommendation is just to make sure your port isn’t on this list.
- On Server, Restart SSH
This one is pretty self-explanatory:
root@beastie:/etc # service sshd
- On Client, Test Log In
Two important things, here:
1. Stay logged in. Open a new terminal window/tab to test this. If you screwed anything up, you might be permanently lock yourself out of the system.
2. Since we have changed the port number, you now need to change your login command slightly:
beastie@macbook ~ ssh -p 9666 [email protected]
If this works you’re good to go.
Conclusion: SSH on FreeBSD
You can now connect to your FreeBSD server using SSH in a fairly safe manner. If your security needs are abnormal, you might want to look into using higher bit encryption and setting up some form of two factor authorization.