Once the Transport Layer has established the encrypted pipe, we move to the Authentication Layer. The goal is simple: the server needs to be sure you are who you say you are. However, the *method* used to prove this identity can range from 'critically weak' to 'enterprise-grade'.
Password auth is the most common but least secure method. Even though the password is encrypted by the SSH tunnel, the password itself is a 'shared secret' that can be guessed (brute-forced), phished, or leaked from a database. In a production environment, password authentication should almost always be disabled.
💡 To mitigate brute-force attacks on passwords, tools like `fail2ban` are used to temporarily block IPs that fail multiple login attempts.
The output `yes` means anyone with a valid username can attempt to guess the password. Changing this to `no` forces the use of stronger methods like Public Keys.
Public Key authentication uses a challenge-response mechanism. The user has a private key and the server has the corresponding public key (stored in `~/.ssh/authorized_keys`). The server sends a random challenge; the client signs it with their private key. If the signature is valid, the user is granted access. The private key *never* leaves the client's machine.
⚠️ If a user does not protect their private key with a passphrase, anyone who steals the `id_rsa` file from their laptop has instant, password-less access to every server that trusts that key.
# Generating a secure Ed25519 key pair
ssh-keygen -t ed25519 -C "admin@vulnarex.com"
# Copying the public key to a remote server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-server| Method | Security Level | Primary Vulnerability | Best Use Case |
|---|---|---|---|
| Password | Low | Brute-force / Phishing | Initial setup only |
| Public Key | High | Private Key Theft | All Production Access |
| Keyboard-Interactive | Medium | Dependent on Backend | MFA / 2FA setups |
| GSSAPI/Kerberos | Very High | KDC Compromise | Enterprise/Active Directory |
Keyboard-interactive authentication allows the server to send custom prompts to the user. This is the foundation for Multi-Factor Authentication (MFA). For example, the server can ask for a password and then a 6-digit TOTP code from a mobile app. Without this layer, SSH is limited to single-factor authentication.
Be careful with `PermitEmptyPasswords`. If this is enabled, any account without a password is a wide-open door for attackers.
Verify exercises to earn ★ 150 XP and unlock next lab level.