Auf meinem Heimserver laufen derzeit einige verschiedene Dienste. Der Einfachheit halber lasse ich die Zertifikate von einer einzigen VM über Certbot verwalten und kopiere sie einfach mit SCP über das Netzwerk.
Die SSH-Verbindungen sind durch einen Schlüssel gesichert, da ich es aber automatisiert ausführe, erfordern die Schlüssel selbst kein Passwort, was offensichtlich nicht ideal ist.
Die Schlüssel werden nur im Root-Konto der VM gespeichert, die Certbot verwaltet, aber ich hätte trotzdem gerne eine Option, bei der das Skript die Dateien kopieren kann, ohne dass ich im Grunde über eine ungesicherte Methode für den Root-Zugriff auf andere Systeme in meinem Netzwerk verfügen muss, falls jemand Zugriff auf eines davon erhält.
Gibt es eine Möglichkeit, die Übermittlung bestimmter Befehle über eine SSH-Verbindung zuzulassen, ohne dass eine Shell-Sitzung geöffnet wird, oder fällt jemandem eine andere Möglichkeit ein, die Dateien bei meinem wöchentlichen Cron-Job zu kopieren, ohne dass jemand die Möglichkeit hätte, per SSH auf meine anderen Rechner zuzugreifen?
Mein Router aktiviert den Benutzer für Certbot nur am Samstagabend, wodurch meine VM sich per SSH anmelden und ein Skript ausführen kann, das die Firewall-Regel deaktiviert, die Port 80 blockiert, den Befehl „Certbot erneuern“ ausführt, die Firewall-Regeln wieder aktiviert und den Certbot-Benutzer deaktiviert. Ich komme damit gut zurecht, da es jede Woche nur ein Zeitfenster von maximal 15 Minuten gibt, in dem der Router-Benutzer aktiviert ist.
Das Kopieren der Zertifikate stellt das Problem dar, da die Konten offensichtlich immer aktiv sind, wenn es als Root ausgeführt wird.
#!/bin/bash
ssh [email protected] "/system script run certbotenable"
#ufw allow 80
certbot renew
#ufw delete allow 80
systemctl restart apache2
ssh [email protected] "/system script run certbotdisable"
scp /etc/letsencrypt/live/sazed.mydomain.com/cert.pem root@sazed:/etc/pve/local/pveproxy-ssl.pem
scp /etc/letsencrypt/live/sazed.mydomain.com/privkey.pem root@sazed:/etc/pve/local/pveproxy-ssl.key
scp /etc/letsencrypt/live/rashek.mydomain.com/cert.pem root@rashek:/root/ssl/fullchain.pem
scp /etc/letsencrypt/live/rashek.mydomain.com/privkey.pem root@rashek:/root/ssl//privkey.key
ssh root@sazed "service pveproxy restart"
Antwort1
Sie können mehrere SSH-Schlüsselpaare generieren.
Auf dem Remote-Server können Sie die erweiterten Optionen in der authorized_keysDatei verwenden und jedem öffentlichen Schlüssel Beschränkungen hinzufügen. Auf diese Weise können Sie die Anzahl der Zugriffsanmeldungen einschränken, die mit einem bestimmten Schlüsselpaar gewährt werden.
Siehe authorized_keys Dateiformatbeschreibung inhttps://www.freebsd.org/cgi/man.cgi?sshd(8)für die Optionen und ihre Bedeutung.
Nützliche Optionen sind beispielsweise command=, den Zugriff auf nur einen einzigen Befehl/eine einzige ausführbare Datei/ein einziges Skript zu beschränken.
Ziemlich üblich ist das Erzwingen von internem SFTP. Dann werden nur Dateiübertragungen mit SFTP zugelassen.
Oder from=diese Begrenzung der Quell-IP, von der Verbindungen akzeptiert werden
Ebenso /etc/ssh/sshd_configkönnen Sie zusätzliche Anforderungen für Root-Logins mit einer MatchDirektive festlegen. Wenn Sie also weiterhin Passwort-Logins für alle regulären Benutzer zulassen müssen, können Sie damit festlegen, dass für Root nur Public-Key-basierte Logins akzeptiert werden.
# /etc/ssh/sshd_config
#here go defaults for all connections/users
PasswordAuthentication yes
PubkeyAuthentication yes
...
# Use Match directives to override default settings and specify specific settings
# for users, groups, hosts
# https://man.openbsd.org/sshd_config#Match
Match User root
PasswordAuthentication no
Und natürlich können Sie das ganze Problem mit dem Root-/privilegierten Konto vermeiden, indem Sie einen Pull- statt einem Push-Ansatz konfigurieren.