Mentre sempre più persone iniziano ad usare SSH al posto di Telnet, vedo sempre più confusione sul modo in cui il demone SSH tratta gli avvisi di password, la scadenza e i tempi di grazia. Parte della confusione è causata dall'errata aspettativa che SSH duplicherà il comportamento di Telnet e del comando di login. Questo blog è un tentativo di spiegare come funziona.
Per prima cosa, ricordate che SSH proviene dal mondo di Unix/Linux e che il mondo non ha l'avviso di 7 giorni prima della scadenza con l'opzione di cambiare la password che il comando di login VOS fornisce. Nemmeno la versione originale del demone SSH ha fornito questo avvertimento/opzione.
A partire dalla release 2.0.0e (bug fixes ssl-205 e ssl-268) questo comportamento è stato modificato in modo tale che il demone SSH ha chiesto una nuova password 7 giorni prima della sua scadenza, proprio come il comando di login. Tuttavia, le connessioni che impostano un tunnel si bloccherebbero alla richiesta di modifica della password perché la richiesta non è mai stata visualizzata all'utente. Il problema era che la configurazione del tunnel di solito non assegna un pseudo-terminale, quindi non c'era posto per visualizzare la richiesta.
Così, a partire dalla versione 2.0.0k (ssl-295) il demone SSH è stato riportato al suo comportamento originale. Una variabile esterna è stata aggiunta al codice per consentire ai siti di abilitare il prompt di modifica della password prima della scadenza, se lo desiderano. Questo viene fatto impostando la variabile sshd$pw_change_method su 1.
Si noti che il comportamento del demone SSH quando richiede una nuova password durante il periodo di preavviso di 7 giorni è diverso dal comportamento del login quando si connette con Telnet. Telnet/login permette di premere il tasto di ritorno per saltare la fase di modifica della password. Il demone SSH richiede di cambiare la password. Il comportamento è diverso a causa del modo in cui il demone SSH sta cambiando la password. Se si aggiunge l'argomento change_password al comando di login, non è possibile saltare la fase di modifica della password. Questo è fondamentalmente ciò che il demone SSH sta facendo. Il bug ssl-279 descrive questa differenza di comportamento, ma non è stato considerato un bug da Engineering. Un'altra cosa che si può notare se si effettua il login sia con Telent/login che con SSH è che Telnet/login riporterà che la password scadrà in N giorni mentre il demone SSH potrebbe riportare che la password scadrà in N+1 giorni. Il comportamento dipende dall'ora del giorno dell'ultimo cambio di password. Questo è stato segnalato come bug ssl-368.
La discussione di cui sopra riguarda l'orario durante il periodo di preavviso di 7 giorni. E durante il periodo di grazia (definito dal valore password_grace_time del comando login_admin)? Durante il periodo di grazia il demone SSH permette di effettuare il login utilizzando la vecchia password e richiede l'inserimento di una nuova password, proprio come il Telnet/login. Tuttavia il messaggio che il demone SSH visualizza è un po' fuorviante. Esso afferma che la vostra password scadrà presto. Il suggerimento ssl-366 è stato inserito per richiedere che il messaggio venga modificato per indicare che la vostra password è scaduta. Tuttavia, indipendentemente dal messaggio, il risultato finale è lo stesso: è necessario inserire una nuova password.
L'ultimo periodo di tempo da considerare è dopo il periodo di grazia. Durante questo periodo il demone SSH appare per consentire il login con la vecchia password e richiede una nuova password, ma dopo aver inserito la nuova password interrompe la connessione. Il comando Telnet/login terminerà la connessione dopo l'inserimento della vecchia password. Questo è documentato come suggerimento ssl-367, il demone SSH non dovrebbe richiedere una nuova password.
C'è un'altra differenza tra il comportamento del demone Telnet/login e quello del demone SSH quando si cambia la password. Dopo aver cambiato la password il demone SSH scollegherà la sessione, richiedendovi di riconnettervi e di effettuare il login con la nuova password.
Infine, un altro bug che deve essere discusso. Se il parametro req_change_first_login come visualizzato dal comando set_login_security è impostato su "yes", allora il demone SSH tratterà tutte le password come non sono scaduti indipendentemente dal loro stato attuale. Questo bug, ssl-361, è stato risolto nella release 2.0.0u e si raccomanda che qualsiasi modulo con il parametro req_change_first_login impostato a yes passi immediatamente a questa release.
Dal momento che il processo sshd biforca un nuovo processo per ogni connessione è possibile installare la nuova versione del file sshd.pm senza forzare tutti gli utenti connessi SSH fuori dal sistema. Per fare ciò è necessario
- Cambiare le directory in >sistema>openssl>sbin
- Rinominare il file sshd.pm in esecuzione in original_sshd.pm
- Spostare una copia del nuovo sshd.pm nella directory corrente
- Execute the command “kill (contents <etc>sshd.pid)” to stop the parent sshd process
- Passare all'utente root con il comando switch_to_root. È necessario conoscere la password di root.
- Avviare il nuovo processo sshd. Se non siete sicuri di come avviare sshd controllate il vostro module_start_up.cm
La procedura per modificare il valore della variabile sshd$pw_change_method è quasi la stessa. I passi 1, 2, 4, 5 e 6 sono gli stessi, ma il passo 3 cambia in
3. Copia original_sshd.pm su sshd.pm
e viene aggiunto un nuovo passo 3a per impostare effettivamente la variabile
3a. Eseguire il comando
"set_external_variabile sshd$pw_change_method -in sshd.pm -tipo intero -a 1".
Azienda