"Kết nối được đóng bởi [HOST IP]" bằng cách sử dụng xác thực khóa dsa

Question

Tôi có thiết lập chung/nhà sử dụng Phần mềm cụm Perceus (http://perceus.org) cho Cụm của chúng tôi. Các nút đang sử dụng CentOS 6.1 x86_64. /home được chia sẻ từ đầu đến các nút bởi 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) 

Đây là/etc/fstab trên mỗi nút (tất cả giống nhau).

... 
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 trên các nút là bản sao của chủ/đầu có cùng UID: GID.

Tôi đã tạo ra cặp khóa bằng cách sử dụng phương pháp sau đây:

$ 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 

Dưới đây là vấn đề.Khi tôi cố gắng ssh vào mỗi nút, tôi nhận được lỗi "Đã kết nối". Đây là đầu ra gỡ lỗi.

$ 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 

Tôi đảm bảo rằng/etc/ssh/sshd_config cho phép xác thực dựa trên khóa (PubkeyAuthentication yes). Tôi đã đảm bảo rằng các quyền trên/home (một lần được gắn trên các nút) là chính xác. Người dùng được xác thực chính xác. Tôi đã thử nfs gắn với và không có "no_all_squash" khởi động lại nfs, rpcidmap, rpcbind và nfslock.

Tôi đã làm việc này với CentOS5 được cài đặt trên các nút có nút chính/đầu khác. CentOS6 dường như đã cho tôi thêm vấn đề với điều này.

Nếu tôi không tạo khóa, tất nhiên tôi được nhắc nhập mật khẩu.

Hosts.allow/từ chối của tôi trống trên cả khách hàng và máy chủ.

Người dùng root có thể kết nối. Perceus xử lý việc tạo khóa cho người dùng root vì nó là một phần của hệ thống tệp ảo. Tôi đoán rằng có điều gì đó sai trái với việc tạo ra chìa khóa của tôi nhưng tôi không thể tìm ra vấn đề là gì.

Answer 1

SOLUTION:

Tiếp theo những lời khuyên dưới đây tôi đã kiểm tra /var/log/security vào nút (host). Nó cho thấy:

fatal: Access denied for user user by PAM account configuration 

sau đó tôi thay đổi nội dung /etc/ssh/sshd_config thay đổi:

UsePAM yes 

để

UsePAM no 

Khởi động lại nút và bây giờ tôi có thể thực hiện đăng nhập bằng mật khẩu ít hơn.

Cảm ơn!

Answer 2

Giải pháp chính xác là khắc phục sự cố, không tắt tính năng sử dụng pam, vì bạn có thể đang ẩn vấn đề bảo mật.

ssh không thành công vì PAM đang từ chối đăng nhập người dùng bằng cách không thực hiện kiểm tra. Xác minh /etc/pam.d/sshd cho những quy tắc nào bạn có và những gì có thể không thành công.

vấn đề

phổ biến nhất là một người sử dụng mà không cần mật khẩu (so sánh /etc/passwd với /etc/shadow, hoặc kiểm tra của bạn /etc/nsswitch và /etc/pam.d/* để xem nơi người sử dụng và auth đến từ), nhưng cũng không có thư mục home, thiếu một số thêm cấu hình auth, UID quá thấp hoặc quá cao, vv

Nếu mật khẩu bị mất tích của nó, ít nhất là đảm bảo với bạn điều này trong /etc/ssh/sshd_config

PermitEmptyPasswords no 

này khối ssh để cho phép đăng nhập vào người sử dụng mà không cần mật khẩu (nhưng không làm gì để khác giao thức, li ke telnet, ftp, http và đăng nhập).

Answer 3

Không tốt để sử dụng ủy quyền không có mật khẩu. Selinux có bật các máy chủ đó không? Nếu có, thì bạn có một trong hai để tắt selinux, hoặc khôi phục lại các chính sách selinux mặc định bằng cách "restorecon -R -v/home/user /. This is a known issue

Answer 4

Trong trường hợp của tôi, tôi thiên đường không được tạo ra cho người dùng sử dụng useradd, thay vì tôi đã thêm người dùng vào tệp/etc/passwd và tạo thư mục chính cho người dùng với tất cả các tệp được yêu cầu

Sau khi sử dụng useradd để tạo người dùng và thêm khóa pub vào tệp authorized_keys sau khi tạo thư mục .ssh các thư mục chính của người sử dụng, vấn đề này đã được giải quyết.

Bằng cách này tôi đang sử dụng centos 7

0.123.

Hy vọng điều này sẽ giúp một số.

Answer 5

Đối với tôi, tôi đã có tệp pam.d bị hỏng. Tôi đã sao chép trong một bộ mới từ một máy chủ tương tự và tất cả đều tốt. Tôi đã không dành thời gian để tìm kiếm các tham nhũng cụ thể, nhưng tôi nghĩ rằng tôi sẽ thêm 2 bit của tôi trong trường hợp bất cứ ai đọc điều này trong tương lai và cần thêm một số ý tưởng.

Answer 6

Tôi gặp sự cố rất giống với vấn đề của bạn.

Hóa ra vấn đề của tôi, và có thể là của bạn, được gây ra bởi vì thư mục home của tôi là một gắn kết NFS, và selinux (trên CentOS 7) đã được ném lên một số lỗi (mà là khá khó khăn để theo dõi). Việc sửa chữa là đơn giản mặc dù.

setsebool -P use_nfs_home_dirs 1