Đang cố gắng SSH vào máy tính từ xa nhưng vẫn hỏi mật khẩu


18

Đang cố gắng SSH vào máy tính từ xa nhưng vẫn hỏi mật khẩu.

Tôi có một số máy tính chạy SElinux và chỉ một trong số đó là cho tôi một thời gian khó khăn khi sử dụng ssh mà không có mật khẩu.

Tôi đã thực hiện một ssh-copy-id và tôi có thể thấy khóa của mình trong .ssh / ủy quyền.

Tôi chmod 700 .ssh và chmod 600 tất cả các tệp trong ./ssh/*

Nếu tôi làm một ssh -v thì đây là đầu ra của tôi:

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to wcmisdlin05 [10.52.208.224] port 22.
debug1: Connection established.
debug1: identity file /home/jsmith/.ssh/identity type -1
debug1: identity file /home/jsmith/.ssh/id_rsa type 1
debug1: identity file /home/jsmith/.ssh/id_dsa type -1
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
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'wcmisdlin05' is known and matches the RSA host key.
debug1: Found key in /home/jsmith/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: /home/jsmith/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/jsmith/.ssh/identity
debug1: Trying private key: /home/jsmith/.ssh/id_dsa
debug1: Next authentication method: password

Ai đó có thể vui lòng cho tôi biết tại sao nó không hoạt động trên một máy tính từ xa này không?


5
Nhìn vào /var/log/secure(nếu đó là quyền) & /var/log/messages(nếu đó là TỰ ĐỘNG.) Mặt khác, đó là sự không phù hợp giữa những gì trong ~/.ssh/authorized_keysvà những gì được gửi bởi máy khách SSH.
Aaron Copley

Câu trả lời:


17

Tôi thường gặp một lỗi tương tự trên các máy CentOS 6 liên quan ssh-copy-idvà SELinux.

Khi ssh-copy-idtạo các tệp khóa được ủy quyền, nó tạo ra nó với các quyền thích hợp, nhưng với nhãn SELinux sai. Cách khắc phục cho việc này là khôi phục các nhãn về mặc định chính sách của chúng bằng lệnh này:

restorecon -R ~/.ssh


1
Câu trả lời tốt. Nhưng đối với một người mới sử dụng SELinux, sẽ rất thú vị khi biết cách kiểm tra danh sách và kiểm tra các quyền.
zrajm

14

Những thứ này luôn được gỡ lỗi dễ dàng hơn nhiều từ phía máy chủ, nếu có thể. Nếu bạn có thể bắt đầu một sshd trên một cổng khác trong chế độ gỡ lỗi, nó sẽ cho bạn biết ngay lập tức tại sao khóa bị từ chối (tôi đoán là thư mục chính của bạn có thể ghi nhóm). Ví dụ, bạn có thể bắt đầu một sshd trong chế độ gỡ lỗi trên cổng 2222 /usr/sbin/sshd -d -p 2222, sau đó kết nối với ssh -p 2222 user@remotehost.


4
Cảm ơn rất nhiều cho dự đoán hoang dã của bạn (thư mục nhà là nhóm có thể ghi). Đó chính xác là trường hợp của tôi.
Sergei Kurenkov

@skwllsp - vui lòng chấp nhận câu trả lời này nếu đó là câu trả lời đúng cho trường hợp của bạn.
Deer Hunter

1
@Deer Hunter, Câu hỏi đã được hỏi bởi một người khác, không phải tôi. Tôi không thể chấp nhận câu trả lời này.
Sergei Kurenkov

@skwllsp - một khoảnh khắc cao cấp từ tôi, xin lỗi.
Deer Hunter

chmod 744 vào thư mục nhà của tôi đã giải quyết nó - nó có liên quan đến câu trả lời này, cảm ơn!
Brandt Solovij

3

Người đăng bài đề cập đến SElinux đã đâm đầu vào vấn đề của tôi, tôi không muốn sử dụng selinux nhưng đã quên vô hiệu hóa nó và máy chủ đã đưa ra chế độ selinux khi khởi động.

ssh -vGỡ lỗi giúp. Chìa khóa được chấp nhận:

debug1: Found key in /var/lib/amanda/.ssh/known_hosts:19
debug1: ssh_rsa_verify: signature correct

Và sau đó tôi nhận được lỗi

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

Cách khắc phục của tôi là tắt selinux setenforce 0và sau đó vô hiệu hóa trong / etc / selinux. Sau đó ssh đăng nhập mật khẩu làm việc cho tôi.


1

Tôi đã trải nghiệm điều này cách đây một thời gian trên RHEL5 (Tôi không biết đây có phải là bản phân phối bạn đang sử dụng không) và thấy rằng đó chỉ là khi tôi sử dụng ssh-copy-id. Hãy thử quét tệp chính vào thư mục chính xác và tất nhiên là đặt lại quyền


0

Trong trường hợp của tôi, vấn đề là ở định dạng authorized_keystệp không chính xác .

Nên có không xuống dòng ở giữa định nghĩa định dạng ( ssh-rss, ssh-dss, ..) và khóa công khai của chính nó.


0

Tôi đã gặp rắc rối trước đó với ssh và keyfiles. Nhân dịp đó, đổi tên khóa id của tôi thành " id_rsa" đã giúp. Thật không may, tôi có các khóa khác nhau cho các máy chủ khác nhau. Vì vậy, cách tiếp cận đó có một hữu ích hạn chế. Nó có thể giúp một lần.

Thứ hai, hôm nay tôi lại gặp lỗi này chỉ trong một phiên XTerm và mọi thứ hoạt động rất tốt trong 6 phiên xterm khác cho cùng một máy chủ / máy vòi. Vì vậy, tôi so sánh đầu ra của tôi từ envtrong cả hai phiên. Tôi thấy đây là phiên làm việc vắng mặt trong phiên không làm việc:

SSH_AUTH_SOCK=/run/user/1001/keyring/ssh 

Tôi đã dán nhiệm vụ đó vào phiên không làm việc:

export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
ssh  user@host
... Welcome ...

Nói cách khác, giải pháp đó đã làm việc cho tôi.

Tôi đã kiểm tra một chút trên SSH_AUTH_SOCKET. Từ câu trả lời này:

đường dẫn của ổ cắm tệp unix mà tác nhân sử dụng để liên lạc với các tiến trình khác

Tôi đoán điều này rất cần thiết cho độ phân giải chính dựa trên kết quả.


-1

debug1: Cung cấp khóa công khai: /home/jsmith/.ssh/id_ rsa

...

debug1: Đang thử khóa riêng: /home/jsmith/.ssh/id_ dsa

Dường như với tôi rằng khóa riêng / công khai chỉ không khớp. Tên khóa cho chúng ta biết rằng khóa chung là khóa RSA và khóa riêng là DSA.

Cố gắng tạo một cặp mới và scpkhóa chung cho máy chủ.


người ta có thể xác minh đây thực sự là trường hợp bằng cách so sánh dấu vân tay của hai phím với ssh-keygen -l -f ~/.ssh/id_rsa' and ssh-keygen -l -f ~ / .ssh / id_rsa.pub`. Tuy nhiên, tôi không tin rằng nó thậm chí sẽ cung cấp chìa khóa nếu có sự không phù hợp. Tôi nghĩ rằng nó chỉ là một người đang bị máy chủ từ chối vì một lý do chưa được xác định, vì vậy nó cố gắng khác.
hầm

-2

Tôi khuyên bạn nên kiểm tra các cơ quan có thẩm quyền trên ./ssh và thư mục nhà của người dùng, trên tệp chính và trên tệp ủy quyền, vì không ai khác nên chủ sở hữu nên được phép viết và đọc ở đó nếu bạn muốn kết nối mật khẩu ssh hoạt động. Điều đó liên quan đến cả máy nguồn và máy đích. Thành thật mà nói, đôi khi nó hoạt động ngay cả khi có quyền lớn hơn, nhưng nó không nên.


1
Vui lòng kiểm tra: serverfault.com/questions/464411/ . Bài viết của bạn cũng dư thừa, vì bạn chưa đọc những gì người khác đã viết.
Deer Hunter
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.