SSH_Complete_Interview_Guide

SSH Mastery Guide for Technical Interviews

The definitive guide covering everything you need to know about SSH for job interviews, from fundamentals to enterprise-level security.

Table of Contents

1. SSH Fundamentals
2. How SSH Actually Works
3. Authentication Methods Deep Dive
4. SSH Key Management Mastery
5. SSH Hardening and Security
6. Command Line Mastery
7. SSH Tunneling and Advanced Features
8. Enterprise SSH Management
9. Troubleshooting Like a Pro
10. Interview Questions with Expert Answers
11. Quick Reference Card

SSH Fundamentals

What is SSH?

SSH (Secure Shell) is a cryptographic network protocol that provides secure communication over insecure networks. Think of it as a secure tunnel for all your remote operations.

Why SSH matters in interviews:

• Essential for DevOps, SysAdmin, and Backend roles
• Demonstrates security awareness
• Shows system administration competence
• Critical for cloud infrastructure management

The Big Picture

SSH replaced insecure protocols like Telnet, rsh, and rlogin. It provides:

• 🔐 Encryption: All communication is encrypted end-to-end
• 🔑 Authentication: Strong user and host verification
• 🛡️ Integrity: Data tampering detection
• 🌉 Tunneling: Secure channel for other protocols
• 📁 File Transfer: Built-in secure file transfer (SCP/SFTP)

How SSH Actually Works

Understanding SSH’s inner workings is crucial for troubleshooting and interview discussions.

The SSH Handshake (Step by Step)

Client                                Server
  |                                     |
  |-------- TCP Connection ------------>| (Port 22)
  |<------- SSH Version Exchange -------|
  |<------- Host Key + Algorithms ------|
  |-------- Key Exchange Begin -------->|
  |<------- Session Keys Established ---|
  |-------- Host Key Verification ----->|
  |-------- User Authentication ------->|
  |<------- Authenticated Session ------|

Protocol Versions (Interview Favorite!)

Version	Status	Key Differences
SSH-1	DEPRECATED	Single connection, weak security
SSH-2	Standard	Multiple channels, stronger crypto

Interview Tip: Always mention you’d disable SSH-1 in production!

Authentication Methods Deep Dive

Interview Gold: Understanding these methods shows security maturity!

Authentication Method Comparison

Method	Security	Use Case	Interview Appeal
Password	⭐	Development only	❌ Avoid
Public Key	⭐⭐⭐⭐	Production standard	✅ Essential
Certificate	⭐⭐⭐⭐⭐	Enterprise scale	✅ Advanced
Host-based	⭐⭐	Legacy systems	⚠️ Niche
MFA/2FA	⭐⭐⭐⭐⭐	High-security environments	✅ Modern

1. Password Authentication (The Dangerous Default)

ssh user@hostname
# System prompts for password

Why interviewers ask about this:

• Tests security awareness
• Common misconfiguration
• Easy attack vector

Red flags to mention:

• Brute-force vulnerable
• Dictionary attacks
• Credential theft risk
• No audit trail

2. Public Key Authentication (The Gold Standard)

ssh -i ~/.ssh/private_key user@hostname

The Magic Behind It:

1. Client has private key (never shared)
2. Server has public key (can be shared)
3. Cryptographic proof without revealing secrets

Interview scenario: “Walk me through what happens when I SSH with a key.”

1. Client: "I want to authenticate as 'user'"
2. Server: "Prove you have the private key for this public key"
3. Client: Signs challenge with private key
4. Server: Verifies signature with public key
5. Server: "Authentication successful!"

3. SSH Certificates (Enterprise Gold Standard)

Critical Interview Topic: SSH certificates solve key management at scale.

The Problem with Keys:

• 1000 servers × 100 developers = 100,000 key pairs to manage
• Key rotation becomes impossible
• No easy way to revoke access
• No centralized audit trail

The Certificate Solution:

# Certificate Authority signs user keys
ssh-keygen -s ca_key -I user@company.com -V +1d user_key.pub
 
# Server trusts the CA, not individual keys
echo "TrustedUserCAKeys /etc/ssh/ca.pub" >> /etc/ssh/sshd_config

Interview Benefits of Understanding Certificates:

• Shows enterprise thinking
• Demonstrates scalability awareness
• Advanced security knowledge

4. Multi-Factor Authentication (MFA/2FA)

Modern Security: Combining something you have + something you know.

# Server configuration for Google Authenticator
AuthenticationMethods publickey,keyboard-interactive
ChallengeResponseAuthentication yes
UsePAM yes

Popular MFA Methods:

• TOTP: Google Authenticator, Authy
• Hardware tokens: YubiKey, RSA SecurID
• SMS: Less secure, but widely supported

Interview Discussion Points:

• Why MFA is critical for privileged access
• How to balance security with usability
• Integration with enterprise identity systems

SSH Key Management Mastery

Interview Insight: Key management questions test both security knowledge and practical experience.

The Modern Key Generation Playbook

# 🥇 GOLD STANDARD: Ed25519 (recommended for new keys)
ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519_production
 
# 🥈 SILVER: RSA 4096 (for legacy compatibility)
ssh-keygen -t rsa -b 4096 -C "your_email@example.com" -f ~/.ssh/id_rsa_legacy
 
# ❌ AVOID: RSA 2048 or lower (legacy, not recommended for new keys)

Key Algorithm Decision Matrix

Algorithm	Strength	Speed	Compatibility	2024 Status
Ed25519	🔥 Excellent	🚀 Fastest	✅ Modern	USE THIS
RSA 4096	✅ Good	🐌 Slower	✅ Universal	Legacy support
ECDSA P-521	✅ Good	⚡ Fast	✅ Good	Alternative
RSA 2048	⚠️ Legacy	🐌 Slow	✅ Universal	Legacy only

Professional Key Distribution

# 🎯 PROFESSIONAL METHOD: ssh-copy-id
ssh-copy-id -i ~/.ssh/id_ed25519 user@hostname
 
# 🔧 MANUAL METHOD (when ssh-copy-id unavailable)
cat ~/.ssh/id_ed25519.pub | ssh user@hostname \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
 
# 🚨 SECURITY CHECK: Verify key installation
ssh user@hostname "tail -1 ~/.ssh/authorized_keys"

Interview Gotcha: Note that ssh-copy-id automatically handles the .pub extension:

# These are equivalent:
ssh-copy-id -i ~/.ssh/id_ed25519 user@host
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

SSH Agent: Your Key Butler

Why SSH Agent matters in interviews:

• Prevents repeated passphrase entry
• Keeps keys in memory securely
• Essential for automation scripts
• Security risk: Agent forwarding can be compromised

# Start SSH agent (usually done in .bashrc/.zshrc)
eval "$(ssh-agent -s)"
 
# Add keys with passphrase caching
ssh-add ~/.ssh/id_ed25519
ssh-add ~/.ssh/id_rsa_legacy
 
# Professional key management
ssh-add -l                    # List loaded keys
ssh-add -t 3600 ~/.ssh/key   # Add key for 1 hour only
ssh-add -D                   # Clear all keys (security practice)

SSH Hardening and Security

Interview Reality: Security discussions showcase your production readiness!

The SSH Security Hierarchy (Memorize This Order!)

1. 🔐 Cryptographic Security

   • Ed25519 keys only (or RSA 4096+)
   • Strong passphrases on private keys
   • Regular key rotation (annually minimum)

2. 🚪 Access Control

   • No password authentication
   • No root login (use sudo)
   • User whitelisting (AllowUsers)
   • Group-based permissions

3. 🛡️ Network Protection

   • Change default port (security through obscurity)
   • IP whitelisting when possible
   • Rate limiting (fail2ban)
   • VPN for additional security

4. 📊 Monitoring & Logging

   • Verbose logging enabled
   • Log monitoring (ELK stack, Splunk)
   • Failed attempt alerting
   • Regular security audits

Client Configuration Mastery (~/.ssh/config)

The Professional’s SSH Config:

# ================================
# GLOBAL SECURITY DEFAULTS
# ================================
Host *
    # Prevent connection hanging
    ServerAliveInterval 60
    ServerAliveCountMax 3
    
    # Security defaults
    ForwardAgent no
    AddKeysToAgent yes
    UseKeychain yes  # macOS only (Linux: use gnome-keyring/kwallet)
    
    # Prevent MitM attacks
    StrictHostKeyChecking ask
    HashKnownHosts yes
 
# ================================
# PRODUCTION SERVER EXAMPLES
# ================================
Host prod-web
    HostName 203.0.113.10
    User deploy
    Port 22022                    # Non-standard port
    IdentityFile ~/.ssh/id_ed25519_production
    ForwardAgent no               # Security: never forward to production
    
Host dev-server
    HostName dev.company.com
    User developer
    IdentityFile ~/.ssh/id_ed25519_dev
    ForwardAgent yes              # OK for development
    LocalForward 3306 localhost:3306  # Database tunnel
 
# ================================
# JUMP HOST CONFIGURATION
# ================================
Host internal-db
    HostName 10.0.1.50
    User dbadmin
    ProxyJump bastion
    
Host bastion
    HostName bastion.company.com
    User ops
    IdentityFile ~/.ssh/id_ed25519_bastion

Server Configuration Hardening (/etc/ssh/sshd_config)

Rather than presenting this as one large block, let’s break it down by security concern:

Protocol and Authentication Security

Protocol 2                         # SSH-2 only
Port 22022                        # Non-standard port
PermitRootLogin no                # CRITICAL: No root login
PasswordAuthentication no         # Keys only
PubkeyAuthentication yes
AuthenticationMethods publickey   # Explicit method
MaxAuthTries 3                   # Limit brute force
LoginGraceTime 30                # Quick timeout

Why these matter: Disabling SSH-1 prevents protocol downgrade attacks. Non-standard ports reduce automated attack attempts. Disabling root login forces proper sudo usage.

User Access Control

AllowUsers deploy ops developer   # Whitelist approach
DenyUsers root guest             # Blacklist dangerous users
AllowGroups ssh-users            # Group-based access
 
# Advanced: Match blocks for conditional rules
Match User admin
    AuthenticationMethods publickey,keyboard-interactive
    ForceCommand /usr/bin/admin-shell

Interview insight: Match blocks allow different rules for different users - perfect for requiring MFA for administrators while allowing key-only auth for service accounts.

Connection and Resource Management

ClientAliveInterval 300          # 5 minutes
ClientAliveCountMax 2            # 2 missed pings = disconnect
MaxStartups 10:30:60            # Connection limits
MaxSessions 4                    # Sessions per connection

Logging and Monitoring

LogLevel VERBOSE                 # Detailed logging
SyslogFacility AUTH             # Where to log
PrintLastLog yes                # Show last login

Feature Restrictions

X11Forwarding no                # Disable unless needed
AllowTcpForwarding no           # Disable unless needed
GatewayPorts no                 # Disable remote forwards
PermitTunnel no                 # Disable VPN-like features

File Permissions (Interview Favorite!)

# CRITICAL: Wrong permissions = SSH rejection
chmod 700 ~/.ssh                    # SSH directory
chmod 600 ~/.ssh/id_*               # Private keys
chmod 644 ~/.ssh/*.pub               # Public keys  
chmod 600 ~/.ssh/authorized_keys     # Server's authorized keys
chmod 600 ~/.ssh/config             # Client config
chmod 644 ~/.ssh/known_hosts         # Known hosts
 
# Server side permissions
chmod 755 /home/username             # User home directory
chmod 700 /home/username/.ssh        # SSH directory
chmod 600 /home/username/.ssh/authorized_keys

Interview Pro Tip: Always mention you check permissions when troubleshooting!

Agent Forwarding Security Risk

Critical Interview Topic: Many candidates don’t understand the risks.

# DANGEROUS: Agent forwarding
ssh -A user@compromised-server
 
# What happens:
# 1. Your local SSH agent socket is forwarded
# 2. Root on remote server can access your agent
# 3. Root can use your keys to access other servers

Safe Alternative: ProxyJump

# SAFE: Jump through servers without exposing agent
ssh -J jump-host final-destination

Interview Discussion: Always explain that ProxyJump creates separate connections, so your keys never exist on intermediate hosts.

Command Line Mastery

Interview Reality: Commands show hands-on experience vs theoretical knowledge.

Essential SSH Commands (Memorize These!)

# ============================================
# BASIC CONNECTIONS (Interview Fundamentals)
# ============================================
ssh user@hostname                    # Standard connection
ssh -p 2222 user@hostname           # Non-standard port
ssh -i ~/.ssh/key user@hostname     # Specific key
ssh user@hostname "uptime"          # Execute single command
ssh -t user@hostname "sudo htop"    # Force pseudo-terminal
 
# ============================================
# DEBUGGING ARSENAL (Troubleshooting Skills)
# ============================================
ssh -v user@hostname               # Basic verbosity
ssh -vvv user@hostname             # Maximum verbosity (interview favorite!)
ssh -o ConnectTimeout=10 user@host # Connection timeout
ssh -o StrictHostKeyChecking=no    # Skip host key check (use carefully!)
 
# ============================================
# FILE OPERATIONS (Practical Skills)
# ============================================
# SCP: One-off file transfers
scp file.txt user@host:/tmp/        # Upload file
scp user@host:/tmp/file.txt ./      # Download file  
scp -r directory/ user@host:/tmp/   # Upload directory
scp -P 2222 file.txt user@host:/    # Non-standard port (note: uppercase P!)
 
# SFTP: Interactive file transfer
sftp user@hostname
sftp -P 2222 user@hostname          # Non-standard port
 
# RSYNC: Superior for large transfers
rsync -avz -e ssh directory/ user@host:/destination/
rsync -avz -e "ssh -p 2222" directory/ user@host:/destination/
 
# ============================================
# POWER USER COMBINATIONS
# ============================================
# Background connection with compression
ssh -f -N -C -L 8080:localhost:80 user@host
 
# Jump through multiple hosts
ssh -J jump1,jump2 final-destination
 
# Execute script on remote server
ssh user@host 'bash -s' < local-script.sh

Interview Gotcha: SSH vs SCP port flags

• SSH: -p (lowercase)
• SCP: -P (uppercase)

File Transfer Comparison

Method	Best For	Pros	Cons
SCP	Simple file copies	Easy, works everywhere	No resume, no sync
SFTP	Interactive transfers	Built into SSH, secure	Manual process
rsync	Large/complex transfers	Resume, sync, efficient	More complex syntax

SSH Tunneling and Advanced Features

Interview Gold: Tunneling shows advanced networking knowledge.

Port Forwarding Types

Local Port Forwarding (Bring Remote to Local)

# Forward local port 8080 to remote port 80
ssh -L 8080:localhost:80 user@hostname
 
# Access remote database securely
ssh -L 3306:db-server:3306 user@jump-host
# Now connect to localhost:3306 to reach db-server:3306

Use cases: Access internal web apps, secure database connections

Remote Port Forwarding (Share Local with Remote)

# Make local port 3000 accessible from remote port 8080
ssh -R 8080:localhost:3000 user@hostname
# Remote users can access localhost:8080 to reach your local:3000

Use cases: Demo local development to remote teams, temporary access

Dynamic Port Forwarding (SOCKS Proxy)

# Create SOCKS proxy on local port 1080
ssh -D 1080 user@hostname
# Configure browser to use localhost:1080 as SOCKS proxy

Use cases: Secure web browsing, bypass geo-restrictions (where permitted)

Advanced SSH Features

SSH Multiplexing (Connection Sharing)

# Enable in ~/.ssh/config
Host *
    ControlMaster auto
    ControlPath ~/.ssh/control-%r@%h:%p
    ControlPersist 10m

Benefits: Faster subsequent connections, reduced authentication overhead

SSH Escape Sequences

~.  # Terminate connection
~^Z # Suspend connection
~#  # List forwarded connections
~?  # Show all escape sequences

Interview tip: Show you know these exist, even if you don’t use them daily.

Enterprise SSH Management

Advanced Interview Topic: Shows you can think at scale.

Certificate-Based SSH at Scale

The Challenge: Managing SSH access for large organizations

• 10,000+ servers
• 1,000+ developers
• Frequent onboarding/offboarding
• Compliance requirements

Traditional Key Management Problems:

# For each new server:
for user in developer1 developer2 ... developer1000; do
    ssh-copy-id $user@new-server
done
 
# For each departing employee:
# Remove key from 10,000 authorized_keys files - nightmare!

Certificate Solution:

# 1. Create Certificate Authority
ssh-keygen -f ca_key -t ed25519
 
# 2. Configure servers to trust CA
echo "TrustedUserCAKeys /etc/ssh/ca.pub" >> /etc/ssh/sshd_config
 
# 3. Issue user certificates
ssh-keygen -s ca_key \
  -I "john.doe@company.com" \
  -V +1d \
  -n john.doe,jdoe \
  ~/.ssh/id_ed25519.pub
 
# 4. User connects with certificate
ssh -i ~/.ssh/id_ed25519-cert.pub user@any-server

Certificate Benefits:

• Centralized revocation (short lifespans)
• Granular permissions per certificate
• Audit trail in certificate metadata
• No key distribution needed

SSH in CI/CD Pipelines

Interview Scenario: “How do you securely deploy code via SSH?”

# BAD: Keys in code
ssh-keygen -f deploy_key  # Committed to repo - NEVER!
 
# GOOD: Dedicated service keys
ssh-keygen -f ci_deploy_key -t ed25519 -N ""
# Store in CI system's secret management
# Use restricted authorized_keys command:
command="cd /app && git pull" ssh-ed25519 AAAAC3...

Best Practices:

• Separate deploy keys per service
• Restrict commands in authorized_keys
• Use pull-based deployments when possible
• Rotate keys regularly

SSH Bastion/Jump Host Patterns

Enterprise Reality: Direct server access is rarely allowed.

Developer → Bastion Host → Internal Servers

Modern ProxyJump Configuration:

# ~/.ssh/config
Host bastion
    HostName bastion.company.com
    User ops
    IdentityFile ~/.ssh/bastion_key
 
Host internal-*
    ProxyJump bastion
    User app
    IdentityFile ~/.ssh/internal_key
 
# Usage: ssh internal-web01 (automatically jumps through bastion)

Advanced: Multi-tier jumps

ssh -J bastion1,bastion2 final-server

Troubleshooting Like a Pro

Interview Favorite: Troubleshooting questions test real-world experience.

The SSH Debug Toolkit

1. Connection Issues

# Layer by layer debugging
ping hostname                        # Network connectivity
telnet hostname 22                  # Port accessibility
nmap -p 22 hostname                 # Port scan
ssh -vvv user@hostname              # Maximum SSH verbosity

2. Authentication Issues

# Key problems
ssh -i ~/.ssh/specific_key user@host
ssh-add -l                          # List loaded keys
ssh -T git@github.com               # Test key without shell
 
# Permission problems
ls -la ~/.ssh/                      # Check local permissions
ssh user@host "ls -la ~/.ssh/"      # Check remote permissions

3. Host Key Issues

# When you get "Host key verification failed"
ssh-keygen -H -F hostname           # Find host key
ssh-keygen -R hostname              # Remove old host key
ssh-keyscan hostname >> ~/.ssh/known_hosts  # Add new key

Common Issues and Solutions

”Permission denied (publickey)”

Debugging steps:

1. Check key permissions (chmod 600 ~/.ssh/id_*)
2. Verify key is loaded (ssh-add -l)
3. Confirm public key on server (cat ~/.ssh/authorized_keys)
4. Check server logs (tail /var/log/auth.log)

“Connection refused”

Possible causes:

1. SSH daemon not running (systemctl status sshd)
2. Firewall blocking (iptables -L | grep 22)
3. Wrong port (nmap -p 1-65535 hostname)
4. Too many connections (MaxStartups in sshd_config)

SSH hanging or slow

Common solutions:

# Disable DNS lookups in sshd_config
UseDNS no
 
# Add to client config for faster connections
Host *
    GSSAPIAuthentication no
    IdentitiesOnly yes

Advanced Troubleshooting

SSH Agent Issues

# Agent not running
echo $SSH_AUTH_SOCK                 # Should show socket path
ssh-add -l 2>&1                    # Check agent status
 
# Agent forwarding problems  
ssh -A -t user@host1 ssh user@host2  # Test forwarding

Certificate Debugging

# Verify certificate
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub
 
# Test certificate authentication
ssh -vvv -i ~/.ssh/id_ed25519-cert.pub user@host

Interview Questions with Expert Answers

Technical Deep Dive Questions

Q: Explain the difference between ssh -L and ssh -R.

Expert Answer:

• ssh -L creates local port forwarding - it opens a port on your local machine that forwards to a remote address. Use case: accessing a remote database securely.
• ssh -R creates remote port forwarding - it opens a port on the remote machine that forwards back to your local machine. Use case: sharing your local development server with remote colleagues.

Q: How does public key authentication work at the protocol level?

Expert Answer:

1. Client connects and announces intent to authenticate with a specific key
2. Server checks if the public key is in authorized_keys
3. Server generates a random challenge and encrypts it with the public key
4. Client decrypts the challenge with its private key and sends back the answer
5. Server verifies the answer - if correct, authentication succeeds

This proves the client has the private key without ever transmitting it.

Q: What’s the security risk with SSH agent forwarding?

Expert Answer: Agent forwarding (ssh -A) creates a socket on the remote server that connects back to your local SSH agent. If the remote server is compromised, an attacker with root access can use that socket to authenticate as you to other servers. The safer alternative is ProxyJump, which creates separate connections without exposing your agent.

Scenario-Based Questions

Q: You’re managing SSH access for 1000 developers across 5000 servers. How do you handle this?

Expert Answer: I’d implement SSH certificates instead of individual key management:

1. Set up an SSH Certificate Authority (CA)
2. Configure all servers to trust the CA (TrustedUserCAKeys)
3. Issue short-lived certificates (24-48 hours) to developers
4. Use certificate principals to control which servers each user can access
5. Implement automated certificate renewal integrated with identity systems This eliminates the key distribution nightmare and provides centralized access control.

Q: SSH connections to your production servers are failing intermittently. How do you troubleshoot?

Expert Answer: I’d approach this systematically:

1. Network layer: Check if it’s connection-related with ping and telnet hostname 22
2. SSH layer: Use ssh -vvv to see where the handshake fails
3. Server capacity: Check MaxStartups in sshd_config and current connection count
4. Authentication: Review /var/log/auth.log for patterns
5. DNS issues: Try connecting by IP instead of hostname
6. Resource limits: Check server load, memory, and disk space

Most intermittent issues are either connection limits or resource exhaustion.

Security Questions

Q: A developer wants to use the same SSH key for GitHub, production servers, and personal projects. What’s your advice?

Expert Answer: This violates the principle of least privilege. I’d recommend:

1. Separate keys per purpose: GitHub key, production key, personal key
2. Use SSH config to automatically select the right key per host
3. Implement key rotation schedules (annually minimum)
4. Use certificate-based auth for production to enable fine-grained access control
5. Store production keys only on secure workstations, never on personal devices

Q: How would you implement SSH access for a SOC 2 compliant environment?

Expert Answer: SOC 2 requires strong access controls and audit trails:

1. Multi-factor authentication for all privileged access
2. Certificate-based SSH with short lifespans (4-8 hours)
3. Session recording for all SSH sessions
4. Centralized logging with immutable audit logs
5. Just-in-time access - users request specific server access for specific time periods
6. Regular access reviews to ensure principle of least privilege
7. Automated compliance scanning to detect configuration drift

Quick Reference Card

Most Important Commands

# Generate modern key
ssh-keygen -t ed25519 -C "email@domain.com"
 
# Copy key to server  
ssh-copy-id -i ~/.ssh/key user@host
 
# Connect with specific key
ssh -i ~/.ssh/key user@host
 
# Debug connection issues
ssh -vvv user@host
 
# Local port forwarding
ssh -L localport:targethost:targetport user@jumphost
 
# Secure file transfer
scp -P 2222 file.txt user@host:/path/
rsync -avz -e ssh directory/ user@host:/destination/
 
# Connection through jump host
ssh -J jumphost target-server

Critical File Locations

• Client config: ~/.ssh/config
• Server config: /etc/ssh/sshd_config
• Host keys: /etc/ssh/ssh_host_*
• Authorized keys: ~/.ssh/authorized_keys
• Known hosts: ~/.ssh/known_hosts
• SSH logs: /var/log/auth.log

File Permissions Checklist

chmod 700 ~/.ssh                    # SSH directory
chmod 600 ~/.ssh/id_*               # Private keys
chmod 644 ~/.ssh/*.pub               # Public keys
chmod 600 ~/.ssh/authorized_keys     # Server authorized keys
chmod 600 ~/.ssh/config             # Client config

Essential Security Checklist

• Ed25519 or RSA 4096+ keys only
• Disable password authentication
• Disable root login
• Change default port from 22
• Set proper file permissions (700/600)
• Enable verbose logging
• Install fail2ban for brute-force protection
• Regular security updates
• Use ProxyJump instead of agent forwarding
• Implement MFA for privileged accounts

Red Flags to Avoid

• Using RSA 2048 or lower bit keys
• Leaving password authentication enabled
• Sharing private keys between users/systems
• Using the same key for multiple purposes
• Storing keys in code repositories
• Agent forwarding to untrusted hosts
• Disabling host key checking permanently

---

This guide covers SSH from fundamentals to enterprise implementation. Master these concepts and you’ll be prepared for any SSH-related interview question, from junior developer roles to senior infrastructure positions.