"Connessione chiusa da [HOST IP]" utilizzando l'autenticazione della chiave dsa

Question

Ho una configurazione condivisa/home utilizzando il software Perceus Cluster (http://perceus.org) per il nostro Cluster. I nodi utilizzano CentOS 6.1 x86_64. /home è condiviso dalla testa ai nodi da nfs (NFSv4).

root@head~]$ 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) 

Ecco il/etc/fstab su ciascun nodo (tutti uguali).

... 
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 sui nodi è una copia della testa/master con UID identico: GID.

ho creato coppie di chiavi utilizzando il seguente metodo:

$ 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] user@head 
The key's randomart image is: 
+--[ DSA 1024]----+ 
[SNIPPED] 
$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys 
$ chmod 400 ~/.ssh/authorized_keys 

qui è il problema.Quando provo a ssh in ogni nodo, ricevo un errore "Connessione chiusa". Ecco l'output di debug.

$ 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 

Ho facendo in modo che/etc/ssh/sshd_config permette l'autenticazione basata su chiave (PubkeyAuthentication sì). Mi sono assicurato che le autorizzazioni su/home (una volta montate sui nodi) siano corrette. Gli utenti sono correttamente autenticati. Ho provato il montaggio di nfs con e senza "no_all_squash" riavvio di nfs, rpcidmap, rpcbind e nfslock.

Ho avuto questo funzionamento con CentOS5 installato sui nodi con un diverso master/nodo principale. CentOS6 sembra proprio darmi ulteriori problemi con questo.

Se non si crea la chiave, ovviamente mi viene richiesta una password.

I miei hosts.allow/deny sono vuoti sia su client che su server.

L'utente root è in grado di connettersi. Perceus gestisce la generazione della chiave per l'utente root poiché fa parte del file system virtuale. Sto indovinando che c'è qualcosa di sbagliato nella generazione della mia chiave ma non riesco a capire quale sia il problema.

Answer 1

SOLUZIONE:

Seguendo i consigli di seguito ho controllato /var/log/security sul nodo (host). Ha dimostrato:

fatal: Access denied for user user by PAM account configuration 

Ho poi editati /etc/ssh/sshd_config cambia:

UsePAM yes 

a

UsePAM no 

riavviato il nodo e io ora in grado di eseguire i login senza password.

Grazie!

Answer 2

La soluzione corretta è quella di risolvere il problema, non disabilitare l'utilizzo della pam, in quanto si potrebbe nascondere un problema di sicurezza.

ssh non funziona perché PAM sta negando l'accesso dell'utente in mancanza di un controllo. Verifica lo /etc/pam.d/sshd per le regole che hai e cosa potrebbe non riuscire.

problema

più comune è un utente senza password (confrontare la /etc/passwd con /etc/shadow, o controllare il vostro /etc/nsswitch e /etc/pam.d/* per vedere dove utenti e autenticazione viene da), ma anche senza la directory home, mancanti alcune configurazioni di autenticazione in più, UID troppo basso o troppo alto, ecc

Se la sua password mancante, almeno assicuratevi di questo nel /etc/ssh/sshd_config

PermitEmptyPasswords no 

questa blocchi SSH per consentire login sugli utenti senza la password (ma non fa nulla per altri protocolli, li ke telnet, ftp, http e login).

Answer 3

Non è consigliabile utilizzare un'autorizzazione senza password. Selinux è attivato su quei server? Se sì, allora si hanno o disattivare SELinux, o ripristinare le politiche di SELinux predefinito da "restorecon -R -v/home/utente /. This is a known issue

Answer 4

Nel mio caso, io porto non ha creato l'utente utilizzando useradd, invece Ho aggiunto l'utente nel file/etc/passwd e creato la directory home per l'utente con tutti i file richiesti

Dopo aver usato useradd per creare l'utente e aver aggiunto la chiave pub al file authorized_keys dopo aver creato la directory .ssh in la directory home dell'utente, il problema è stato risolto

A proposito, sto usando centos 7

Spero che questo aiuti qualcuno.

Answer 5

Per me, avevo danneggiato i file pam.d. Ho copiato in un nuovo set da un server simile e tutto andava bene di nuovo. Non ho avuto il tempo di cercare la corruzione specifica, ma ho pensato di aggiungere i miei 2 bit nel caso qualcuno lo leggesse in futuro e avesse bisogno di altre idee.

Answer 6

Ho avuto un problema molto simile al tuo.

Si scopre il mio problema, e possibilmente la vostra, è stato causato perché la mia home directory era un monte NFS, e selinux (su CentOS 7) stava gettando alcuni errori (che erano piuttosto difficile da rintracciare). La soluzione era semplice però.

setsebool -P use_nfs_home_dirs 1