Skip to main content

Authentication Methods

Understand all authentication methods supported by Xermius—from simple passwords to advanced key-based authentication.

Authentication Overview​

What is authentication?

Authentication = Proving you are who you say you are

Server asks: "Who are you?"
You prove: "I'm user X, here's proof"
Server verifies: "OK, access granted"

Supported Methods​

1. Password Authentication​

How it works:

You → Username + Password → Server
Server checks password
Match? → Access granted
No match? → Access denied

Setup:

New Host:
Name: [My Server    ]
Host: [server.example.com]
User: [john]

Authentication:
● Password

Password:
[••••••••••]

[✓] Save password (encrypted)

[Save]

Pros:

✓ Simple to setup
✓ Works everywhere
✓ No files to manage
✓ Easy to share (not recommended!)

Cons:

✗ Can be guessed/cracked
✗ Vulnerable to keyloggers
✗ Need to type each time
✗ Weak passwords common
✗ Phishing risk

Best for:

- Quick tests
- Temporary access
- First-time setup
- Legacy systems

2. SSH Key Authentication​

How it works:

You have: Private key (secret)
Server has: Public key (from you)

You → "I have private key" → Server
Server: "Prove it with challenge"
You → Signed response → Server
Server verifies signature
Match? → Access granted

Setup:

New Host:
Authentication:
● SSH Key

Select Key:
[My Personal Key  ▼]

Passphrase (if protected):
[••••••••••]

[Save]

Pros:

✓ Very secure
✓ Cannot be guessed
✓ No password typing
✓ Supports automation
✓ Scalable
✓ Audit trail

Cons:

✗ More complex setup
✗ Key files to manage
✗ Must be on server first

Best for:

- Production servers
- Regular access
- Automation
- Security-conscious setups
- Team environments

3. Two-Factor Authentication (2FA)​

How it works:

Something you know: Password
+
Something you have: Phone/token

Both required for access

Setup (keyboard-interactive):

Connection flow:
1. Enter password
2. Server sends prompt
3. Enter 2FA code from app
4. Access granted

Xermius supports:
- Google Authenticator
- Authy
- Hardware tokens
- SMS codes

Pros:

✓ Maximum security
✓ Protects even if password stolen
✓ Required for compliance
✓ Audit trail

Cons:

✗ Need device/app
✗ Slower to connect
✗ Can't automate
✗ Lost device = lockout

Best for:

- Critical servers
- Compliance requirements
- Financial systems
- PCI-DSS environments

4. Certificate Authentication​

How it works:

Certificate Authority (CA) signs your key
Server trusts CA
Your signed key → Automatic trust

Like: ID card signed by government

Setup:

Certificate-based:
1. Organization has CA
2. CA signs your SSH key
3. Certificate proves identity
4. Time-limited access

Configure:
Use SSH key with certificate
Server automatically trusts

Pros:

✓ Centralized management
✓ Time-limited access
✓ Automatic expiration
✓ Easy revocation
✓ No per-server setup

Cons:

✗ Requires CA infrastructure
✗ More complex
✗ Enterprise feature

Best for:

- Large organizations
- Enterprise environments
- Temporary contractors
- Audit requirements

5. Hardware Key (YubiKey)​

How it works:

SSH private key stored on hardware device
Cannot be extracted
Physical touch required

You → Insert YubiKey → Touch button → Connected

Setup:

Hardware Security:
1. Configure YubiKey
2. Store SSH key on device
3. Connect to Xermius
4. Touch for authentication

Requires: YubiKey or similar

Pros:

✓ Maximum security
✓ Key cannot be stolen
✓ Physical authentication
✓ Audit trail

Cons:

✗ Requires hardware
✗ Can lose device
✗ More expensive

Best for:

- Maximum security needs
- Government
- Financial institutions
- Security researchers

Choosing the Right Method​

Decision Tree​

Need automation?
├─ Yes → SSH Key (no passphrase)
└─ No → Continue

Maximum security needed?
├─ Yes → Hardware Key or 2FA
└─ No → Continue

Quick setup?
├─ Yes → Password (temporary)
└─ No → Continue

Production system?
├─ Yes → SSH Key (with passphrase)
└─ No → Password OK

Team environment?
├─ Yes → SSH Keys (separate per user)
└─ No → Either method

Recommendation by Scenario​

Personal Projects:

Recommended: SSH Key
Why: Secure + Convenient
Setup: 10 minutes

Alternative: Password
When: Quick tests only

Work Servers:

Recommended: SSH Key + Passphrase
Why: Security + Audit trail
Rotation: Every 6 months

Alternative: 2FA
When: Critical systems

Production:

Recommended: SSH Key + 2FA
Why: Maximum security
Backup: Hardware key

Never: Password only

Automation/CI-CD:

Required: SSH Key (no passphrase)
Why: Cannot type interactively
Security: Dedicated key, limited scope

Alternative: Service accounts

Contractors/Temp:

Recommended: Certificate (time-limited)
Why: Automatic expiration
Backup: SSH key + manual removal

Alternative: SSH key + calendar reminder

Combining Methods​

Password + Key​

Use both:

Some servers support:
1. Try SSH key first
2. Fall back to password

Configure:
Auth Method: SSH Key
Fallback: Password

If key fails → Prompt for password

Key + 2FA​

Double security:

Keyboard-interactive with key:
1. Present SSH key
2. Enter 2FA code
3. Access granted

Best of both:
- Key security
- 2FA protection

Multi-Key Setup​

Try multiple keys:

Auth Priority:
1. Primary key
2. Backup key
3. Emergency key

First match wins

Configuration Examples​

Password Only​

Host: production.example.com
Port: 22
User: deploy
Auth: Password
Password: [saved encrypted]

SSH Key Only​

Host: staging.example.com
Port: 22
User: admin
Auth: SSH Key
Key: Work - Production 2024
Passphrase: [saved encrypted]

Key + Password Fallback​

Host: legacy.example.com
Port: 22
User: root
Primary Auth: SSH Key (id_rsa)
Fallback Auth: Password
Saved: Both encrypted

2FA (keyboard-interactive)​

Host: secure.example.com
Port: 22
User: john
Auth: keyboard-interactive
Steps:
  1. Password prompt
  2. 2FA code prompt
Save: Password only

Security Comparison​

Security Level​

Password:           ★☆☆☆☆
Password (strong):  ★★☆☆☆
SSH Key:            ★★★★☆
SSH Key + Pass:     ★★★★★
Key + 2FA:          ★★★★★
Hardware Key:       ★★★★★
Certificate:        ★★★★★

Convenience​

Password:           ★★★★★
SSH Key:            ★★★★★
Key + Passphrase:   ★★★★☆
2FA:                ★★★☆☆
Hardware Key:       ★★★☆☆
Certificate:        ★★★★☆

Setup Complexity​

Password:           ★☆☆☆☆
SSH Key:            ★★☆☆☆
Key + Passphrase:   ★★☆☆☆
2FA:                ★★★☆☆
Hardware Key:       ★★★★☆
Certificate:        ★★★★★

Migration Guide​

From Password to SSH Key​

Step 1: Generate Key

Keychain → Generate New Key
Type: ED25519
Name: Work - Server Access
[Generate]

Step 2: Deploy Key

Right-click key → Deploy to Server
Server: [your-server]
User: [your-user]
Password: [current password]
[Deploy]

Step 3: Test

Connect to server
Should work without password

Step 4: Update Host

Edit Host → Authentication
Password → SSH Key
Select: Work - Server Access
Save

Step 5: Remove Password (optional)

On server:
sudo passwd -l username

Password login disabled
Key only

From One Key to Another​

During rotation:

1. Generate new key
2. Deploy new key (keep old)
3. Test new key
4. Update all hosts
5. Remove old key from servers
6. Delete old key from keychain

Troubleshooting​

Authentication Failed​

Password:

Check:
□ Correct username
□ Correct password
□ Account not locked
□ Server allows password auth

SSH Key:

Check:
□ Public key on server
□ Correct private key selected
□ Passphrase correct (if used)
□ Permissions (700 ~/.ssh, 600 files)
□ Server allows key auth

Too Many Authentication Failures​

Error: "Received disconnect: Too many authentication failures"

Cause: Tried too many keys

Fix:

Limit keys tried:
Edit Host → Advanced
Max auth tries: 3

or

Specify exact key:
Don't use agent forwarding
Use specific key only

Permission Denied (publickey)​

Means: Server requires key, password not accepted

Fix:

1. Server config requires keys
2. Generate SSH key
3. Deploy to server
4. Update host to use key

Best Practices​

1. Right Tool for Job​

Quick test: Password OK
Production: SSH key required
Critical: Add 2FA
Automation: Key without passphrase

2. Defense in Depth​

Layer security:
- Strong authentication (key)
- Firewall rules
- Fail2ban
- VPN access
- Jump hosts

3. Regular Audits​

Monthly review:
□ Who has access?
□ Keys still needed?
□ Passwords rotated?
□ 2FA working?
□ Remove old users

4. Separate Keys​

Don't reuse keys:
✓ Work → Work key
✓ Personal → Personal key
✓ Client A → Client A key

One key compromised ≠ all compromised

5. Document Everything​

For each method:
- Why chosen
- Who uses it
- Rotation schedule
- Emergency access

Next Steps​