Lỗi SSH: loại khóa không xác định '----- BEGIN'


8

Tôi gặp sự cố khi sử dụng khóa được ủy quyền để đăng nhập SSH vào máy chủ từ xa. Các thông báo lỗi tôi nhận được trông như thế này:

OpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xx [xxx.xx.xx.xx] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /Users/bfenker/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
...
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/bfenker/.ssh/id_rsa type 1
ssh_exchange_identification: Connection closed by remote host

Các câu hỏi khác trên trang web này đã đăng các câu hỏi tương tự và giải pháp thường là kiểm tra kỹ tất cả các quyền ở phía máy khách, điều mà tôi đã thực hiện:

drwxr-xr-x+ 23 bfenker          staff   782 May  8 11:02 bfenker
drwx------   8 bfenker          staff   272 May  8 10:05 .ssh
-rw-------   1 bfenker  staff  1675 May  8 09:51 id_rsa
-rw-r--r--   1 bfenker  staff   418 May  8 09:51 id_rsa.pub
-rw-------   1 bfenker  staff   999 May  8 09:46 identity
-rw-r--r--   1 bfenker  staff   663 May  8 09:46 identity.pub
-rw-r--r--   1 bfenker  staff   416 May  8 09:06 known_hosts

Tôi có thể sử dụng khóa được ủy quyền để SSH vào một máy chủ khác và từ máy chủ này SSH vào máy chủ mà tôi muốn. Đây là một cách giải quyết có thể vượt qua mà tôi đang cố gắng khắc phục, nhưng tôi nghĩ nó cũng cho thấy rằng cả máy khách của tôi và máy chủ đều được thiết lập ổn.

Lưu ý rằng khi tôi SSH thành công vào một máy chủ khác, tôi nhận được các thông báo lỗi tương tự, nhưng dường như nó sẽ phục hồi bắt đầu bằng các dòng:

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0

Có ai biết tại sao điều này hoạt động trong một số trường hợp nhưng không phải trong trường hợp tôi muốn? Bất kỳ đề xuất khác sẽ được nhiều đánh giá cao!


Bạn đã thay đổi máy chủ /etc/hosts.allow/etc/hosts.denycác tập tin?
Michael Hampton

Câu trả lời:


13

Hoại tử! Dựa trên thực tế là bạn có thể sử dụng khóa này để đăng nhập vào máy chủ khác @ michael-hampton đang đi đúng hướng: có một cái gì đó (tường lửa / tcp Wrappers / sshd config) trên máy chủ đích đang từ chối truy cập. Tất cả điều này nói về các định dạng khóa không chính xác là một cá trích đỏ dựa trên việc giải thích không chính xác thông tin gỡ lỗi. Dòng

debug1: identity file /Users/bfenker/.ssh/id_rsa type 1

cho biết ssh đã có thể hiểu chìa khóa.


4
Điều này sẽ cao hơn, tôi đã có cùng một nhật ký như thế này, nhưng cuối cùng tôi đã hiểu khóa SSH và tôi đã không kết nối vì một lý do khác. Tại sao nó nói trong nhật ký nó không thể hiểu được chìa khóa, trong khi thực tế nó có thể, nằm ngoài tôi.
mgrandi

Trước tiên, nó cố gắng đọc nó ở một định dạng dòng duy nhất và nếu thất bại, nó sẽ xuất nó thành nhật ký dài dòng và sau đó thử các định dạng khác, điều này sẽ thành công.
Samoth

8

Khóa SSH của bạn được lưu trữ ở định dạng sai. OpenSSH sử dụng các khóa được đặt trong một dòng duy nhất. Bạn cần ssh-keygenvới -i-mcác tùy chọn, xem man ssh-keygen. Có lẽ một trong những điều này:

ssh-keygen -m RFC4716 -i -f /Users/bfenker/.ssh/id_rsa

Sử dụng đầu ra dưới dạng tệp khóa mới ( ssh-keygen ... >newkeyfile).

Chỉnh sửa 1:

Xin lưu ý điều này: "Tùy chọn này sẽ đọc một tệp khóa riêng tư (hoặc công khai) không được mã hóa "

Vì vậy, có lẽ tập tin phải được thay đổi thành một mà không có cụm mật khẩu bởi một chương trình hiểu định dạng đó.


Cảm ơn vì đã trả lời. Ứng dụng ssh-keygen của tôi không có -mtùy chọn và việc thử mà không có -mtùy chọn này gây ra lỗi này: buffer_get_string_ret: bad string length 813827235 key_from_blob: can't read key type decode blob failed.
fenkerbb

Sau đó, bạn nên kiểm tra tài liệu của phần mềm SSH hoặc thực hiện chuyển đổi trên hệ thống Linux bình thường (một hệ thống mà bạn tin tưởng).
Hauke ​​Laging

Hà! "Bình thường" linux! Tôi đang dùng MacOSX vì vậy tôi nhận thấy rằng hệ điều hành của tôi có thể là vấn đề ở đây.
fenkerbb

@fenkerbb Không phải hệ điều hành của bạn mà là định dạng khóa mặc định của việc triển khai SSH (= hệ điều hành) của bạn. Bạn sẽ có cùng một vấn đề với puttyWindows. Nhưng putty rất hay khi rất thuận tiện cung cấp cả hai định dạng ... (ít nhất là cho các khóa công khai)
Hauke ​​Laging

Tôi đã thử lệnh của bạn với một phiên bản khác của ssh-keygen và nhận được lỗi này buffer_get_string_ret: bad string length 813827235 Dòng đầu tiên của tệp chính của tôi là -----BEGIN RSA PRIVATE KEY-----và bắt đầu trên dòng tiếp theo là một danh sách dài các ký tự chữ và số. @Hauke ​​Laging
fenkerbb

1

Trước tiên, bạn nên kiểm tra nhật ký sshd của bạn. I E

less /var/log/secure

Tùy thuộc vào tệp phân phối unix với nhật ký bảo mật có thể khác nhau. Nhưng khi bạn tìm thấy nếu, nó sẽ cho biết lý do mà bạn không thể đăng nhập.


1

Tôi cũng phải đối mặt với vấn đề này gần đây. Trong trường hợp của tôi, tất cả các quyền đều đúng, bao gồm .ssh, tệp rsa, thư mục chính và mọi thứ liên quan đến người dùng. Vấn đề là tôi đã có một khóa công khai được tạo trước đó trong .ssh không tương ứng với khóa riêng tôi đang sử dụng để đăng nhập. Xóa khóa công khai khỏi .ssh đã khắc phục sự cố.

Tôi đã sử dụng ssh-keygen để tạo thư mục .ssh dẫn đến khóa pub này và do đó có vấn đề.


1

Tôi cảm thấy như câu trả lời ở đây không rõ ràng lắm. Câu trả lời của Mark Wagner không bao gồm nó, nhưng không giải thích đầy đủ tình huống.

Các dòng trong đầu ra được tiền tố với các mức gỡ lỗi của chúng, điều này cũng đưa ra gợi ý về tầm quan trọng của chúng: nhưng số thấp hơn có ý nghĩa hơn. Các debug3:công cụ ít quan trọng hơn nhiềudebug1:

Khi tệp khóa được đọc, ssh trước tiên cố gắng phân tích nó thành khóa RSA không dùng nữa (bây giờ được gọi là "RSA1"), các phím đó bắt đầu bằng SSH PRIVATE KEY FILE FORMATvà số phiên bản. Các khóa RSA mới đều bắt đầu -----BEGIN RSA PRIVATE KEY-----. Đây là một nỗ lực đăng nhập trong đó identitylà khóa kiểu RSA1 cũ và id_rsalà kiểu mới.

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type 0
debug1: identity file /home/user/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /home/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
[...]
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1

Tại thời điểm này nó đã xác định các loại chủ chốt trong các tập tin identitynhư type 0id_rsanhư type 1. Các tệp khác mà nó kiểm tra không tồn tại và do đó type -1.

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3

Vì đây là giao thức 2, khóa RSA của giao thức 1 identitysẽ bị bỏ qua trong quá trình trao đổi khóa.

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/id_rsa (0x5622d77426a0)
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))

Ở đây nó nhắc nhở chúng ta về các tập tin chính mà nó muốn sử dụng. Không chắc tại sao nó không từ chối các tệp bị thiếu, chỉ có tệp giao thức 1, nhưng ...

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
[...]
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 372 bytes for a total of 1689
debug1: Server accepts key: pkalg ssh-rsa blen 277

Và ở đây nó cung cấp id_rsachìa khóa và nó được chấp nhận.

Vì vậy, trong ngắn hạn, vấn đề trong tiêu đề câu hỏi là một cá trích đỏ xuất phát từ ssh cố gắng nhiều cách để phân tích các khóa mà nó tìm thấy, không phải là một vấn đề thực sự với một khóa.


0

Tôi gặp vấn đề tương tự trên MacBook Pro với MacOS 10.7.5. Không có gì sai với các khóa của tôi, chỉ là chúng được mã hóa (với cụm mật khẩu, giống như bạn phải làm) và không được mã hóa bởi ssh một cách chính xác. Có vẻ như ssh-agentđang có vấn đề.

Theo bài viết này , hãy thử điều này:

  1. Đặt /usr/bin/ssh-agentcác mục đăng nhập của bạn (Tùy chọn hệ thống -> Người dùng và nhóm -> chọn người dùng -> Mục đăng nhập). Rất khó để điều hướng /usr/bintrong hộp thoại, vì vậy bài viết đề nghị tạo một liên kết trong thư mục chính của bạn ( ln -s /usr/bin/ssh-agent) mà bạn có thể xóa sau khi bạn đặt nó vào Mục Đăng nhập.

  2. Thoát Terminal.app

  3. Khởi động lại máy.

  4. Mở Terminal và thử lại lệnh ssh của bạn.

Làm việc cho tôi (ít nhất, nó đã có một lần).

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.