You’ve got a Linux server online and now you’re wondering: “Is this thing actually safe?”

If you’re running CentOS/RHEL or Ubuntu/Debian, and you handle anything important (client data, your own projects, internal tools), then you need at least basic hardening. Let’s walk through two of the most important ones: encrypting your data communication and getting rid of old, insecure services.

I’ll keep it practical, step-by-step, and focused on things you can do even if you’re not a full-time security engineer.

1. What We’re Fixing (and Who This Is For)

If you do any of these on a Linux server:

• Log in remotely to manage it
• Transfer files between servers
• Host web apps over HTTP/HTTPS

…then your traffic can be watched if it isn’t encrypted, especially on shared networks or the internet.

We’re targeting people who:

• Use CentOS/RHEL or Ubuntu/Debian servers
• Have SSH access and basic terminal skills
• Want simple, safe defaults to make their server harder to abuse

We’ll focus on two big ideas from the hardening checklist:

1. Encrypt data communication (so people can’t just sniff your passwords and data)
2. Stop using old protocols like FTP, telnet, rsh, etc.

Nothing here is fancy, but it’s the stuff that stops the easiest attacks.

2. Encrypt Your Data Communication

Anything that crosses the network in plain text can be read by someone with a packet sniffer. That includes:

• Logins
• Commands
• Files

So, rule of thumb: if it goes over the network, try to encrypt it.

The tools in the source we’re building from are:

• ssh, scp, sftp, rsync (over SSH)
• sshfs (over SSH)
• GnuPG (for data and communication encryption/signing)
• OpenVPN and tinc (for encrypted tunnels / networks)
• HTTPS with SSL on Lighttpd, Apache, Nginx (e.g. Let’s Encrypt)

You don’t need all of them. Pick what you actually use.

3. Use SSH Instead of Telnet/Rlogin

If you’re still using telnet or rsh to log in… stop. Those send your username and password in plain text.

Use SSH instead.

3.1. Basic SSH login

From your local machine:

ssh username@your-server-ip

Why this matters: SSH encrypts the entire session — commands, output, and credentials.

3.2. Copy files with `scp`

Instead of FTP, you can move files using scp over SSH:

# Upload a file
scp file.txt username@your-server-ip:/path/on/server/

# Download a file
scp username@your-server-ip:/path/on/server/file.txt ./

Same encryption as SSH, just used for file transfer.

3.3. Use `sftp` for interactive file transfer

If you like the FTP-style interface but want encryption:

sftp username@your-server-ip

You’ll get an interactive prompt similar to FTP, but protected by SSH.

3.4. Rsync over SSH

If you sync directories a lot, rsync over SSH is more efficient:

rsync -avz -e ssh localdir/ username@your-server-ip:/remote/dir/

The -e ssh tells rsync to use SSH underneath, so it’s encrypted.

4. Mount Remote Filesystems with SSHFS

Sometimes you just want the remote server’s files to appear as if they’re local.

That’s where sshfs (SSH Filesystem) comes in. It uses SSH + FUSE to mount a remote directory securely.

4.1. Install sshfs (example commands)

On many Linux distros, the tool is called sshfs and uses FUSE under the hood. Check your package manager for the exact package name.

Why this matters: You get a mounted remote filesystem with encrypted communication, using your existing SSH keys/users.

4.2. Mount the remote directory

General pattern:

sshfs username@your-server-ip:/remote/path /local/mountpoint

Once mounted, /remote/path appears at /local/mountpoint, and everything you read/write is transferred over SSH.

Safety tip:
– Use appropriate permissions on your local mountpoint.
– Unmount when you’re done.

5. Encrypt Data and Communication with GnuPG

Sometimes you need to encrypt files or messages before sending them, or sign them so the recipient knows they’re really from you.

That’s where GnuPG (GPG) comes in. According to the source, it:

• Encrypts and signs your data and communication
• Has a versatile key management system
• Works with many public key directories

Typical uses:

• Encrypt a backup before copying it off the server
• Sign configuration archives so you can verify them later

Basic idea (high level):

1. Generate a key pair (public + private)
2. Share your public key with others (or keep it for your own use)
3. Encrypt data using the public key
4. Decrypt with the private key and verify signatures

Safety tip:
– Keep your private key secure and backed up properly.
– Never store the private key in publicly accessible paths.

6. Use VPN Tunnels: OpenVPN or tinc

If you need secure communication between multiple hosts over the internet or an untrusted LAN, you can tunnel everything through an encrypted connection.

From the source:

• OpenVPN is a cost-effective, lightweight SSL VPN.
• tinc uses tunneling and encryption to create a secure private network between hosts.

Common scenarios:

• Connect branch offices to a central server
• Secure traffic between production and backup servers
• Access private services remotely without exposing them publicly

High-level workflow:

1. Install OpenVPN or tinc on participating hosts
2. Generate keys/certificates
3. Configure tunnels and routing
4. Start the VPN service and test connectivity

Safety tip:
– Keep VPN keys/certs backed up and protected.
– Limit which subnets are reachable over the VPN.

7. Serve Sites Over HTTPS (SSL/TLS)

If you’re serving websites or APIs, you should encrypt HTTP using HTTPS.

The source mentions:

• Lighttpd SSL HTTPS configuration and installation
• Apache SSL (mod_ssl) HTTPS configuration and installation
• Nginx with free Let’s Encrypt SSL certificate on Debian or Ubuntu

The idea is similar regardless of the web server:

1. Enable SSL/TLS support in your web server (e.g., mod_ssl in Apache, SSL module in Lighttpd/Nginx)
2. Get an SSL certificate (Let’s Encrypt is a popular free option)
3. Configure the server to listen on port 443 and use the certificate
4. Redirect HTTP (port 80) to HTTPS where appropriate

Why this matters:

• Protects login forms, dashboards, and API calls from being sniffed
• Prevents credentials and session cookies from traveling in plain text

Safety tip:

• Test HTTPS configuration on a staging environment if possible.
• Keep your private certificate keys secured with proper file permissions.

8. Stop Using FTP, Telnet, and Rlogin/Rsh

Now for the other side of the coin: removing the bad stuff.

According to the source:

Under most network configurations, user names, passwords, FTP / telnet / rsh commands and transferred files can be captured by anyone on the same network using a packet sniffer.

So if you’re running things like:

• ftp
• telnet
• rsh, rlogin
• NIS-related services

…those are big security holes.

8.1. Replace them with secure alternatives

From the source, recommended replacements:

• Use OpenSSH (SSH) instead of telnet/rlogin/rsh
• Use SFTP or FTPS (FTP over SSL) instead of plain FTP

This keeps the same basic workflow (remote login, file transfer), just wrapped in encryption.

8.2. Remove outdated services on CentOS/RHEL

The source gives an example yum command to remove some of these outdated services:

# As root or with sudo
yum erase xinetd ypserv tftp-server telnet-server rsh-

This removes:

• xinetd (often used to host old network services)
• ypserv (NIS server)
• tftp-server
• telnet-server
• rsh- related packages (rsh/rlogin tools)

Safety tip before running this:

• Make sure you are not relying on any of these services for legacy systems.
• If in doubt, test on a staging server or a snapshot of the VM.

If you’re on Ubuntu/Debian, the package names and command (apt) will differ, but the idea is the same: uninstall or disable these insecure services.

9. Quick Safety Habits for These Changes

When you’re hardening a server, even small mistakes can lock you out or break workflows. A few basic habits help a lot:

1. Have a backup login method
   If you’re changing anything related to SSH or network services, keep an existing session open until you’ve tested new access.
2. Use staging when possible
   Try changes on a staging server or VM snapshot first, especially removal of packages.
3. Check permissions on secrets
4. Private keys (SSH, GnuPG, SSL) should be readable only by the right user (often 600 or 640 with correct group).
5. Change one thing at a time
   Make a change, test it, then move on. Easier to debug if something breaks.

10. Recap and Next Step

We focused on two major parts of Linux server hardening from the source material:

• Encrypt everything you can
  Use SSH (ssh, scp, sftp, rsync), sshfs for mounts, GnuPG for data and communication, VPNs (OpenVPN/tinc) for host-to-host networks, and HTTPS for web.
• Stop using insecure legacy services
  Avoid plain FTP, telnet, rsh/rlogin, NIS and related services. On CentOS/RHEL, you can use yum erase xinetd ypserv tftp-server telnet-server rsh- as a starting cleanup step.

If you do just these two things, your Linux server is already in a much better place than a default, out-of-the-box install.

If this saved you time, bookmark CrushEdge for more fixes.