A medida que más y más gente comienza a usar SSH en lugar de Telnet, veo más y más confusión sobre la forma en que el demonio de SSH trata los tiempos de advertencia, expiración y gracia de las contraseñas. Parte de la confusión es causada por la expectativa incorrecta de que SSH duplicará el comportamiento de Telnet y el comando de inicio de sesión. Este blog es un intento de explicar cómo funciona.
Primero, recuerde que SSH viene del mundo de Unix/Linux y que el mundo no tiene la advertencia de 7 días antes de la expiración con opción de cambiar la contraseña que el comando de inicio de sesión de VOS proporciona. La versión original del demonio SSH tampoco proporcionó esta advertencia/opción.
A partir de la versión 2.0.0e (corrección de errores ssl-205 y ssl-268) este comportamiento fue cambiado de manera que el demonio SSH pidió una nueva contraseña 7 días antes de que la contraseña expirara, al igual que el comando de inicio de sesión. Sin embargo, las conexiones que establecieran un túnel se colgarían en la solicitud de cambio de contraseña porque la solicitud nunca se mostraba al usuario. El problema era que la configuración del túnel no suele asignar una pseudo-terminal, por lo que no había lugar para mostrar el aviso.
Así que a partir de la versión 2.0.0k (ssl-295) el demonio SSH volvió a su comportamiento original. Una variable externa fue añadida al código para permitir a los sitios habilitar el aviso de cambio de contraseña pre-vencimiento si lo desean. Esto se hace estableciendo la variable sshd$pw_change_method en 1.
Tenga en cuenta que el comportamiento del demonio SSH cuando se le pide una nueva contraseña durante el período de advertencia de 7 días es diferente del comportamiento de inicio de sesión cuando se conecta con Telnet. Telnet/login le permite simplemente presionar la tecla de retorno para saltarse el paso de cambio de contraseña. El demonio SSH requiere que cambies la contraseña. El comportamiento es diferente debido a la forma en que el demonio SSH está cambiando la contraseña. Si agregas el argumento change_password al comando de inicio de sesión, tampoco puedes omitir el paso de cambio de contraseña. Esto es básicamente lo que hace el demonio SSH. El error ssl-279 describe esta diferencia de comportamiento pero no ha sido considerado un error por Ingeniería. Otra cosa que usted puede notar si ingresa con ambos Telent/login y SSH es que Telnet/login reportará que su contraseña expirará en N días mientras que el demonio SSH puede reportar que su contraseña expirará en N+1 días. El comportamiento depende de la hora del día del último cambio de contraseña. Esto ha sido reportado como un error ssl-368.
La discusión anterior trata del tiempo durante el período de alerta de 7 días. ¿Y durante el período de gracia (definido por el valor password_grace_time del comando login_admin)? Durante el periodo de gracia el demonio SSH te permite entrar usando la contraseña antigua y requiere que introduzcas una nueva contraseña, igual que el Telnet/login. Sin embargo, el mensaje que muestra el demonio SSH es un poco engañoso. Dice que tu contraseña expira pronto. Se ha introducido la sugerencia ssl-366 para solicitar que el mensaje sea cambiado para indicar que su contraseña ha expirado. Sin embargo, independientemente del mensaje, el resultado final es el mismo: debe introducir una nueva contraseña.
El último período de tiempo a considerar es después del período de gracia. Durante este tiempo, el demonio SSH aparece para permitirte iniciar la sesión con la contraseña antigua y te pide una nueva contraseña, pero después de introducir la nueva contraseña termina la conexión. El comando Telnet/login terminará la conexión después de introducir la contraseña antigua. Esto está documentado como sugerencia ssl-367, el demonio SSH no debería pedir una nueva contraseña.
Hay otra diferencia entre el comportamiento del demonio Telnet/login y el demonio SSH cuando se cambia una contraseña. Después de cambiar la contraseña el demonio SSH desconectará la sesión, requiriendo que usted se reconecte y entre con la nueva contraseña.
Por último, un bicho más que necesita ser discutido. Si el parámetro req_change_first_login como se muestra en el comando set_login_security se establece en "yes" entonces el demonio SSH tratará todas las contraseñas como no expiró sin importar su estado actual. Este error, ssl-361, está corregido en la versión 2.0.0u y se recomienda que cualquier módulo con el parámetro req_change_first_login establecido en yes se actualice al menos a esta versión inmediatamente.
Como el proceso sshd bifurca un nuevo proceso para cada conexión, es posible instalar la nueva versión del archivo sshd.pm sin forzar a todos los usuarios conectados a SSH a salir del sistema. Para ello es necesario
- Cambie los directorios a >sistema>abressl>sbin
- Cambie el nombre del archivo sshd.pm en curso a original_sshd.pm
- Mover una copia del nuevo sshd.pm en el directorio actual
- Execute the command “kill (contents <etc>sshd.pid)” to stop the parent sshd process
- Cambie al usuario raíz con el comando switch_to_root. Necesitará saber la contraseña de root.
- Iniciar el nuevo proceso de sshd. Si no estás seguro de cómo iniciar sshd revisa tu module_start_up.cm
El procedimiento para cambiar simplemente el valor de la variable sshd$pw_change_method es casi el mismo. Los pasos 1, 2, 4, 5 y 6 son los mismos, pero el paso 3 cambia a
3. Copia original_sshd.pm a sshd.pm
y se añade un nuevo paso 3a para establecer la variable
3a. Ejecutar el comando
"set_external_variable sshd$pw_change_method -in sshd.pm -type integer -to 1"