Fondo
Tengo un servidor configurado con acceso SSH mediante claves ras. No se permite el acceso con contraseña.
Estaba funcionando bien. Mi usuario (lo llamaré USUARIO1) y root pudieron iniciar sesión con sus respectivas claves.
CAMBIOS QUE POTENCIALMENTE CAUSARON PROBLEMAS
Ayer hice algunos cambios en el servidor, siguiendo las instrucciones.en este articulo, para otorgar a un nuevo usuario (USUARIO2) acceso limitado a una carpeta (la raíz web). También seguí las instrucciones enEste artículo.
Para resumir esos cambios, creé un nuevo usuario (USUARIO2) e hice una búsqueda bindfsen la raíz web ( /home/user1/sites/domain/public/) para /home/user2/domain/public/). Se hicieron algunas otras cosas, según esos artículos, pero hasta donde puedo decir, ninguna de ellas afecta los permisos y el acceso SSH del USUARIO1. Así que no intentaré reiterarlos todos aquí.
Según uno de esos artículos, también agregué lo siguiente al sshd_configarchivo:
subsystem sftp internal-sftp
Match User USER2
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
Hasta donde puedo decir, eso es lo único que ha cambiado desde la última vez que pude iniciar sesión con USUARIO1.
ASUNTO
Después de realizar los cambios mencionados anteriormente, no pude iniciar sesión al día siguiente (hoy). Me sale el error Permission denied (publickey).,.
Seguí todas las recomendaciones estándar para establecer los permisos y la propiedad correctos para la ~/home/USER1/.sshcarpeta y ~/home/USER1/.ssh/authorized_keysel archivo. Aunque mis acciones de ayer no cambiaron ninguno de ellos, por lo que básicamente solo estaba volviendo a aplicar los permisos existentes.
El contenido de mi /etc/ssh/sshd_configarchivo es:
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
UsePAM yes
Subsystem sftp /usr/lib/openssh/sftp-server
Match User USER2
PasswordAuthentication yes
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
AuthorizedKeysFile %h/.ssh/authorized_keysfue comentado anteriormente. Lo descomenté mientras intentaba solucionar este problema.
No sé qué impide que mi USUARIO1 tenga acceso SSH basado en claves. Si hay más información que pueda ser útil, hágamelo saber.
ACTUALIZACIÓN: Logré solucionarlo, pero no estoy seguro de por qué ocurrió
Después de verificar que todos los permisos fueran correctos y que no hubiera nada extraño en el sshd-configarchivo, configuré ssh para permitir el inicio de sesión con contraseña y luego volví a copiar mi archivo id_rsa.pub (usando ssh-copy-id) en el servidor.
Esto ha restaurado mi acceso para USUARIO1 con una clave.
No entiendo totalmente por qué ocurrió este problema y planeo usar las instrucciones de esos artículos en servidores adicionales (ya que resultó ser una forma muy útil de otorgar a un desarrollador (por ejemplo) acceso SFTP estricto (solamente) al sitio web y tengo permiso para realizar cambios en los archivos. Entonces, si alguien tiene tiempo para señalar cuál fue el error en las instrucciones, por favor hágalo.
Para evitar que lea esos artículos, aquí hay un desglose de los pasos que tomé:
mkdir -p /home/user2/websites/application1
chown -Rf user2:user2 /home/user2/websites
chmod -Rf 770 /home/user2/websites
Añadir lo siguiente a/etc/fstab
bindfs#/home/user1/websites/domain/public /home/user2/websites/application1 fuse force-user=user2,force-group=user2,create-for-user=user1,create-for-group=user1,create-with-perms=0770,chgrp-ignore,chown-ignore,chmod-ignore 0 0
chown user1:user1 /home/user1/websites/domain/public
chmod 770 /home/user1/websites/domain/public
Creó el nuevo usuario:
sudo useradd -d /home/user2/website/application1 user2
sudo passwd user2
Agregado a sshd-config
subsystem sftp internal-sftp
Match User user2
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
Entonces,sudo service ssh restart
PREGUNTA
Entonces, mi pregunta modificada es: ¿qué habría causado en los pasos anteriores user1tener acceso ssh con su clave?