10

クラスターにPerceusClusterSoftware（http://perceus.org）を使用して共有/homeセットアップを行っています。ノードはCentOS6.1x86_64を使用しています。/ homeは、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)

これが各ノードの/etc/ fstabです（すべて同じ）。

...
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は、同一のUID：GIDを持つヘッド/マスターのコピーです。

次の方法を使用してキーペアを作成しました。

$ 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

ここに問題があります。 各ノードにSSHで接続しようとすると、「接続が閉じられました」というエラーが発生します。これがデバッグ出力です。

$ 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

/ etc / ssh / sshd_configがキーベースの認証を許可していることを確認しています（PubkeyAuthenticationはい）。/ home（ノードにマウントされた後）の権限が正しいことを確認しました。ユーザーは適切に認証されます。「no_all_squash」を使用して、または使用せずにnfsをマウントして、nfs、rpcidmap、rpcbind、およびnfslockを再起動してみました。

別のマスター/ヘッドノードを持つノードにインストールされたCentOS5でこれを動作させました。CentOS6は、これに関して私に追加の問題を与えているようです。

キーを作成しない場合は、もちろんパスワードの入力を求められます。

私のhosts.allow/denyは、クライアントとサーバーの両方で空です。

rootユーザーは接続できます。Perceusは、仮想ファイルシステムの一部であるため、rootユーザーのキー生成を処理します。キーの生成に問題があると思いますが、何が問題なのかわかりません。

4

6 に答える 6

13

正しい解決策は、セキュリティ上の問題を隠している可能性があるため、pam の使用を無効にするのではなく、問題を修正することです。

PAM がいくつかのチェックに失敗してユーザーのログインを拒否しているため、ssh が失敗しています。/etc/pam.d/sshd使用しているルールと失敗している可能性のあるルールを確認します。

最も一般的な問題は、ユーザーがパスワードを持っていないことです ( を と比較する/etc/passwdか、とを調べて、ユーザーと認証がどこから来ている/etc/shadowかを確認してください) だけでなく、ホーム ディレクトリがない、追加の認証構成が欠落している、UID が低すぎるか高すぎる、などもあります。/etc/nsswitch/etc/pam.d/*

パスワードが見つからない場合は、少なくとも/etc/ssh/sshd_config

PermitEmptyPasswords no

これにより ssh がブロックされ、ユーザーがパスワードなしでログインできるようになります (ただし、telnet、ftp、http、login などの他のプロトコルには何もしません)。

于 2013-01-20T02:22:53.227 に答える
4

解決：

以下のアドバイスに従って/var/log/security、ノード（ホスト）を確認しました。それは示しました：

fatal: Access denied for user user by PAM account configuration

次に、変更を編集しました/etc/ssh/sshd_config：

UsePAM yes

に

UsePAM no

ノードを再起動すると、パスワードなしのログインを実行できるようになりました。

ありがとう！

于 2012-04-11T14:14:55.287 に答える
1

パスワードなしの認証を使用するのはよくありません。selinux はこれらのサーバーでオンになっていますか? はいの場合は、selinux をオフにするか、「restorecon -R -v /home/user/」でデフォルトの selinux ポリシーを復元する必要があります。 これは既知の問題です。

于 2013-07-31T19:20:11.480 に答える
1

私はあなたと非常によく似た問題を抱えていました。

NFS私の問題、そしておそらくあなたの問題は、私のホームディレクトリがマウントであり、selinux（CentOS 7では）いくつかのエラーが発生していたために発生したことが判明しました（追跡するのは非常に困難でした）。しかし、修正は簡単でした。

setsebool -P use_nfs_home_dirs 1
于 2016-09-26T13:57:38.077 に答える
0

私の場合、useradd を使用してユーザーを作成していません。代わりに、/etc/passwd ファイルにユーザーを追加し、必要なすべてのファイルを含むユーザーのホーム ディレクトリを作成しました。

useradd を使用してユーザーを作成し、ユーザーのホーム ディレクトリに .ssh ディレクトリを作成した後、pub キーを authorized_keys ファイルに追加すると、問題は解決しました。

ちなみに私はcentos7を使っています

これが誰かに役立つことを願っています。

于 2015-04-27T18:09:38.863 に答える
0

私の場合、pam.d ファイルが破損していました。同様のサーバーから新しいセットをコピーしたところ、すべて正常に戻りました。特定の破損を探すのに時間はかかりませんでしたが、将来誰かがこれを読んでさらにアイデアが必要になった場合に備えて、2ビットを追加すると思いました.

于 2016-01-06T17:45:00.737 に答える