How to Configure OpenSSL and OpenSSH on FreeBSD?

Published on: February 02, 2023

.

12 min read

.

For German Version

OpenSSL version on FreeBSD is a general-purpose cryptographic library that supports Transport Layer Security 1.0/1.1/1.2/1.3 (TLSv1/TLSv1.1/TLSv1.2/TLSv1.3) network security protocols.

The OpenBSD team maintains OpenSSH, which is installed by default on FreeBSD.

In this article, we will explain what OpenSSL and OpenSSH are, how you can generate OpenSSl certificates and how you can encrypt mail traffic using certificates. Moreover, this article describes the built-in client tools for securely accessing other systems and transferring data from a FreeBSD system. The document then explains how to set up an SSH server on a FreeBSD machine.

What is OpenSSL?

OpenSSL is a cryptography toolkit that implements the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols as well as the necessary cryptographic standards.

The openssl program provides a command-line interface for utilizing the cryptographic features of the OpenSSL crypto library from the shell. openssl utility offers the following functionalities:

• Generation and administration of private keys, public keys, and parameters

• Generation of X.509 certificates, CSRs, and CRLs

• Public key cryptographic operations

• Encryption and Decryption using Ciphers

• Calculation of Message Digests

• SSL/TLS Client and Server Tests

• Time Stamp requests, creation, and validation

• S/MIME signed or encrypted e-mail handling

The openssl software gives a plethora of commands, each with a plethora of parameters and arguments. The syntax of the openssl command is given below:

openssl  command [ command_opts ]  [ command_args ]


openssl  list [ standard-commands  | digest-commands | cipher-commands | cipher-algorithms | digest-algorithms | public-key-algorithms]

  
openssl  no-XXX [  arbitrary  options ]

How to Use OpenSSL on FreeBSD?

OpenSSL is often used to encrypt mail client authentication and secure web-based transactions such as credit card purchases. Some ports, including www/apache24 and databases/postgresql11-server, provide an OpenSSL compilation option. If chosen, the port adds OpenSSL support to the underlying system.

You may add the following line to /etc/make.conf to have the port built against OpenSSL from the security/openssl port:

DEFAULT VERSIONS+= ssl=openssl

OpenSSL is often used to give certificates for software applications. A certificate is used to validate a company's or an individual's credentials.

This section illustrates how to generate and use certificates on FreeBSD.

How to Generate OpenSSL Certificates?

You may generate 2 types of certificates on your FreeBSD server:

• Certificates that will be signed by an external Certificate Authority (CA)

• Self-signed certificates

warning

The application that utilizes a certificate that has not been signed by an external Certificate Authority (CA), such as http://www.verisign.com, issues a warning. Obtaining a signed certificate incurs a fee, however, utilizing a signed certificate is optional since certificates may be self-signed. Using an external authority eliminates alerts and puts people at rest.

How to Generate Certificates Using External Authority?

To produce a certificate that will be signed by an external CA, you may follow the steps given below:

1. Run the command below and provide the appropriate information at the prompts. This input data will be recorded on the certificate.

openssl req -new -nodes -out req.pem -keyout cert.key -sha256 -newkey rsa:2048

2. Type Country Name code, such as US.

3. Type State or Province Name (full name) [Some-State]:, such as California.

4. Type Locality Name, like Cupertino

5. Type Organization Name, like MyCompany

6. Type Organizational Unit Name, like IT.

7. Type the fully qualified name of the system that will utilize the certificate at the Common Name question, such as server.mycompany.com. If this name does not match the server, the application checking the certificate will alert the user, making the certificate's verification ineffective.

8. Type Email Address.

9. Type a challenge password.

10. You may type an optional company name.

Generating a RSA private key
................................................+++++
...................................................................................................................+++++
writing new private key to 'cert.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:Cupertino
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:server.mycompany.com
Email Address []:web@mycompany.com

Please enter the following 'extra' attributes to be sent with your certificate request

A challenge password []:myStrongPass
An optional company name []:

This command will generate two new files inside the current directory:

• The certificate request, req.pem, may be submitted to a CA, which will authenticate the credentials provided, sign the request, and return the signed certificate.

• The second file, cert.key, contains the certificate's private key and should be kept in a safe place. If this information gets into the wrong hands, it might be exploited to impersonate the user or the service.

The content of the certificate request file, req.pem, looks similar to the below:

-----BEGIN CERTIFICATE REQUEST-----
MIIDFTCCAf0CAQAwgZUxCzAJBgNVYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
MRIwEAYDVQQHDAlDdXBlcnRpbm8xEjAQBgNVBAoMCU15Q29tcGFueTELMAkGA1UE
CwwCSVQxGjAYBgNVBAMMEXdlYi5teWNvbXBhbnkuY29tMSAwHgYJKoZIhvcNAQkB
FhF3ZWJAbXljb21wYW55LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAN/NMpDfAeVqXuDus8Hv/1FBts0TkUioKUdTBXVlnPDcRuMrgT/3qHnZ7b
POUucFWv3bFp88gaRq24onGgtqQuFlo6B5bmdshJu+OcAnNkay+TRKYN+PtIqDxV
rJkaT13muuJvcgH8Lj/sbHPrXUdHMVfagxOR/7NrsEiB9zQrHrG+G9ynsi23jqLJ
LA+lw2Mk/qEo77S1Nuu3/y829RiplS07LDj6lA4DE9RgRdfrYBjBt0V+WWyIN/kg
4HAmz11cqVqC9b+YgCj9i3IQFHAKqqBRKUc5tqxiUrh61VN1IQ66+3yVafclHCPs
5SE3U7PCyeou77oleipTjGQq4LUCAwEAAaA6MBsGCSqGSIb3DQEJAjEODAxteVN0
cm9uZ1Bhc3MwGwYJKoZIhvcNAQkHMQ4MDG15U3Ryb25nUGFzczANBgkqhkiG9w0B
AQsFAAOCAQEApG3ptjxHhCBvH72k/DYqyIiuQK7jMZS8TiLz++1zX6nkr8WXzI
r/X6kWeBnuGCHxcDBnHPB2HNg8/OVH8outIDRMj4DuQJcfj0MHxsISoOw5B5UUxN
7ljghi/Q8uzAP+zVl0T+hgIB+J+nGVUEhh5X67zK9Yso2C6wqggPiAtp0mNfe4ce
kUlkQzdAUKS5labzJeoY9aAS3lGUudJAVbNOTsJtsi4xFC2DsDRBUZKP2Hjg/8UZ
nIkhPWfPR9IG4LhgiceJaxc6OQzDQYBbk1YdaIc03OmKQsen5mMkPhThDuL/ggVL
6es7PSIs4abbYqAGTsOcXpaTRVtEpEhw==
-----END CERTIFICATE REQUEST-----

How to Generate Self-signed Certificates?

A self-signed certificate may be generated if a certificate authority (CA) signature is not needed by following the steps given below.

1. Create the RSA key by running the following command:

openssl genrsa -writerand -genkey -out cert.key 2048

2. The above command will create a private key file cert.key in the current directory. Create a self-signed certificate using this key by running the next command. Follow the standard instructions to create a certificate.

openssl req -new -x509 -days 365 -key cert.key -out cert.crt -sha256

3. Type Country Name code, such as US.

4. Type State or Province Name (full name) [Some-State]:, such as California.

5. Type Locality Name, like Cupertino

6. Type Organization Name, like MyCompany

7. Type Organizational Unit Name, like IT.

8. Type the fully qualified name of the system that will utilize the certificate at the Common Name question, such as server.mycompany.com. If this name does not match the server, the application checking the certificate will alert the user, making the certificate's verification ineffective.

9. Type Email Address.

You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:Cupertino
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:server.mycompany.com
Email Address []:web@mycompany.com

10. This creates a certificate file named cert.crt in the current directory. Both a private key file cert.key, and the certificate itself, cert.crt, should be stored in a location that only root may access, ideally /etc/ssl/. Run the next command:

mv cert.* /etc/ssl/

11. These files should have 0700 permissions. Set file permissions by running the next command:

chmod 0700 /etc/ssl/cert.*

How to Use Certificates for Encrypting Sendmail?

Encrypting connections to the Sendmail mail server to circumvent clear text authentication is one use of a certificate.

warning

If the user has not installed a local copy of the certificate, certain mail clients may show an error.

In FreeBSD 10.0-RELEASE and later, it is possible to automatically generate a self-signed certificate for Sendmail. You may use OpenSSL certificates to encrypt Sendmail traffic by following the next steps:

1. Add the following lines to /etc/rc.conf to enable OpenSSL certificates support for Sendmail:

sendmail_enable="YES"
sendmail_cert_create="YES"
sendmail_cert_cn="server.mycompany.com"

This will generate a self-signed certificate named /etc/mail/certs/host.cert, a signing key named /etc/mail/certs/host.key, and a CA certificate named /etc/mail/certs/cacert.pem. The Common Name supplied in sendmail_cert_cn will be used by the certificate.

2. After committing the changes, restart Sendmail by running the next command. If everything goes well, /var/log/maillog will include no error messages.

service sendmail restart

3. To verify the settings, you may run the following command and connect to the mail server's listening port using telnet.

telnet localhost 25

This should display the output similar to the given below:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 server ESMTP Sendmail 8.16.1/8.16.1; Thu, 2 Feb 2023 11:31:39 +0300 (+03)

4. Type the following command.

ehlo server

This should display the output similar to the given below:

250-server Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP

If the STARTTLS line is present in the output, then everything is functioning properly.

What is OpenSSH?

OpenSSH is a collection of network communication utilities designed to provide distant workstations with safe access. Additionally, TCP/IP connections may be safely tunneled or routed through SSH connections. OpenSSH encrypts all data transmissions to prevent eavesdropping, connection hijacking, and other network-level assaults.

When data is delivered over the network in an unencrypted manner, network sniffers located anywhere between the client and server may intercept user/password information or session data. OpenSSH provides several authentication and encryption techniques to prevent this from occurring.

How to Use SSH Client Utilities?

To log into a server remotely, you may use ssh and provide a username that exists on the server as well as the server's IP address or hostname:

ssh username@10.10.10.28

If this is the first time the given server has been accessed, the user will be required to validate the server's fingerprint:

The authenticity of host '10.10.10.28 (10.10.10.28)' can't be established.
ED25519 key fingerprint is SHA256:9+ESHcNaDTLpZ7fRVahs8jy6QJk4VhOXnSmTXuBrbno.
No matching host key fingerprint found in DNS.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

SSH uses a key fingerprinting mechanism to authenticate the server's identity when a client connects. When the user accepts the key's fingerprint by typing yes when connecting for the first time, a copy of the key is stored in the user's home directory in the .ssh/known_hosts file. Future login attempts are compared to the stored key, and a warning is shown if the server's key does not match the saved key. Before resuming the connection, the user must first determine why the key has changed if this happens.

Current OpenSSH versions only allow SSHv2 connections. Version 1 of the SSH protocol is outdated.

Use scp to copy a file securely to or from a remote system. This example transfers the distant file freebsd.iso to a file with the same name in the current directory on the local machine.

scp username@server.mycompany.com:/freebsd.iso  freebsd.iso
Password for username@server.mycompany: *******
freebsd.iso 100% |*****************************| 554735
00:00

Since this host's fingerprint has already been validated, the server's key is automatically confirmed before querying the username for their password.

Similar parameters are supplied to scp and cp. The first input is the file or files to transfer, and the second is the location to copy to. Given that the file is retrieved via the network, one or more of the file parameters are as follows:

user@host:<path to remote file>

When copying directories recursively, scp uses -r parameter.

You may utilize sftp to initiate an interactive session for file copying.

How to Use Key-based Authentication?

A SSH server authenticate clients using a number of different techniques. The most frequent authentication mechanisms are passwords and SSH keys. While passwords do give some protection against unwanted access, SSH keys are far more secure.

The problem with passwords is that they are often generated manually and lack appropriate length and complexity. Therefore, brute force assaults may damage their security. SSH keys give an option that is consistently safe.

Each SSH key pair consists of a private key and a matching public key, and may be used in lieu of passwords for authentication.

The private key is stored on the client's computer and functions similarly to a password. If an unauthorized individual has access to your private key, it should be deemed compromised and instantly replaced. The private key is normally at least 2048 bits in length and may optionally be encrypted with a passphrase (essentially a password needed to use the private key) to restrict its usage in the event that an unauthorized individual obtains access to it.

The corresponding public key is freely distributed without repercussions. The public key is used to encrypt communications that only the private key can decipher; this is the foundation of SSH key authentication.

To allow the usage of a private key for authentication, the accompanying public key must be placed on a remote server user's account. The public key must be added to the .ssh/authorized_keys file inside the remote user's home directory. When a client attempts to connect to a remote server, the server can verify whether the client possesses a private key that corresponds with one of the authorized public keys; if the private key is verified to match an authorized public key, the client is authenticated and a shell session is initiated.

You may use ssh-keygen to create RSA authentication keys by following steps given below. To produce a pair of public and private keys, choose the key type and follow the on-screen instructions. It is advised to safeguard the keys using a memorable, yet difficult-to-guess password.

1. Run the next command.

ssh-keygen -t rsa

2. Press Enter to accept default file in which to save the key. If you accept the default, the keys will be kept in the .ssh directory under the home directory of your user.

3. Type passphrase. The private key is encrypted using this optional password. If you provide a passphrase in this field, it will be needed anytime the private key is used for authentication. Authentication requires both the private key and its passphrase, which may offer extra protection if the private key is hacked. If you do not enter a passphrase, you will be able to use the private key to log into your servers without a password; authentication will be dependent only on your private key, so be careful to safeguard it.

4. Retype passphrase to verify it.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Created directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa
Your public key has been saved in /home/username/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:ap4FzRbCtlHKTgeqME7t0Jgy0kEBSwCjVh4/eZyhHOE username@server
The key's randomart image is:
+---[RSA 3072]----+
|B+++ oo.. |
|o+B.=+=+o |
|O*.+.EO+o |
|*+o. +oB . |
| ... + S |
| + |
| o . |
| o o |
| o |
+----[SHA256]-----+

The private key is kept in ~/.ssh/id_rsa, while the public key is kept in ~/.ssh/id_rsa.pub. Key-based authentication requires that the public key be transferred to ~/.ssh/authorized_keys on the remote host. To copy public key to the remote server for this purpose you may need to run a couple of commands. You must create the ~/.ssh directory, if it doesn't already exist, and then add the public key into a file called authorized_keys into the directory. You may use the >> redirect to add the key to the authorized keys file, if it already exists, if any public SSH keys have previously been installed on the remote user's account.

Assuming your public key's default name is id_rsa.pub, the command to install the public SSH key is as follows (replace the remote user and host):

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Enter the password and press RETURN. If the command was correctly completed, you will get no response. The contents of your public key, id rsa.pub, will be placed to the end of the remote user's authorized keys file.

You may now run the following command to connect the SSH server using your private key:

ssh -i ~/.ssh/id_rsa -p 22 username@server.mycompany.com

warning

Numerous users believe that keys are designed to be safe and will use them without a passphrase. This conduct is hazardous. By manually inspecting the private key, an administrator may determine whether a key pair is secured by a passphrase. The key owner employs a passphrase if the private key file includes the term ENCRYPTED. In addition, to improve the security of end users, a from may be included to the public key file. Adding from="10.10.10.5" in front of the ssh-rsa prefix, for instance, restricts the user to logging in exclusively from that IP address.

If a passphrase is used, the user is requested for it each time a connection is established with the server. You may use ssh-agent and ssh-add to load SSH keys into memory and eliminate the need to input the passphrase each time.

ssh-agent handles authentication using the private keys that are put into it. ssh-agent may be used to run a shell or window manager, among other applications.

To use ssh-agent in a shell, provide a shell as the command's parameter. Add the identity by executing ssh-add and supplying the private key's passphrase. The user will then be able to ssh to any host with the installed public key.

ssh-agent csh
% ssh-add
Enter passphrase for key '/usr/home/username/.ssh/id_rsa':
Identity added: /usr/home/username/.ssh/id_rsa (/usr/home/username/.ssh/id_rsa)

To utilize ssh-agent with Xorg, add a ~/.xinitrc entry for it. This offers ssh-agent services to all Xorg-launched apps. A sample ~/.xinitrc may be as follows:

exec ssh-agent startxfce4

Every time Xorg begins, this launches ssh-agent, which in turn runs XFCE. Once Xorg has been restarted for the modifications to take effect, execute ssh-add to load all SSH keys.

How to Disable Password Authentication?

You have successfully setup your account for SSH key-based authentication in the previous section. However, your server's password-based authentication system is still operational, leaving it vulnerable to brute-force assaults.

Before completing the instructions in this section, ensure that SSH key-based authentication is either setup for the root account on this server or, preferable, for an account with sudo access. This step will shut down password-based logins, thus it is crucial that you continue to have administrative access.

Once the aforementioned prerequisites are met, connect into the remote server using SSH keys as root or an account with sudo capabilities. Edit the configuration file for SSH /etc/ssh/sshd_config and add the following line to the configuration"

ChallengeResponseAuthentication no

For the modifications to take effect, the sshd service must be restarted. This command will restart the SSH daemon on FreeBSD:

service sshd restart

Password-authentication has been removed, thus any SSH access to the server must now utilize SSH key authentication.

How to Create SSH Tunnel?

OpenSSH is capable of creating a tunnel to encapsulate another protocol inside a secure session. For example, to construct a tunnel for telnet you may run the next command:

ssh -2  -N  -f  -L 5023:localhost:23 username@server.mycompany.com

This illustration employs the following options:

• -2: Forces ssh to connect to the server using version 2.

• `-N: Indicates no command or tunnel-only operation. If not specified, ssh establishes a standard session.

• -f: Executes ssh in the background.

• -L: Indicates a local tunnel in format of localport:remotehost:remoteport .

• [email protected]: The login name to use on the remote SSH server provided.

A SSH tunnel functions by generating a localhost listen socket on the given localport. It then passes all connections received on localport to remotehost:remoteport through the SSH connection. In the example, the client's port 5023 is forwarded to the remote machine's port 23. Given that telnet uses port 23, this generates an encrypted telnet connection over an SSH tunnel.

As seen in the examples below, this approach may be used to encapsulate any number of insecure TCP protocols, such as SMTP, POP3, and FTP.

• To create a secure tunnel for SMTP run the next command:

ssh -2  -N  -f  -L 5025:localhost:25 username@server.mycompany.com

Together with ssh-keygen and other user accounts, this may be used to build a more seamless SSH tunneling environment. Keys may be entered in lieu of a password, and tunnels can be operated as a distinct user.

• To create a secure tunnel for POP3 run the next command:

ssh -2  -N  -f  -L 2110:mailserver.mycompany.com:110 username@ssh-server.mycompany.com

In this instance, an SSH server allows connections from the outside world. On the same network lies a mail server with POP3 server functionality. To securely check email, establish an SSH connection to the SSH server and tunnel to the mail server:

Once the tunnel is operational, configure the email client to transmit POP3 queries to localhost on port 2110. This connection will be sent securely to mailserver.mycompany.com through the tunnel.

• To bypass a firewall you may use the following command:

ssh -2  -N  -f  -L 8888:musicsite.com:8000 user@unfirewalled-system.myhome.net

Some firewalls screen outgoing as well as incoming connections. For instance, a firewall may restrict remote computer access to ports 22 and 80, allowing only SSH and web browsing. This restricts access to any service that uses a port other than 22 or 80. The answer is to build an SSH connection to a computer outside the network's firewall and tunnel to the required service using that connection.

A streaming client may now be directed to localhost port 8888, which will be redirected to musicsite.com on port 8000, circumventing the firewall successfully.

How to Enable SSH Server?

In addition to offering SSH client tools, FreeBSD may be configured as an SSH server that accepts connections from other SSH clients.

• To determine if sshd is running, use the service command:

service sshd status

• Add the following line to /etc/rc.conf if the ssh service is not running:

sshd_enable="YES"

This will launch sshd, the OpenSSH daemon application, the next time the machine boots.

To start ssh server immediately, run the next command:

service sshd start

OpenSSH Daemon (sshd) is the ssh daemon application. It secures communications between two untrusted sites across an insecure network. sshd waits for client connections. It is often launched by /etc/rc.d/sshd at boot time. It creates a separate daemon for every incoming connection. Key exchange, encryption, authentication, command execution, and data exchange are managed by the forked daemons.

sshd may be customized using command-line arguments or a configuration file (sshd_config by default); command-line options supersede values specified in the configuration file.

The CLI syntax of the sshd is given below:

sshd [-46DdeiqTt] [-C  connection_spec] [-c  host_certificate_file]
[-E  log_file]  [-f  config_file] [-g  login_grace_time]
[-h  host_key_file] [-o  option] [-p  port] [-u  len]

When sshd gets the SIGHUP signal, it rereads its configuration file by running itself with the name and settings it was started with, such as /usr/sbin/sshd.

When sshd is started for the first time on a FreeBSD system, the host keys are immediately generated and the fingerprint is presented on the console. Provide the fingerprint to users in order for them to validate it the first time they connect to the server.

You may use netstat or sockstat to confirm that ssh is operating and TCP port 22 is accessible:

 netstat -na | grep LISTEN

You should see the output similar to the given below:

tcp4       0      0 *.587                  *.*                    LISTEN
tcp6       0      0 *.25                   *.*                    LISTEN
tcp4       0      0 *.25                   *.*                    LISTEN
tcp4       0      0 *.80                   *.*                    LISTEN
tcp6       0      0 *.80                   *.*                    LISTEN
tcp4       0      0 127.0.0.1.9000         *.*                    LISTEN
tcp4       0      0 127.0.0.1.3306         *.*                    LISTEN
tcp46      0      0 *.33060                *.*                    LISTEN
tcp4       0      0 *.22                   *.*                    LISTEN
tcp6       0      0 *.22                   *.*                    LISTEN

sockstat -4 -l

You should see the output similar to the given below:

USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     sendmail   2403  5  tcp4   *:25                  *:*
root     sendmail   2403  7  tcp4   *:587                 *:*
www      httpd      2213  4  tcp4   *:80                  *:*
www      httpd      2212  4  tcp4   *:80                  *:*
www      httpd      2211  4  tcp4   *:80                  *:*
www      httpd      2210  4  tcp4   *:80                  *:*
www      httpd      2209  4  tcp4   *:80                  *:*
root     httpd      2198  4  tcp4   *:80                  *:*
www      php-fpm    2190  6  tcp4   127.0.0.1:9000        *:*
www      php-fpm    2183  6  tcp4   127.0.0.1:9000        *:*
root     php-fpm    2182  8  tcp4   127.0.0.1:9000        *:*
mysql    mysqld     2170  29 tcp46  *:33060               *:*
mysql    mysqld     2170  32 tcp4   127.0.0.1:3306        *:*
root     sshd       1007  4  tcp4   *:22                  *:*
root     syslogd    831   7  udp4   *:514                 *:*

• To stop the sshd service run the next command

service sshd stop

• To restart the sshd service run the next command

service sshd restart

How to Secure SSH Server?

Despite the fact that sshd is the most popular remote administration facility for FreeBSD, brute force and drive-by assaults are typical for any system that is accessible over public networks. Several other settings are available to prevent these assaults from succeeding, and they will be detailed in this section.

• Using the AllowUsers keyword in the OpenSSH server configuration file, it is advisable to restrict which users and from where may log into the SSH server. For instance, to restrict root logins to 192.168.0.10, add the following line to /etc/ssh/sshd_config:

AllowUsers root@192.168.0.10

• To permit admin to log in from anywhere, list that user without specifying an IP address add the following line to /etc/ssh/sshd_config:

AllowUsers admin

• Multiple users must be mentioned on a single line, as follows:

AllowUsers root@192.168.0.10 admin

• To configure SSH at another TCP port, such as 2222 instead of 22, add the following line to /etc/ssh/sshd_config:

Port 2222

• FreeBSD disables SSH root login by default for security reasons. Therefore, you cannot connect to your FreeBSD server through SSH as root. It is highly suggested to deactivate SSH root login and use a non-privileged user with SSH access enabled. If you still wish to give SSH access to the root user for any reason, you may add the following line to /etc/ssh/sshd_config:

PermitRootLogin yes

After modifying /etc/ssh/sshd_config, instruct sshd to reload its configuration file by executing:

service sshd reload

warning

When this keyword is used, it is essential to specify every user who must log into this computer. Any user not listed in that line will be denied access. Additionally, case sensitivity applies to the keywords used in the OpenSSH server configuration file. If the keyword is misspelled, including its capitalization, it will be disregarded. Always test modifications to this file to ensure that they function as anticipated.

In addition, users may be required to implement two-factor authentication using a public and private key. When necessary, the user may build a key pair using ssh-keygen and submit the public key to the administrator. This key file will be added to the authorized keys directory, as previously specified in the client section. To compel users to utilize just keys, the following configuration option may be enabled:

AuthenticationMethods publickey

tip

Avoid conflating /etc/ssh/sshd_config with /etc/ssh/ssh_config (note the extra d in the first filename). The first configuration file configures the server, while the second configuration file configures the client.