Trust Management
Learn how to manage trust levels for SSH host keys, handle trust changes, and maintain a secure connection environment.
Trust Levels Explained
Overview
Xermius uses three trust levels to classify known hosts:
✓ Trusted (Green) - Safe, verified, normal use
⚠ Warning (Yellow) - Needs attention, use cautiously
✗ Revoked (Red) - Blocked, don't connect
1. Trusted Status
Meaning: Host key has been verified and accepted. Safe for regular use.
Visual indicators:
┌──────────────────────────────────────────────┐
│ ✓ production.example.com TRUSTED│
│ ED25519: SHA256:abc123... │
│ Last verified: 2 hours ago │
│ ──────────────────────────────────────────│
│ Status: Trusted ✓ │
│ Color: Green │
│ Connection: Automatic │
└──────────────────────────────────────────────┘
When set:
- First connection accepted and verified
- Manually marked as trusted
- Imported from system SSH
- After legitimate key update
Behavior:
When connecting:
1. Xermius checks fingerprint
2. If matches: Connect automatically ✓
3. If different: Show warning ⚠️
4. No user interaction needed (normal)
Best for:
- Production servers
- Regularly used servers
- Verified personal servers
- Company infrastructure
2. Warning Status
Meaning: Host key requires attention. Not yet verified or suspicious activity detected.
Visual indicators:
┌──────────────────────────────────────────────┐
│ ⚠ staging.example.com WARNING │
│ RSA: SHA256:def456... │
│ Last verified: Never │
│ ──────────────────────────────────────────│
│ Status: Warning ⚠ │
│ Color: Yellow/Orange │
│ Connection: Prompt user │
└──────────────────────────────────────────────┘
When set:
- First time connection (default)
- Manually flagged for review
- Suspicious activity detected
- Pending verification
- Temporary access
Behavior:
When connecting:
1. Xermius shows warning prompt
┌───────────────────────────────────────┐
│ ⚠️ Unverified Host │
├───────────────────────────────────────┤
│ This host has not been verified. │
│ │
│ Fingerprint: SHA256:def456... │
│ │
│ Verify before connecting! │
│ │
│ [Cancel] [Connect Anyway] │
└───────────────────────────────────────┘
2. User must explicitly confirm
3. Connection proceeds if confirmed
Best for:
- New servers (pending verification)
- Test/development servers
- Temporary servers
- Third-party servers
- Shared hosting
3. Revoked Status
Meaning: Host key has been explicitly revoked. Connection blocked for security.
Visual indicators:
┌──────────────────────────────────────────────┐
│ ✗ compromised.example.com REVOKED │
│ ECDSA: SHA256:ghi789... │
│ Last verified: 3 months ago │
│ ──────────────────────────────────────────│
│ Status: Revoked ✗ │
│ Color: Red │
│ Connection: Blocked │
│ Reason: Security breach detected │
└──────────────────────────────────────────────┘
When set:
- Host key changed unexpectedly (automatic)
- Server compromised (manual)
- Server decommissioned (manual)
- Security policy violation (manual)
- Known malicious host (manual)
Behavior:
When connecting:
1. Xermius blocks connection
┌───────────────────────────────────────┐
│ ✗ Connection Blocked │
├───────────────────────────────────────┤
│ This host key has been revoked. │
│ │
│ Reason: Host key changed │
│ Date: Jan 15, 2024 │
│ │
│ DO NOT CONNECT unless you have │
│ verified the key change is legitimate.│
│ │
│ [View Details] [Cancel] │
└───────────────────────────────────────┘
2. Connection refused
3. No option to proceed
4. Must be manually changed to connect
Best for:
- Compromised servers
- Decommissioned servers
- Servers with changed keys (pending verification)
- Malicious hosts
- Policy violations
Managing Trust Levels
Changing Trust Status
Method 1: From Known Hosts List
1. Open Known Hosts tab
2. Find host in list
3. Click on host
4. Host details shown
5. Click "Change Trust Status"
6. Select new status:
┌───────────────────────────────────────┐
│ Change Trust Status │
├───────────────────────────────────────┤
│ Current: Warning ⚠ │
│ │
│ New Status: │
│ ⦿ Trusted │
│ ○ Warning │
│ ○ Revoked │
│ │
│ Reason (optional): │
│ [Verified via server console] │
│ │
│ [Cancel] [Update] │
└───────────────────────────────────────┘
7. Add reason (recommended)
8. Click "Update"
9. Status changed
Method 2: During Connection
1. Connect to server
2. If warning shown, can change:
┌───────────────────────────────────────┐
│ ⚠️ Unverified Host │
├───────────────────────────────────────┤
│ [Connect Once] │
│ [Trust and Remember] │
│ [Mark as Revoked] │
└───────────────────────────────────────┘
3. Choose appropriate action:
- Trust and Remember: Sets to Trusted
- Mark as Revoked: Sets to Revoked
- Connect Once: Keeps as Warning
Method 3: Bulk Update
1. Select multiple hosts (Ctrl+Click)
2. Right-click → "Change Trust Status"
3. Choose new status
4. Add reason (applies to all)
5. Confirm bulk update
6. All selected hosts updated
Trust Status Guidelines
When to use Trusted:
✓ Fingerprint verified
✓ Regular use server
✓ Company infrastructure
✓ Long-term server
✓ Properly documented
Requirements:
- Verified through reliable channel
- Documented verification
- Known administrator
- Regular maintenance
- Security compliance
When to use Warning:
⚠ First time connection
⚠ Temporary server
⚠ Test/development
⚠ Pending verification
⚠ Infrequent use
⚠ Third-party server
Characteristics:
- Not yet verified
- Short-term access
- Low security impact
- Non-production
- Experimental
When to use Revoked:
✗ Key changed unexpectedly
✗ Security breach suspected
✗ Server compromised
✗ Decommissioned server
✗ Policy violation
✗ Known malicious
Indicators:
- Unauthorized changes
- Security alerts
- Incident reports
- Formal decommissioning
- Blacklist entry
Workflow Examples
Workflow 1: New Production Server
Scenario: Setting up new production server
Steps:
Day 1: Server Setup
1. Server installed by ops team
2. SSH configured
3. Fingerprint documented
4. Team notified
Day 1: First Connection
1. You connect (first time)
Status: Warning (default)
2. Verify fingerprint:
- Check documentation
- Compare with admin's record
- Or check server console
3. If verified:
- Change status to Trusted
- Add comment: "Verified via documentation"
- Save
4. Future connections:
- Automatic ✓
- No prompts
- Fast access
Workflow 2: Suspicious Key Change
Scenario: Server key changed unexpectedly
Steps:
Morning: Normal Connection
- Status: Trusted
- Connects automatically ✓
Afternoon: Key Changed
1. You try to connect
2. Xermius detects mismatch:
⚠️ Host key has changed!
3. Automatic action:
- Status changed to: Revoked
- Connection blocked
- Alert logged
4. Investigation:
- No known maintenance
- No change tickets
- Admin unaware
- Red flag! 🚩
5. Actions taken:
- Keep as Revoked
- Alert security team
- Incident investigation
- Server quarantine
6. After investigation:
If legitimate:
- Update fingerprint
- Change to Trusted
- Document reason
If breach:
- Keep as Revoked
- Server rebuilt
- New fingerprint
- New entry created
Workflow 3: Temporary Dev Server
Scenario: Short-term development server
Steps:
Setup:
1. Create dev server (will delete in 1 week)
2. First connection
3. Status: Warning (keep as is)
4. Add comment: "Temp dev server, expires Jan 25"
Usage:
1. Each connection prompts:
"Unverified host, continue?"
2. Click "Connect Anyway"
3. Access granted
4. Reminder it's temporary
Cleanup:
1. Week ends
2. Server deleted
3. Remove from Known Hosts
4. No security impact
Workflow 4: Production Server Maintenance
Scenario: Planned server reinstall
Steps:
Before Maintenance:
1. Review change ticket: SYS-1234
2. Note: "Server reinstall Jan 20, 2PM"
3. New fingerprint provided
4. Team notified
During Maintenance:
1. Server goes offline
2. Ops team rebuilds
3. SSH reconfigured
4. New keys generated
5. Fingerprint published
After Maintenance:
1. You try to connect
2. Xermius detects key change:
Status changed to: Revoked
3. Verify new fingerprint:
- Compare with ticket SYS-1234
- Matches provided fingerprint ✓
4. Update:
- Delete old entry
- Or update fingerprint
- Change status to: Trusted
- Comment: "Updated after reinstall (SYS-1234)"
5. Resume normal use
Trust Policies
Organization-Level Policies
Example policy structure:
Trust Policy v1.0
1. Trusted Status Requirements:
✓ Fingerprint verified by two methods
✓ Documented in infrastructure wiki
✓ Approved by security team
✓ Annual revalidation required
2. Warning Status Usage:
- Development environments (optional)
- Personal test servers (allowed)
- Third-party services (required)
- Max duration: 90 days
3. Revoked Status Triggers:
- Automatic: Key mismatch
- Manual: Security incident
- Manual: Decommissioning
- Manual: Compliance violation
4. Change Process:
- Document reason (required)
- Security approval for Trusted
- Incident report for Revoked
- Audit log maintained
Enforcement
Settings-based enforcement:
Settings → Security → Trust Policy
[✓] Require verification for Trusted status
Must verify before marking as Trusted
[✓] Auto-revoke on key mismatch
Automatic Revoked status on change
[✓] Block connections to Revoked hosts
Cannot connect to revoked hosts
[ ] Require approval for Trusted status
Security team must approve
Enforcement level:
⦿ Strict (enforce all rules)
○ Moderate (allow overrides with reason)
○ Flexible (warnings only)
Audit Trail
Trust change logging:
Audit Log Entry:
Date: 2024-01-17 14:30:00
User: john.smith@company.com
Host: production.example.com
Action: Trust Status Changed
From: Warning
To: Trusted
Reason: Verified via server console
Approver: security@company.com
Ticket: SEC-456
View audit log:
Settings → Security → Audit Log
Filter: Trust Changes
Date range: Last 30 days
User: All
Results:
┌────────────────────────────────────────────┐
│ Date Host Change User │
├────────────────────────────────────────────┤
│ Jan 17 14:30 prod.ex.com → Trusted John │
│ Jan 16 09:15 test.ex.com → Warning Jane │
│ Jan 15 16:45 old.ex.com → Revoked Ops │
└────────────────────────────────────────────┘
Export: [CSV] [PDF] [JSON]
Advanced Management
Bulk Trust Management
Scenario: Verify all production servers
1. Filter: Show all "Warning" status
2. Review list:
- 12 production servers
- All need verification
3. For each server:
- Verify fingerprint
- Check documentation
- Confirm legitimacy
4. Select all verified (Ctrl+A)
5. Bulk action:
Right-click → "Change Trust Status"
→ Trusted
→ Reason: "Bulk verification Jan 2024"
6. Confirm
7. All updated to Trusted
Trust Expiration
Auto-review policy:
Settings → Security → Trust Management
[✓] Enable trust expiration
Review trust status periodically
Expiration period:
[90] days for Trusted status
[30] days for Warning status
Action on expiration:
⦿ Change to Warning (require reverification)
○ Send notification only
○ Disable account
Notification:
[✓] Email reminder 7 days before
[✓] In-app notification
Trust Import/Export
Export trust configuration:
1. Known Hosts → Export
2. Choose format:
⦿ Include trust status (JSON)
○ OpenSSH format only (compatible)
3. Export file includes:
{
"hosts": [
{
"hostname": "prod.example.com",
"fingerprint": "SHA256:abc...",
"trustStatus": "trusted",
"verifiedBy": "john@company.com",
"verifiedDate": "2024-01-17",
"reason": "Console verification",
"expiresAt": "2024-04-17"
}
]
}
4. Use for:
- Backup
- Team sharing
- Disaster recovery
- Compliance records
Monitoring & Alerts
Alert Configuration
Set up alerts:
Settings → Notifications → Security Alerts
[✓] Alert on key mismatch
Notify when host key changes
[✓] Alert on revoked connection attempt
Notify when trying to connect to revoked host
[✓] Alert on unverified connections
Notify when connecting to Warning status
[✓] Alert on bulk trust changes
Notify when >5 hosts changed at once
Notification method:
[✓] In-app notification
[✓] Email
[ ] Slack/Teams
[ ] SMS (critical only)
Security Dashboard
View trust overview:
Dashboard → Security → Trust Status
┌────────────────────────────────────────────┐
│ Trust Status Summary │
├────────────────────────────────────────────┤
│ ✓ Trusted: 45 hosts (75%) │
│ ⚠ Warning: 12 hosts (20%) │
│ ✗ Revoked: 3 hosts (5%) │
│ │
│ Recent Changes (7 days): │
│ - 5 changed to Trusted │
│ - 2 changed to Warning │
│ - 1 changed to Revoked │
│ │
│ Attention Required: │
│ ⚠ 3 hosts pending verification (>30 days) │
│ ⚠ 1 trust expiring soon (7 days) │
│ │
│ [View Details] [Run Audit] │
└────────────────────────────────────────────┘
Best Practices
1. Document Everything
Always add comments:
Good comments:
✓ "Verified via server console on Jan 17 by John"
✓ "Updated after planned maintenance (ticket OPS-123)"
✓ "Personal dev server - expires Feb 1"
✓ "Marked revoked due to security incident INC-456"
Bad comments:
✗ "ok"
✗ ""
✗ "prod server"
2. Regular Reviews
Monthly checklist:
□ Review all Warning status hosts
□ Verify or promote to Trusted
□ Check Revoked hosts (still needed?)
□ Update expired trusts
□ Clean up deleted servers
□ Export backup
□ Review audit log
3. Principle of Least Trust
Start restrictive:
New hosts → Warning (default)
After verification → Trusted
On suspicion → Revoked
Not "Trusted by default"
4. Verify Before Trusting
Never skip verification:
❌ "Looks fine, mark as Trusted"
❌ "It's probably ok"
❌ "No time to verify now"
✓ "Let me verify first"
✓ "I'll check with admin"
✓ "Comparing fingerprints"
5. Timely Revocation
Act quickly:
Key changed → Immediate revocation
Suspicious activity → Revoke first, investigate after
Decommissioned → Revoke same day
Don't delay security actions
6. Team Communication
Share trust decisions:
Team chat:
"Updated prod-web-01 to Trusted after verification"
"Revoked old-test-server - being decommissioned"
"All staging servers verified, now Trusted"
Transparency builds trust in the system
Troubleshooting
Can't Connect - Revoked Host
Problem: Connection blocked due to revoked status
Solution:
1. Check why revoked:
- View host details
- Read revocation reason
- Check audit log
2. If legitimate change:
- Verify new fingerprint
- Update host key
- Change to Trusted
- Document reason
3. If still suspicious:
- Keep as Revoked
- Investigate further
- Contact security
- Don't force connection
Too Many Warning Prompts
Problem: Constantly prompted for Warning hosts
Solution:
Option 1: Verify and trust
- Review each Warning host
- Verify fingerprints
- Change to Trusted
- Reduces prompts
Option 2: Adjust policy
Settings → Security
[ ] Prompt for Warning status connections
(Not recommended for production)
Option 3: Accept Warning status
- Keep for temporary/dev servers
- Conscious reminder they're unverified
- Security feature, not bug
Bulk Status Reset
Problem: All hosts changed to Warning after import
Solution:
After import, trust status reset to default
Fix:
1. If from JSON backup:
- Trust status preserved
- Check import options
- Re-import with full data
2. If from OpenSSH format:
- No trust data in format
- Must manually review
- Or use JSON backup instead
3. Prevent in future:
- Always export as JSON (full data)
- Keep trust information
- Document trust levels
Next Steps
- 🔐 Known Hosts Management - Complete guide
- 🔍 Host Key Verification - Verification process
- 🔗 Creating SSH Connections - Connect to servers
- 🔒 Security Best Practices - Complete security guide