Aquí hay una breve nota sobre la configuración de inicios de sesión sin contraseña entre 2 sistemas Linux. El proceso consiste básicamente en generar una clave de autenticación pública y agregarla al archivo ~/.ssh/authorized_keys de los hosts remotos.
Generar clave de autenticación
Si no existe un archivo de clave de autenticación SSH, genere uno ejecutando ssh-keygen dominio. Cuando se le solicite una frase de contraseña, use una frase de contraseña en blanco si se requiere un inicio de sesión sin contraseña:
# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: 1e:b2:f4:89:5a:7f:2d:a5:a5:4d:6d:66:2c:82:d8:18 root@remote-host
Copiar la clave pública al host remoto
Usa el ssh-copy-id comando para instalar la mitad pública de la clave de autenticación recién generada en el directorio de inicio de un usuario específico en el host remoto. El comando ssh-copy-id agregará automáticamente la información de identidad en ~/.ssh/authorized_keys archivo para el usuario especificado en el host remoto (creando ~/.ssh y ~/.ssh/authorized_keys si es necesario).
# ssh-copy-id -i ~/.ssh/id_rsa.pub user@remote-host user@remote-hosts's password:
Alternativamente, si el servidor no está instalado con openssh-clients (un paquete que proporciona la utilidad de comando ssh-copy-id), puede copiar la clave de autenticación con el comando:
# cat ~/.ssh/id_rsa.pub | ssh user@remote-host "cat >> ~/.ssh/authorized_keys"
Si todo está configurado correctamente, debería poder iniciar sesión en el host remoto sin contraseña.
Resolución de problemas
Verifique los permisos correctos
La causa más común de problemas para hacer funcionar la autenticación ssh basada en claves son los permisos de archivos en el servidor ssh remoto
Si se siguieron los pasos anteriores y ssh'ing al usuario apropiado aún solicita contraseñas, inspeccione los permisos en los archivos del usuario local y remoto . Los permisos de los directorios deben ser exactamente como se muestra a continuación. El ejemplo que se muestra aquí es para el usuario “oracle”
drwx------. 25 oracle oinstall 4096 Aug 21 11:01 /home/oracle/ drwx------. 2 oracle oinstall 4096 Aug 17 13:13 /home/oracle/.ssh -rw-------. 1 oracle oinstall 420 Aug 17 13:13 /home/oracle/.ssh/authorized_keys
Si los permisos no son como se muestra arriba, configúrelos correctamente:
# chmod 600 ~/.ssh/authorized_keys chmod 700 ~/.ssh/
Reinicie el servicio sshd para que los cambios surtan efecto:
# service sshd restart
deshabilitar SElinux
SELinux también puede potencialmente evitar que sshd acceda al directorio ~/.ssh en el servidor. Este problema se puede descartar (o resolver) ejecutando restorecon de la siguiente manera en el directorio ~/.ssh del usuario remoto:
# restorecon -Rv ~/.ssh