SSH & Key Management

Securely connect to Linux servers using multiple authentication methods. CtrlOps supports password, PEM key, SSH agent, and private key authentication with hardware-backed credential storage.

SSH/SFTP Connection Flow

Authentication Chain

CtrlOps tries authentication methods in this order until one succeeds:

1. Explicit Private Key

Used when you provide a specific key file (e.g., .pem for AWS EC2):

// Try user-provided key first
if let Some(key_path) = &config.private_key {
    let key_content = fs::read_to_string(key_path)?;
    session.userauth_pubkey_memory(
        &config.username,
        None,
        &key_content,
        config.password.as_deref()
    )?;
}

2. SSH Agent

Uses your system's SSH agent for key management:

3. Fallback Keys

Automatically tries common key locations:

~/.ssh/id_ed25519      (preferred - modern, secure)
~/.ssh/id_rsa          (legacy compatibility)
~/.ssh/id_ecdsa        (elliptic curve)
~/.ssh/id_dsa          (deprecated)

4. Password Authentication

Last resort when no keys work:

Securely manage SSH keys across all your servers. Generate new keys, rotate existing ones, and maintain iron-clad access control from a visual interface.

Why Proper User Management Matters

Best practices:

• Each person has their own SSH key pair
• Grant minimum necessary permissions
• Regular key rotation
• Remove access when team members leave

SSH Key Management

Understanding SSH Keys

Each key pair consists of:

• Private key (kept secret, on user's computer)
• Public key (added to server, can be shared)

Think of it like a lock and key:

• Public key = The lock on your door
• Private key = Your physical key

Adding a New SSH Key

ssh-keygen -t ed25519 -C "user@yourdomain.com"

# On the server
echo "ssh-ed25519 AAAAC3NzaC... user@yourdomain.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

ssh user@server-ip

Managing Multiple Keys

When users have multiple keys:

# Create config file
nano ~/.ssh/config

# Add entries
Host server1
    HostName 192.168.1.100
    User john
    IdentityFile ~/.ssh/server1_key

Host server2
    HostName 192.168.1.101
    User john
    IdentityFile ~/.ssh/server2_key

Rotating SSH Keys

When to rotate:

• Employee departure
• Suspected compromise
• Annually (compliance)
• After security incidents

Rotation process:

User Account Management

Creating User Accounts

# Create user with home directory
sudo adduser johndoe

# Set password
sudo passwd johndoe

# Add to sudo group (admin access)
sudo usermod -aG sudo johndoe

User Groups

Common group structure:

admins      - Full server access
developers  - Can deploy code
operators   - Can restart services
analysts    - Read-only access

Creating groups:

# Create group
sudo groupadd developers

# Add user to group
sudo usermod -aG developers johndoe

# Check user's groups
groups johndoe

Removing Users

# Disable login (keep files)
sudo usermod -L johndoe

# Remove user (keep home directory)
sudo deluser johndoe

# Remove user and home directory
sudo deluser --remove-home johndoe

# Remove from all groups
sudo deluser johndoe sudo

Team Collaboration

Role-Based Access

Administrator:

• Full server access
• Can manage other users
• System configuration rights

Developer:

• Deploy code
• Restart application services
• View logs

Operator:

• Monitor systems
• Restart services
• Read-only on sensitive files

Auditor:

• View-only access
• Can read logs
• Cannot modify anything

Managing Access in CtrlOps

SSH Access Dashboard:

Team Members
━━━━━━━━━━━━━━━━━━━━━━━━━━━
👤 John Doe       Admin     Last login: Today
👤 Jane Smith     Dev       Last login: Yesterday
👤 Bob Johnson    Operator  Last login: 3 days ago
👤 Alice Brown    Auditor   Last login: 1 week ago
━━━━━━━━━━━━━━━━━━━━━━━━━━━

Actions available:

• View all users
• Add/remove SSH keys
• Assign roles
• Set expiration dates
• View activity logs

Sharing Access Safely

Instead of sharing passwords or keys:

1. Create individual accounts for each person
2. Assign appropriate permissions via groups
3. Add their individual SSH keys to the server
4. Document who has access in your records

Never do:

• ❌ Share root password
• ❌ Share private keys
• ❌ Email credentials
• ❌ Store passwords in plain text

Key Security Best Practices

Protecting Private Keys

On user's computer:

# Set proper permissions
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

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

# Add passphrase protection
ssh-keygen -p -f ~/.ssh/id_ed25519

Monitoring Access

Check who accessed the server:

# Recent logins
last

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

# Successful SSH connections
sudo grep "Accepted" /var/log/auth.log

Automated Alerts

Set up notifications for:

• New SSH key added
• User login from new IP
• Failed login attempts (more than 5)
• Privilege escalation (sudo usage)

Compliance & Auditing

Access Logs

Required information:

• Who accessed the server
• When they accessed it
• What commands they ran
• Which files they modified

Enable audit logging:

# Install auditd
sudo apt install auditd

# Monitor SSH config changes
auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config_changes

# Monitor user authentication
auditctl -w /etc/passwd -p wa -k user_accounts

Quarterly Reviews

Access audit checklist:

• List all active users
• Review their permissions
• Check last login dates
• Remove inactive accounts
• Rotate old SSH keys
• Update documentation

Offboarding Process

When team members leave:

Troubleshooting

"Permission denied (publickey)"

• Check authorized_keys file permissions (should be 600)
• Verify public key was copied correctly
• Ensure key is in correct user's home directory
• Check SSH config allows key authentication

"Too many authentication failures"

• SSH agent has too many keys loaded
• Specify key manually: ssh -i ~/.ssh/specific_key user@server

"Could not resolve hostname"

• Wrong IP address or hostname
• DNS not resolving
• Network connectivity issue

Connection Diagnostics

Test SSH Connectivity

# Basic connectivity test
ssh -v user@server

# Test specific key
ssh -i ~/.ssh/key.pem -v user@server

# Check server SSH config
ssh -G user@server

Debug Connection Issues

# Verbose output
ssh -vvv user@server

# Check host key
ssh-keyscan -H server_ip >> ~/.ssh/known_hosts

# Test port connectivity
nc -zv server_ip 22

Summary

• One key per person — never share
• Regular rotation — every 6-12 months
• Principle of least privilege — minimum access needed
• Immediate removal — when people leave
• Regular audits — quarterly reviews
• Strong passphrases — protect private keys