Da immer mehr Leute anfangen, SSH anstelle von Telnet zu verwenden, sehe ich immer mehr Verwirrung über die Art und Weise, wie der SSH-Daemon Passwort-Warnungen, Ablauf- und Karenzzeiten behandelt. Ein Teil der Verwirrung wird durch die falsche Erwartung verursacht, dass SSH das Verhalten von Telnet und dem Anmeldebefehl dupliziert. Dieser Blog ist ein Versuch, zu erklären, wie es funktioniert.
Denken Sie zunächst daran, dass SSH aus der Welt von Unix/Linux kommt und diese Welt nicht die 7-Tage-Warnung vor Ablauf mit der Option zum Ändern des Passworts hat, die der VOS-Anmeldebefehl bietet. Auch die ursprüngliche Version des SSH-Daemons bot diese Warnung/Option nicht.
Ab Version 2.0.0e (Fehlerbehebungen ssl-205 und ssl-268) wurde dieses Verhalten so geändert, dass der SSH-Daemon 7 Tage vor Ablauf des Passworts nach einem neuen Passwort fragte, genau wie der Befehl login. Allerdings blieben Verbindungen, die einen Tunnel einrichten, bei der Aufforderung zur Passwortänderung hängen, weil die Aufforderung dem Benutzer nie angezeigt wurde. Das Problem war, dass beim Einrichten eines Tunnels normalerweise kein Pseudoterminal zugewiesen wird, sodass es keinen Platz gab, um die Aufforderung anzuzeigen.
Daher wurde der SSH-Daemon ab Version 2.0.0k (ssl-295) wieder auf sein ursprüngliches Verhalten zurückgesetzt. Dem Code wurde eine externe Variable hinzugefügt, mit der Sites die Aufforderung zum Ändern des Passworts vor Ablauf der Gültigkeit aktivieren können, wenn sie dies wünschen. Dies geschieht durch Setzen der Variable sshd$pw_change_method auf 1.
Beachten Sie, dass sich das Verhalten des SSH-Daemons bei der Aufforderung zur Eingabe eines neuen Passworts während der 7-tägigen Warnzeit von dem Verhalten von login bei der Verbindung mit Telnet unterscheidet. Bei Telnet/login können Sie einfach die Eingabetaste drücken, um den Schritt zur Passwortänderung zu überspringen. Der SSH-Daemon verlangt, dass Sie das Kennwort ändern. Das Verhalten ist aufgrund der Art und Weise, wie der SSH-Daemon das Kennwort ändert, unterschiedlich. Wenn Sie dem Login-Befehl das Argument change_password hinzufügen, dürfen Sie den Schritt "Passwort ändern" ebenfalls nicht überspringen. Dies ist im Grunde das, was der SSH-Daemon tut. Der Bug ssl-279 beschreibt diesen Unterschied im Verhalten, wurde aber von der Technik als kein Bug eingestuft. Eine andere Sache, die Sie vielleicht bemerken, wenn Sie sich sowohl mit Telent/login als auch mit SSH anmelden, ist, dass Telnet/login meldet, dass Ihr Passwort in N Tagen abläuft, während der SSH-Daemon meldet, dass Ihr Passwort in N+1 Tagen abläuft. Das Verhalten hängt von der Tageszeit der letzten Passwortänderung ab. Dies wurde als Fehler ssl-368 gemeldet.
Die obige Diskussion befasst sich mit der Zeit während der 7-tägigen Warnperiode. Was ist mit der Karenzzeit (definiert durch den Wert password_grace_time des Befehls login_admin)? Während der Karenzzeit erlaubt der SSH-Daemon die Anmeldung mit dem alten Kennwort und verlangt die Eingabe eines neuen Kennworts, genau wie bei der Telnet-Anmeldung. Allerdings ist die Meldung, die der SSH-Daemon anzeigt, ein wenig irreführend. Sie besagt, dass Ihr Passwort bald abläuft. Mit dem Vorschlag ssl-366 kann die Meldung geändert werden, um anzuzeigen, dass Ihr Kennwort abgelaufen ist. Unabhängig von der Meldung ist das Endergebnis jedoch das gleiche - Sie müssen ein neues Kennwort eingeben.
Der letzte zu berücksichtigende Zeitraum ist nach der Karenzzeit. Während dieser Zeit scheint der SSH-Daemon die Anmeldung mit dem alten Kennwort zuzulassen und fordert Sie zur Eingabe eines neuen Kennworts auf, aber nach Eingabe des neuen Kennworts wird die Verbindung beendet. Der Befehl Telnet/login beendet die Verbindung, nachdem Sie das alte Kennwort eingegeben haben. Dies ist als Vorschlag ssl-367 dokumentiert, der SSH-Daemon sollte nicht zur Eingabe eines neuen Passworts auffordern.
Es gibt einen weiteren Unterschied zwischen dem Verhalten von Telnet/Login und dem SSH-Daemon beim Ändern eines Passworts. Nach dem Ändern des Kennworts trennt der SSH-Daemon die Sitzung, sodass Sie sich erneut verbinden und mit dem neuen Kennwort anmelden müssen.
Zum Schluss noch ein weiterer Fehler, der diskutiert werden muss. Wenn der Parameter req_change_first_login, der vom Befehl set_login_security angezeigt wird, auf "yes" gesetzt ist, behandelt der SSH-Daemon alle Passwörter als nicht als abgelaufen, unabhängig von ihrem tatsächlichen Zustand. Dieser Fehler, ssl-361, ist in Version 2.0.0u behoben und es wird empfohlen, dass jedes Modul, bei dem der Parameter req_change_first_login auf "yes" gesetzt ist, sofort auf mindestens diese Version aktualisiert wird.
Da der sshd-Prozess für jede Verbindung einen neuen Prozess aufspaltet, ist es möglich, die neue Version der Datei sshd.pm zu installieren, ohne alle mit SSH verbundenen Benutzer vom System zu zwingen. Um dies zu tun, müssen Sie
- Ändern Sie die Verzeichnisse in >system>openssl>sbin
- Benennen Sie die laufende Datei sshd.pm in original_sshd.pm um
- Verschieben Sie eine Kopie der neuen sshd.pm in das aktuelle Verzeichnis
- Execute the command “kill (contents <etc>sshd.pid)” to stop the parent sshd process
- Wechseln Sie mit dem Befehl switch_to_root zum Benutzer root. Dazu müssen Sie das Root-Passwort kennen.
- Starten Sie den neuen sshd-Prozess. Wenn Sie unsicher sind, wie Sie sshd starten, prüfen Sie Ihre module_start_up.cm
Das Verfahren, um einfach den Wert der Variable sshd$pw_change_method zu ändern, ist fast das gleiche. Die Schritte 1, 2, 4, 5 und 6 sind die gleichen, aber Schritt 3 ändert sich in
3. Kopieren Sie original_sshd.pm nach sshd.pm
und ein neuer Schritt 3a wird hinzugefügt, um die Variable tatsächlich zu setzen
3a. Führen Sie den Befehl
"set_external_variable sshd$pw_change_method -in sshd.pm -type integer -to 1"
Unternehmen