←
Linux··5 min

SSH

SSH is how you connect to remote Linux machines. Understanding it properly — key-based auth, server hardening, tunneling — means you can use it securely and efficiently every day.

Series: Learning Linux from Scratch

  1. 1. Learning Linux from Scratch — After a Full IT Apprenticeship
  2. 2. What is Linux?
  3. 3. The Filesystem
  4. 4. Users and Permissions
  5. 5. Installing and Managing Software
  6. 6. Text Editors
  7. 7. Shell Scripting Basics
  8. 8. Process Management
  9. 9. Networking Fundamentals
  10. 10. SSH
  11. 11. systemd and Services
  12. 12. Disk Management
  13. 13. Users and Groups — In Depth
  14. 14. Cron and Scheduled Tasks
  15. 15. Firewall — iptables and ufw
  16. 16. Environment Variables and the Shell
  17. 17. Log Management
  18. 18. Kernel Module Management
  19. 19. The /proc Filesystem — In Depth
  20. 20. The /sys Filesystem and udev
  21. 21. Kernel Parameters and sysctl
  22. 22. Compiling and Installing a Custom Kernel

SSH — Secure Shell — is how you connect to remote Linux machines. Whether you are managing a server, deploying code, or just moving files around, SSH is the tool. Understanding it properly means you can use it securely and efficiently.

How SSH works

SSH creates an encrypted tunnel between your machine (the client) and a remote machine (the server). Everything sent through that tunnel — commands, output, file transfers — is encrypted.

The server runs a daemon called sshd that listens on port 22 by default. When you connect, the server and client negotiate encryption, authenticate you, and open a shell session.

Basic connection

ssh username@hostname

For example:

ssh jan@192.168.1.50

Or using a domain name:

ssh jan@myserver.com

If the server is running on a non-standard port:

ssh -p 2222 jan@myserver.com

Password vs key-based authentication

By default SSH asks for your password. This works but has two problems: passwords can be guessed or brute-forced, and typing them repeatedly is tedious.

Key-based authentication is better. You generate a key pair — a private key that stays on your machine and a public key that goes on the server. When you connect, the server challenges your client to prove it has the private key without ever sending the key itself.

Generating a key pair

ssh-keygen -t ed25519 -C "your@email.com"

ed25519 is the recommended algorithm — it is fast and secure. You will be asked where to save the key (default is ~/.ssh/id_ed25519) and whether to set a passphrase.

Use a passphrase. It encrypts your private key so that even if someone gets the file, they cannot use it without the passphrase.

This creates two files:

  • ~/.ssh/id_ed25519 — your private key. Never share this.
  • ~/.ssh/id_ed25519.pub — your public key. This goes on servers.

Copying your public key to a server

ssh-copy-id jan@192.168.1.50

This appends your public key to ~/.ssh/authorized_keys on the remote machine. After this, SSH will use your key instead of asking for a password.

If ssh-copy-id is not available, do it manually:

cat ~/.ssh/id_ed25519.pub | ssh jan@192.168.1.50 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Permissions matter

SSH is strict about file permissions. If the permissions are wrong, key auth silently fails.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519

~/.ssh/config

If you connect to multiple servers, typing full connection details every time gets old fast. The SSH config file lets you define shortcuts.

nano ~/.ssh/config
Host myserver
    HostName 192.168.1.50
    User jan
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host workserver
    HostName work.example.com
    User luca
    Port 2222
    IdentityFile ~/.ssh/id_rsa

Now instead of:

ssh jan@192.168.1.50

You just type:

ssh myserver

Hardening the SSH server

The server configuration lives in /etc/ssh/sshd_config. These are the most important settings to change on any server exposed to the internet.

Disable password authentication

Once key-based auth is working, disable passwords entirely:

PasswordAuthentication no

Disable root login

Never allow direct root login over SSH:

PermitRootLogin no

Change the default port

Not security through obscurity — it just eliminates noise from automated bots scanning port 22:

Port 2222

After making changes, reload the daemon:

sudo systemctl reload sshd

Do not close your current SSH session until you have verified the new settings work in a separate session. Locking yourself out of a remote server is a real problem.

SSH tunneling

SSH can forward ports between machines. This is called tunneling.

Local port forwarding

Forward a port from the remote server to your local machine:

ssh -L 8080:localhost:80 jan@myserver.com

Now localhost:8080 on your machine is connected to port 80 on the server. Useful for accessing a web service on a server that is not publicly exposed.

Remote port forwarding

Forward a port from your local machine to the remote server:

ssh -R 9090:localhost:3000 jan@myserver.com

Now port 9090 on the server connects to port 3000 on your local machine. Useful for exposing a local development server temporarily.

Dynamic port forwarding (SOCKS proxy)

ssh -D 1080 jan@myserver.com

Creates a SOCKS proxy on your local port 1080. Configure your browser to use it and all traffic routes through the server.

Copying files over SSH

scp

scp localfile.txt jan@myserver.com:/home/jan/

Copy in the other direction:

scp jan@myserver.com:/home/jan/file.txt ./

rsync

rsync is more powerful than scp — it only transfers changed parts of files and can resume interrupted transfers:

rsync -avz ./localfolder/ jan@myserver.com:/home/jan/remotefolder/
  • -a — archive mode (preserves permissions, timestamps, etc.)
  • -v — verbose
  • -z — compress during transfer

SSH is one of those tools you will use every single day in any serious Linux work. Key-based auth, a properly configured ~/.ssh/config, and a hardened server config are the baseline for doing it right.

Next up: systemd and services — how Linux manages what runs on your system.

#linux
0 views