Tại sao tôi nhận được "Quyền bị từ chối (khóa công khai)" khi thử SSH từ Ubuntu cục bộ sang máy chủ Amazon EC2?

Vì nó không được đề cập rõ ràng, sshd theo mặc định rất nghiêm ngặt về quyền đối với authorized_keys các tập tin. Vì vậy nếu authorized_keys là có thể ghi cho bất kỳ ai khác ngoài người dùng hoặc có thể ghi được bởi bất kỳ ai khác ngoài người dùng, nó sẽ từ chối xác thực (trừ khi sshd được định cấu hình với StrictModes no)

Ý tôi là "có thể ghi được" là nếu bất kỳ thư mục mẹ nào có thể ghi được cho bất kỳ ai khác ngoài người dùng, người dùng được phép sửa đổi các thư mục đó có thể bắt đầu sửa đổi quyền theo cách mà họ có thể sửa đổi/thay thế ủy quyền.

Hơn nữa, nếu /home/username/.ssh thư mục không thuộc quyền sở hữu của người dùng và do đó người dùng không có quyền đọc khóa mà bạn có thể gặp phải sự cố:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Lưu ý rằng jane không sở hữu .ssh tập tin. Khắc phục sự cố này thông qua

chown -R jane:jane /home/jane/.ssh

Các loại vấn đề về quyền hệ thống tập tin này sẽ không hiển thị với ssh -v, và chúng thậm chí sẽ không hiển thị trong nhật ký sshd (!) cho đến khi bạn đặt cấp độ nhật ký thành DEBUG.

• Biên tập /etc/ssh/sshd_config. Bạn muốn một dòng đọc LogLevel DEBUG ở đó đâu đó. Tải lại máy chủ SSH bằng cơ chế do distro cung cấp. (service sshd reload trên RHEL/CentOS/Khoa học.) Tải lại duyên dáng sẽ không bỏ các phiên hiện có.
• Hãy thử xác thực lại.
• Tìm ra nơi nhật ký cơ sở xác thực của bạn đi và đọc chúng. (IIRC, /var/log/auth.log trên các bản phát hành dựa trên Debian; /var/log/secure trên RHEL/CentOS/Khoa học.)

Dễ dàng hơn nhiều để tìm ra những gì đang xảy ra với đầu ra gỡ lỗi bao gồm lỗi quyền hệ thống tập tin. Nhớ hoàn nguyên thay đổi thành /etc/ssh/sshd_config khi xong!

Tôi đã nhận được lỗi này, vì tôi quên thêm -l Lựa chọn. Tên người dùng cục bộ của tôi không giống như trên hệ thống từ xa.

Điều này không trả lời câu hỏi của bạn, nhưng tôi đã đến đây để tìm câu trả lời cho vấn đề của mình.

Tôi đã nhận được thông báo này trên một phiên bản mới dựa trên Ubuntu AMI. Tôi đã sử dụng tùy chọn -i để cung cấp PEM nhưng nó vẫn hiển thị "Quyền bị từ chối (khóa công khai)".

Vấn đề của tôi là tôi đã không sử dụng đúng người dùng. Bằng cách chạy ssh với ubfox @ ec2 ... nó hoạt động như bình thường.

Một cái gì đó dễ đọc hơn ssh -v (theo ý kiến ​​của tôi tất nhiên), là tail -f /var/log/auth.log. Điều đó nên được chạy trên máy chủ mà bạn đang cố gắng kết nối, trong khi cố gắng kết nối. Nó sẽ hiển thị lỗi trong văn bản thuần túy.

Điều này giúp tôi giải quyết vấn đề của mình:

Người dùng [tên người dùng] từ xx.yy.com không được phép vì không có nhóm người dùng nào được liệt kê trong Allowgroup

Kiểm tra tệp / etc/ssh/sshd_config của bạn. Ở đó, tìm dòng nói

PasswordAuthentication no

Dòng đó cần được sửa đổi để nói có thay vì không. Ngoài ra, khởi động lại máy chủ sshd sau đó.

Sudo /etc/init.d/ssh restart

Có lẽ không liên quan đến poster hiện tại, nhưng có thể giúp những người khác tìm thấy điều này khi tìm kiếm câu trả lời cho các tình huống tương tự. Thay vì để Amazon tạo cặp khóa ssh, tôi khuyên bạn nên tải khóa ssh công khai, tiêu chuẩn, mặc định của riêng bạn lên Amazon và chỉ định rằng khi bạn chạy phiên bản EC2.

Điều này cho phép bạn bỏ cú pháp loại "-i" trong ssh, sử dụng rsync với các tùy chọn tiêu chuẩn và cũng cho phép bạn sử dụng cùng một khóa ssh trên tất cả các vùng EC2.

Tôi đã viết một bài viết về quá trình này ở đây:

Tải khóa ssh cá nhân lên Amazon EC2
[.__.] http://alests.com/2010/10/ec2-ssh-keys

Thật kỳ lạ, vấn đề của tôi hóa ra là máy chủ đã được khởi động lại và nó đã được cấp một tên DNS mới. Tôi đã sử dụng tên DNS cũ. Tôi biết điều này nghe có vẻ ngu ngốc nhưng tôi phải mất một thời gian để tìm ra điều này.

Nếu bạn đang cố gắng kết nối với điện thoại CyanogenMod chạy Dropbear, bạn nên chạy các dòng sau để đảm bảo mọi thứ đều được phép:

chmod 600 /data/dropbear/.ssh/authorized_keys

hoặc là

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

và

chmod 755 /data/dropbear/ /data/dropbear/.ssh

Điều này đã sửa nó cho tôi, nếu không không có gì có thể kết nối.

Nếu bạn đang sử dụng CentOS 5, bạn có thể muốn đặt StrictModes no trong /etc/ssh/sshd_config. Tôi đang chia sẻ/thư mục chính bằng NIS/NFS và tôi đặt tất cả các quyền chính xác, nhưng nó luôn nhắc tôi với mật khẩu. Sau khi tôi đặt StrictModes no, vấn đề biến mất!

Tôi đã có cùng một vấn đề mặc dù tôi đã phải tuân theo tất cả các bước bao gồm

$ ec2-authorize default -p 22

Tuy nhiên, tôi đã bắt đầu ví dụ của mình ở khu vực phía tây-1. Vì vậy, lệnh trên cũng nên xác định rằng.

$ ec2-authorize default -p 22 --region us-west-1

Sau lệnh này tôi đã có thể ssh vào ví dụ. Tôi đã dành một chút thời gian trước khi tôi nhận ra vấn đề và hy vọng bài đăng này giúp đỡ người khác.

Câu trả lời của Greg giải thích cách khắc phục sự cố tốt hơn, tuy nhiên vấn đề thực tế là bạn có khóa ssh được đặt ở một bên của giao dịch (máy khách), đang thử xác thực khóa công khai thay vì xác thực dựa trên mật khẩu. Vì bạn không có khóa công khai tương ứng trên phiên bản EC2, điều này sẽ không hoạt động.

Tôi cũng gặp vấn đề tương tự và sau khi thử hàng tấn giải pháp không hoạt động, tôi đã mở cổng SSH trên tường lửa của bộ định tuyến (bảng điều khiển tường lửa của bộ định tuyến của tôi là một mớ hỗn độn, vì vậy thật khó để biết chuyện gì đang xảy ra). Dù sao, nó đã sửa nó :)

Super đẫm máu khó chịu mà lỗi bạn nhận được là Quyền bị từ chối, ngụ ý rằng có một loại kết nối nào đó được tạo ra, grr.

Tôi vừa gặp vấn đề tương tự sau khi vô tình thêm quyền ghi nhóm vào thư mục chính của người dùng.

Tôi phát hiện ra đây là nguyên nhân do chạy tail -f /var/log/secure trên máy và thấy lỗi Authentication refused: bad ownership or modes for directory /home/<username>.

Đây là một trường hợp hiếm gặp, nhưng nếu bạn đã bật selinux và bạn đang sử dụng nfs cho thư mục với ủy quyền (ví dụ: thư mục chung được chia sẻ), bạn sẽ cần phải tắt selinux (không được khuyến nghị vì lý do bảo mật, nhưng bạn có thể tạm thời tắt nó để xem nếu điều này gây ra sự cố) hoặc cho phép selinux sử dụng các thư mục nhà nfs. Tôi không rõ về các chi tiết, nhưng điều này làm việc cho tôi setsebool -P use_nfs_home_dirs 1