Tại sao tôi lại bị từ chối cấp phép (công khai) khi sử dụng SSH từ Ubuntu cục bộ đến máy chủ Amazon EC2?

Tôi có một phiên bản của một ứng dụng chạy trên đám mây trên phiên bản Amazon EC2 và tôi cần kết nối nó từ Ubuntu cục bộ của mình. Nó hoạt động tốt trên một trong các Ubuntu cục bộ và cả máy tính xách tay. Tôi nhận được thông báo "Quyền bị từ chối (khóa công khai)" khi cố gắng truy cập SSH vào EC2 trên một Ubuntu cục bộ khác. Nó thật lạ đối với tôi.

Tôi đang nghĩ một số vấn đề với cài đặt bảo mật trên Amazon EC2 có quyền truy cập IP hạn chế vào một phiên bản hoặc chứng chỉ có thể cần phải tạo lại.

có ai biết cách giải quyết không?

Điều đầu tiên cần làm trong tình huống này là sử dụng -vtùy chọn để sshbạn có thể xem loại xác thực nào được thử và kết quả là gì. Điều đó có giúp khai sáng tình hình?

Trong bản cập nhật cho câu hỏi của bạn, bạn đề cập "trên Ubuntu cục bộ khác". Bạn đã sao chép khóa riêng ssh sang máy khác chưa?

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 các authorized_keystệp. Vì vậy, nếu authorized_keyscó thể ghi được cho bất kỳ ai khác ngoài người dùng hoặc có thể được ghi bởi bất kỳ ai khác ngoài người dùng, họ sẽ từ chối xác thực (trừ khi sshd được định cấu hình 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/.sshthư 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 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 .sshtậ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 xuất hiện ssh -vvà thậm chí chúng sẽ không hiển thị trong nhật ký sshd (!) Cho đến khi bạn đặt mức nhật ký thành DEBUG.

• Chỉnh sửa /etc/ssh/sshd_config. Bạn muốn một dòng đọc LogLevel DEBUGở đó một nơi nào đó. Tải lại máy chủ SSH bằng cơ chế do distro cung cấp. ( service sshd reloadtrê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.logtrên các bản phát hành dựa trên Debian; /var/log/securetrê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. Hãy nhớ hoàn nguyên thay đổi /etc/ssh/sshd_configkhi hoàn thành!

Tôi đã nhận được lỗi này, vì tôi quên thêm -ltùy 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 ví dụ 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://alatural.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 thiết lập StrictModes notrong /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!

Câu trả lời của Greg giải thích làm thế nào để giải quyết vấn đề 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ó :)

Siê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 được thực hiện, grr.

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.

Đâ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

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/securetrên máy và thấy lỗi Authentication refused: bad ownership or modes for directory /home/<username>.