Secure Shell (SSH) Proving Methods: An Overview for Red and Blue Teams

Secure Shell (SSH) is the de facto standard for secure remote administration and file transfers across networks. One of the most critical aspects of SSH is its proving methods—how a client proves its identity to a server and vice versa. Understanding these methods is vital for both attackers (red teamers) and defenders (blue teamers).

General Overview of SSH Proving Methods

SSH provides several authentication mechanisms to prove a client's identity to a server:

  1. Password Authentication

    • The simplest form: user provides a password.
    • Easy to configure but vulnerable to brute force and credential theft.

  2. Public Key Authentication

    • The client proves identity using an asymmetric key pair.
    • A private key signs a challenge, and the server verifies it with the corresponding public key.
    • Considered much stronger than passwords.

  3. Host-based Authentication

    • Relies on trust between hosts, often within controlled environments.
    • Rarely used due to trust management complexity.

  4. Keyboard-Interactive Authentication

    • Provides flexibility (e.g., multi-factor authentication).
    • Server prompts the client for responses.

  5. GSSAPI Authentication

    • Integrates with Kerberos and enterprise authentication systems.
    • Useful in large organizations for centralized identity management.

Example SSH Configurations

Public Key Authentication (Recommended)

Generate Key Pair:

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

Copy Public Key to Server:

ssh-copy-id user@server

Server Configuration (/etc/ssh/sshd_config):

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Restart the SSH service:

sudo systemctl restart ssh

Red Team Perspective (Attacker)

From a red team perspective, proving methods define attack surfaces:

  1. Password Attacks

    • Brute Force/Dictionaries: Automated attempts with tools like hydra.

      hydra -l user -P passwords.txt ssh://target-ip

    • Exploit weak or reused credentials.

  2. Key Theft

    • Stealing private keys from compromised endpoints (~/.ssh/id_rsa).
    • Searching for exposed keys in code repositories.

  3. Man-in-the-Middle (MITM)

    • Exploiting weak host verification to impersonate a trusted server.
    • Example: Using ssh-mitm frameworks to capture credentials if strict host key checking is disabled.

  4. Exploiting Misconfiguration

    • Weak sshd_config settings (e.g., PermitRootLogin yes, PasswordAuthentication yes).
    • Lack of rate limiting or MFA.

Blue Team Perspective (Defender)

Blue teams should harden SSH proving methods to reduce attack vectors:

  1. Disable Password Authentication

    PasswordAuthentication no

    Use public key or multi-factor authentication instead.

  2. Implement Key Management Practices

    • Rotate SSH keys regularly.
    • Enforce strong key types (e.g., ed25519, rsa >= 4096).
    • Audit authorized keys.

  3. Enforce MFA for SSH

    • Use Google Authenticator, Duo, or hardware tokens.
    • Example: AuthenticationMethods publickey,keyboard-interactive.

  4. Restrict Root Login

    PermitRootLogin prohibit-password

  5. Monitor and Detect Attacks

    • Use fail2ban to block brute force attempts.

    • Monitor logs:

      tail -f /var/log/auth.log

  6. Host Key Verification

    • Enforce strict host key checking in ~/.ssh/config:

      Host *
    StrictHostKeyChecking yes

Conclusion

SSH proving methods play a central role in securing remote access. While attackers often exploit weak configurations, defenders can mitigate risks through strong authentication mechanisms, strict configuration, and proactive monitoring.

  • Red Teams focus on identifying weak proving methods, key leaks, and misconfigurations.
  • Blue Teams must enforce robust key-based authentication, disable weak methods, and monitor activity.

When configured correctly, SSH remains one of the most secure protocols for remote access in modern IT environments.

Love it? Share this article: