Was ist das hier?

Key-only, Root aus, Rate-Limits, sichere Admin-Zugänge. (Operator Guide für Railway).

Schnell‑Triage (5 Minuten)

• Was ist exponiert (Ports, Admin, Webhooks, Origins, Buckets)?
• Sind gerade Anomalien sichtbar (Spikes, 4xx/5xx, Login‑Fehler, Bot‑Traffic)?
• Sind Secrets/Keys kompromittiert (Repo, CI, Logs, Chat)?

Konfiguration (sshd_config) – AWS Linux (Ubuntu/Debian kompatibel)

# /etc/ssh/sshd_config (Härtung)
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256
MACs hmac-sha2-512,hmac-sha2-256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
LoginGraceTime 30
MaxAuthTries 3
AllowUsers deploy admin
# Optional: gruppenbasiert
# AllowGroups ssh-users

Audit & Monitoring

# Auth-Logs live beobachten
sudo journalctl -u ssh -f | sed -n 's/.*Failed password.*/[FAIL] &/p; s/.*Accepted publickey.*/[OK] &/p'

# Fail2ban Status (falls aktiv)
sudo fail2ban-client status sshd || true

# CloudWatch Agent (optional) – SSH Auth Logs shippen
sudo tee /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/ssh.json <<'JSON'
{
  "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/auth.log", "log_group_name": "ssh-auth" } ] } } }
}
JSON
sudo systemctl restart amazon-cloudwatch-agent || true

Rollback

# Vor Änderung Backup anlegen
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%s)

# Rollback durchführen
sudo cp -a /etc/ssh/sshd_config.bak.* /etc/ssh/sshd_config && sudo systemctl reload ssh

Validierung

# Konfig testen und Dienst neuladen
sudo sshd -t && sudo systemctl reload ssh

# Negativ-Test: Passwort-Login muss scheitern
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@host || echo "OK: password login disabled"

Fix‑Schritte (Copy/Paste‑fähig)

• Sofort: SSH nur über Private Access/VPN oder Allowlist (keine 0.0.0.0/0).
• Key-only: PasswordAuthentication no; PubkeyAuthentication yes.
• RootLogin: PermitRootLogin no; Admin via sudo, unique users.
• Rate limiting: fail2ban oder sshd MaxAuthTries + firewall limits.
• Verifikation: neuer SSH Login, dann alte Pfade testen (müssen scheitern).

Verifikation

curl -I https://deine-domain.tld
curl -sS https://deine-domain.tld/health || true

Prävention / Guardrails

• Least privilege
• Logs + Alerts
• Rollback/Deploy-Disziplin

Warnungen

• Änderungen klein halten, verifizieren, dann weiter.

Was andere Tools nicht sagen

Die meisten Guides zeigen nur den Happy Path. Was wirklich wichtig ist: Key-only, Root aus, Rate-Limits, sichere Admin-Zugänge. (Operator Guide für Railway). – aber erst nach einem erfolgreichen Smoke Test zählt es als erledigt. Viele Admins vergessen den Rollback-Plan und das Monitoring nach dem Change.

• Defaults allein reichen nicht – ohne Verifikation ist jeder Fix unvollständig.
• Externe Scantools sehen oft nicht den Unterschied zwischen 'konfiguriert' und 'wirksam'.
• Incident-Postmortems zeigen: 60% der Rückfälle entstehen durch fehlende Guardrails, nicht durch falschen Fix.