SSH & Security

This guide explains SSH (Secure Shell) in plain English — what it is, how it keeps you safe, and best practices for securing your servers.

What is SSH?

SSH is like a secure phone call between your computer and your server. It:

• Encrypts all communication (nobody can listen in)
• Authenticates you (proves you are who you say you are)
• Protects your data from hackers and eavesdroppers

Think of it like this:

• Without SSH: Shouting your password across a crowded room
• With SSH: Whispering through a sealed, soundproof tube

SSH Keys Explained

The Two-Key System

SSH uses two keys that work together:

Where Does CtrlOps Store Keys?

CtrlOps stores your SSH keys securely on your local machine:

• Mac: ~/Library/Application Support/CtrlOps/keys/
• Windows: %APPDATA%\CtrlOps\keys\
• Linux: ~/.config/CtrlOps/keys/

Keys are encrypted at rest and never leave your computer.

Root vs Non-Root Access

What is Root?

root is the superuser account on Linux — it has unlimited power:

• Can delete any file
• Can install any software
• Can change any setting
• Can break the entire system

When to Use Root

Use root when you need to:

• Install system-wide software
• Modify system configuration
• Manage other user accounts
• Access protected system files

Don't use root when:

• Running regular applications
• Editing your own project files
• Doing routine maintenance

Best Practice: Create a Non-Root User

For daily operations, create a regular user account:

# As root, create a new user
sudo adduser myusername

# Add user to sudo group for admin privileges
sudo usermod -aG sudo myusername

This way, you:

• Have daily access without risking accidental damage
• Can escalate to root when needed with sudo
• Limit the blast radius if credentials are compromised

Security Best Practices

1. Disable Password Authentication

Passwords can be guessed. Use SSH keys exclusively:

# Edit SSH config
sudo nano /etc/ssh/sshd_config

# Change these lines:
PasswordAuthentication no
PubkeyAuthentication yes

# Restart SSH
sudo systemctl restart sshd

2. Use a Firewall

Only allow SSH from trusted IPs:

# Allow SSH only from your office IP
sudo ufw allow from 203.0.113.0/24 to any port 22

# Or block all incoming except SSH
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

3. Keep Software Updated

Security patches fix vulnerabilities:

# Ubuntu/Debian
sudo apt update && sudo apt upgrade

# CentOS/RHEL
sudo yum update

4. Monitor Login Attempts

Check who's trying to access your server:

# See failed login attempts
sudo grep "Failed password" /var/log/auth.log

# See successful logins
sudo grep "Accepted" /var/log/auth.log

5. Use Fail2Ban

Automatically block IPs with too many failed attempts:

# Install
sudo apt install fail2ban

# Enable
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

CtrlOps Security Features

CtrlOps adds additional security layers:

Encrypted Storage

• All credentials encrypted with AES-256
• Keys stored in OS-level secure enclaves
• Automatic key rotation reminders

Session Management

• Connections timeout after inactivity
• Automatic reconnection with fresh authentication
• Session logging for audit trails

Approval-Based Execution

• High-risk commands require confirmation
• Dry-run mode for dangerous operations
• Rollback capabilities for mistakes

What If My Key is Compromised?

If you think someone has your private key:

# On the server, edit authorized keys
nano ~/.ssh/authorized_keys

# Delete the line corresponding to the compromised key

# Generate new key
ssh-keygen -t ed25519 -C "your_email@yourdomain.com"

# Add new public key to server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# See recent logins
last

# See failed attempts
sudo grep "Failed password" /var/log/auth.log

Summary

• SSH encrypts your connection to the server
• Private keys must be kept secret — never share them
• Public keys can be safely shared and go on the server
• Root access is powerful — use it sparingly
• Regular updates and firewalls keep you secure