Difficulty Level: 🟡 Intermediate
Risk Level: 🟠 Medium - Be careful when modifying security settings
Learn how to manage SSH keys, passwords, review login history, and maintain your server's security.
SSH keys are the primary way to access your server. Here's how to manage them.
When you want to give someone access to your server, you'll add their public key (not private key!).
Ask the team member to send you their public key (the .pub file). It looks like this:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJfF7... user@example.com
⚠️ IMPORTANT: Never ask for their private key! Only the
.pubfile.
Method 1: Using nano (Recommended for beginners)
# Connect to your server
ssh -p 1077 USERNAME@YOUR_SERVER_IP
# Edit the authorized_keys file
nano ~/.ssh/authorized_keys
Ctrl + X to exitY to saveEnter to confirmMethod 2: Using echo (One command)
# Connect to your server
ssh -p 1077 USERNAME@YOUR_SERVER_IP
# Add the key directly (replace with actual public key)
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJfF7... user@example.com" >> ~/.ssh/authorized_keys
Method 3: Using ssh-copy-id (From team member's computer)
If the team member has access to a terminal and already have functional access to the server, they can add their own key:
# From their computer (not the server)
ssh-copy-id -p 1077 USERNAME@YOUR_SERVER_IP
# View all authorized keys
cat ~/.ssh/authorized_keys
Ask the team member to try connecting:
ssh -p 1077 USERNAME@YOUR_SERVER_IP
💡 TIP: Add a comment with a hashtag at the end of the line to each key, so you know who it belongs to:
ssh-ed25519 AAAAC3Nza... john@company.com # John Doe - Added 2024-01-15
When someone leaves your team or no longer needs access, remove their key.
# View all authorized keys with line numbers
cat -n ~/.ssh/authorized_keys
This shows:
1 ssh-ed25519 AAAAC3... admin@company.com
2 ssh-ed25519 AAAAC3... john@company.com
3 ssh-ed25519 AAAAC3... jane@company.com
Method 1: Using nano (Visual editing)
nano ~/.ssh/authorized_keys
Ctrl + K to delete the entire lineCtrl + X to exitY to saveEnter to confirmMethod 2: Using sed (Delete specific line)
# Delete line 2 (John's key)
sed -i '2d' ~/.ssh/authorized_keys
Method 3: Recreate file without the key
# Backup first
cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.backup
# Create new file with only keys you want to keep
cat > ~/.ssh/authorized_keys << 'EOF'
ssh-ed25519 AAAAC3... admin@company.com
ssh-ed25519 AAAAC3... jane@company.com
EOF
# View remaining keys
cat ~/.ssh/authorized_keys
# Verify permissions are correct
ls -la ~/.ssh/authorized_keys
# Should show: -rw------- (600 permissions)
⚠️ WARNING: If you accidentally delete all keys, you'll be locked out! Always keep at least one working key (yours).
See all authorized keys:
cat ~/.ssh/authorized_keys
See keys with better formatting:
# Show with line numbers and comments
cat -n ~/.ssh/authorized_keys | grep -E "ssh-|#"
Check permissions (should be 600):
ls -la ~/.ssh/authorized_keys
Fix permissions if needed:
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh
⚠️ WARNING: Don't forget that the root user may also have access to the server. His key is in the directory /root/.ssh
Your server uses SSH key authentication by default, but passwords can still be reactivated if you want to keep that option. It's a less secure option, but since fail2ban is installed, bruteforce your server is impossible.
Change your own password:
# Run the passwd command
passwd
# You'll be prompted:
# Current password: [type current password]
# New password: [type new password]
# Retype new password: [confirm new password]
Password requirements:
Change another user's password (if you have sudo):
sudo passwd USERNAME
💡 TIP: Use a password manager to generate and store strong passwords!
By default, password authentication is disabled for security. Here's how to enable it if needed.
⚠️ WARNING: Enabling password authentication reduces security. Only do this if absolutely necessary.
# Open SSH config file
sudo nano /etc/ssh/sshd_config
Look for these settings and change them:
# Change this:
PasswordAuthentication no
# To this:
PasswordAuthentication yes
💡 TIP: Use
Ctrl + Win nano to search for "PasswordAuthentication"
# Restart SSH to apply changes
sudo systemctl restart sshd
# Verify SSH is still running
sudo systemctl status sshd
⚠️ IMPORTANT: Keep your current SSH session open while testing! Open a new terminal to test password login before closing your original connection.
From a new terminal:
# Try connecting with password
ssh -p 1077 USERNAME@YOUR_SERVER_IP
# You should now be prompted for a password
To return to key-only authentication (more secure):
sudo nano /etc/ssh/sshd_config
# Change these:
PasswordAuthentication yes
# Back to:
PasswordAuthentication no
sudo systemctl restart sshd
✅ BEST PRACTICE: Always use SSH keys instead of passwords when possible.
Regularly check who's accessing your server and when.
View recent successful logins:
# Show last 20 logins
last -n 20
# Example output:
# admin pts/0 192.168.1.100 Mon Jan 15 14:32 still logged in
# admin pts/0 192.168.1.100 Mon Jan 15 10:15 - 12:30 (02:15)
View last login for each user:
lastlog
# Example output:
# Username Port From Latest
# admin pts/0 192.168.1.100 Mon Jan 15 14:32:10 +0000 2024
# john pts/1 203.0.113.50 Sun Jan 14 09:21:43 +0000 2024
View last login for specific user:
lastlog -u USERNAME
Filter by time:
# Logins in the last 7 days
last -s -7days
# Logins since specific date
last -s 20240101
Check authentication log for failed attempts:
# View recent auth events
sudo tail -n 50 /var/log/auth.log
# Search for failed password attempts
sudo grep "Failed password" /var/log/auth.log | tail -n 20
# Search for failed SSH key attempts
sudo grep "publickey" /var/log/auth.log | grep "Failed" | tail -n 20
Count failed attempts by IP:
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr
Example output:
15 203.0.113.45
8 198.51.100.23
3 192.0.2.100
🔍 INTERPRETATION: If you see many failed attempts from unknown IPs, that's normal - bots constantly scan for SSH servers. That's why fail2ban is installed!
See who's logged in right now:
# Simple view
who
# Detailed view with idle time
w
# Example output:
# USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
# admin pts/0 192.168.1.100 14:32 0.00s 0.04s 0.00s w
# john pts/1 203.0.113.50 15:10 5:00 0.02s 0.02s vim
See active SSH connections:
# List all SSH connections
ss -tnp | grep :1077
# Or using netstat
sudo netstat -tnp | grep :1077
Fail2ban automatically blocks IPs that show malicious behavior (too many failed login attempts).
View fail2ban status:
# Overall status
sudo fail2ban-client status
# Example output:
Status
|- Number of jail: 3
`- Jail list: port-scan, ssh-username-scan, sshd
Check specific jail (sshd) status:
sudo fail2ban-client status port-scan
# Example output:
Status for the jail: port-scan
|- Filter
| |- Currently failed: 598
| |- Total failed: 27725
| `- Journal matches:
`- Actions
|- Currently banned: 354
|- Total banned: 354
`- Banned IP list: 198.12.88.142 80.94.95.115 91.191.209.54 [....]
View fail2ban logs:
# Recent fail2ban activity
sudo tail -n 50 /var/log/fail2ban.log
# Search for bans
sudo grep "Ban" /var/log/fail2ban.log | tail -n 20
# Search for unbans
sudo grep "Unban" /var/log/fail2ban.log | tail -n 20
If someone (or you!) gets accidentally banned, here's how to unban them:
Unban a specific IP:
# Unban the IP
# sudo fail2ban-client set [jail-name] unbanip [ip-to-unban]
sudo fail2ban-client set sshd unbanip 203.0.113.45
# Verify it's unbanned
sudo fail2ban-client status sshd
Unban all IPs (nuclear option):
# Stop fail2ban
sudo systemctl stop fail2ban
# Start fail2ban (all bans cleared)
sudo systemctl start fail2ban
💡 TIP: Write down the unbanning command somewhere safe in case you lock yourself out!
Prevent specific IPs from ever being banned (like your office IP or home IP).
# Create local config (preferred method)
sudo nano /etc/fail2ban/jail.local
# Add these lines at the top
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
YOUR_HOME_IP
YOUR_OFFICE_IP
192.168.1.0/24
# Example:
ignoreip = 127.0.0.1/8 ::1
203.0.113.45
198.51.100.23
192.168.1.0/24
IP format options:
203.0.113.45192.168.1.0/24 (all IPs from .1 to .254)# Test configuration first
sudo fail2ban-client -t
# If no errors, restart
sudo systemctl restart fail2ban
# Verify it's running
sudo systemctl status fail2ban
# Check if your IPs are in the ignore list
sudo fail2ban-client get sshd ignoreip
Change how long IPs stay banned:
# Edit local config
sudo nano /etc/fail2ban/jail.local
Add or modify:
[sshd]
enabled = true
port = 1077
bantime = 3600 # Ban for 1 hour (in seconds)
findtime = 600 # Look for failures in 10-minute window
maxretry = 5 # Ban after 5 failed attempts
Common bantime values:
600 = 10 minutes3600 = 1 hour86400 = 24 hours-1 = Permanent banRestart fail2ban after changes:
sudo systemctl restart fail2ban
ℹ️ INFO: I've set up your server to ban any IP permanently.
UFW (Uncomplicated Firewall) protects your server by controlling which ports are accessible.
View firewall status:
sudo ufw status
# Example output:
Status: active
To Action From
-- ------ ----
80/tcp ALLOW Anywhere # http
443/tcp ALLOW Anywhere # https
1077/tcp ALLOW Anywhere # ssh
80/tcp (v6) ALLOW Anywhere (v6) # http
443/tcp (v6) ALLOW Anywhere (v6) # https
1077/tcp (v6) ALLOW Anywhere (v6) # ssh
# Since you have fail2ban, you will have many rule based on banned IPs, in order to show only opened port, you can filter out the REJECT rules
sudo ufw status | grep ALLOW
# Example output:
80/tcp ALLOW Anywhere # http
443/tcp ALLOW Anywhere # https
1077/tcp ALLOW Anywhere # ssh
80/tcp (v6) ALLOW Anywhere (v6) # http
443/tcp (v6) ALLOW Anywhere (v6) # https
1077/tcp (v6) ALLOW Anywhere (v6) # ssh
View numbered rules (easier to delete):
sudo ufw status numbered
# Example output:
[356] 80/tcp ALLOW IN Anywhere # http
[357] 443/tcp ALLOW IN Anywhere # https
[358] 1077/tcp ALLOW IN Anywhere # ssh
[359] Anywhere (v6) REJECT IN fe80::f816:3eff:fe15:f6bd # by Fail2Ban after 5 attempts against port-scan
[360] 80/tcp (v6) ALLOW IN Anywhere (v6) # http
[361] 443/tcp (v6) ALLOW IN Anywhere (v6) # https
[362] 1077/tcp (v6) ALLOW IN Anywhere (v6) # ssh
View detailed status:
sudo ufw status verbose
⚠️ WARNING: Only open ports you actually need. Every open port is a potential security risk.
Open a single port:
# Allow port 8080
sudo ufw allow 8080/tcp
# Verify it was added
sudo ufw status
Open a port range:
# Allow ports 8000-9000
sudo ufw allow 8000:9000/tcp
Allow from specific IP:
# Only allow 203.0.113.45 to access port 3306
sudo ufw allow from 203.0.113.45 to any port 3306
Common ports you might need:
80 - HTTP (web traffic)443 - HTTPS (secure web traffic)1077 - SSH (already open)3306 - MySQL (database)5432 - PostgreSQL (database)6379 - Redis (cache)Delete a rule by number:
# First, view numbered rules
sudo ufw status numbered
# Delete rule number 4
sudo ufw delete 4
# Confirm when prompted
Delete a rule by specification:
# Remove port 8080
sudo ufw delete allow 8080/tcp
# Remove specific IP rule
sudo ufw delete allow from 203.0.113.45 to any port 3306
Deny a port (block explicitly):
# Block port 25 (SMTP)
sudo ufw deny 25/tcp
1. Default deny incoming:
# This should already be set
sudo ufw default deny incoming
sudo ufw default allow outgoing
2. Always keep SSH open:
# Before making changes, ensure SSH is allowed
sudo ufw allow 1077/tcp
3. Enable logging (helpful for debugging):
# Enable logging
sudo ufw logging on
# View logs
sudo tail -f /var/log/ufw.log
4. Reload after changes:
# Reload firewall rules
sudo ufw reload
⚠️ CRITICAL WARNING: Never disable UFW or delete the SSH port rule (1077/tcp) or you'll lock yourself out!
🚨 CRITICAL ALERT: If you add new Docker container and expose their port, Docker will automatically open their port, and it will have priority on any pre-existing firewall rules.
If you accidentally block SSH and can't connect:
Option 1: Cloud Provider Console
sudo ufw allow 1077/tcp
sudo ufw reload
Option 2: Disable UFW temporarily
# From console
sudo ufw disable
# Fix your rules
sudo ufw allow 1077/tcp
sudo ufw enable
You should now be able to:
Use this checklist monthly:
# SSH Keys
cat ~/.ssh/authorized_keys # View authorized keys
nano ~/.ssh/authorized_keys # Edit authorized keys
chmod 600 ~/.ssh/authorized_keys # Fix permissions
# Password
passwd # Change your password
# Login History
last -n 20 # Recent logins
lastlog # Last login per user
who # Currently logged in
sudo grep "Failed" /var/log/auth.log # Failed attempts
# Fail2ban
sudo fail2ban-client status sshd # Check bans
sudo fail2ban-client set sshd unbanip IP # Unban IP
# Firewall
sudo ufw status # Check firewall
sudo ufw allow PORT/tcp # Open port
sudo ufw delete allow PORT/tcp # Close port
Next Guide: 04 - Linux Command Cheatsheet
Previous Guide: 02 - SSH Connection Guide
Back to: Documentation Home