Hallo. ☺
Ich betreibe nun seit einiger Zeit einen Root-Server und helfe auch Bekannten von mir beim Administrieren ihrer Server. Da ich für jede Maschine einen eigenen Key zur Authentifikation verwende, hat sich bei mir nun kleine Menge an Keys in meinem ~/.ssh/ Verzeichnis angesammelt. Um zu vermeiden, dass mein SSH-Client immer erst alle Keys durchprobiert, verwende ich zum Verbinden den Schalter -i und gebe den jeweilig korrekten Key direkt an.
Da auf diesen Servern verschiedene Dienste mit unterschiedlichen Berechtigungen/Systemusern betrieben werden, nutze ich für Backups mit rsync den echten root Zugang. In der SSH-Konfiguration ist das Anmelden mit Passwort selbstverständlich deaktiviert. Aus Paranoia verwende ich für die root Sitzung jedes mal einen neuen SSH-Key und entferne ihn danach wieder. Hierfür melde ich mich erst über meinen normalen Nutzer an und trage den aktuellen, temporären Key für root via su/sudo ein um danach die rsync Sitzung starten zu können. Diesen temporären Key erstelle ich lokal NICHT in ~/.ssh/, sondern in meinem Arbeitsverzeichnis. Dieser wird dann für die Backups auch wieder mit -i angegeben.
Nun ist meine Key Sammlung letzte Woche auf den sechsten gewachsen. Und ab hier komme ich, trotz -i in Konflikt mit MaxAuthTries. Diese Option ist nicht explizit von mir gesetzt und somit per default auf 6. Was mich über die Verhaltensweise von -i etwas verwundern lässt. Für mich lesen sich die Manpages so, dass man hier explizit einen Key zur Authentifikation wählt und der Client alle anderen im User-space verfügbaren ignorieren soll.
1 | man ssh
|
-i identity_file Selects a file from which the identity (private key) for public key authentication is read. The default is ~/.ssh/identity for pro‐ tocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2. Identity files may also be specified on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files). ssh will also try to load certificate information from the filename obtained by appending -cert.pub to identity filenames.
1 | less /etc/ssh/ssh_config
|
# Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end.
Klar, man kann mehrere Keys setzen, doch ich verstehe es hier so, dass die CLI Option vorrangig behandelt wird. Dieses beschriebene Verhalten ist aber nicht der Fall. Sowohl sftp -i tempkey root@host als auch rsync -e "ssh -i ${PWD}/tempkey" root@host scheinen den gewählten Key lediglich zur User-space Datenbank hinzuzufügen und dennoch erst alle Keys aus ~/.ssh/ durchzuprobieren. Das Verhalten tritt nicht auf, wenn ich Testweise alle Keys aus ~/.ssh/ entferne.
Hier stellt sich mir die Frage, wofür ich -i für die normalen Keys überhaupt verwende, wenn ich dabei den gewählten Key offensichtlich nur doppelt setze, anstatt in als einzigen zu wählen. Habe ich die Beschreibungen hier Missverstanden, oder ein ungewolltes Fehlverhalten seitens der SSH-Clienten entdeckt?
Da ich ich das Verhalten nicht auf Ubuntu testen kann und es nur auf Debian Servern und Clienten beobachtet habe, erstelle ich das mal hier.