it-swarm.com.de

"Verbindung wurde durch [Host-IP] geschlossen" mithilfe der dsa-Schlüsselauthentifizierung

Ich habe ein Shared/Home-Setup mit der Perceus Cluster-Software ( http://perceus.org ) für unseren Cluster. Knoten verwenden CentOS 6.1 x86_64. /Home wird vom Kopf für die Knoten von nfs (NFSv4) gemeinsam genutzt.

[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)

Hier ist die/etc/fstab auf jedem Knoten (alle gleich).

...
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 auf Knoten ist eine Kopie des Heads/Masters mit identischer UID: GID.

Ich habe Schlüsselpaare mit folgender Methode erstellt:

$ 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

Hier ist das Problem. Wenn ich versuche, in jeden Knoten ssh einzulegen, erhalte ich die Fehlermeldung "Connection Closed" . Hier ist die Debugging-Ausgabe.

$ 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

Ich muss sicherstellen, dass/etc/ssh/sshd_config die schlüsselbasierte Authentifizierung zulässt (PubkeyAuthentication yes). Ich habe sichergestellt, dass die Berechtigungen für/home (einmal auf den Knoten eingehängt) korrekt sind. Benutzer werden ordnungsgemäß authentifiziert. Ich habe versucht, NFS mit und ohne "no_all_squash" zu starten, um NFS, Rpcidmap, Rpcbind und Nfslock neu zu starten.

Ich habe dies mit CentOS5 auf den Knoten mit einem anderen Master/Head-Knoten installiert. CentOS6 scheint mir einfach zusätzliche Probleme zu bereiten.

Wenn ich den Schlüssel nicht erstelle, werde ich natürlich zur Eingabe eines Passworts aufgefordert.

Meine hosts.allow/deny sind auf Clients und auf dem Server leer.

Der Root-Benutzer kann eine Verbindung herstellen. Perceus übernimmt die Schlüsselgenerierung für den Root-Benutzer, da er Teil des virtuellen Dateisystems ist. Ich vermute, dass mit der Generierung meines Schlüssels etwas nicht stimmt, aber ich kann nicht herausfinden, was das Problem ist.

9
qtipp

Die richtige Lösung besteht darin, das Problem zu beheben und die Nutzung der PAM nicht zu deaktivieren, da Sie möglicherweise ein Sicherheitsproblem verbergen.

ssh schlägt fehl, weil PAM die Benutzeranmeldung versagt, indem einige Überprüfungen fehlgeschlagen sind. Überprüfen Sie den /etc/pam.d/sshd für die Regeln, die Sie haben und welche Fehler möglicherweise auftreten.

das häufigste Problem ist ein Benutzer ohne Kennwort (vergleichen Sie den /etc/passwd mit /etc/shadow, oder überprüfen Sie Ihren /etc/nsswitch und /etc/pam.d/*, um zu sehen, woher die Benutzer und auth kommen), aber auch kein Home-Verzeichnis, zu dem eine zusätzliche Auth-Konfiguration fehlt, die UID ist zu niedrig oder zu niedrig hoch usw.

Wenn es das fehlende Passwort ist, stellen Sie sicher, dass Sie dies in der /etc/ssh/sshd_config

PermitEmptyPasswords no

Dadurch wird ssh blockiert, um die Anmeldung bei Benutzern ohne Kennwort zuzulassen (dies gilt jedoch nicht für andere Protokolle wie Telnet, FTP, http und Login).

13
higuita

LÖSUNG:

Dem untenstehenden Rat folgend, habe ich /var/log/security auf dem Knoten (Host) überprüft. Es zeigte:

fatal: Access denied for user user by PAM account configuration

Ich habe dann /etc/ssh/sshd_config geändert:

UsePAM yes

zu

UsePAM no

Der Knoten wurde neu gestartet, und ich kann jetzt kennwortlose Anmeldungen durchführen.

Vielen Dank!

4
qtipp

Ich hatte ein sehr ähnliches Problem wie Sie.

Es stellt sich heraus, dass mein Problem und möglicherweise deins von Ihnen verursacht wurde, weil mein Home-Verzeichnis ein NFS-Mount war und selinux (unter CentOS 7) einige Fehler aufwarf (die ziemlich schwer zu finden waren). Das Update war jedoch einfach.

setsebool -P use_nfs_home_dirs 1
1
Simon

Es ist nicht gut, eine passwortlose Autorisierung zu verwenden. Ist Selinux auf diesen Servern aktiviert? Wenn ja, müssen Sie entweder selinux deaktivieren oder die Standardrichtlinien für selinux wiederherstellen, indem Sie "restorecon -R -v/home/user /. Dies ist ein bekanntes Problem

1
Theodor

Ich hatte korrupte pam.d-Dateien. Ich habe ein neues Set von einem ähnlichen Server kopiert und alles war wieder gut. Ich habe mir nicht die Zeit genommen, nach der spezifischen Korruption zu suchen, aber ich dachte, ich würde meine 2 Bits hinzufügen, falls jemand dies in der Zukunft liest und weitere Ideen braucht.

0
jdh239

In meinem Fall habe ich den Benutzer nicht mit useradd erstellt. Stattdessen habe ich den Benutzer in der Datei/etc/passwd hinzugefügt und das Ausgangsverzeichnis für den Benutzer mit allen erforderlichen Dateien erstellt.

Nachdem Sie useradd zum Erstellen des Benutzers und das Hinzufügen des pub-Schlüssels zur authorized_keys-Datei nach dem Erstellen des .ssh-Verzeichnisses im Basisverzeichnis des Benutzers verwendet haben, wurde das Problem behoben.

Übrigens benutze ich Centos 7

Hoffe das hilft jemandem.

0
Sunil Dias