Không thể xác thực khóa công khai SSH để hoạt động [đã đóng]

Máy chủ của tôi đang chạy CentOS 5.3. Tôi đang dùng Mac chạy Leopard. Tôi không biết ai chịu trách nhiệm cho việc này:

Tôi có thể đăng nhập vào máy chủ của mình tốt thông qua xác thực mật khẩu. Tôi đã trải qua tất cả các bước để thiết lập PKA (như được mô tả tại http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html ), nhưng khi Tôi sử dụng SSH, nó từ chối thậm chí thử xác minh khóa công khai. Sử dụng lệnh

ssh -vvv user@host

(trong đó -vvv điều chỉnh mức độ chi tiết đến mức tối đa) Tôi nhận được kết quả đầu ra có liên quan sau:

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

theo sau là một dấu nhắc cho mật khẩu của tôi. Nếu tôi cố gắng buộc vấn đề với

ssh -vvv -o PreferredAuthentications=publickey user@host

tôi có

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.

Vì vậy, mặc dù máy chủ cho biết họ chấp nhận phương thức xác thực khóa công khai và ứng dụng khách SSH của tôi vẫn khăng khăng, tôi đã từ chối. (Lưu ý sự vắng mặt dễ thấy của dòng "Cung cấp khóa công khai:" ở trên.) Bạn có đề xuất nào không?

Kiểm tra xem máy Centos của bạn có:

RSAAuthentication yes
PubkeyAuthentication yes

trong sshd_config

và đảm bảo rằng bạn có sự cho phép thích hợp trên thư mục ~ / .ssh / của máy centos.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

nên làm thủ thuật.

Tôi gặp vấn đề tương tự - PC từ xa không thể sử dụng xác thực khóa chung để đăng nhập vào máy chủ CentOs 6. Vấn đề trong trường hợp của tôi là liên quan đến SELinux - thư mục chính của người dùng đang cố đăng nhập có thông báo bối cảnh bảo mật. Tôi đã giải quyết điều này bằng cách sử dụng restoreconcông cụ này:

restorecon -Rv /home

1- kiểm tra / etc / ssh / sshd_config, đảm bảo bạn có

RSAAuthentication có
PubkeyAuthentication có

2- kiểm tra nhật ký an toàn từ máy từ xa, tra cứu nhật ký lỗi sshd daemon. ví dụ trong Ubuntu của tôi

# grep 'sshd' / var / log / safe | grep 'Xác thực bị từ chối' | đuôi -5
Ngày 4 tháng 8 06:20:22 xxx sshd [16860]: Từ chối xác thực: quyền sở hữu xấu hoặc chế độ cho thư mục / home / xxx
Ngày 4 tháng 8 06:20:22 xxx sshd [16860]: Từ chối xác thực: quyền sở hữu xấu hoặc chế độ cho thư mục / home / xxx
Ngày 4 tháng 8 06:21:21 xxx sshd [17028]: Xác thực bị từ chối: quyền sở hữu hoặc chế độ xấu cho thư mục / home / xxx
Ngày 4 tháng 8 06:21:21 xxx sshd [17028]: Xác thực bị từ chối: quyền sở hữu hoặc chế độ xấu cho thư mục / home / xxx
Ngày 4 tháng 8 06:27:39 xxx sshd [20362]: Xác thực bị từ chối: quyền sở hữu hoặc chế độ xấu cho thư mục / home / xxx

Sau đó kiểm tra quyền sở hữu và chế độ cho thư mục / home / xxx, có thể bạn cần chạy cái này

chmod 755 / nhà / xxx

Kiểm tra kỹ xem các quyền của bạn có đúng không và cấu trúc tệp (cụ thể là chính tả) là chính xác, cho cả máy cục bộ và máy từ xa. URL bạn đề cập đến tất cả chúng, nhưng nó đáng để kiểm tra xem những gì bạn có phù hợp. Thông thường các quyền sẽ ném một lỗi có liên quan mặc dù.

Bạn đã kiểm tra xem sshd_config trên hộp CentOS 5.3 của bạn có được đặt để cho phép PubkeyAuthentication hoặc RSAAuthentication không?

Kiểm tra nhật ký máy chủ SSH trên hệ thống CentOS - nó có thể cung cấp thêm thông tin. Tôi không chắc liệu CentOS có kiểm tra khóa ssh trong danh sách đen hay không, nhưng tôi đã thấy các từ chối ssh công khai tương đối im lặng cho đến khi đầu ra -vvv đi, nhưng các nhật ký đã giải thích rõ ràng những gì đang diễn ra

Hiểu rồi! Hóa ra đó là một vấn đề phía khách hàng. (Tôi nghĩ rằng bất kỳ sự cố nào phía máy chủ sẽ mang lại đầu ra gỡ lỗi hữu ích hơn.) Vì những lý do mà tôi không biết, trên máy Mac của tôi, tệp / etc / ssh_config có dòng

PubkeyAuthentication = no

Tôi nhận xét rằng một dòng, và bây giờ mọi thứ hoạt động tốt.

Bên cạnh các chế độ của tập tin / thư mục, đảm bảo rằng quyền sở hữu là chính xác! Người dùng phải sở hữu thư mục nhà riêng, .ssh / và các tệp trong đó.

Tôi đã phải chạy chown -R $user:$user /home/$userđể vượt qua thất bại ssh của tôi.

Đồng thời kiểm tra xem nó có thể tự động cung cấp khóa hay không, sử dụng -i path / to / key nếu không hoặc chỉ để kiểm tra

Âm thanh như một vấn đề cấu hình với tôi. Giống như Daniel đề nghị có hai điều cần kiểm tra:

1. Các khóa SSH $HOME/.ssh/authorized_keyscó thể đọc được; và
2. SSHd được cấu hình để cho phép đăng nhập khóa công khai.

Kiểm tra tên người dùng với những gì bạn đang cố gắng đăng nhập. Theo mặc định, đó là tên người dùng của bạn trên máy cục bộ.

Đầu ra của máy khách như trong ssh -vsẽ tiết lộ rằng có một vấn đề tại một bước nhất định trong giao thức, nhưng khi đó là do một cái gì đó trên máy chủ, máy khách sẽ không được thông báo về nguyên nhân. Kiểm tra các tệp nhật ký máy chủ để tìm hiểu những gì sai. Bạn có thể cần phải rootcó quyền để làm như vậy. Ví dụ: đối với sshdcấu hình để đăng nhập vào syslog, bạn có thể tìm thấy các thông báo trong /var/log/secure. Giống như những người này:

Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys

Lý do trong trường hợp này là một (ngu ngốc) mặc định defaultcủa 0002. Điều đó có nghĩa là, viết quyền truy cập cho nhóm. (Groupname = tên người dùng, nhưng vẫn.) Trình nền SSH sẽ không tin tưởng các tệp có thể bị người khác giả mạo hơn người dùng ( rootdĩ nhiên , và , tất nhiên). Bạn có thể giải quyết vấn đề bằng cách sử dụng chmod.

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file

tôi vừa bị mắc kẹt trong cùng một vấn đề truy cập với lõi fedora 16 đến xu 5,5

các bản ghi và verbose trông giống hệt nhau

vấn đề là khóa công khai, nó có một số dữ liệu không có thật, tạo lại nó và đăng nó trong sshd_server, bạn sshd_client đang gửi thông tin khóa nhưng không được máy chủ nhận ra (nó không khớp với bất kỳ khóa nào trong ủy quyền)

Một người khác bị cắn bởi điều này. Sau một hồi tìm kiếm, hóa ra tôi đã cho ssh khóa công khai (với tùy chọn -i) thay vì khóa riêng. Đừng!