Tengo una instancia EC2 en funcionamiento con varios usuarios, algunos de los cuales están conectados a sus directorios personales, algunos son solo ftp y no tienen acceso al shell, etc. ec2-user es la cuenta de administrador principal, aunque otros también tienen acceso root e inicios de sesión ssh completos. Todo funciona muy bien en la instancia en ejecución.
Puedo tomar una instantánea de la instancia y lanzar nuevas instancias a partir de la instantánea. No importa lo que seleccione en términos del par de claves asociado con la nueva instancia (usar el par de claves original para el usuario de ec2, crear un nuevo par de claves o no usar ningún par de claves), una vez que la nueva instancia se inicia y se ejecuta, no puedo ssh en el servidor usando ec2-user o cualquier otro usuario habilitado para ssh. Sin embargo, ftp funciona bien.
Los grupos de seguridad no son un problema, hasta donde yo sé, el tráfico entrante está permitido (y de todos modos, es el mismo grupo de seguridad que la instancia original).
El /var/log/secure de los intentos de inicio de sesión me da:
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method none
sshd[1739]: debug1: attempt 0 failures 0
sshd[1738]: debug1: user ec2-user does not match group list sftponly at line 142
sshd[1738]: debug1: PAM: initializing for "ec2-user"
sshd[1738]: debug1: PAM: setting PAM_RHOST to "..."
sshd[1738]: debug1: PAM: setting PAM_TTY to "ssh"
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method publickey
sshd[1739]: debug1: attempt 1 failures 0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: Failed publickey for ec2-user from xx.xx.xx.xx port 60597 ssh2
sshd[1739]: Connection closed by xx.xx.xx.xx
sshd[1739]: debug1: do_cleanup
Es el mismo error para todos los usuarios habilitados para ssh. Como puede ver en el registro, cambié mi sshd_config en la instancia original para que busque las claves públicas en la carpeta /etc/ssh/keys.
He montado las instancias fallidas como volúmenes en la instancia de trabajo. Las claves están en la carpeta, con los mismos permisos y los mismos valores de clave, todo como se esperaba. Aquí está ls -al de la carpeta de claves (.) y el archivo de usuario ec2.
drwxr-xr-x. 2 root root 4096 Dec 1 16:59 .
-rw-------. 1 ec2-user ec2-user 388 Jul 25 13:27 ec2-user
¿Qué podría estar causando este problema? Me gustaría resolver el problema al momento de guardar y ejecutar una instantánea o al configurar la instancia original, pero sin montar la instancia problemática y realizar cambios manuales para que sea funcional pero no solucione el problema mayor.
ACTUALIZACIÓN: Aquí están las configuraciones activas en el archivo sshd_config:
#...
Protocol 2
#...
SyslogFacility AUTHPRIV
LogLevel DEBUG
#...
AuthorizedKeysFile /etc/ssh/keys/%u
#...
PasswordAuthentication no
#...
ChallengeResponseAuthentication no
#...
GSSAPIAuthentication yes
#...
GSSAPICleanupCredentials yes
#...
UsePAM yes
#...
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
#...
X11Forwarding yes
#...
Subsystem sftp internal-sftp -f AUTH -l VERBOSE
#...
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l VERBOSE -f AUTH
#...
Respuesta1
Sospecho que esto es un problema de SELinux. Verifique el contexto de la carpeta que está utilizando; espero que no sea correcto para contener claves.
Me temo que ya no tengo acceso a un cuadro de Redhat para establecer exactamente cuál debería ser el contexto. Dicho esto, prueba esto:
ls -lZ /root/.ssh
Esto generará el contexto selinux que debe tener su nueva carpeta. Si no recuerdo mal debería ser algo así como system_u:system_r:sshd_t
Luego debemos aplicar ese contexto de seguridad a la ubicación de sus nuevas claves autorizadas:
semanage fcontext -a -t system_u:system_r:sshd_t “/etc/ssh/keys(/.*)?”
Lo cual asoció el contexto correcto con la ubicación de las nuevas claves. Finalmente, podemos aplicar el contexto a la nueva ubicación.
restorecon -Rv /etc/ssh/keys
Respuesta2
¿Está configurada la directiva 'AllowUsers' en sshd_config? ¿Quizás esté configurado para un usuario específico en el servidor original y ssh aún no se ha reiniciado, por lo que aún acepta a todos los usuarios?
Oh, acabo de ver esto en la depuración: "el usuario ec2-user no coincide con la lista de grupos sftponly en la línea 142". Verifique sshd_config. ¿Es posible que haya rechazado un grupo o solo haya permitido sftp?