6 votos

SSH sin contraseña

Yo soy incapaz de ssh sin contraseña, por alguna razón, en un nuevo CentOS cuadro.

He tratado de seguir estas guías:

Pero ni trabajan. Incluso me controla a mi /etc/ssh/sshd_config archivo. PubkeyAuthentication yes fue originalmente comentó a cabo, así que sin comentar esa línea y se reinicia sshd, pero aún sin éxito. Cualquier pensamiento de cualquier otra cosa que podría estar faltando?

Estoy tratando de ssh desde el servidor a servidor B como root. Por lo tanto, ha iniciado la sesión como root en una caja, a continuación, ssh a la siguiente como root sin que se le pida una contraseña.

ACTUALIZACIÓN

Me encontré con un ssh -v ... pero no se puede copiar/pegar en aquí. Todo se veía bien hasta esta línea:

debug1: Next authentication method:  gssapi-with-mic
debug1: Unspecified GSS failure.  Minor Code may provide more information
Unknown code krb5 195

4voto

Soviero Puntos 1590

Un pequeño how-to para la clave pública de la autenticación basada en CentOS/Red Hat/etc...

En el cliente SSH:

ssh-keygen # Accept all defaults, do not enter a password.
ssh-copy-id USER@SERVER_IP
restorecon -R ~/.ssh

En el servidor SSH:

# Login to the server normally (with password)
restorecon -R ~/.ssh

De clave pública basado en la autenticación de ahora debería funcionar.

2voto

stew Puntos 5826

Estos problemas (que son generalmente los permisos relacionados) son mucho más fáciles de depurar desde el lado del servidor. Te recomiendo empezar otra sshd en modo de depuración con: /usr/sbin/sshd -d -p 2222 que comenzará otro sshd en el puerto 2222, a continuación, ejecute ssh -p 2222 user@sshserver en el lado del cliente. Ver lo que sale de la sshd cuando el cliente intenta autenticar.

Problemas de permisos no tienen que ser sólo /home/$USER/.ssh. también podría ser un problema con /, /homeo /home/$USER. Si cualquiera de los que son un grupo de escritura puede ser un problema.

Otro problema común es que usted mis-pegar y poner puedes incluir varias líneas en el medio de su clave en el archivo authorized_keys

1voto

dmourati Puntos 9454
serverA# ls -lah /root
serverA# ls -lah /root/.ssh
serverA# selinuxenabled 
serverA# echo $?

serverB# ls -lah /root
serverB# ls -lah /root/.ssh
serverB# senlinuxenabled
serverB# echo $?

Si eso no mostrar el problema, pruebe lo siguiente. ServerA es el cliente y el servidor b el servidor ssh.

En serverB, edite el archivo /etc/ssh/sshd_config. Busque la línea que se parece a:

LogLevel INFO

Cambiar a:

LogLevel DETALLADO

Entonces:

serverB# /etc/init.d/sshd restart

En el servidor:

serverA# ssh -vvv root@serverb

Ahora puedes revisa el archivo /var/log/secure archivo en el servidor b en busca de pistas.

Como consejo final, por favor revisar:

http://www.ibm.com/developerworks/library/l-keyc/index.html

1voto

Johnny Edge Puntos 411

Comprobar sus permisos, deben ser

drwx------

para su .ssh directorio y

-rw-------

para su authorized_keys archivo.

Así, para establecer los permisos correctamente, intente esto:

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

0voto

Soviero Puntos 1590

Si usted tiene SELinux habilitado, entonces este es un problema común...

Ejecute el siguiente en el servidor SSH:

restorecon -R /home/$USER/.ssh

o, para el usuario root:

restorecon -R /root/.ssh

'Nuff Dijo...

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: