Máy chủ OpenSSH từ chối chấp nhận xác thực khóa


13

Tôi đã cố gắng sử dụng xác thực khóa công khai trên máy chủ mới của mình và tôi đã gặp phải vấn đề này.

$ ssh -v -i .ssh/server 192.168.1.100
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data .ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file .ssh/server type -1
debug1: identity file .ssh/server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
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 '192.168.1.100' is known and matches the RSA host key.
debug1: Found key in .ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/server
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

và sau đó tôi phải nhập mật khẩu của mình để đăng nhập.

Nhưng, nếu tôi đã có một phiên được kết nối với máy chủ đó (được kết nối bằng mật khẩu), thì kết nối sau sẽ sử dụng khóa auth để tránh nhập mật khẩu.

Nếu không có kết nối SSH nào được thiết lập, tôi không thể kết nối mà không có mật khẩu đầu vào.

Điều này thực sự kỳ lạ với tôi, tôi đã kiểm tra MD5 /usr/sbin/sshdgiữa máy chủ mới và máy chủ bình thường khác, nó giống nhau. Sau đó, tôi chỉ sao chép /etc/ssh/sshd_configtừ máy chủ bình thường khác sang máy chủ mới và chạy service ssh restart. Vấn đề vẫn còn tồn tại.

Làm thế nào tôi có thể sửa chữa điều này?

Câu trả lời:


10

Kiểm tra xem .sshthư mục của bạn và các tệp bên trong nó trên máy khách chỉ có thể đọc được bởi chủ sở hữu ( chmod -R 600 .ssh) và chủ sở hữu có đúng với thư mục và tệp không (sử dụng chownlệnh nếu cần).

Đồng thời kiểm tra authorized_keysthư mục và tệp trên máy chủ (có thể trong /root/.sshhoặc thư mục chính của người dùng đang cố đăng nhập) để đảm bảo quyền và chủ sở hữu của họ được đặt theo cùng một cách.


Chỉnh sửa: dựa trên nhiều phản hồi hơn (và một số phỏng đoán!) - bạn có thể kiểm tra /etc/ssh/sshd_configvà xem liệu tham số sau có được đặt như bên dưới không. Nếu không, hãy thử chỉnh sửa nó.

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Lưu ý, điều này giả sử bạn không đăng nhập từ xa bằng root


.ssh của tôi là 700 và các tệp trong .ssh là 600 và tôi đã kiểm tra lại ~ / .ssh / ủy quyền trong máy từ xa. Thiết lập khóa công khai auth là việc đầu tiên tôi làm sau khi cài đặt hệ thống, do đó không có khả năng bị làm rối bởi hoạt động khác. btw, vấn đề vẫn còn ..
lxyu

OK - Tôi đang thêm một cái gì đó vào câu trả lời của tôi dựa trên điều này.
Linker3000

có một dòng "#AuthorizedKeysFile% h / .ssh / ủy quyền". Tôi đã thử nhận xét nó, nhưng không có ích gì .. btw, cùng '/ usr / sbin / sshd' với cùng 'sshd_config', chúng hoạt động khác nhau như thế nào?
lxyu

Cuối cùng tôi đã cài đặt lại Ubuntu, sau đó tôi thiết lập máy chủ openssh sau một phút và nó hoạt động tốt ... Vẫn không biết có chuyện gì. :(
lxyu

Đôi khi rất khó để tìm ra vấn đề. Tôi đã từng viết sai chính thức ủy quyền là auhorized_keys. Tôi cần khoảng một giờ để khắc phục sự cố này. Bạn đã nhìn thấy sai lầm? Nó thực sự là khó khăn! :-)
nalply

4

Tôi đã sửa trường hợp lỗi này bằng cách xóa id_rsa.pubkhỏi .ssh.

Tôi đã sao chép id_rsatừ một máy khác và phân phối nó trên một số khách hàng giả. Do đó, id_rsaid_rsa.pubthực sự là các khóa khác nhau ngăn cản việc sử dụng id_rsahoàn toàn.

Không có thông báo lỗi để chỉ rõ điều này mặc dù. Tôi đã tìm ra nó một cách tình cờ, cố gắng đưa các máy khác nhau vào trạng thái giống hệt nhau.


3

Từ phát hiện của tôi, sự cho phép ít nhất của giám đốc nhà của mục tiêu là 750 . Nếu bit của thế giới là không 0, nó sẽ không hoạt động.

Ví dụ. cho thư mục gốc:

drwxr-x--- 3 root root 4096 Jul 20 11:57 root

Tiếp theo là /root/.ssh

drwx------  2 root root  4096 Jul 17 03:28 .ssh

Sau đó /root/.ssh/authorized_keys

-rw------- 1 root root 1179 Jul 17 03:28 authorized_keys

3

Trong trường hợp của tôi, các quyền trên thư mục chính là 775 thay vì 0755hoặc thấp hơn.

Toàn bộ đường dẫn đến tệp ủy quyền, tức là /home/user/.ssh/phải 0755hoặc thấp hơn.


CẢM ƠN BẠN Điều này vừa được đọc về một cơn đau đầu tôi đã có một tuần nay. Hầu hết mọi người chỉ đề cập đến thư mục .ssh (700) và ủy quyền_key (600)
Jonathan Komar

2

Sau khi gặp nhiều rắc rối, tôi đã có được giải pháp cho vấn đề:

Thư mục chính của người dùng không được phép 777hoặc thế giới có thể ghi. Nếu đúng như vậy, xác minh khóa SSH sẽ thất bại và bạn phải đặt mật khẩu để đăng nhập.


1

Chỉ cần đảm bảo tài khoản bạn đang cố gắng ssh đến là người dùng có mật khẩu trên máy chủ từ xa. Tôi chỉ đập đầu vào tường trong nửa giờ trước khi tìm thấy câu trả lời này tại đây: /programming//a/14421105/758174


1

Nếu dòng của bạn /etc/ssh/sshd_configchưa được bình luận, thì cấu hình SSH của bạn chỉ cho phép một danh sách người dùng cố định ssh vào hệ thống và bạn cần thêm bất kỳ tài khoản mới nào vào danh sách:

AllowUsers root user1 user2 user3

Bất kỳ người dùng nào khác ngoài những người được liệt kê ở trên đang cố gắng đăng nhập qua SSH sẽ nhận được thông báo lỗi khó hiểu này:

Roaming not allowed by server

0

Tôi phát hiện ra rằng sau khi thay đổi tên người dùng và nhóm (nhưng không phải ID) /etc/passwd/etc/groupquên thay đổi cho /etc/shadowphù hợp, tôi nhận được thông báo "Không cho phép chuyển vùng".

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.