Putty: Bắt máy chủ từ chối lỗi chính của chúng tôi


86

Tôi đã tạo cặp khóa bằng cách sử dụng puttygen.exe(máy khách là windows 8). Trên máy chủ (Ubuntu 12.04.3 LTS), tôi đã đưa khóa công khai của mình vào ~/.ssh/authorized_keys. Khóa công khai là:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231

Vì vậy, nó chính xác (một dòng, không có nhận xét, bắt đầu bằng ssh-rsa, v.v.)

.ssh cấp quyền dir là 700, quyền đối với tệp ủy quyền là 600. Cả thư mục và tệp đều thuộc sở hữu của người dùng thực mà tôi cố gắng đăng nhập.

Khi tôi thử kết nối, tôi nhận được 'server refused our key'và máy chủ yêu cầu mật khẩu. Đó là tất cả. Không có gì được đăng nhập /var/log/auth.logkhi cố gắng đăng nhập bằng khóa.

Tôi đã tìm khắp mọi nơi và tất cả các bài báo và mẹo đều đề cập đến việc đặt chmod 600 và 700 cho tệp / thư mục và định dạng khóa chính xác. Tôi đã làm tất cả những điều này vẫn nhận được lỗi 'từ chối khóa của chúng tôi' và tôi hết ý tưởng.


2
Bạn đã nói Putty sử dụng cùng một khóa? bạn đang đăng nhập với cùng một người dùng? đây là cài đặt SSH mặc định hay bạn đã sửa đổi sshd_config?
Noam Rathaus

Puttygen tạo ra 3 khóa: riêng tư, công khai và đó là phiên bản khóa riêng với phần mở rộng .ppk. Tất nhiên tôi đang sử dụng .ppk với putty.exe và đã dán khóa công khai vào .ssh / allow_keys trên máy chủ. Đó là cài đặt / cấu hình SSH mặc định, tôi chưa sửa đổi sshd_config.
PawelRoman

BTW, tôi phải tạo thư mục .ssh và auhtorized_keys, vì đó là cài đặt Ubuntu mới và nó không có ở đó. Có lẽ điều này có một cái gì đó để làm với vấn đề?
PawelRoman

3
Đảm bảo sshd_config được định cấu hình để sử dụng khóa công khai, có thể không
Noam Rathaus

2
Bạn có thấy gì trong /var/log/auth.log không? tăng LogLevel logs' SSH để DEBUGvà xem nếu bạn có thể thấy bất kỳ vấn đề đăng nhập, nếu nó vẫn không hiển thị bạn truy cập bạn đang tìm kiếm trong file log sai
Noam Rathaus

Câu trả lời:


61

OK, có một lỗi đánh máy nhỏ trong khóa của tôi. Rõ ràng khi dán vào tệp, chữ cái đầu tiên đã bị cắt và nó bắt đầu bằng sh-rsa thay vì ssh-rsa.

nrathathaus - câu trả lời của bạn rất hữu ích, cảm ơn rất nhiều, câu trả lời này được ghi có cho bạn :) Tôi đã làm như bạn nói và đặt câu trả lời này trong sshd_conf:

LogLevel DEBUG3

Bằng cách xem các nhật ký, tôi nhận ra rằng sshd đọc chính xác khóa nhưng từ chối nó vì số nhận dạng không chính xác.


7
Chính xác vấn đề tương tự :)
Trefex

Bạn đã kiểm tra nhật ký nào và chúng ở đâu? Bạn đang nói về mã định danh là gì?
user1046647

3
@ user1046647 LogLevelđược định nghĩa trong /etc/ssh/sshd_config. Nhật ký mặc định là /var/log/auth.logtrừ khi được định nghĩa khác trong sshd_config.
Axel Kemper

3
Nếu bạn mở allow_key trong vim và ngay lập tức cố gắng dán chữ 's' đầu tiên từ 'ssh_rsa "được coi là lệnh vim, sau đó vim sẽ chuyển sang chế độ chèn và văn bản còn lại sẽ được dán. Nếu bạn vào chế độ chèn trước đó dán (ví dụ: sử dụng i) 's' ở đầu sẽ không bị cắt.
Pawel

1
! sudo service ssh restartđể các thay đổi có hiệu lực. Nếu không thì không có gì trong tệp nhật ký xác thực của tôi.
hogan

30

Thêm một vài suy nghĩ khi các câu trả lời khác có ích, nhưng không phù hợp chính xác.

Trước hết, như đã đề cập trong câu trả lời được chấp nhận, hãy chỉnh sửa

/etc/ssh/sshd_config

và đặt cấp độ nhật ký:

LogLevel DEBUG3

Sau đó cố gắng xác thực và khi không thành công, hãy tìm tệp nhật ký:

/var/log/secure

Nó sẽ có lỗi mà bạn đang tìm kiếm.


/var/log/tồn tại, nhưng securekhông tồn tại. Làm cách nào để biết nhật ký nào đang được ghi vào?
aliteralmind

11
Mặc định /var/log/auth.log, ít nhất là trong Ubuntu 14.04.1 của tôi.
Axel Kemper

ĐÚNG! cảm ơn bạn! lần lượt ra key file quán rượu của tôi đã có một vô hình \ n ở cuối
alextsil

1
Linux / Ubuntu rất khó chịu. Đã dành 20 phút cố gắng để tìm ra lý do tại sao không có securetệp trước khi đọc các nhận xét @axel ở đây.
JYelton

17

Trong trường hợp của tôi, tôi cũng phải thay đổi quyền của / home / user từ 0755 thành 0700.


1
đây là nguyên nhân và giải pháp cho tôi
pstanton

4
và cho bản thân mình thư mục 700 và authorized_keys 600 giải quyết vấn đề
David Soussan

1
Đối với tôi giống nhau, chmod 700 trên .ssh thư mục và chmod 600 trên authorized_keys giải quyết vấn đề
Iwo Kucharski

Thư mục .ssh 700 và các khóa được ủy quyền 600 đã sửa nó cho tôi.
Deep-B

13

Trong trường hợp của tôi, là một vấn đề về quyền.

Tôi đã thay đổi cấp độ nhật ký thành DEBUG3và trong /var/log/securetôi thấy dòng này:

Authentication refused: bad ownership or modes for directory

Googled và tôi tìm thấy bài đăng này:

https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

chmod g-w /home/your_user
chmod 700 /home/your_user/.ssh
chmod 600 /home/your_user/.ssh/authorized_keys

Về cơ bản, nó yêu cầu tôi:

  • loại bỏ wquyền nhóm của dir nhà người dùng của bạn
  • thay đổi quyền 700của .sshdir
  • thay đổi quyền đối 600với authorized_keystệp.

Và điều đó hoạt động.

Một điều nữa là ngay cả khi tôi đã kích hoạt đăng nhập root, tôi không thể rootlàm việc. Tốt hơn hãy sử dụng người dùng khác.


Câu trả lời này đã được bỏ phiếu thấp. Các quyền bị bỏ qua của thư mục chính có thể khiến bạn mất cả ngày để khắc phục sự cố.
chingNotCHing

Cảm ơn vì đã bình chọn cho tôi. Tôi chỉ chia sẻ những gì tôi nhận được.
WesternGun

6

Đang chạy Windows 8.1, tôi gặp sự server refused our keycố.

Làm theo hướng dẫn: https://winscp.net/eng/docs/guide_windows_openssh_server Thật dễ dàng tạo kết nối bằng đăng nhập Windows usernamepassword. Tuy nhiên, xác thực với sự usernamekết hợp với a private key, phản hồi là server refused our key.

Bắt nó hoạt động với khóa công khai phụ thuộc vào các quyền trên tệp: C:\ProgramData\ssh\administrators_authorized_keys

Đây là một trang hữu ích: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Dừng hai dịch vụ OpenSSH, sau đó mở command promptbằng admin permissions. Sau đó chạy: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd

Lưu ý: chỉ định đường dẫn đầy đủ đến exe, nếu không sẽ sshdphàn nàn. Điều này tạo ra một trình nghe kết nối sử dụng một lần. Là -dddcấp độ 3 tiết.

Sau khi kết nối, quét các nhật ký được tiết lộ:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
        No such file or directory

Phải tạo tệp: C:\ProgramData\ssh\administrators_authorized_keys Và sao chép public keyvăn bản vào đó, ví dụ: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505 Và sau đó lưu tệp. Tôi đã lưu tệp như UTF-8với BOM. Không thử nghiệm ANSI.

Sau đó, chạy lại dòng lệnh một lần, trong nhật ký hiển thị:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
        Authentication refused.

S-1-5-11là tên được đặt cho System.

Để sửa lỗi Bad permissions, hãy nhấp chuột phải vào administrators_authorized_keystệp, đi tới Security Tab, nhấp vào Advancednút và xóa các quyền kế thừa. Sau đó, xóa tất cả Group or user names:ngoại trừ tên người dùng đăng nhập Windows, ví dụ: YourMachineName\username Quyền cho điều đó usernamephải có Read Allow, Write Denymọi thứ khác đều không được chọn. Chủ sở hữu của tệp cũng phải làYourMachineName\username

Điều này đã khắc phục sự cố.

Các liên kết hữu ích khác:

Tải xuống OpenSSH-Win32.zip từ: https://github.com/PowerShell/Win32-OpenSSH/releases

C # ví dụ về cách sử dụng WinSCPnet.dll để tạo kết nối với máy chủ OpenSSH: https://winscp.net/eng/docs/library#csharp

Đây là đoạn mã để tạo kết nối bằng cách sử dụng WinSCPnet.dll:

static void WinSCPTest() {
    SessionOptions ops = new SessionOptions {
        Protocol = Protocol.Sftp, 
        PortNumber = 22,
        HostName = "192.168.1.188", 
        UserName = "user123",
        //Password = "Password1",
        SshHostKeyFingerprint = @"ssh-rsa 2048 qu0f........................ddowUUXA="
    };

    ops.SshPrivateKeyPath = @"C:\temp\rsa-key-20190505.ppk";

    using (Session session = new Session()) {
        session.Open(ops);
        MessageBox.Show("success");
    }
}

Thay thế SshHostKeyFingerprintSshPrivateKeyPathvới các giá trị của riêng bạn.

Chỉnh sửa: đã thêm ảnh chụp màn hình của quyền đối với tệp administrator_authorized_keys: nhập mô tả hình ảnh ở đây

Khi OpenSSH SSH Serverđang chạy dưới dạng một Dịch vụ, thì chỉ Systemnên có quyền. Tuy nhiên, nếu chạy sshd.exetừ dấu nhắc lệnh, thì người dùng hiện tại phải là người duy nhất được liệt kê (cho phép đọc, từ chối ghi).


3
Bạn đã làm nhiều điều ở đây mà có ích. Lần đầu tiên chạy sshd với cờ gỡ lỗi trên dòng lệnh. Nhật ký Hệ thống Dịch vụ Windows hiển thị rất ít và hoàn toàn vô ích để gỡ lỗi. Thứ hai, thực tế chính là với tư cách là Quản trị viên, có một lỗi chỉ xuất hiện trong tệp administrator_authorized_keys chứ không phải thư mục Users .ssh được mong đợi dành cho Authorised_keys (điểm đáng buồn của mọi người khi chạy sshd trên Windows). Cuối cùng là thư mục 'ssh' trong ProgramData! Tôi đã tự hỏi nơi nó đang đặt chứng chỉ máy chủ, v.v. Vì vậy, chỉ có thông tin của bạn ở đây giúp tôi sau khi vò đầu bứt tai trong một ngày hoặc lâu hơn. Cảm ơn!
Master James

câu trả lời này là câu trả lời duy nhất phù hợp với tôi trên lớp miễn phí phiên bản ec2 phiên bản mới 2019.
yolob 21

3

Tôi thêm câu trả lời này để giúp bất kỳ ai, giống như tôi, đã dành hàng giờ để tìm kiếm trên Internet mà không thành công.

ĐÈN THƯ MỤC TRANG CHỦ CỦA BẠN ĐƯỢC TÍCH LŨY.

Hoặc đối với vấn đề đó, bất kỳ thư mục nào trong đó tệp "allow_keys" của bạn được lồng vào nhau. Trời đất, điều đó sẽ giúp tôi tiết kiệm rất nhiều thời gian. Để kiểm tra, hãy thực hiện

ls -A

trên thư mục có trạng thái mã hóa mà bạn muốn xác định. Nếu thư mục chứa thư mục có tên ".encryptfs" thì câu trả lời là, có, thư mục đó đã được mã hóa. Điều này sẽ cản trở khả năng của bạn truy cập vào tệp "allow_keys" có chứa khóa ssh công khai cần thiết để xác minh.

Để khắc phục điều này, hãy đặt tệp "allow_key" vào cây thư mục không chứa mã hóa.


3

Giải pháp đơn giản mà tôi tìm thấy là di chuyển authorized_keystệp khỏi thư mục .ssh ẩn và đặt nó vào thư mục ssh hệ thống:

/etc/ssh/keys/authorized_keys

Ngay sau khi tôi làm điều này, nó hoạt động không có vấn đề gì.


3

gặp sự cố tương tự trong windows server 2008 r2 và đã khám phá rất nhiều cách để giải quyết, cuối cùng đã làm được điều đó bằng cách sau:

mở C: \ Program Files (x86) \ OpenSSH \ etc \ sshd_config bằng textpad hoặc bất kỳ trình soạn thảo văn bản nào khác

xóa nhận xét khỏi các dòng sau, sau khi xóa, chúng sẽ trông giống như sau:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

lưu nó và cố gắng đăng nhập bằng khóa cá nhân ngay bây giờ. chúc vui vẻ.


ssh đôi khi được cài đặt w / dòng authorizedkeysfile nhận xét ra vì vậy nó không biết được nơi để tìm kiếm các tập tin phím ủy quyền :-(
kenyee

Các quyền cần thiết cho tệp ủy quyền là gì? Và nó có phải nằm trong thư mục người dùng hoặc trong thư mục của OpenSSH không?
GarfieldKlon

Nó phải nằm trên thư mục OpenSSH hoặc nơi bạn đã cài đặt OpenSSH của mình. bạn sẽ có thể tìm thấy nó
Ravi Anand

Đảm bảo rằng bạn đang thiết lập nó bằng tài khoản Admin.
Ravi Anand

2

Nhờ nrathaus và /var/log/auth.logđiều tra về cấp độ gỡ lỗi đến như sau.

Một lý do khác là thư mục chính của bạn có thể có các quyền khác với 755.


Thư mục chính của bạn phải là 700, đó là mặc định trên CentOS.
karatedog

2

Tôi gặp sự cố này ngày hôm nay và vấn đề của tôi là khi sao chép khóa công khai từ tệp, các ký tự dòng mới cũng được bao gồm. Bạn có thể sử dụng ": set list" trong vim để xem tất cả các dòng mới bị ẩn và đảm bảo xóa tất cả các dòng mới ngoại trừ dòng cuối cùng. Ngoài ra, khóa của tôi lúc đầu bị thiếu "ssh-rsa". Hãy chắc chắn rằng bạn cũng có điều đó.


1
Tương tự ở đây: khi sao chép từ PuttyGen, tôi có các dòng mới sau "ssh-rsa" và sau khóa. Sau khi loại bỏ chúng, nó đã hoạt động.
Lucian P.

1

Đối với những người nhận được lỗi này từ Windows Server, tôi cũng gặp lỗi này và đó là sự cố tài khoản người dùng. Với nhiều tổ chức, chính sách nhóm dành cho Quản trị viên có thể không cho phép thiết lập Máy chủ SSH và các kết nối. Với kiểu thiết lập đó, việc này phải được thực hiện từ tài khoản Quản trị viên cục bộ. Có thể đáng để xem xét nếu bạn đã xác nhận rằng không có bất kỳ lỗi chính tả nào trong khóa công khai.


1

Trong trường hợp của tôi, tôi đã phải tắt SELinux trên Centos6.6 để nó hoạt động :)

Chỉnh sửa / etc / selinux / config và thiết lập như sau, sau đó khởi động lại máy chủ.

selinux=disabled

BTW ... quên đề cập rằng tôi phải đặt LogLevel = DEBUG3 để xác định sự cố.


1
Thay vì tắt SELinux, bạn có thể thay đổi ngữ cảnh bảo mật trên thư mục .ssh. chcon -R -t ssh_home_t .ssh
palehorse

1

Tôi đã gặp lỗi tương tự trên solaris nhưng tìm thấy trong /var/adm/splunk-auth.log như sau:

sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed

Trong / etc / shadow, tài khoản đã bị khóa:

weblogic:*LK*UP:16447::::::3

Đã xóa phần "* LK *":

weblogic:UP:16447::::::3

và tôi có thể sử dụng ssh với Authority_keys như bình thường.


1

Trong trường hợp của tôi, nó được gây ra bởi ( /etc/ssh/sshd_config):

PermitRootLogin no

Đã thay đổi thành yes, khởi động lại dịch vụ và vào bình thường.


1

Tôi đã giải quyết được vấn đề này, puttygen là phần mềm của bên thứ ba, khóa ssh do nó tạo ra không được sử dụng trực tiếp, vì vậy bạn phải thực hiện một số thay đổi. Ví dụ, nó trông như thế này

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ---- 

Tôi bỏ một số bảng chữ cái ở giữa, thay thế bằng *, nếu không, StackOverflow nói với tôi rằng định dạng mã sai, đừng cho tôi đăng。

đây là khóa ssh của tôi được tạo bởi puttygen, bạn phải thay đổi thành này

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname

Trong trường hợp của tôi, tôi đã xóa một số nhận xét, chẳng hạn như

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----

và thêm ssh-rsavào đầu, thêm yourname@hostnamevào cuối. lưu ý : không xóa ==cuối cùng và bạn phải thay đổi "tên của bạn" và "tên máy chủ" cho bạn, Trong trường hợp của tôi, tên của bạn uaskh@mycomputerlà bạn muốn đăng nhập vps của mình. Khi tất cả những điều này đã hoàn thành, bạn có thể tải lên công khai -key nhà uaskh của ~/.ssh/authorized_keysbởi cat public-key >> ~/.ssh/authorized_keyssau đó sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keyssau đó bạn phải chỉnh sửa / etc / ssh / sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keyshệ điều hành của tôi là CentOS 7, Đây là lần đầu tiên tôi đến anwser câu hỏi, tôi sẽ cố gắng nỗ lực của tôi để làm, Cảm ơn bạn!


1
@Ronak Bhatt, Cảm ơn những nỗ lực của bạn, tôi đã cố gắng làm cho mã rõ ràng hơn, đối với tất cả mã này, tôi đã sử dụng ctrl + K, nhưng StackOverflow nói với tôi "kháng nghị câu trả lời của bạn chứa mã, vui lòng sử dụng định dạng đúng" và tôi không hiểu tại sao nó khác nhau giữa viết và gửi, tôi không thể gửi câu trả lời của mình, dẫn đến việc tôi phải thêm mã vào 'mã' từng dòng. Tôi sẽ học định dạng đánh dấu, nghĩ.
hạt nhân

Trong phiên bản hiện tại PuttyGen sẽ hiển thị khóa công khai ở định dạng chính xác để sao chép và dán. Vì vậy, không cần phải chuyển đổi thủ công key pub putty sang định dạng chính xác.
Erik Kalkoken

1

Ôi Chúa ơi, tôi đã mất nhiều ngày để cố gắng sửa lỗi này. Vì vậy, đây là những gì đã làm việc cho tôi. Tôi quay lại màn hình đầu tiên như sau: cd / root / mkdir .ssh cd .ssh chmod 700 .ssh nano -w allow_keys service ssh restart Vì vậy, tôi đã sử dụng root để đăng nhập thông qua Putty và nó đã hoạt động. vì vậy hãy cố gắng làm điều tương tự với người dùng mà bạn muốn sử dụng trong putty.


0

Tôi đang sử dụng tệp PUTTYgen với psftp và tôi đã gặp sự cố này trên Máy chủ Windows của mình khi chúng tôi được yêu cầu tạo khóa mới cho máy khách. Tệp private_key_name .ppk và tệp open_ssh.txt phải nằm trong cùng một thư mục để kết nối hoạt động.


0

Trong trường hợp của tôi, home trên nfs là 777, cần là 750. Điều đó đã khắc phục được sự cố.


0

Tôi gặp sự cố này trong đó sshd chỉ đọc từ authorized_keys2.

Sao chép hoặc đổi tên tệp đã khắc phục sự cố cho tôi.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

PS Tôi đang sử dụng Putty từ Windows và đã sử dụng PuTTyKeygen để tạo cặp khóa.


0

Tôi đã gặp phải vấn đề tương tự khi cố gắng đăng nhập qua Mobaxterm. Khóa cá nhân được tạo thông qua puttygen. Tạo lại khóa đã hữu ích trong trường hợp của tôi.


0

Khi sử dụng Cpanel, bạn có thể kiểm tra xem khóa có được cấp quyền hay không

SSH Access >> Khóa công khai >> Quản lý >> Ủy quyền hoặc Hủy ủy quyền.


0

nếu bạn gặp lỗi này trong /var/log/secure

error: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG + rKz93l7em1BsUBzjHPMsswD

nó có nghĩa là khóa của bạn đang có khoảng trống, nếu bạn tạo khóa thông qua puttgen khi bạn xem .ppktệp, nó sẽ giống như sau:

AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==

và khi bạn cố gắng dán nó, bạn sẽ gặp lỗi khi đọc khóa, vì vậy hãy cố gắng chỉnh sửa khóa và tạo thành một dòng và thử nó

cái này sẽ giống cái gì đó

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname


0

Những gì hiệu quả với tôi là:

  • Đã dừng phiên bản ec2
  • tách âm lượng ra
  • đính kèm âm lượng với phiên bản cũ bằng cùng một phím và có thể SSH
  • gắn ổ đĩa vào một số thư mục tạm thời
  • đã kiểm tra tệp trong thư mục mount_point / home / ec2-user / .ssh / allow_keys
    • Tốt nhất, tệp này cần có thông tin chính của chúng tôi nhưng đối với tôi tệp này trống
  • đã sao chép tệp ủy quyền phiên bản cũ sang ổ đĩa mới được gắn kết
  • ngắt kết nối thiết bị
  • gắn lại với phiên bản ec2 ban đầu
  • khởi động nó và để nó vượt qua kiểm tra sức khỏe

Lần này nó làm việc cho tôi. Nhưng tôi không biết tại sao nó không có thông tin tệp chính của tôi lúc đầu khi phiên bản được khởi chạy. Kiểm tra liên kết này quá https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm


0

Trong trường hợp của tôi, vấn đề là như thế này, trong quá trình tạo khóa ssh, tôi đã cố ý thay đổi thư mục mặc định của các khóa. Vì vậy, thay vì sử dụng vị trí ~ / .ssh / allow_keys mà tôi đã chọn sử dụng ~/home/user/folder1/.ssh/authorized_keys, để những thay đổi này hoạt động, tôi phải thực hiện các thay đổi tương tự về vị trí mới trên tệp này /etc/ssh/sshd_config. Nhưng cho đến khi tôi nhận ra điều này, tôi đã thử một số giải pháp do những người khác ở đây đề xuất bao gồm đặt quyền của thư mục chính 700và thư mục .ssh thành 600.


0

Các bước sửa lỗi Root mount (Tôi đã làm theo khi thay đổi quyền với thư mục ec2-user và tệp khóa ủy quyền) Quá trình này sẽ tương tự như tách và đính kèm một ổ bút

Dưới đây là một số trường hợp khác mà bạn có thể gặp phải -

  1. Bạn đang sử dụng khóa cá nhân SSH nhưng khóa công khai tương ứng không có trong tệp ủy quyền.
  2. Bạn không có quyền đối với tệp ủy quyền của mình.
  3. Bạn không có quyền đối với thư mục .ssh.
  4. Tệp ủy quyền của bạn hoặc thư mục .ssh không được đặt tên chính xác.
  5. Tệp ủy quyền của bạn hoặc thư mục .ssh đã bị xóa.

Các bước để khắc phục chúng

  • Dừng phiên bản Ec2 có vấn đề
  • Tách ổ đĩa gốc (/ dev / sda1)
  • Tạo một phiên bản ec2 hoặc sử dụng một phiên bản đang chạy
  • Gắn ổ đĩa tách rời (/ dev / sdvf) vào phiên bản ec2 mới

Bây giờ sau khi bạn đăng nhập vào ec2 mới, hãy chạy các bước dưới đây

  • Lệnh lsblk - liệt kê tất cả các mount có sẵn
  • Chọn giá trị gắn kết mà bạn ngắt kết nối khỏi trường hợp có vấn đề
  • Khi người dùng ec2 chạy “sudo mount / dev / mapper / rootvg-home / mnt” sudo mount /dev/mapper/rootvg-home /mnt
  • Sau đó thay đổi thư mục thành / mnt
  • Thực hiện tất cả các thay đổi cần thiết

Bây giờ chúng tôi đã sửa khối lượng của mình với vấn đề mà chúng tôi phải đối mặt. Chủ yếu đó có thể là vấn đề về quyền của người dùng - Umount / mnt để ngắt kết nối nó - Bây giờ hãy truy cập bảng điều khiển và chỉ vào ổ đĩa được đính kèm với phiên bản mới và tách nó ra - Sau khi tách ra, hãy gắn nó vào ổ đĩa mới của bạn với tên / dev / sda1

Với điều đó đã nói, bạn sẽ có thể đăng nhập thành công


0

Theo kinh nghiệm của tôi, tôi khuyên bạn nên tạo khóa từ putty, không nên tạo từ phía linux. Vì khóa sẽ là định dạng PEM cũ. Dù sao, chỉ là gợi ý của tôi. Tôi đã làm như các bước dưới đây và làm việc tốt với tôi và với nhóm của tôi.

  1. Tạo một cặp khóa với PuTTYGen.exe trên cục bộ của bạn (loại: RSA, độ dài: 2048 bit).

  2. Lưu khóa cá nhân / công khai dưới dạng tệp " id_rsa.ppk / id_rsa.pub " trên cục bộ của bạn.

  3. Tạo "authorized_keys" tập tin trên địa phương của bạn, sau đó nhập khóa công khai trong " id_rsa.pub " thành " authorized_keys ". Hãy nhớ rằng nội dung phải bắt đầu bằng " ssh-rsa " và chỉ một dòng .

nhập mô tả hình ảnh ở đây

  1. Sử dụng WinScp (hoặc lệnh putty) để sao chép " allow_keys & id_rsa.pub " từ cục bộ sang linux-user-home " /home/$USER/.ssh/ " của bạn.

nhập mô tả hình ảnh ở đây

  1. Chạy các lệnh sau:

    chmod 700 .ssh

    chmod 600 .ssh / allow_keys

    chown $ USER: $ USER .ssh -R

  2. Kiểm tra cài đặt kết nối của bạn bằng cách tải khóa cá nhân " id_rsa.ppk " trong hồ sơ PuTTY.exe, sau đó nhấp vào mở (đặt cụm mật khẩu của bạn nếu có).

nhập mô tả hình ảnh ở đây

nhập mô tả hình ảnh ở đây


0

hãy kiểm tra khóa của bạn, hôm nay đây phải là khóa rsa (id_rsa.pub) và không còn là khóa dss (id_dsa.pub), sử dụng puttygen 0.70 và chọn RSA trên loại khóa để tạo, thay thế khóa công khai trên máy chủ ~ /. ssh / allow_keys


0

Sau khi thêm khóa, hãy đăng nhập như ec2-userthể bạn đang sử dụng máy Amazon Linux


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.