ssh không còn cho phép xác thực khóa công khai


22

Máy của tôi gần đây đã ngừng chấp nhận xác thực khóa công khai. Tôi có một máy tính để bàn Ubuntu 11.04 mà tôi ssh vào từ một máy tính windows. Tôi sử dụng putty với cuộc thi. Tôi có thể kết nối nhưng chỉ với xác thực mật khẩu tương tác, không phải bằng khóa rsa mà tôi đã thiết lập.

Tôi đã xác minh rằng khóa được liệt kê trong ~ / .ssh / ủy quyền. Làm thế nào để tôi sửa lỗi này và tôi phải kiểm tra cái gì?


2
Kiểm tra đầu tiên mà cả ba ~, ~/.ssh~/.ssh/authorized_keyschỉ có thể ghi bởi bạn (đặc biệt là không có nhóm quyền ghi). Tìm kiếm /var/log/auth.logcác mục nhật ký được tạo tại thời điểm đăng nhập của bạn. Sao chép-dán chúng vào câu hỏi của bạn (chỉnh sửa tên cho riêng tư nếu bạn muốn). Ngoài ra, hãy kiểm tra xem sự cố có hoàn toàn ở phía máy chủ hay không: sao chép khóa riêng sang máy Linux (bạn sẽ cần chuyển đổi tệp khóa riêng của PuTTY sang định dạng OpenSSH) và xem có ssh localhosthoạt động không.
Gilles 'SO- ngừng trở nên xấu xa'

thư mục nhà của tôi là có thể ghi được vì một số lý do. Điều đó đã sửa nó. Đặt nó như một câu trả lời để tôi có thể chấp nhận nó.
Andrew Redd

Câu trả lời:


28

Nếu xác thực khóa chung không hoạt động: đảm bảo rằng ở phía máy chủ, thư mục chính của bạn ( ~), ~/.sshthư mục và ~/.ssh/authorized_keystệp, tất cả chỉ có thể ghi được bởi chủ sở hữu của chúng . Cụ thể, không ai trong số họ phải có thể ghi được bởi nhóm (ngay cả khi người dùng ở một mình trong nhóm). chmod 755hoặc chmod 700là ok, chmod 770là không.

Kiểm tra những gì khi có lỗi:

  • Chạy ssh -vvvđể xem rất nhiều đầu ra gỡ lỗi. Nếu bạn đăng câu hỏi hỏi tại sao bạn không thể kết nối với ssh, hãy bao gồm đầu ra này (bạn có thể muốn ẩn danh tên máy chủ và tên người dùng).
  • Nếu bạn có thể, hãy kiểm tra máy chủ đăng nhập /var/log/auth.log.
  • Nếu xác thực khóa chung không hoạt động, hãy kiểm tra lại các quyền, đặc biệt là bit nhóm (xem bên trên).

(từ wiki thẻ U & L , được sao chép sang AU )
Gilles 'SO- ngừng trở nên xấu xa'

1
Câu trả lời tốt đẹp! Tôi đã quên homedir của mình: o
RobAu

Nếu bạn đang chạy phiên bản gần đây của ssh (hoặc sshd), các khóa DSA không còn được hỗ trợ theo mặc định vì các vấn đề bảo mật. Cách khắc phục thực sự duy nhất là nâng cấp lên RSA hoặc các khóa tốt hơn.
Mikko Rantalainen

Tôi đã thay đổi quyền của thư mục nhà của tôi và những gì? Tôi đã bị khóa khỏi SSH! Tôi đã thay đổi các phím ssh, không, máy chủ vẫn từ chối kết nối! Tôi đã điên khi cố gắng tìm một giải pháp và với câu trả lời của bạn về chmod 700 vào thư mục nhà của tôi, ssh bắt đầu làm việc !!!!!!! Cảm ơn! Nếu kết nối đầu cuối của tôi bị rớt trong khi cố gắng tìm giải pháp, tôi sẽ hoàn toàn bị khóa khỏi máy chủ. Vì vậy, hãy cẩn thận không chơi với quyền thư mục nhà của bạn! (Tôi vừa thay đổi quyền thư mục nhà của mình, không phải thư mục .ssh nhưng vẫn bị khóa khỏi SSH)
Tarik


5

Nếu bạn kiểm tra các quyền trên các thư mục và có dấu "." ngay sau họ, sau đó bạn có thể đã bật selinux, điều này sẽ gây rối với trao đổi khóa và mặc định là nhận dạng mật khẩu thủ công.

Bạn có thể vô hiệu hóa SELinux để khắc phục sự cố bằng cách làm theo các hướng dẫn tại đây: http://www.centos.org/docs/5/html/5.1/Deployment_Guide/sec-sel-enable-disable-enfor thi.html hoặc chỉ chỉnh sửa / etc / selinux / config tập tin và thay đổi nó từ "thi hành" thành "bị vô hiệu hóa".

Hi vọng điêu nay co ich.


Tôi đã bật selinux, nhưng vô hiệu hóa nó dường như không sửa được. Bí quyết cho tôi là chmod 600 ~/.ssh/authorized_keys- tập tin có thể ghi theo nhóm. (thông qua pyrosoft.co.uk/blog/2013/01/12/ khăn )
David Carboni

Điều này đã giúp tôi! Cảm ơn bạn!
907

Bạn cũng có thể để xác thực SSH hoạt động với SELinux bằng cách đặt bối cảnh SELinux chính xác. Khôi phục bối cảnh được cấu hình hệ thống trên thư mục chính của bạn ( restorecon ~ -R) là điểm khởi đầu tốt.
Josh Kelley

4

Tôi sẽ đảm bảo rằng bạn có các cài đặt của mình trong / etc / ssh / sshd_config.

Để buộc chỉ sử dụng PKI và không cho phép mật khẩu, hãy tìm dòng

#PasswordAuthentication yes 

trong tập tin của bạn, bỏ ghi chú và đặt nó thành

PasswordAuthenticate no

Tôi cũng sẽ đọc qua sự cân bằng của các cài đặt để đảm bảo chúng có ý nghĩa. Cụ thể, hãy cố gắng đảm bảo rằng bạn sử dụng các khóa RSA vì DSA được biết là bị xâm phạm.


11
Bạn đang giải thích cách vô hiệu hóa xác thực mật khẩu. Điều này sẽ không giúp làm cho xác thực khóa công khai hoạt động (khóa công khai được thử trước tiên). Andrew: không tắt xác thực mật khẩu cho đến khi bạn chắc chắn xác thực khóa công khai hoạt động!
Gilles 'SO- ngừng trở nên xấu xa'

2

Một nguyên nhân có thể của vấn đề là bạn có khóa DSA nhưng hiện tại SSH (rõ ràng) mặc định yêu cầu khóa RSA. Tôi gặp vấn đề khi nâng cấp lên 16.04. Bạn có thể xem thêm ở đây nhưng câu trả lời ngắn gọn là thêm vào như sau ~/.ssh/config:

PubkeyAcceptedKeyTypes ssh-dss

1

Tôi đã khắc phục sự cố này bằng cách bỏ bình luận "Mật khẩu xác thực có" trong / etc / ssh / sshd_config.


1

Do nhu cầu xử lý sự cố liên lạc giữa hai máy khác nhau, tôi có hai khóa riêng ở ~/.sshphía máy khách.

Thay vì định cấu hình mỗi máy chủ lưu trữ với khóa riêng tương ứng ~/.ssh/identitynhư tôi nên làm, tôi đã có khóa phụ (và trong trường hợp này là sai) được cấu hình cho tất cả các máy chủ:

Host *
IdentityFile ~/.ssh/identity_b

Sửa lỗi đã ~/.ssh/identitygiải quyết:

Host a
IdentityFile ~/.ssh/identity_a
Host b
IdentityFile ~/.ssh/identity_b

0

Tôi chỉ gặp vấn đề tương tự nhưng thay đổi quyền chmodkhông giúp được gì, vì hóa ra tôi không có quyền sở hữu ~/.ssh/authorized_keystệp. Bạn có thể thay đổi quyền sở hữu của .sshthư mục với:

sudo chown -R "$USER" ~/.ssh

-1

Bằng cách nào đó, điều này làm việc cho tôi:

root @ kaiser: ~ # vim / etc / ssh / sshd_config

Thay đổi dòng này từ có thành không 28 StrictModes no

Thử lại

sysadmin @ suselinux1: ~> con sysadmin kaiser Chào mừng bạn đến với Ubuntu 12.04.1 LTS (GNU / Linux 3.2.0-25-chung i686)

Lần đăng nhập cuối: Thứ Sáu, ngày 9 tháng 11 15:40:11 2012 từ 10.1.3.25 sysadmin @ kaiser: ~ $ date vie nov 9 17:53:11 CST 2012 sysadmin @ kaiser: ~ $


3
Làm một cái gì đó mà không biết nó làm gì và tại sao nó hoạt động có thể được chấp nhận, nhưng đề xuất tương tự là xấu, và công bằng hơn, tồi tệ hơn nếu nó liên quan đến một hệ thống an ninh.
Mahesh

2
đã đồng ý. hãy để điều này được khuyến khích để tạo ra các sshdtài liệu tốt hơn , chính xác là không thuộc danh mục "đọc thứ bảy tốt đẹp"
code_monk
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.