2012-04-10 7 views
9

Tengo una configuración compartida/doméstica usando el software de clúster Perceus (http://perceus.org) para nuestro clúster. Los nodos usan CentOS 6.1 x86_64. /home es compartido desde la cabeza a los nodos por nfs (NFSv4)."Conexión cerrada por [HOST IP]" usando la autenticación de clave dsa

[email protected]~]$ cat /etc/exports 
/var/lib/perceus/ 10.10.10.0/255.255.255.0(ro,no_root_squash,async) 
/home/ 10.10.10.0/255.255.255.0(rw,no_root_squash,no_all_squash,async) 

Aquí está el/etc/fstab en cada nodo (todos iguales).

... 
10.10.10.2:/var/lib/perceus/ /var/lib/perceus/ nfs ro,soft,bg 0 0 
10.10.10.2:/home/ /home nfs rw,soft,bg 0 0 

/etc/fstab en los nodos es una copia de la cabeza/principal con UID idéntica: GID.

He creado pares de claves utilizando el siguiente método:

$ cd ~ 
$ rm -rf .ssh 
$ mkdir .ssh 
$ chmod 700 .ssh 
$ ssh-keygen -t dsa -P "" 
Generating public/private dsa key pair. 
Enter file in which to save the key (/home/user/.ssh/id_dsa): 
Your identification has been saved in /home/user/.ssh/id_dsa. 
Your public key has been saved in /home/user/.ssh/id_dsa.pub. 
The key fingerprint is: 
[SNIPPED] [email protected] 
The key's randomart image is: 
+--[ DSA 1024]----+ 
[SNIPPED] 
$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys 
$ chmod 400 ~/.ssh/authorized_keys 

aquí está el problema.Cuando intento enviar ssh a cada nodo, recibo un mensaje de error "Connection Cerrado". Aquí está la salida de depuración.

$ ssh node01 
Connection closed by 10.10.10.101 

$ ssh node01 -vvv 
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: Applying options for * 
debug2: ssh_connect: needpriv 0 
debug1: Connecting to node01 [10.10.10.101] port 22. 
debug1: Connection established. 
debug1: identity file /home/user/.ssh/identity type -1 
debug1: identity file /home/user/.ssh/id_rsa type -1 
debug3: Not a RSA1 key file /home/user/.ssh/id_dsa. 
debug2: key_type_from_name: unknown key type '-----BEGIN' 
debug3: key_read: missing keytype 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug3: key_read: missing whitespace 
debug2: key_type_from_name: unknown key type '-----END' 
debug3: key_read: missing keytype 
debug1: identity file /home/user/.ssh/id_dsa type 2 
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 
debug1: match: OpenSSH_5.3 pat OpenSSH* 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_5.3 
.... SNIPPED ... 
debug2: dh_gen_key: priv key bits set: 139/256 
debug2: bits set: 482/1024 
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent 
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY 
debug3: Wrote 144 bytes for a total of 981 
debug3: check_host_in_hostfile: filename /home/user/.ssh/known_hosts 
debug3: check_host_in_hostfile: match line 1 
debug3: check_host_in_hostfile: filename /home/user/.ssh/known_hosts 
debug3: check_host_in_hostfile: match line 1 
debug1: Host 'node01' is known and matches the RSA host key. 
debug1: Found key in /home/user/.ssh/known_hosts:1 
debug2: bits set: 501/1024 
debug1: ssh_rsa_verify: signature correct 
debug2: kex_derive_keys 
debug2: set_newkeys: mode 1 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug3: Wrote 16 bytes for a total of 997 
debug2: set_newkeys: mode 0 
debug1: SSH2_MSG_NEWKEYS received 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug3: Wrote 48 bytes for a total of 1045 
debug2: service_accept: ssh-userauth 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug2: key: /home/user/.ssh/identity ((nil)) 
debug2: key: /home/user/.ssh/id_rsa ((nil)) 
debug2: key: /home/user/.ssh/id_dsa (0x7f79b940f650) 
debug3: Wrote 64 bytes for a total of 1109 
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password 
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password 
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password 
... [SNIPPED]... 
debug1: Next authentication method: publickey 
debug1: Trying private key: /home/user/.ssh/identity 
debug3: no such identity: /home/user/.ssh/identity 
debug1: Trying private key: /home/user/.ssh/id_rsa 
debug3: no such identity: /home/user/.ssh/id_rsa 
debug1: Offering public key: /home/user/.ssh/id_dsa 
debug3: send_pubkey_test 
debug2: we sent a publickey packet, wait for reply 
debug3: Wrote 528 bytes for a total of 1637 
debug1: Server accepts key: pkalg ssh-dss blen 434 
debug2: input_userauth_pk_ok: SHA1 fp 46:a2:c3:86........... 
debug3: sign_and_send_pubkey 
debug1: read PEM private key done: type DSA 
debug3: Wrote 592 bytes for a total of 2229 
Connection closed by 10.10.10.101 

He asegurándose de que/etc/ssh/sshd_config permite la autenticación basada en una clave (PubkeyAuthentication sí). Me he asegurado de que los permisos en/home (una vez montados en los nodos) sean correctos. Los usuarios están autenticados correctamente. He intentado montar nfs con y sin "no_all_squash" reiniciando nfs, rpcidmap, rpcbind y nfslock.

He tenido esto trabajando con CentOS5 instalado en los nodos con un nodo maestro/cabeza diferente. CentOS6 parece darme problemas adicionales con esto.

Si no creo la clave, por supuesto me piden una contraseña.

Mis hosts.allow/deny están vacíos tanto en los clientes como en el servidor.

El usuario raíz puede conectarse. Perceus maneja la generación de claves para el usuario raíz ya que es parte del sistema de archivos virtual. Supongo que algo está mal con la generación de mi clave, pero no puedo entender cuál es el problema.

+0

echar un vistazo a '/ var/log/secure *' cuando se conecta – lunixbochs

+0

Encontrado: 'fatal: Acceso denegado para el usuario por usuario PAM cuenta configuration' bondad – qtipp

Respuesta

4

SOLUCIÓN:

Siguiendo los consejos a continuación que comprueba /var/log/security en el nodo (host). Mostraba:

fatal: Access denied for user user by PAM account configuration 

entonces editado /etc/ssh/sshd_config cambiante:

UsePAM yes 

a

UsePAM no 

reinicia el nodo y ahora puede realizar inicios de sesión con contraseña menos.

Gracias!

13

La solución correcta es solucionar el problema, no deshabilitar el uso de pam, ya que podría estar ocultando un problema de seguridad.

ssh está fallando porque PAM está negando el inicio de sesión de usuario al fallar algún control. Verifique el /etc/pam.d/sshd para conocer las reglas que tiene y las posibles fallas.

problema

más común es un usuario sin contraseña (comparar la /etc/passwd con /etc/shadow o verificar el /etc/nsswitch y /etc/pam.d/* para ver donde los usuarios y autenticación está viniendo), pero también hay en Inicio, falta alguna configuración de autenticación adicional, UID demasiado baja o demasiado alta, etc.

Si su contraseña de la falta, al menos asegúrese de que esta en el /etc/ssh/sshd_config

PermitEmptyPasswords no 

esta bloques ssh para permitir el acceso de los usuarios sin contraseña (pero no hace nada para otra protocolos, li ke telnet, ftp, http e inicio de sesión).

+1

Gracias por su respuesta !!! Me he estado preguntando por qué un usuario específico (gpadmin) no podía ssh en localhost, todo lo demás en '.ssh' se configuraba correctamente con los permisos adecuados, resulta que era un usuario sin contraseña. Acabo de hacer 'sudo passwd gpadmin' y ahora ese usuario puede ssh en localhost como todos los demás. –

+0

Gracias por su respuesta. Acabo de clonar a un usuario en/etc/passwd pero no en/etc/shadow ... – Mildred

+1

gee, me alegraste el día: ¿cómo es posible que se necesite una contraseña para iniciar sesión sin contraseña ...? –

1

No es bueno usar una autorización sin contraseña. ¿Han encendido selinux esos servidores? Si es así, entonces usted tiene cualquiera de desactivar SELinux o restaurar las políticas de SELinux por defecto "restorecon -R -v/home/usuario /. This is a known issue

0

En mi caso, no he creado el usuario no utilizar useradd, en vez He agregado el usuario en el archivo/etc/passwd y he creado el directorio de inicio para el usuario con todos los archivos necesarios.

Después de usar useradd para crear al usuario y agregar la clave pub al archivo authorized_keys después de crear el directorio .ssh en el directorio de inicio del usuario, el problema se resolvió.

Por cierto estoy usando centos 7

Espero que esto ayude a alguien.

0

Para mí, tenía archivos corruptos pam.d. Copié en un nuevo conjunto de un servidor similar y todo estaba bien nuevamente. No me tomé el tiempo para buscar la corrupción específica, pero pensé que agregaría mis 2 bits en caso de que alguien lea esto en el futuro y necesite más ideas.

1

Tuve un problema muy similar al tuyo.

Resulta que mi problema, y ​​posiblemente el suyo, fue causado porque mi directorio personal era un montaje NFS, y selinux (en CentOS 7) estaba arrojando algunos errores (que eran bastante difíciles de rastrear). La solución fue simple sin embargo.

setsebool -P use_nfs_home_dirs 1 
Cuestiones relacionadas