SSH and OpenSSH Server: IT Security

Introduction to SSH and the OpenSSH server

In technical terms, SSH is the acronym for Secure Shell, a protocol that lets you establish an encrypted remote session — and therefore a more secure one — through a command-line interface with another host on a network.

The benefits of OpenSSH

With that in mind, let's talk about OpenSSH, an open-source network service that provides a complete suite of tools for remotely managing servers and computers.

OpenSSH is one of the most reliable and secure systems for remote systems management, and it's widely used in production environments worldwide. It supports a broad range of network protocols, including SSH, SFTP and SCP, which can be used to remotely manage Linux servers and Unix systems.

Encryption of data in transit, public/private key authentication and protection against network attacks are just some of the many security options available with OpenSSH.

OpenSSH is also highly flexible and customizable, letting system administrators configure the service to meet their specific needs. It's reliable and stable, and unlike some other remote management services, it doesn't require constant maintenance.

Thanks to its steadily growing popularity, OpenSSH is backed by a large community of developers who continuously contribute to its development and maintenance — meaning system administrators can always rely on a trustworthy, secure solution that is constantly improved and updated.

In short, OpenSSH is an excellent choice for anyone looking for a reliable and secure solution for the remote management of their servers and computers. With its full toolset, advanced security options and large developer community, OpenSSH is a solution highly recommended for system administrators seeking a robust, dependable way to manage their systems remotely.

Main use cases for the SSH service

SSH is a highly versatile and adaptable service, and a solution we recommend to any person or organization across a wide range of situations. Here are the main use cases:

• Remote server administration: SSH is one of the most widely used systems for remotely administering servers. System administrators can use it to access their servers from anywhere and manage them securely.

• Secure file transfer: SSH also supports the SFTP protocol, which enables secure file transfer between servers and computers — particularly useful when handling large volumes of sensitive data.

• VPN connections: SSH can be used to create a secure, protected VPN connection between two or more systems, useful for remote access to corporate networks.

• Process automation: SSH can be used to automate server management processes, for example by running remote scripts or commands.

• Security: SSH provides strong encryption of data in transit, protecting sensitive information during remote system management.

• Network tunneling: SSH can be used to create a secure tunnel across a public network, protecting sensitive information during transmission.

• Remote database management: SSH can be used to securely access and manage remote databases.

• System monitoring: SSH can be used to monitor remote systems, for example to detect performance issues.

• Remote backup: SSH can be used to securely create backup copies of remote data.

• Software development: developers can use SSH to remotely access their development systems and work efficiently on their projects.

Key-Based Authentication Instead of Passwords

The single most effective security improvement for any server exposed to SSH is switching from password authentication to key-based authentication. On the client machine:

ssh-keygen -t ed25519 -C "nome@azienda.it"

This generates a private key (kept on the client, never shared) and a public key (~/.ssh/id_ed25519.pub). The public key is then copied to the server:

ssh-copy-id utente@server

From that point on, connecting with ssh utente@server uses the key pair instead of a password. On the server side, password authentication can then be disabled entirely by editing /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

and restarting the service with systemctl restart sshd. Disabling PermitRootLogin means administrators log in with their own account and use sudo for privileged commands, which also leaves a proper audit trail of who did what — something a shared root password never gives you.

A Few Other sshd_config Settings Worth Knowing

• Port 22 — changing the default port doesn't make SSH itself more secure, but it does cut down dramatically on the noise from automated scanners that only ever try port 22.
• AllowUsers utente1 utente2 — restricts SSH access to an explicit list of accounts, useful on a server where only a couple of people actually need remote access.
• MaxAuthTries 3 — limits how many authentication attempts a single connection gets before being dropped, slowing down brute-force attempts.
• Fail2ban — not part of OpenSSH itself, but commonly deployed alongside it: it watches the auth log and temporarily bans IP addresses after a set number of failed login attempts, which meaningfully cuts down automated attack traffic on any server exposed to the internet.

Errors You'll Actually Run Into

• Permission denied (publickey) — either the public key wasn't copied correctly to the server's ~/.ssh/authorized_keys, or the permissions on that file/directory are too open (SSH silently refuses to use a key if ~/.ssh is writable by anyone other than the owner — it should be 700, and authorized_keys should be 600).
• Connection refused — the SSH service isn't running on the target host, or a firewall is blocking the port; this is a network/service problem, not a credentials one.
• REMOTE HOST IDENTIFICATION HAS CHANGED! — the server's host key no longer matches the one stored in the client's ~/.ssh/known_hosts, most often because the server was reinstalled or replaced. If that's expected, the fix is removing the old entry with ssh-keygen -R nome_host; if it wasn't expected, it's worth verifying nothing suspicious is happening before proceeding.
• Connection hangs with no error at all — often a firewall silently dropping the packets rather than actively refusing the connection; worth testing from the network the server is on before assuming it's an SSH configuration issue.

Tunnels: A Practical, Common Use Case

Beyond remote administration, SSH tunnels are a genuinely common way to reach a service that isn't meant to be exposed directly to the internet — for example a database or an internal admin panel reachable only from inside the office network. A local tunnel:

ssh -L 8080:localhost:80 utente@server

forwards local port 8080 to port 80 on the remote server, through the encrypted SSH connection, without opening that port to the public internet at all.

A solution just a click away!

For any IT need, feel free to contact TN Solutions with no obligation: our qualified technicians offer server support and consulting services to businesses and individuals alike. Fill in the form below.

Related articles

If you'd like to learn more, here are some in-depth guides on related topics:

• Choosing the right RAID level (0, 1, 5, 6 and 10)

• The AMD vs Intel processor buying guide

• The new version of the pfSense firewall: everything you need to know

• Nginx: what it is and how it works

• Varnish Cache: what it is and how it works

• Network design for businesses

• The Linux system administrator's role in a company