What Is SSH
SSH means Secure Shell (secure terminal). It’s the standard way to open a terminal on a computer that’s far away from you. Instead of typing commands on your machine, you type commands that run directly on the server, as if you were sitting in front of it. Everything sent between the two ends is encrypted, or scrambled, so no one in between can read it.
server via tunnel -->🧠 Analogy: A Secret, Armored Tunnel
Imagine your server is in a distant fortress. To talk to it, you could shout down the street, but anyone would hear you. SSH builds a secret tunnel and shielded that goes straight from your desk into the fortress. Everything you send through this tunnel:
- •No one on the outside can read it (will be encrypted)
- •No one can impersonate you (the login requires your key)
- •You control it from inside (type it here, run it there)
💡 Tip: You already use SSH without realizing it
When you git push for GitHub using a URL that starts with git@github.com, behind the scenes, SSH handles the secure connection. The same protocol you’ll use to access your VPS moves your code every day.
Generating Your Key Pair
SSH uses two keys that are created together: one publishes is a private. The public one is the one you distribute to the servers you want to connect to. The private one stays stored on your machine and never, ever leave it. You're the one who has your private key. The whole world has your public key, and that's fine.
🧠 Analogy: Lock and Key
The key publishes and like a open padlock: you distribute copies of it to everyone. Anyone can lock a door with your padlock. But only the key private opens this lock, and this key exists only in your pocket. That's why sharing the public key is safe, while losing the private key is dangerous.
ssh-keygen - Create the key pair
Run this command in the your machine (not on the server). The -t ed25519 choose a modern, secure key type.
$ ssh-keygen -t ed25519 -C "seu-email@exemplo.com"
Generating public/private ed25519 key pair.
# Where should you save it? Press Enter for the default
Enter file in which to save the key (/home/voce/.ssh/id_ed25519):
# Key passphrase (optional, but recommended). You can leave it blank
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/voce/.ssh/id_ed25519
Your public key has been saved in /home/voce/.ssh/id_ed25519.pub
See the two files created
$ ls -l ~/.ssh
# -rw------- = only you can read and write (the private one)
-rw------- 1 you you 411 jun 17 10:00 id_ed25519
# .pub = the public one (can be shown)
-rw-r--r-- 1 you you 102 jun 17 10:00 id_ed25519.pub
# View the contents of PUBLIC (this one you can copy)
$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... seu-email@exemplo.com
✓ What TO DO
- ✓Share only the file
.pub - ✓Adding a passphrase to the private key
- ✓Back up the private key somewhere safe
✗ What NOT to do
- ✗Send the private key (
id_ed25519) for no one - ✗Upload the private key to GitHub or a public cloud
- ✗Pasting the private key into chats or emails
⚠️ Common Error
Problem: You copied the wrong file, and the server refuses the connection.
Solution: You should copy the contents of the file ending in .pub (the public key). If you copied the file without the .pub, the private key stayed put; it should never leave your machine. Always check the .pub at the end of the name.
Copying the Public Key to the Server
Your public key needs to be on the server so it can recognize you. The server stores authorized keys in a file called ~/.ssh/authorized_keys. Whenever you try to log in, it checks whether your key is on this list. There are two ways to add your key: the easy one (ssh-copy-id) and the manual one.
Easy way: ssh-copy-id
A single command copies your public key and puts it in the right place.
$ ssh-copy-id usuario@192.168.0.10
# It asks for the server PASSWORD (just this once)
user@192.168.0.10's password:
Number of key(s) added: 1
Now try logging into the machine with: "ssh usuario@192.168.0.10"
Manual way: authorized_keys
If the ssh-copy-id doesn't exist (common on Windows), do it manually. First copy your public key, then paste it on the server.
# On YOUR machine, view the public key
$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3Nza... voce@exemplo.com
# Log in to the server and paste it into the authorized list
$ ssh usuario@192.168.0.10
$ mkdir -p ~/.ssh && chmod 700 ~/.ssh
$ echo "ssh-ed25519 AAAAC3Nza... you@example.com" >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
Test key-based access
Now try logging in again. If the key worked, it no asks for the password again.
$ ssh usuario@192.168.0.10
# No password prompt = the key is working!
Welcome to Ubuntu 22.04 LTS
user@server:~$
⚠️ Common Error
Problem: Even with the key copied, the server keeps asking for a password.
Solution: Almost always, it’s a permissions issue. SSH ignores the folder .ssh if it's "too open." Run on the server: chmod 700 ~/.ssh e chmod 600 ~/.ssh/authorized_keys. This closes the file so only you can access it.
Connecting: ssh usuario@ip
The command to log in is simple: ssh usuario@ip. O user and the account on the server (usually root or a name you created) and the IP is the address of the VPS you wrote down in the previous module. On your first connection, SSH will show you the server’s "fingerprint" and ask if you trust it.
Anatomy of the command
$ ssh root@203.0.113.45
↑ ↑ ↑
cmd user server IP
# To use a port other than the default (22)
$ ssh -p 2222 root@203.0.113.45
👁 What you’ll see on your first visit
$ ssh root@203.0.113.45
The authenticity of host '203.0.113.45' can't be established.
ED25519 key fingerprint is SHA256:a1b2c3d4...
Are you sure you want to continue connecting (yes/no)?
yes
Warning: Permanently added '203.0.113.45' to known hosts.
Welcome to Ubuntu 22.04 LTS
root@servidor:~$
This fingerprint and the server's identity. You type yes just once. SSH stores this identity in the file ~/.ssh/known_hosts and next time, it won’t ask again.
💡 Tip: To exit, type exit
While you're connected, every command runs on the server, not on your computer. To end the session and return to your local terminal, just type exit and press Enter. The prompt will show your machine’s name again.
⚠️ Common Error
Problem: Connection refused or Connection timed out.
Solution: Check three things. (1) Is the IP correct? Compare it with the provider's dashboard. (2) Is the server running? (3) Is port 22 allowed through the VPS firewall? "Refused" usually means the service is stopped; "timed out" usually means the firewall is blocking it. You'll adjust the firewall in the next module.
Shortcuts with ~/.ssh/config
Type ssh root@203.0.113.45 -p 2222 every time is tiring and easy to get wrong. The file ~/.ssh/config lets you give a nickname for each server. After that, you enter a short name, like ssh meuvps, and SSH fills in the rest automatically.
🧠 Analogy: Cell Phone Contacts
You don’t memorize each friend’s phone number: you save it in your contacts with a name and call them by name. The ~/.ssh/config and your server address book. Instead of memorizing IP, username, and port, you save everything under a nickname and "connect" using the nickname.
Create the config file
Open (or create) the file on your machine with nano and write one block per server:
$ nano ~/.ssh/config
# Type this inside nano:
Host meuvps
HostName 203.0.113.45
User root
Port 2222
IdentityFile ~/.ssh/id_ed25519
Save with Ctrl+O, Enter, and exit with Ctrl+X.
What each line means
- •
Host- the nickname you'll type (e.g.,meuvps) - •
HostName- the server's real IP or domain - •
User- the user you log in as - •
Port- the SSH port (only if it's different from 22) - •
IdentityFile- which private key to use for this connection
Before and after
# Before: long and easy-to-mistype command
$ ssh -p 2222 -i ~/.ssh/id_ed25519 root@203.0.113.45
# Then: just the alias
$ ssh meuvps
root@servidor:~$
✓ What TO DO
- ✓Use clear aliases (
prod,teste) - ✓Indent the lines inside each
Host - ✓Point the
IdentityFilecorrect per server
✗ What NOT to do
- ✗Write the port on the
Host - ✗Point the
IdentityFilefor the key.pub - ✗Leave the file readable by other users
Disabling Password Access
As long as the server accepts passwords, internet bots will keep trying to guess yours thousands of times a day. Since you can now log in with a key, you can permanently close the password door. Without an accepted password, these attacks stop working. Only the person with the right private key—you—can get in.
⚠️ Caution: Test the key FIRST
This is the most dangerous part of the module. If you turn off the password without make sure the key works, you could lock yourself out of your own server. Rule of thumb: open a second terminal window and confirm that ssh meuvps log in without asking for a password, and only then change the configuration. Keep the current session open as a safety net.
Open the SSH configuration file
On the server, edit the main file with administrator permissions (sudo).
$ sudo nano /etc/ssh/sshd_config
Change the PasswordAuthentication line
Look for this line (it may appear with # in front, which is a comment) and leave it like this:
# Before (accepted passwords)
#PasswordAuthentication yes
# Afterward (without the # and with "no")
PasswordAuthentication no
Save with Ctrl+O, Enter, and exit with Ctrl+X.
Restart the SSH service
The change only takes effect after you restart sshd. Your current session remains open.
$ sudo systemctl restart ssh
# On some systems, the service is called sshd
$ sudo systemctl restart sshd
Confirm in a new window
Without closing the old session, open another one and log in again. It has to work with a key.
$ ssh meuvps
# Logged in without asking for a password = everything is set!
root@servidor:~$
👁 What changes for an attacker
# Attempt by someone who doesn't have your key:
$ ssh root@203.0.113.45
root@203.0.113.45: Permission denied (publickey).
Notice the publickey: the server says it only accepts keys. With no password to guess, the automated attack has no way to try.
💡 Tip: Keep a plan B
Almost every VPS provider offers a web console (sometimes called "VNC" or "serial console") in the control panel. If you ever lose SSH access, this console lets you access the server through your browser without relying on SSH. Find out where this button is before you need it.
📚 Module Summary
Next Module:
3.3 - Firewall: Controlling Which Ports Are Open and Closing the Server Off to the World