Host Key Verification
Learn how to properly verify SSH host keys to ensure secure connections and protect against man-in-the-middle attacks.
What is Host Key Verification?
Simple Explanation: When you connect to an SSH server, it shows you its "ID card" (host key). Verification is checking that this ID is legitimate and matches what you expect.
Why it matters:
Scenario: Connecting to production.example.com
Without verification:
You → Unknown Server → Accepts blindly
↑ Could be attacker!
With verification:
You → Server shows ID
→ You verify ID
→ Match? Connect ✓
→ No match? Block ✗
Understanding Host Keys
What is a Host Key?
Definition: A host key is the server's SSH public key that uniquely identifies it. Like a fingerprint for a server.
Key components:
1. Key Type: ED25519, RSA, ECDSA
2. Public Key: Long string of characters
3. Fingerprint: Short, readable representation
Example:
Type: ssh-ed25519
Public Key: AAAAC3NzaC1lZDI1NTE5AAAAI... (256 chars)
Fingerprint: SHA256:abc123def456ghi789jkl012mno...
Fingerprint Formats
SHA256 (Modern, Recommended):
SHA256:abc123def456ghi789jkl012mno345pqr678
- Base64 encoded
- 43 characters
- Most secure
- Standard since OpenSSH 6.8
MD5 (Legacy):
01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef
- Hexadecimal with colons
- 47 characters (16 bytes)
- Older format
- Less secure
- Still widely shown for compatibility
Example comparison:
Server: production.example.com
SHA256: iL9B8B7gvqKzYGlMPDKq9lH8F2nkR5dE3mWlP7xQ4Ac
MD5: 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef
Both represent the same key, different format
Verification Process
First-Time Connection
Step-by-step:
1. Initiate connection
Click "Connect" to new server
Or: SSH user@new-server.com
2. Xermius shows prompt:
┌──────────────────────────────────────────────┐
│ Verify Host Key │
├──────────────────────────────────────────────┤
│ Connecting to: │
│ new-server.com (192.168.1.100:22) │
│ │
│ This is the first connection to this host. │
│ │
│ Host fingerprint: │
│ ED25519 SHA256:iL9B8B7gvqKzYGlMPDKq9lH... │
│ │
│ MD5: 01:23:45:67:89:ab:cd:ef:01:23:45:67 │
│ │
│ ⚠️ Verify this fingerprint before accepting! │
│ │
│ How to verify: │
│ 1. Contact server administrator │
│ 2. Check server console │
│ 3. Compare with official records │
│ │
│ [Copy Fingerprint] │
│ │
│ [Cancel] [Trust Once] [Trust and Remember] │
└──────────────────────────────────────────────┘
3. Get official fingerprint
Option A - From Server Admin:
Email/Slack admin:
"Hi, connecting to new-server.com.
Please send SSH fingerprint for verification."
Admin replies:
"ED25519: SHA256:iL9B8B7gvqKzYGlMPDKq9lH..."
Option B - From Server Console:
# Login to server via console/KVM
# Run command:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# Output:
256 SHA256:iL9B8B7gvqKzYGlMPDKq9lH8F2nkR5dE3mWlP7xQ4Ac root@server (ED25519)
Option C - From Documentation:
Check server setup docs
Look for "SSH Fingerprints" section
Compare documented fingerprint
4. Compare fingerprints
Shown in Xermius:
SHA256:iL9B8B7gvqKzYGlMPDKq9lH8F2nkR5dE3mWlP7xQ4Ac
From server/admin:
SHA256:iL9B8B7gvqKzYGlMPDKq9lH8F2nkR5dE3mWlP7xQ4Ac
Character by character comparison:
✓ Match! Safe to connect
5. Accept host key
Click: "Trust and Remember"
Result:
- Host key saved
- Connection proceeds
- Future connections auto-verified
Subsequent Connections
Automatic verification:
1. You connect to known server
2. Xermius checks saved fingerprint
3. Server sends its fingerprint
4. Xermius compares:
Saved: SHA256:iL9B8B7...
Received: SHA256:iL9B8B7...
5. If match:
✓ Connection proceeds silently
6. If different:
✗ Connection blocked
⚠️ Warning shown
Verification Methods
Method 1: Server Console
Most reliable method
Steps:
# 1. Access server console
# (Physical access, KVM, or cloud console)
# 2. Login as root or sudo user
# 3. Display fingerprints for all key types:
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# 4. Output:
2048 SHA256:abc123... root@server (RSA)
256 SHA256:def456... root@server (ECDSA)
256 SHA256:iL9B8B7... root@server (ED25519)
# 5. Copy ED25519 fingerprint (most secure)
# 6. Compare with Xermius shown fingerprint
Pros:
- ✅ Most trustworthy
- ✅ Direct from server
- ✅ No intermediaries
Cons:
- ⚠️ Requires console access
- ⚠️ Not always available
Method 2: Administrator
Request from server admin
Email template:
Subject: SSH Fingerprint Verification
Hi [Admin],
I'm connecting to [server-name] for the first time
and need to verify the SSH host key.
Server: production.example.com
IP: 192.168.1.100
Could you please provide the ED25519 fingerprint?
Thanks,
[Your Name]
Admin response:
Hi [Name],
SSH Fingerprint for production.example.com:
ED25519: SHA256:iL9B8B7gvqKzYGlMPDKq9lH8F2nkR5dE3mWlP7xQ4Ac
RSA: SHA256:abc123def456ghi789jkl012mno345pqr678stu901
Use ED25519 if available.
Regards,
[Admin]
Pros:
- ✅ Reliable
- ✅ Easy to do
- ✅ Admin keeps record
Cons:
- ⚠️ Depends on admin availability
- ⚠️ Trust in admin required
Method 3: Out-of-Band Verification
Verify through separate channel
Example scenarios:
Scenario A - Phone Verification:
1. See fingerprint in Xermius
2. Call admin on phone
3. Admin reads fingerprint
4. You compare character by character
5. Match? Proceed
Scenario B - Video Call:
1. Video call with admin
2. Admin shares screen
3. Shows server console
4. You see fingerprint live
5. Compare and verify
Scenario C - Physical Meeting:
1. Meet admin in person
2. Admin shows fingerprint on laptop
3. Direct comparison
4. Most secure method
Pros:
- ✅ Very secure
- ✅ Hard to intercept
- ✅ Real-time verification
Cons:
- ⚠️ Inconvenient
- ⚠️ Not always practical
Method 4: Documentation
Check official documentation
Where to look:
1. Server setup documentation
2. Company wiki/knowledge base
3. Infrastructure repository
4. Configuration management
5. Security documentation
Example documentation:
# Production Server SSH Fingerprints
Last updated: 2024-01-15
## production.example.com (192.168.1.100)
- ED25519: SHA256:iL9B8B7gvqKzYGlMPDKq9lH...
- RSA: SHA256:abc123def456ghi789jkl012...
- Last rotated: 2024-01-10
Pros:
- ✅ Always available
- ✅ Self-service
- ✅ Fast
Cons:
- ⚠️ Must be kept updated
- ⚠️ Depends on documentation quality
- ⚠️ Stale info risk
Key Change Detection
When Keys Change
Legitimate reasons:
✓ Server reinstalled
✓ SSH upgraded/reconfigured
✓ Security key rotation
✓ Hardware replacement
✓ Disaster recovery
Suspicious reasons:
✗ No known change
✗ Unexpected notification
✗ Recently verified
✗ No maintenance window
✗ Different from documentation
Change Detection Alert
What you see:
┌──────────────────────────────────────────────┐
│ ⚠️ WARNING: HOST KEY MISMATCH! │
├──────────────────────────────────────────────┤
│ Remote host identification has changed! │
│ │
│ Host: production.example.com │
│ IP: 192.168.1.100 │
│ │
│ EXPECTED fingerprint: │
│ ED25519 SHA256:iL9B8B7gvqKzYGlMPDKq... │
│ (Last verified: Jan 15, 2024) │
│ │
│ RECEIVED fingerprint: │
│ ED25519 SHA256:xyz789uvw012abc345def... │
│ │
│ ⚠️ POSSIBLE REASONS: │
│ • Server was reinstalled │
│ • Man-in-the-middle attack │
│ • DNS hijacking │
│ • Wrong server │
│ │
│ DO NOT PROCEED unless you can verify this │
│ change is legitimate! │
│ │
│ [Show Details] [Cancel] [Update Key] │
└──────────────────────────────────────────────┘
Investigation Steps
1. Check for known changes:
□ Was there recent maintenance?
□ Check change management system
□ Ask in team chat
□ Review recent tickets
□ Check deployment logs
2. Verify new fingerprint:
□ Contact admin
□ Check server console
□ Compare with documentation
□ Verify through separate channel
3. Look for red flags:
⚠️ No one knows about change
⚠️ Change happened at odd time
⚠️ No tickets/approvals
⚠️ Multiple servers changed
⚠️ Can't reach server admin
4. Decision tree:
Known legitimate change?
├─ Yes → Update key and reconnect
└─ No
└─ Can verify new fingerprint?
├─ Yes → Update key
└─ No
└─ DON'T CONNECT!
- Report to security
- Investigate further
- Wait for confirmation
Security Scenarios
Scenario 1: Legitimate Key Change
Situation:
Server was reinstalled yesterday
You have ticket number: IT-1234
Admin confirmed via email
Action:
1. Verify change details:
- Check ticket IT-1234
- Confirm with admin
- Review change log
2. Get new fingerprint:
- From admin
- Or server console
3. Compare fingerprints:
- Shown: SHA256:xyz789...
- Admin: SHA256:xyz789...
- ✓ Match!
4. Update in Xermius:
- Click "Update Key"
- Add comment: "Updated after reinstall (IT-1234)"
- Save
5. Reconnect
Scenario 2: Suspicious Key Change
Situation:
No known changes
Server admin on vacation
Change at 3 AM
Multiple servers affected
Action:
1. DO NOT CONNECT!
2. Immediate steps:
- Cancel connection
- Mark host as "Revoked"
- Alert security team
- Document details
3. Investigation:
- Check other servers
- Review access logs
- Check network traffic
- Verify DNS records
4. Security response:
- Follow incident response plan
- Isolate affected servers
- Analyze for breach
- Rotate credentials
5. Only reconnect after:
- Security clears incident
- New keys verified
- Root cause identified
Scenario 3: First Connection
Situation:
New production server
First time connecting
High security environment
Action:
1. STOP - Don't rush!
2. Prepare:
- Get fingerprint from admin
- Or check documentation
- Or access server console
3. Compare carefully:
Character by character:
SHA256:iL9B8B7gvqKzYGlMPDKq9lH8F2nkR5dE3mWlP7xQ4Ac
SHA256:iL9B8B7gvqKzYGlMPDKq9lH8F2nkR5dE3mWlP7xQ4Ac
↑ Every character must match
4. If match:
- Accept and save
- Add detailed comment
- Document verification method
5. If no match:
- DON'T CONNECT
- Re-verify
- Contact admin
Best Practices
1. Always Verify First Connection
Never blindly accept:
❌ Bad:
"First connection? Sure, accept!"
→ Connects to potential attacker
✓ Good:
"First connection? Let me verify fingerprint first."
→ Requests fingerprint from admin
→ Compares carefully
→ Then accepts
2. Use Secure Verification Channel
Channel security:
Most Secure:
✓ Server console (direct access)
✓ In-person verification
✓ Video call with screen share
Secure:
✓ Phone call (voice verification)
✓ Encrypted messaging
✓ Official documentation
Less Secure:
⚠️ Email (can be intercepted)
⚠️ Instant messaging
⚠️ Slack/Teams
Insecure:
✗ SSH to verify SSH (circular!)
✗ Website over HTTP
✗ Unknown source
3. Document Verifications
Keep records:
In known host comment:
"Verified via server console on 2024-01-15 by John"
"Confirmed with admin Jane via phone"
"Key updated after maintenance (ticket IT-1234)"
In team documentation:
Server: production.example.com
Fingerprint: SHA256:iL9B8B7...
Last verified: 2024-01-15
Verified by: John Smith
Method: Server console
Next rotation: 2024-07-15
4. Regular Audits
Monthly checklist:
□ Review all known hosts
□ Check verification dates
□ Update stale entries
□ Remove decommissioned servers
□ Verify documentation current
□ Test backup/restore
5. Rotate Keys Regularly
Key rotation schedule:
Production servers: Every 6-12 months
Development servers: Yearly
Test servers: As needed
After rotation:
1. Announce to team
2. Update documentation
3. Notify all users
4. Provide new fingerprints
5. Give grace period
6. Monitor connections
6. Train Team Members
Security awareness:
Topics to cover:
- What is host key verification
- Why it matters
- How to verify properly
- What to do if suspicious
- Who to contact
- Documentation location
Common Mistakes
❌ Mistake 1: Blind Acceptance
Wrong:
"First time? Just click yes."
"Warning? Ignore it."
"Don't waste time verifying."
Right:
"First time? Let me verify."
"Warning? Investigate why."
"Security takes priority."
❌ Mistake 2: Ignoring Warnings
Wrong:
Host key changed?
"Must be nothing, accept anyway."
Right:
Host key changed?
"Stop! Why did it change?"
"Let me investigate."
"Verify before proceeding."
❌ Mistake 3: Weak Verification
Wrong:
Verify how?
"I'll just Google the fingerprint."
"Let me check that forum post."
"Trust this random website."
Right:
Verify how?
"Contact the server admin."
"Check official documentation."
"Access server console."
❌ Mistake 4: No Documentation
Wrong:
Accepted fingerprint
No record kept
Can't remember why
Can't verify later
Right:
Accepted fingerprint
Added comment: "Verified via console"
Documented in wiki
Team informed
Can verify anytime
Troubleshooting
Can't Get Official Fingerprint
Problem: No way to verify fingerprint
Solutions:
Option 1: Delay connection
Wait until you can verify
Contact admin
Request fingerprint
Don't rush
Option 2: Alternative access
Cloud console
KVM access
Physical access
Backup admin
Option 3: "Trust Once"
If you must connect:
- Use "Trust Once" option
- Don't save fingerprint
- Verify later
- Update when confirmed
Fingerprint Formats Don't Match
Problem: Admin sends MD5, Xermius shows SHA256
Solution:
Both valid, different formats
Request matching format:
"Please send SHA256 fingerprint"
Or convert:
Use online conversion tool
Or ask admin for both formats
Multiple Key Types
Problem: Server has RSA, ECDSA, ED25519
Solution:
Prefer in order:
1. ED25519 (most secure, modern)
2. ECDSA (good security)
3. RSA (if >= 2048 bits)
Verify the one your client uses
Usually ED25519 if available
Next Steps
- 🛡️ Trust Management - Managing trust levels
- 🔐 Known Hosts Management - Complete guide
- 🔗 Creating SSH Connections - Connect to servers
- 🔒 Security Best Practices - Complete security guide