He tratado de configurar una contraseña-menos ssh b / w A
a B
y B
a A
también. Se generó la clave pública y privada utilizando ssh-keygen -trsa
ambas máquinas. Utilizó la ssh-copy-id
utilidad para copiar las claves públicas de A
a B
, así como B
a A
.
El ssh sin contraseña funciona desde A
hasta B
pero not
desde B
hasta A
. He comprobado los permisos de la carpeta ~ / ssh / y parece ser normal.
A's .ssh
permisos de carpeta:
-rw------- 1 root root 13530 2011-07-26 23:00 known_hosts
-rw------- 1 root root 403 2011-07-27 00:35 id_rsa.pub
-rw------- 1 root root 1675 2011-07-27 00:35 id_rsa
-rw------- 1 root root 799 2011-07-27 00:37 authorized_keys
drwxrwx--- 70 root root 4096 2011-07-27 00:37 ..
drwx------ 2 root root 4096 2011-07-27 00:38 .
B's .ssh
permisos de carpeta:
-rw------- 1 root root 884 2011-07-07 13:15 known_hosts
-rw-r--r-- 1 root root 396 2011-07-27 00:15 id_rsa.pub
-rw------- 1 root root 1675 2011-07-27 00:15 id_rsa
-rw------- 1 root root 2545 2011-07-27 00:36 authorized_keys
drwxr-xr-x 8 root root 4096 2011-07-06 19:44 ..
drwx------ 2 root root 4096 2011-07-27 00:15 .
A
es un ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 mar 2009) B
es una máquina debian (OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 oct 2007)
De A
:
#ssh B
funciona bien.
De B
:
#ssh -vvv A
...
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x7f1581f23a50)
debug2: key: /root/.ssh/id_dsa ((nil))
debug3: Wrote 64 bytes for a total of 1127
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1495
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:
Lo que esencialmente significa que no se está autenticando con el archivo /root/id_rsa
. Ejecuté el ssh-add
comando en ambas máquinas también.
La parte de autenticación del /etc/ssh/sshd_config
archivo es
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
Me estoy quedando sin ideas. Cualquier ayuda sería apreciada.
PermitRootLogin
en/etc/ssh/sshd_config
A?yes
contrario, el usuario no recibirá una contraseña.Respuestas:
Solo asegúrese de haber seguido el siguiente procedimiento:
En la máquina A
abra una terminal e ingrese los comandos de la siguiente manera:
Solo para asegurarnos de que somos root.
Si el comando anterior muestra algo como lo que se muestra a continuación, somos root, de lo contrario, cambie a root usando el
su
comando1) Crea las claves.
No he usado ninguna frase de contraseña. Si necesita uno, puede usarlo.
2) Copie la clave pública en el
.ssh/authorized_keys
archivo de la máquina BAhora intente iniciar sesión en la máquina, con
ssh 'root@mylap'
, y regístrese:para asegurarnos de que no hayamos agregado claves adicionales que no esperaba.
Reemplace mylap con el nombre de host o la ip de la máquina en la que desea iniciar sesión (es decir, la máquina B)
3) Inicie sesión en B sin contraseña
En la máquina B
4) Cree las claves para volver a iniciar sesión en la Máquina A
5) Copie la clave pública en el
.ssh/authorized_keys
archivo de la máquina AAhora intente iniciar sesión en la máquina, con
ssh 'root@aneesh-pc'
, y regístrese:para asegurarnos de que no hayamos agregado claves adicionales que no esperaba.
6) Inicie sesión en A sin contraseña
Si puede completar estos pasos, ya ha terminado. Ahora tiene dos máquinas con inicio de sesión habilitado ssh-key (public-key).
fuente
/root
(770)drwxrwx--- 70 root root 4096 2011-07-27 00:37 ..
era demasiado abierto. Cambió los permisosdrwxr-xr-x
y ahora está funcionando. No podía imaginar el hecho de que el permiso del directorio principal afectara elssh
.770
también se configuró, cambió a ay750
todo está bien con el mundo :) Siempre me parece olvidar que las prems de Linux pueden funcionar al revés de esa manera.Después de configurar ssh sin contraseña , todavía me pidieron mi contraseña de usuario. Al
/var/log/auth.log
observar la máquina remota, se señaló el problema:Por lo tanto, asegúrese de tenerlo bien:
Aunque prohibir a otros usuarios que escriban sobre su
.ssh
carpeta es obvio, tener el mismo requisito para su carpeta de inicio fue más complicado.También, comprobación
/etc/ssh/ssd_config
para asegurarse de queRSAAuthentication
yPubkeyAuthentication
opciones no son discapacitados. El valor predeterminado esyes
que no debería ser un problema.fuente
~/.ssh
a otra cosa y luego crear una nueva con mi propia clave allí.Probablemente solo un problema de permisos de nivel superior. Es necesario para eliminar los permisos de escritura de grupo y otra a su directorio y el directorio .ssh. Para corregir estos permisos, ejecute
chmod 755 ~ ~/.ssh
ochmod go-w ~ ~/.ssh
.Si todavía tiene problemas, emita el siguiente grep en su registro:
(reemplace
LOCAL_USER_NAME
con su nombre de usuario local ...)Es de esperar que le diga más sobre su problema, suponiendo que la información de autenticación sshd se registre en el registro seguro, que debería ser por defecto. Si ve errores que se ven así:
Es el problema descrito anteriormente y necesita encontrar el directorio en cuestión y eliminar los permisos de escritura del grupo y otros.
En cuanto a la razón por la que necesitaría restringir los permisos de escritura en su directorio de inicio (a pesar de que los permisos ya están restringidos en su .ssh y directorios posteriores), permitirá a otros usuarios cambiar el nombre de su directorio .ssh y crear uno nuevo, aunque eso sería inutilizable como está (debido a permisos incorrectos), la solución para la mayoría de los usuarios probablemente sería cambiar los permisos en lugar de verificar el contenido del directorio ...
TLDNR : Permitir acceso de escritura para el grupo y / u otro a su directorio de inicio hará que ssh fuerce el inicio de sesión con contraseña.
fuente
¿Está utilizando la cuenta raíz en cada máquina? Por lo general, en Ubuntu usaría una cuenta de usuario y le daría privilegios de sudo según sea necesario.
Si está utilizando un usuario no root,
sudo chown $USER -R ~/.ssh
puede solucionar su problemaOtras cosas para verificar:
verifica que B's
id_rsa.pub
esté en A'sauthorized_keys
.comprobar A
/etc/ssh/sshd_config
contienefuente
/etc/ssh/sshd_config
archivoen / etc / ssh / sshd_config en el cambio de destino
a
luego mata -HUP tu PID sshd:
fuente
root
inicio de sesión SSH funcione. Eso no tiene nada que ver con lo que trata esta pregunta. Además, si laroot
cuenta está habilitada (no está por defecto en Ubuntu), habilitar losroot
inicios de sesión SSH puede ser bastante peligroso.