Khóa Ssh được máy chủ chấp nhận nhưng ngắt kết nối máy khách

Xin chào,

Tôi gặp sự cố với SSH sau khi cài đặt fedora 23.

Khi tôi không kết nối với máy chủ từ xa bằng khóa riêng, máy chủ của tôi sẽ tìm khóa:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Nhưng khi bạn thấy khách hàng của tôi tự ngắt kết nối

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Tôi có thể kết nối với máy chủ của mình bằng putty trên windows bằng cùng một khóa riêng và tôi có thể kết nối với điện thoại của mình bằng một khóa riêng khác.

Bạn còn ý kiến ​​nào không ?

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Cảm ơn bạn

Chỉnh sửa: Tôi có thể kết nối với một mật khẩu

Trước hết, có rất nhiều tài liệu chi tiết, được viết rất tốt, chi tiết về cách thiết lập hoặc định cấu hình xác thực dựa trên khóa công khai có sẵn trực tuyến. Xin vui lòng xem một trong số họ và xem nếu bạn đã theo dõi mọi thứ chính xác. Đây là một. Vì vậy, tôi sẽ không lặp lại điều đó một lần nữa.

Khái niệm rất cơ bản là (được sao chép từ đây ):

Xác thực dựa trên khóa sử dụng hai khóa, một khóa "công khai" mà bất kỳ ai cũng được phép xem và một khóa "riêng tư" khác mà chỉ chủ sở hữu mới được phép xem. Để liên lạc an toàn bằng xác thực dựa trên khóa, người ta cần tạo một cặp khóa, lưu trữ khóa riêng trên máy tính mà người dùng muốn đăng nhập và lưu trữ khóa chung trên máy tính mà người dùng muốn đăng nhập.

Bây giờ từ nhật ký gỡ lỗi bạn đã đăng:

• Có vẻ như có hai người dùng khác nhau có liên quan. /home/theo/.ssh/authorized_keysvà /home/tbouge/.ssh/id_rsa. Bạn đang cố gắng đăng nhập như một người dùng vào thư mục nhà của người dùng khác?
• Lỗi Postponed publickey for theo..có nghĩa là phương thức xác thực không mong muốn đã được thử trước phương thức khóa publick. SSH sẽ thử mọi phương thức xác thực được kích hoạt trong cấu hình, lần lượt từng phương thức. Trong trường hợp của bạn, bạn đã GSSAPIAuthentication yeskích hoạt những gì bạn không sử dụng. Bạn có thể vô hiệu hóa nó một cách an toàn bằng cách làm GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodrất có thể là nó không thể xử lý tệp khóa riêng (quyền của tệp hoặc vấn đề tên). SSH rất nhạy cảm về quyền truy cập thư mục và tệp trong cả máy tính cục bộ và máy tính từ xa. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Vì vậy, hãy chắc chắn rằng bạn được đặt chính xác. Xem điều này: /unix/131886/ssh-public-key-wont-send-to-server

• Đối với lỗi thứ ba : Permission denied (public key)., có một vài điều cần kiểm tra.

  • Tên người dùng sai
  • Cặp khóa sai

  • Máy chủ mục tiêu sai

    • Dưới đây là chi tiết hơn: /programming/18551556/ allow-denied-publickey-who-ssh-access-to-amazon-ec2-instance .

Phần sau đây hơi khó hiểu:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Để hiểu rõ hơn về nó, chúng ta hãy thực hiện từng bước quy trình xác thực như được mô tả ở đây tại digitalocean :

1. Máy khách bắt đầu bằng cách gửi ID cho cặp khóa mà nó muốn xác thực với máy chủ.
2. Máy chủ kiểm tra tệp ủy quyền của tài khoản mà khách hàng đang cố đăng nhập để lấy ID khóa.
3. Nếu tìm thấy khóa chung có ID trùng khớp trong tệp, máy chủ sẽ tạo một số ngẫu nhiên và sử dụng khóa chung để mã hóa số.
4. Máy chủ gửi cho khách hàng tin nhắn được mã hóa này.
5. Nếu máy khách thực sự có khóa riêng được liên kết, nó sẽ có thể giải mã tin nhắn bằng khóa đó, tiết lộ số gốc.
6. Máy khách kết hợp số được giải mã với khóa phiên chia sẻ đang được sử dụng để mã hóa thông tin liên lạc và tính toán hàm băm MD5 của giá trị này.
7. Sau đó, khách hàng sẽ gửi hàm MD5 này trở lại máy chủ như một câu trả lời cho thông điệp số được mã hóa.
8. Máy chủ sử dụng cùng khóa phiên chia sẻ và số gốc mà nó đã gửi cho máy khách để tự mình tính toán giá trị MD5. Nó so sánh tính toán của chính nó với tính toán mà khách hàng đã gửi lại. Nếu hai giá trị này khớp nhau, điều đó chứng tỏ rằng máy khách đã sở hữu khóa riêng và máy khách được xác thực.

Trong trường hợp của bạn, như bạn có thể thấy, máy tính từ xa chỉ chấp nhận của bạn public key, mã hóa gói bằng khóa đó và gửi lại cho máy khách. Bây giờ máy tính khách cần chứng minh rằng nó có quyền private key. Chỉ với private_key, nó có thể giải mã tin nhắn nhận được và gửi lại câu trả lời. Trong trường hợp này, khách hàng không thực hiện được điều đó và quá trình xác thực kết thúc mà không thành công.

Tôi hy vọng điều này sẽ giúp bạn hiểu được các vấn đề và giải quyết chúng.

Các đặc quyền trên các tập tin ssh của bạn có đúng không?

Thư mục .ssh -> 700

khóa công khai -> 644

khóa riêng -> 600

Đồng thời kiểm tra người dùng và nhóm

Bạn nói rằng bạn có cùng một phím trên máy tính windows; Bạn có chắc chắn rằng tệp khóa riêng mà bạn có trên máy Linux của mình là chính xác không? Có thể khóa riêng ở định dạng putty mà ssh không dễ hiểu. Trong mọi trường hợp, nếu tôi đặt một tệp khóa riêng tư không chính xác hoặc không hợp lệ, tôi sẽ nhận được chính xác cùng một lỗi mà bạn có.

Để khắc phục sự cố, sẽ tốt hơn nếu tạo một khóa mới trên máy Linux thay vì sử dụng lại khóa từ máy khác. Bạn chỉ có thể thêm khóa công khai mới vào tệp ủy quyền trên máy chủ và sau đó bạn có thể sử dụng cả khóa Windows từ Windows và khóa Linux mới từ Fedora.

vấn đề của bạn có vẻ khá phổ biến và tôi cũng nói rõ.

 Permission denied (publickey).

điều đó có ý nghĩa gì với bạn không? Đối với tôi nó có ý nghĩa rất lớn đối với tôi.

bạn có thể kiểm tra phía máy chủ nếu bạn có selinux runnin ở chế độ thực thi không? nếu không cho tôi biết selinux đang chạy ở chế độ nào.

Ngoài ra, nếu bạn có thể thực hiện thêm một lần nữa và ghi lại nhật ký kiểm toán của lần thử đó và đăng ở đây, nó chắc chắn sẽ cho chúng tôi biết lý do:

  tail -f /var/log/audit/audit.log  (and try to attempt)

Đó là vấn đề cấp phép rõ ràng nhưng không cho phép tệp :-)

Có vẻ như vấn đề (trong trường hợp của tôi ...) là do loại khóa.

Tôi vừa mới giải quyết nó bằng cách thêm vào ~/.ssh/configtệp sau vào tệp cục bộ (máy khách Fedora 23):

PubkeyAcceptedKeyTypes=+ssh-dss

Mặc dù tôi đã thêm dòng đó vào cả máy chủ và tệp cấu hình máy khách, nhưng chỉ có phía máy khách mới tạo ra sự khác biệt. Lưu ý rằng các quyền cần phải được đọc 600cho tập tin cấu hình.

Tôi không biết liệu có ai khác vẫn gặp phải sự cố này không, nhưng cuối cùng tôi đã giải quyết nó cho một máy của tôi (máy tính xách tay) đang gặp sự cố. Tôi tin rằng tôi biết những gì cuối cùng đã sắp xếp nó và tôi sẽ để lại thông tin ở đây với hy vọng rằng nó sẽ giúp bất kỳ ai khác vẫn có thể gặp phải điều này - và cũng để ai đó có thể hy vọng kiểm tra giải pháp của tôi và xác nhận rằng đó thực sự là những gì Đã giải quyết vấn đề.

Vấn đề, như hóa ra, không phải (đối với tôi) với SSH, mà là cách PAM định cấu hình các khóa của tôi. Cấu hình trong đó /etc/pam.dđã lỗi thời (mặc dù nó hoạt động bình thường qua Fedora 22) và kết quả là những điều chính xác không được thực hiện khi đăng nhập [nữa] để lấy chìa khóa của tôi $HOME/.ssh/. Chạy lệnh này:

# sudo authconfig --updateall

xây dựng lại cấu hình /etc/pam.d đúng cách. Trong lần khởi động lại tiếp theo, sau khi tôi đăng nhập, lần đầu tiên tôi cố gắng ssh ra máy chủ của mình, một hộp thoại yêu cầu tôi nhập cụm mật khẩu cho khóa ssh ( $HOME/.ssh/id_rsa). Tôi đã làm như vậy, đánh dấu vào ô "Tự động mở khóa khi đăng nhập" và thì đấy! Khả năng của tôi để ssh ra từ máy tính xách tay đã được khôi phục.

Lý lịch

Manh mối dẫn tôi đến việc giải quyết vấn đề này xuất hiện khi tôi nhập khóa RSA từ nguồn bên ngoài. (Một USB tôi mang theo, với "truy cập từ xa" của tôi quan trọng cho mạng gia đình của tôi. Tôi tắt PasswordAuth để hướng ra bên ngoài phải đối mặt với năm máy chủ của tôi trước sau khi một sự xâm nhập.) Sau ssh-add-ing RẰNG khóa RSA, không giống như người ngồi trong $HOME/.ssh/id_rsa, nó đã được chấp nhận bởi máy chủ từ xa mà không có vấn đề.

Sau đó, tôi đã kết thúc việc làm những gì đáng lẽ là dư thừa ssh-add, để chọn $HOME/.ssh/id_rsa. Tôi nhận thấy rằng sau khi tôi thực hiện điều đó, ssh-add -lcó hai mục nhập cho cùng một khóa:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Lưu ý cách một trong hai mục nhập không hiển thị mã định danh khóa, chỉ tên tệp khóa riêng khớp với chữ ký công khai của nó. Như thể khóa riêng không thực sự được mở khóa bởi người quản lý khóa.

Tôi tin rằng đó chính xác là những gì đang xảy ra và PAM đã chuyển "khóa xấu" cho tác nhân SSH chưa được mở khóa bằng cụm mật khẩu. Vì vậy, khi ssh cố gắng xác thực bằng khóa, nó thực sự không có một nửa riêng tư (đã mở khóa) của cặp khóa và do đó xác thực thất bại.

Đó là phỏng đoán cuối cùng, nhưng bất kể có ai gặp vấn đề với khóa ssh không được chấp nhận bởi các máy chủ từ xa (nơi trước đây) sau khi nâng cấp lên F23, xây dựng lại /etc/pam.d/thư mục bằng cách sử dụng authconfiglà một giải pháp đáng để thử.

Kiểm tra quyền sử dụng thư mục nhà. Nó quan trọng. Phải là 755. 700 hoặc 770 sẽ không hoạt động.

Trong của bạn ssh_config, hãy thử uncommenting và / hoặc thêm / gỡ bỏ / phụ thêm vào một trong hai Cipher, Ciphershoặc MACsdòng (s).

Tôi thấy rằng sshdđang tìm kiếm một loại mật mã cụ thể nào đó không được đưa vào yêu cầu, có thể được thêm vào bằng cách định cấu hình nó trong của bạn ssh_config.

... Và tôi cho rằng bạn không có bất kỳ cơ hội nào được PubkeyAuthenticationđặt notrên máy chủ từ xa, bởi vì điều đó chắc chắn sẽ khiến điều này thất bại.