SSH and essential Linux commands: a practical server management guide

Short answer

SSH is the protocol that gives you an encrypted channel to a remote server. Combined with essential Linux commands, it lets you manage files, permissions, processes, disk usage and logs from a single terminal session. This guide walks through the commands used most often in day-to-day work.

The order below follows a real task: connect, copy files, read permissions, check resources, read logs and harden the server. The goal is not to memorise flags but to know which tool answers which question.

What SSH is and what it protects

SSH (Secure Shell) is an application-layer protocol that builds an encrypted tunnel between two machines. Passwords, commands and transferred file contents never cross the network as plain text. The official OpenSSH manual describes three layers: transport, which handles encryption and server authentication; user authentication, which establishes who you are; and connection, which carries sessions and tunnels.

In practice SSH is used to reach a server, move files, open tunnels to internal services and run deployment scripts remotely. A secure connection alone does not make a host safe: weak authentication or careless permissions still hand over access.

Key generation: replacing passwords with ssh-keygen

Passwords are a shared secret that can be guessed, reused or phished. Public key authentication keeps the private half on your machine and only the public half on the server. Create a pair locally:

ssh-keygen -t ed25519 -C "[email protected]"

The command produces ~/.ssh/id_ed25519, the private key, and ~/.ssh/id_ed25519.pub, the public key that is safe to share. Never send the private key by email or chat; if it leaks, so does access to the server. A passphrase adds a second layer.

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-address

This appends the key to ~/.ssh/authorized_keys. To avoid retyping the passphrase, load the key into the agent once per session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

The advantage is revocation: with per-device keys you delete one line when a laptop is lost, while a shared password must be rotated for everyone.

Connecting and creating shortcuts with ~/.ssh/config

The basic form of a connection is a user, a host and an optional port:

ssh user@server-address
ssh -p 2222 user@server-address
ssh user@server-address "uptime"

The last form runs a single command instead of opening a shell, which is useful in scripts. Rather than repeating long host names and ports, define shortcuts in ~/.ssh/config:

Host project
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

After that, ssh project is enough, and the file shows which key belongs to which host. Keep permissions strict: ~/.ssh should be 700, while config and the private key should be 600; SSH refuses a private key that others can read. Through a bastion, use ssh -J user@bastion-host target-host.

Copying files: scp and rsync

scp is enough for a single file or a small directory:

scp report.txt user@server:/var/www/site/
scp -r ./local-folder user@server:/var/www/
scp user@server:/var/log/nginx/error.log ./

rsync transfers only the changed parts, which is better for large directories and backups:

rsync -avz --progress ./site/ user@server:/var/www/site/

The trailing slash matters: ./site/ copies the directory contents, while ./site copies the directory itself. Backups usually add --delete to remove files on the target that no longer exist in the source:

rsync -avz --delete --dry-run ./site/ user@server:/var/www/site/

Warning: --delete removes extra files on the target with no undo. Always check with --dry-run first; a mistyped source path can wipe live files.

Navigating the server and working with files

Three commands tell you where you are: pwd prints the working directory, ls lists its contents and cd changes it.

pwd
ls -la
cd /var/www/site
mkdir -p backups/2026
cp config.php config.php.bak
mv old.log archive/old.log
find /var/www -name "*.log" -size +100M

ls -la also shows hidden files, and missing a .env file is a common mistake. cp does not copy directories; use cp -r. find filters by name, size or age. Be careful with deletion:

rm old-backup.tar.gz
rm -r archive/2024

Warning: rm has no recycle bin; the removal is permanent. rm -rf is especially dangerous because an empty variable can turn it into a command aimed at the root directory. Guard the path:

rm -rf -- "${TARGET_DIR:?TARGET_DIR is not set}"

Viewing and searching file contents

cat suits short files and less long ones. Log files usually only need the beginning or the end:

cat /etc/hostname
less /var/log/nginx/access.log
head -n 20 report.csv
tail -n 50 /var/log/syslog
tail -f /var/log/nginx/error.log

tail -f keeps following the file, the most practical way to watch a live log while reproducing a problem; inside less, / searches and q quits. grep handles text search:

grep -i "error" /var/log/syslog | tail -n 30
grep -rn "TODO" ./src
grep -c "GET /api" /var/log/nginx/access.log
grep -rn --exclude-dir=node_modules "apiKey" .

-i ignores case, -r recurses into directories, -n prints line numbers and -c returns the match count. Running cat on a very large file can lock up your terminal, so less and tail are safer.

File permissions: reading ls -l, using chmod and chown

The output of ls -l shows permissions, owner and group on one line:

-rw-r--r-- 1 deploy www-data 4096 Sep 18 10:12 config.php

The first character is the file type (- for a file, d for a directory). The next nine form three groups of three: owner, group and others. Within each group, r is read (4), w is write (2) and x is execute (1), so 644 gives the owner read and write while others only read, and 755 suits directories and executables.

chmod 644 config.php
chmod 600 ~/.ssh/id_ed25519
chmod +x deploy.sh
chown deploy:www-data /var/www/site/config.php
chown -R deploy:www-data /var/www/site/uploads

Changing ownership usually requires sudo. Before running chown -R, confirm the path; at the wrong root directory it can break ownership across the system.

Warning: chmod 777 makes a file writable and executable by every user, and on a web root it opens the door to running an uploaded script. chmod -R 777 looks like a fix while making the hole permanent. Give the narrowest permission that works and assign ownership to the service user. SSH also ignores a private key others can read, an easily missed cause of Permission denied.

Processes and resource usage

When a server slows down, the first question is which process is consuming resources:

ps aux | grep nginx
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head
top
df -h
du -sh /var/log/*

ps aux lists running processes and top shows usage live; htop is friendlier. df -h reports disk usage per filesystem and du -sh the size of a directory. A full disk is a common reason a database or web service goes down quietly, so free space deserves a regular check. Services are managed with systemctl:

systemctl status nginx
sudo systemctl restart nginx
sudo systemctl enable --now nginx

status shows the current state plus recent log lines; when a reload is enough, prefer it over a restart so connections are not dropped.

Reading logs: journalctl and /var/log

On systemd hosts, logs are read with journalctl:

journalctl -u nginx -n 100
journalctl -u ssh --since "1 hour ago"
journalctl -p err -b
journalctl -f

-u filters by service, --since by time, -p err keeps only error-level entries and -b limits output to the current boot; look here first when a service crashes. On systems without systemd, logs are plain files:

ls /var/log
tail -n 50 /var/log/auth.log

The authentication log (called /var/log/secure on some distributions) records successful and failed logins. A steady stream of failures means the server is being scanned.

Security hardening: narrowing the attack surface

A default installation is broad because it prioritises convenience. On a production server, apply these steps in order:

• Create a normal user with sudo rights and confirm key-based login works.
• Disable root login with PermitRootLogin no in the sshd configuration.
• Disable password login with PasswordAuthentication no, only after key login works.
• Open only the ports you need and enable automatic security updates.

Validate the configuration and reload rather than restarting:

sudo sshd -t
sudo systemctl reload ssh

Warning: a broken sshd configuration locks you out completely. Make changes while another session is open, check the syntax with sshd -t, and do not close it until a fresh terminal logs in. To block repeated failed logins, use fail2ban:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Changing the SSH port does not make a server secure on its own; it only reduces scan noise. The real protection is key-based authentication with password login off.

Common errors and how to fix them

Permission denied (publickey)

The server is rejecting your key. Check, in order: is the public key in authorized_keys; is ~/.ssh set to 700 and the private key to 600; is the user name correct? For detail:

ssh -v user@server-address

The verbose output shows which key files were tried and which methods the server accepts.

Host key verification failed

The server’s key changed or the record does not match. A reinstall or a reassigned IP can cause this, but the message can also indicate a machine in the middle. Once the change is confirmed as expected, remove the old record:

ssh-keygen -R server-address

Connection refused, timed out and no route to host

Connection refused means the SSH service is not running or is listening on another port, so check the service and the port. A timeout means packets never arrived, pointing at a firewall rule, a wrong IP or a network outage. no route to host indicates a routing problem.

Checklist

• A key pair exists and the private key is protected by a passphrase.
• ~/.ssh is 700; the private key and config are 600.
• Login works with the key and without a password.
• Frequently used hosts are defined in ~/.ssh/config.
• Copy and backup jobs were tested with --dry-run first.
• The target path was verified before any delete.
• No directory in the web root is set to 777.
• Disk usage and memory are checked regularly.
• Critical service logs are reviewed with journalctl.
• Root and password login are disabled and validated with sshd -t.

Most of these items are configured once and cause no trouble for months; what matters is knowing which command to reach for when something breaks. For the full syntax, see the OpenSSH manual and the ssh manual page.

Taking server management beyond one person

The command line is enough for one server, but as a team grows the harder questions are who holds access, how releases are deployed and where backups live. At that point SSH access, deployment scripts and configuration management belong in one plan. If you want that infrastructure on a corporate footing, our corporate software solutions and custom software projects pages outline the scope. Our guide to DevOps picks up where these commands leave off, and if you are comparing partners, corporate software companies in Izmir covers what to evaluate.

Our group company Web Tasarım Ofisi supports teams with hosting, server setup and maintenance for web projects. To review your current setup, get in touch.