Quyền bị từ chối (khóa công khai) khi SSH Truy cập vào phiên bản Amazon EC2 [đã đóng]

Tôi muốn sử dụng ví dụ Amazon ec2 của mình nhưng gặp phải lỗi sau:

Permission denied (publickey).

Tôi đã tạo cặp khóa của mình và tải xuống tệp .pem .

Được:

chmod  600 pem file.

Sau đó, lệnh này

ssh -i /home/kashif/serverkey.pem  ubuntu@ec2-54-227-242-179.compute-1.amazonaws.com

Nhưng có lỗi này:

Permission denied (publickey)

Ngoài ra, làm cách nào tôi có thể kết nối với filezilla để tải lên / tải xuống tệp?

Thông báo lỗi này có nghĩa là bạn không thể xác thực.

Đây là những lý do phổ biến có thể gây ra rằng:

1. Đang cố gắng kết nối với khóa sai. Bạn có chắc chắn trường hợp này đang sử dụng khóa này?
2. Đang cố gắng kết nối với tên người dùng sai. ubuntulà tên người dùng cho việc phân phối AWS ubuntu dựa, nhưng trên một số người khác của nó ec2-user(hoặc admintrên một số Debians, theo câu trả lời Bogdan Kulbida của) (cũng có thể là root, fedora, xem dưới đây)
3. Đang cố gắng kết nối máy chủ sai. Đó có phải là máy chủ phù hợp mà bạn đang cố gắng đăng nhập không?

Lưu ý rằng điều đó 1.cũng sẽ xảy ra nếu bạn đã gửi nhầm /home/<username>/.ssh/authorized_keystệp vào ví dụ EC2 của bạn.

Giới thiệu 2., thông tin về tên người dùng bạn nên sử dụng thường thiếu từ mô tả Hình ảnh AMI. Nhưng bạn có thể tìm thấy một số tài liệu trong AWS EC2, dấu đầu dòng 4.: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Sử dụng lệnh ssh để kết nối với thể hiện. Bạn sẽ chỉ định tệp khóa riêng (.pem) và user_name @ public_dns_name. Đối với Amazon Linux, tên người dùng là ec2-user. Đối với RHEL5, tên người dùng là root hoặc ec2-user . Đối với Ubuntu, tên người dùng là ubfox . Đối với Fedora, tên người dùng là fedora hoặc ec2-user . Đối với SUSE Linux, tên người dùng là root . Mặt khác, nếu người dùng ec2 và root không hoạt động, hãy kiểm tra với nhà cung cấp AMI của bạn.

Cuối cùng , hãy lưu ý rằng có nhiều lý do khác khiến việc xác thực thất bại. SSH thường khá rõ ràng về những gì đã sai nếu bạn quan tâm thêm -vtùy chọn vào lệnh SSH và đọc kết quả đầu ra, như được giải thích trong nhiều câu trả lời khác cho câu hỏi này.

Trong trường hợp này, vấn đề phát sinh từ Cặp khóa bị mất. Về điều này:

• Không có cách nào để thay đổi Cặp khóa trên một ví dụ . Bạn phải tạo một phiên bản mới sử dụng Cặp khóa mới.
• Bạn có thể giải quyết vấn đề nếu ứng dụng của bạn được sử dụng bởi một ứng dụng trên Elastic Beanstalk .

Bạn có thể làm theo các bước sau:

1. Truy cập vào Bảng điều khiển quản lý AWS
2. Mở tab Beanstalk đàn hồi
3. Chọn ứng dụng của bạn từ Tab Tất cả ứng dụng
4. Từ bên trái menù chọn Cấu hình
5. Nhấp vào Gear Instances
6. Trong Mẫu máy chủ, hãy kiểm tra đầu vào Cặp khóa EC2 và chọn Cặp khóa mới của bạn. Bạn có thể phải làm mới danh sách để xem Cặp khóa mới mà bạn vừa tạo.
7. Tiết kiệm
8. Elastic Beanstalk sẽ tạo cho bạn các phiên bản mới được liên kết với cặp khóa mới.

Nói chung, hãy nhớ rằng bạn phải cho phép phiên bản EC2 của bạn chấp nhận lưu lượng SSH gửi đến.

Để làm điều này, bạn phải tạo một quy tắc cụ thể cho Nhóm bảo mật của phiên bản EC2 của bạn. Bạn có thể làm theo các bước sau.

1. Truy cập vào Bảng điều khiển quản lý AWS
2. Mở tab EC2
3. Từ danh sách Trường hợp chọn trường hợp bạn quan tâm
4. Trong Tab Mô tả , tên của Nhóm Bảo mật mà phiên bản của bạn đang sử dụng.
5. Một lần nữa trong Tab Mô tả, nhấp vào Xem quy tắc và kiểm tra xem Nhóm bảo mật của bạn có quy tắc cho lưu lượng truy cập ssh trong cổng 22 không
6. Nếu không, trong Network & Security menù chọn Security Group
7. Chọn Nhóm bảo mật được sử dụng bởi cá thể của bạn và nhấp vào Tab trong
8. Ở bên trái của Tab trong, bạn có thể soạn một quy tắc cho lưu lượng truy cập SSH:
   • Tạo quy tắc mới : SSH
   • Nguồn : Địa chỉ IP hoặc mạng con mà bạn muốn truy cập vào ví dụ
   • Lưu ý : Nếu bạn muốn cấp quyền truy cập không giới hạn cho cá thể của mình, bạn có thể chỉ định 0.0.0.0/0 , mặc dù Amazon không khuyến nghị thực hành này
9. Nhấp vào Thêm quy tắc và sau đó áp dụng thay đổi của bạn
10. Kiểm tra xem bây giờ bạn có thể kết nối với cá thể của bạn thông qua SSH không.

Hy vọng điều này có thể giúp ai đó như đã giúp tôi.

Đây là cách tôi giải quyết vấn đề

ssh -i <key> ec2-user@<ec2 ip>

Tôi đã giải quyết vấn đề chỉ cần đặt sudotrước

sudo ssh -i mykey.pem myec2.amazonaws.com

Nhưng giải pháp thích hợp là thay đổi quyền sở hữu trước, sau đó kết nối như một người dùng bình thường như Janus Troelsen nói dưới đây. Trong trường hợp của tôi, nó sẽ là:

chown wellington:wellington key.pem

Hãy thử sử dụng

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

HOẶC LÀ

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

Một nguyên nhân có thể khác của lỗi này:

Khi thư mục nhà của người dùng có thể ghi nhóm của người dùng có thể , người dùng không thể đăng nhập.

(Được sao chép trên Ubuntu dụ.)

đối với phiên bản micro ub Ubuntu 12.04 lts tôi phải đặt tên người dùng làm tùy chọn

ssh -i pemfile.pem -l ubuntu dns

Bạn cần làm các bước sau:

1. Mở ứng dụng khách hoặc thiết bị đầu cuối ssh của bạn nếu bạn đang sử dụng Linux.
2. Xác định vị trí tệp khóa riêng của bạn và thay đổi thư mục của bạn.
   cd <path to your .pem file>
3. Thực hiện các lệnh dưới đây:
   chmod 400 <filename>.pem
ssh -i <filename>.pem ubuntu@<ipaddress.com>

Nếu ubuntungười dùng không làm việc thì hãy thử với ec2-user.

Tôi đã vật lộn với cùng một quyền bị từ chối lỗi rõ ràng là do

key_parse_private2: missing begin marker 

Trong tình huống của tôi, nguyên nhân là tệp cấu hình ssh của người dùng hiện tại (~ / .ssh / config).

Sử dụng như sau:

ssh -i ~/myKey.pem ec2-user@<IP address> -v 'exit'

Đầu ra ban đầu cho thấy:

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

... nhiều dòng gỡ lỗi ở đây ...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

Dòng thứ ba ở trên là nơi xác định vấn đề thực tế; tuy nhiên, tôi đã tìm kiếm thông báo gỡ lỗi bốn dòng từ dưới lên (ở trên) và bị đánh lừa. Không có vấn đề gì với khóa nhưng tôi đã kiểm tra và so sánh các cấu hình khác.

Tập tin cấu hình ssh người dùng của tôi đặt lại máy chủ thông qua cài đặt toàn cầu ngoài ý muốn như dưới đây. Dòng máy chủ đầu tiên không nên là một bình luận.

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

Tôi hy vọng người khác thấy điều này hữu ích.

Tôi đã quên thêm tên người dùng (ubfox) khi kết nối phiên bản Ubuntu của tôi. Vì vậy, tôi đã thử điều này:

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

và cách chính xác là

ssh -i /path/my-key-pair.pem ubuntu@my-ec2-instance.amazonaws.com

Điều này đã xảy ra với tôi nhiều lần. Tôi đã sử dụng Amazon Linux AMI 2013.09.2 và Ubuntu Server 12.04.3 LTS, cả hai đều nằm trên tầng miễn phí.

Mỗi lần tôi đưa ra một ví dụ tôi đều có quyền từ chối xuất hiện. Tôi chưa xác minh điều này nhưng lý thuyết của tôi là máy chủ không được thiết lập hoàn toàn trước khi tôi cố gắng ssh vào nó. Sau một vài lần thử với sự cho phép bị từ chối, tôi đợi vài phút và sau đó tôi có thể kết nối. Nếu bạn đang gặp vấn đề này, tôi khuyên bạn nên chờ năm phút và thử lại.

Dưới đây là một tình huống bực bội có thể gây ra lỗi này:

Nếu bạn đang ăn một phiên bản mới từ một AMI mà bạn đã tạo ra một phiên bản khác (ví dụ xyz), thì phiên bản mới sẽ chỉ chấp nhận cùng khóa mà phiên bản A đã sử dụng. Điều này là hoàn toàn dễ hiểu nhưng nó gây nhầm lẫn bởi vì trong quá trình từng bước tạo ra trường hợp mới, bạn được yêu cầu chọn hoặc tạo một khóa (ở bước cuối cùng) sẽ không hoạt động.

Bất kể khóa bạn tạo hoặc chọn, chỉ có khóa bạn đang sử dụng, ví dụ XYZ sẽ được chấp nhận bởi thể hiện mới.

Tôi đã vật lộn với điều này trong một thời gian cho đến khi tôi tìm thấy như sau:

eb ssh

Khi bạn sử dụng nó từ thư mục dự án, bingo-bango no muss no fuss, bạn đang ở trong

Trong trường hợp của riêng tôi, tôi đã làm như sau:

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

Tôi ban đầu sử dụng root@một phần và tôi đã nhận được lời nhắc này:

Please login as the user "ec2-user" rather than the user "root".

Tôi đang ở trong Windows với WinSCP . Nó hoạt động tuyệt vời trên cả File Explorer và PuTTY SSH Shell để truy cập Amazon EC2-VPC Linux của tôi. Không có gì để làm chmod pem filevì nó sử dụng được myfile.ppk chuyển đổi bởi PuTTYgen từ tệp pem .

điều tương tự cũng xảy ra với tôi, nhưng tất cả những gì đang xảy ra là khóa riêng bị mất khỏi móc khóa trên máy cục bộ của tôi.

ssh-thêm -K

thêm lại khóa, sau đó lệnh ssh để kết nối trở lại hoạt động.

Vấn đề này có thể được giải quyết bằng cách đăng nhập vào hộp Ubuntu bằng lệnh dưới đây:

ssh -i ec2key.pem ubuntu@ec2-public-IP

Tôi đã hai lần sửa khóa và ssh dòng lệnh (tôi biết vì tôi đang sao chép một phiên bản Ubuntu 14.04 đang hoạt động), nhưng không thể ssh vào một phiên bản mới, ngay cả sau khi chờ 5 phút như đề xuất của Wade Anderson ở trên.

Tôi đã phải phá hủy và tạo lại máy. Điều này đã xảy ra vào hai dịp riêng biệt. Vì ban đầu tôi không thể vào được, tôi không thể thấy điều gì sai.

Vì vậy, nếu bạn có vấn đề này, hãy thử nó.

bạn phải kiểm tra vài thứ sau:

1. Đảm bảo địa chỉ IP của bạn là chính xác
2. Đảm bảo bạn đang sử dụng Khóa chính xác
3. Hãy chắc chắn rằng bạn đang sử dụng tên người dùng chính xác, bạn có thể thử: 3.1. quản trị viên 3.2. người dùng ec2 3.3. ubfox

Tôi đã có cùng một vấn đề và nó đã được giải quyết sau khi tôi đổi tên người dùng thành ubfox. Trong tài liệu AWS đã được đề cập đến người dùng ec2-user nhưng bằng cách nào đó nó không hoạt động với tôi.

Khóa riêng của tôi đã được đặt thành quyền 400 và kết quả là Quyền bị từ chối đặt nó thành '644' đã giúp tôi.

key_load_private_type: Quyền bị từ chối là lỗi cụ thể tôi gặp phải

Giải pháp: Sudo chmod 644 <key.pem>

Lưu ý: đặt thành 644 là bắt buộc, nó không hoạt động với 400

Khi bạn cố gắng làm

ssh -i <.pem path> root@ec2-public-dns

Bạn nhận được một tin nhắn khuyên bạn sử dụng ec2-user.

Please login as the user "ec2-user" rather than the user "root".

Vì vậy, sử dụng

ssh -i <.pem path> ec2-user@ec2-public-dns

Tôi đã có cùng một vấn đề và nó rất kỳ lạ. Nếu bạn tin rằng bạn đang làm tốt hơn là làm theo điều này: Đôi khi có sự nhầm lẫn về người dùng cho ví dụ EC2 !! Đôi khi bạn nhận được người dùng ec2, ubfox, centos, v.v. Vì vậy, hãy kiểm tra tên người dùng của bạn cho machie !!

Đăng nhập với người dùng root ssh -i yourkey.pem (400 permission) root@<ip> Nó sẽ ném lỗi và sẽ cung cấp cho bạn tên người dùng có sẵn . sau đó đăng nhập với người dùng đó.

Đó là một điều cơ bản, nhưng luôn xác nhận người dùng nào bạn đang cố gắng đăng nhập. Im trường hợp của tôi chỉ là một sự xao lãng . Tôi đã thử sử dụng một người dùng root :

ssh -i ~/keys/<key_name> root@111.111.111.111

Nhưng là một người dùng khác :

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

tôi đã có cùng một lỗi nhưng tình hình khác nhau. với tôi nó đã xảy ra bất ngờ sau rất nhiều thời gian tôi có thể ssh thành công với máy tính từ xa của mình ngoài kia. sau rất nhiều lần tìm kiếm giải pháp cho vấn đề của tôi là quyền truy cập tập tin. Tất nhiên điều này là lạ bởi vì tôi đã không thay đổi bất kỳ quyền nào trong máy tính của tôi hoặc điều khiển từ xa thuộc về tệp / thư mục của ssh. Vì vậy, từ wiki archlinux tốt ở đây là:

Đối với máy cục bộ, hãy làm điều này:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

Đối với máy từ xa, hãy làm điều đó:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

sau đó ssh của tôi bắt đầu hoạt động trở lại mà không có sự cho phép từ chối (khóa công khai).

Một vấn đề có thể khác: ID đăng nhập sai

Kiểm tra 'Hướng dẫn sử dụng'

Tất cả các đề xuất tốt ở trên, nhưng những gì tôi gặp phải là tôi đã chọn một ví dụ được tạo sẵn. Sau khi thể hiện đã bắt đầu, hãy xem hướng dẫn sử dụng. Tôi đã sử dụng không đúng id đăng nhập của khóa riêng khi trong hướng dẫn tôi phải sử dụng 'bitnami' (ví dụ: bitnami @ domain -i key.pem)

Tôi đã có lỗi tương tự

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Vấn đề của tôi là trường hợp không khởi động đúng do lỗi trên tập lệnh khởi động từ Step 3: Configure instance detail bên dướiAdvanced details:

Những gì tôi nghĩ rằng tôi đã nhập:

#include
 https://xxxx/bootstrap.sh


Những gì thực sự nhập phá vỡ thiết lập cá thể

#include

https://xxxx/bootstrap.sh

Vì vậy, khóa công khai ở phía cá thể không được tạo

Đó là trường hợp nhạy cảm.

Sai: Người dùng SSH EC2 @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

Chính xác: SSH ec2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

Tôi đã có thể SSH từ một máy, nhưng không phải từ một máy khác. Hóa ra tôi đã sử dụng khóa riêng sai.

Cách tôi tìm ra điều này là bằng cách lấy khóa chung từ khóa riêng của mình, như thế này:

ssh-keygen -y -f ./myprivatekey.pem

Những gì xuất hiện không khớp với những gì trong ~/.ssh/authorized_keysví dụ EC2.

Tất cả các câu trả lời được xếp hạng hàng đầu ở trên là chính xác và sẽ hoạt động trong hầu hết các trường hợp. Trong trường hợp họ không như trong trường hợp của tôi, tôi chỉ cần loại bỏ ~/.ssh/known_hoststập tin của mình trên máy mà tôi đang cố gắng ssh từ đó và điều đó đã giải quyết vấn đề cho tôi. Tôi đã có thể kết nối sau đó.