SSH กลับมาในรูปแบบที่ไม่ถูกต้อง


23

เมื่อไม่นานมานี้ฉันตั้งเซิร์ฟเวอร์บน AWS และใช้คีย์ SSH ที่สร้างขึ้น ฉันบันทึกรหัสไปยัง Lastpass และได้รับรหัสจากที่นั่นมาก่อนและทำให้มันใช้งานได้ อย่างไรก็ตามหลังจากลองอีกครั้งในวันนี้ฉันไม่สามารถทำงานได้

-rw------- 1 itsgreg users 1674 Jun 6 12:51 key_name

ฉันลองssh -i key_nameแล้วssh-keygen -f key_nameแต่ไม่มีอะไรทำงานฉันได้รับข้อความแสดงข้อผิดพลาดนี้เสมอ:

Load key "key_name": invalid format

มีวิธีแก้ไขปัญหานี้หรือไม่?

คำตอบ:


13

ตรวจสอบเนื้อหาของkey_nameถ้าตัวแทนบอกว่าinvalid formatมีบางอย่างผิดปกติกับกุญแจ - เช่น .. คุณแน่ใจหรือว่านั่นคือกุญแจที่ถูกต้อง? แม้ว่าจะไม่ใช่รหัสส่วนตัวที่คุณต้องการเอเจนต์ ssh จะไม่กลับมาinvalid formatหากคีย์ใช้งานได้คุณก็จะไม่สามารถเชื่อมต่อได้ คุณอาจวางกุญแจสาธารณะของคุณในนั้นด้วยเหตุผลบางอย่าง ตรวจสอบ!


5
ตรวจสอบอย่างแน่นอน เริ่มต้นด้วยและจบลงด้วย----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----บวกกับมันเคยทำงาน
Gregor Menih

2
ไม่น่าเป็นไปได้สูง แต่ยังคงเป็นไปได้คือไฟล์เสียหาย สร้างใหม่และเติมเนื้อหาอีกครั้งจาก Lastpass
13

2
ว้าวนั่นช่วยได้จริง! หลังจากสร้างรหัสใหม่ฉันสังเกตว่ารหัสใหม่มี 64 ตัวอักษรต่อบรรทัดในขณะที่รหัสเก่าของฉันมี 76 ฉันได้จัดรูปแบบกุญแจเก่าของฉันให้มีเพียง 64 ตัวอักษรต่อบรรทัดจากนั้นก็เริ่มทำงาน! ฉันยังขาดเส้นประหนึ่งจากบรรทัดแรก
Gregor Menih

2
"ฉันยังขาดเส้นประหนึ่งจากบรรทัดแรก" เหมือนกัน ขอบคุณ @ItsGreg สำหรับสิ่งนั้น ฉันคิดถึงตัวละครตัวแรกบ่อยๆเมื่อเลือกและคัดลอกระหว่างเทอร์มินัล!
starfry

15

สิ่งที่ฉันทำเพื่อแก้ไขปัญหานี้คือการที่ผมใช้ในการแปลงไฟล์ PPK PuttyGenโดยใช้

ก่อนอื่นให้โหลดurkey.PPKจากนั้นบนเมนูการแปลงให้คลิกส่งออกไปยังรูปแบบไฟล์ Openssh มันจะสร้างไฟล์ newkey

ตอนนี้ ssh -i "newkey" user@127.0.0.1

เสร็จสิ้น หวังว่ามันจะช่วย


4

ฉันขอให้ openssh ใช้ไฟล์ข้อมูลเฉพาะโดยระบุเป็นไฟล์. ssh / config

การกำหนดค่าการทำงานเดิมมี

IdentityFile = <path to public key file> 

สิ่งนี้หยุดทำงานโดยไม่มีการเปลี่ยนแปลงใด ๆ ในความคิดเล็กน้อยฉันแทนที่ "เส้นทางไปยังไฟล์กุญแจสาธารณะ" ด้านบนด้วย "เส้นทางไปยังไฟล์กุญแจส่วนตัว" ที่ได้ผล เหตุผลก็คือทั้งไฟล์สาธารณะและกุญแจส่วนตัวมีจำนวนมากที่เกี่ยวข้องกับ peudoprime ตามอัลกอริทึม RSA หากคุณแทนที่ไฟล์กุญแจส่วนตัวด้วยไฟล์กุญแจสาธารณะหมายเลขการเข้ารหัสเหล่านี้จะไม่ถูกแยกอย่างถูกต้องจากบล็อก base64 ที่บันทึกไว้ในไฟล์คีย์ ดูเหมือนว่าบางรุ่นของ ssh สามารถหาส่วนขยาย. pub และใช้เพื่อระบุไฟล์คีย์ส่วนตัวที่ถูกต้อง - และเวอร์ชันอื่น ๆ ก็ไม่ทำเช่นนั้น นี่เป็นอีกวิธีหนึ่งที่ข้อผิดพลาดนี้สามารถเกิดขึ้นได้ หวังว่าจะช่วยใครซักคน


ในกรณีของฉันฉันมีconfigไฟล์ติดตั้งpath_to_public_keyและทุกอย่างทำงานได้ อย่างไรก็ตามเมื่อ mac ทำการรีสตาร์ทอย่างหนักและไม่กี่วันต่อมาฉันพยายามทำgit pushฉันเริ่มรับข้อผิดพลาดที่ระบุไว้ด้านบน แต่เมื่อฉันเปลี่ยนมันเป็นpath_to_private_keyสิ่งที่กำลังทำงาน ... อืม ไม่แน่ใจว่าทำไม ..
lukik

3

ฉันมีปัญหาเดียวกันและปรากฎว่าฉันมีตัวแยกบรรทัดสไตล์ Windows (CRLF) ในไฟล์ด้วยเหตุผลบางอย่าง

นอกจากนี้ไฟล์จะต้องลงท้ายด้วย LF เดียว

แก้ไขสิ่งเหล่านั้นทำให้สิ่งที่สวยงามอีกครั้ง


เป็นเรื่องที่น่าตกใจว่า LF สุดท้ายนั้นมีความจำเป็น แต่ก็เป็นปัญหาบางส่วนด้วยส่วนอื่นที่ฉันสร้างไฟล์ใน Windows และการทำเช่นนั้นจะทำให้ CRLF มีการแบ่งบรรทัด สำหรับการอ้างอิงของผู้อื่นdos2unixคือคำสั่งในการแปลงจากตัวแบ่งบรรทัด CRLF (Windows-style) เป็น LF (Linux-style)
Hashim

1

คุณควรแปลงคีย์. pkk เป็น OpenSSH

นี่คือวิธีที่คุณทำ :

  1. ดาวน์โหลด PuttyGen และสร้าง keypair ของคุณ (หากคุณยังไม่พร้อม keypair) บันทึกคีย์ส่วนตัวในโฟลเดอร์ของคุณ (.ppk)
  2. หากคุณมีคีย์ส่วนตัวอยู่แล้วให้โหลดไฟล์ไพรเวตคีย์ (.ppk) โดยกดปุ่ม "โหลด" มิฉะนั้นข้ามขั้นตอนนี้
  3. ภายใต้เมนู "การแปลง" ให้เลือกส่งออกคีย์ OpenSSH แล้วบันทึกลงในโฟลเดอร์ของคุณ
  4. ตอนนี้คุณพร้อมที่จะใช้กุญแจในการเข้าสู่ระบบเซิร์ฟเวอร์ของคุณโดยไม่ต้องพิมพ์รหัสผ่าน (ฉันถือว่าคุณใส่รหัสสาธารณะภายใต้ /root/.ssh/authorized_keys, chmod 600 /root/.ssh/authorized_keys และเริ่ม SSH อสูรใหม่)

1

ฉันเพิ่งพบเจอสิ่งนี้ในวันนี้เมื่อกำลังเขียนการติดแท็ก git สำหรับท่อ CI ของฉัน

นี่คือความแตกต่างระหว่างสองปุ่มของฉัน:

$ diff ~/.ssh/gitlab ~/.ssh/git_ssh_key
27c27
< -----END OPENSSH PRIVATE KEY-----
---
> -----END OPENSSH PRIVATE KEY-----
\ No newline at end of file

ฉันเปลี่ยนรหัสอย่างเช่น:

     with open(ssh_key_file, 'w') as skf:
-        skf.write(ssh_key)
+        skf.write(ssh_key + '\n')

และตอนนี้คีย์ ssh ของฉันใช้งานได้

TL; DR - ฉันคิดว่าคุณต้องมีการขึ้นบรรทัดใหม่ที่ท้ายรหัสส่วนตัวของคุณ


1

ในกรณีของฉันปรากฎว่าฉันมีบรรทัดใหม่ระหว่าง "ส่วนหัว" เริ่มต้น / สิ้นสุดและข้อมูลสำคัญ:

-----BEGIN RSA PRIVATE KEY-----

- Key data here -

-----END RSA PRIVATE KEY-----

การลบบรรทัดใหม่พิเศษดังนั้นมันจึงกลายเป็น

-----BEGIN RSA PRIVATE KEY-----
- Key data here -
-----END RSA PRIVATE KEY-----

แก้ไขปัญหาของฉัน



0

ฉันมีปัญหานี้เพราะฉันมีคีย์ใน ~ / .ssh ซึ่งจริง ๆ แล้วเป็นรูปแบบที่ไม่ถูกต้องและฉันมีคีย์มากมายซึ่งหมายความว่า SSH พยายามทุกอย่างแม้ว่าฉันจะระบุไฟล์ข้อมูลประจำตัวในคำสั่ง มันเพิ่งจะเกิดความล้มเหลวเพราะมันสามารถลองได้แค่ 5 คีย์ที่ฉันคิดแล้วจากนั้นก็ทิ้งฉันไว้ที่ข้อผิดพลาดซึ่งเป็น Legit สำหรับไฟล์ข้อมูลประจำตัวที่ไม่ถูกต้อง ทางออกคือใช้IdentitiesOnly yesใน ~ / .ssh / config ของฉัน


0

ฉันมีข้อผิดพลาดนี้เนื่องจากมีบรรทัดว่างที่จุดเริ่มต้นของไฟล์คีย์ ง่ายที่จะพลาดถ้าคุณกำลังcatออกไป


0

นี่เป็นข้อผิดพลาด ssh (อย่างน้อยบางรุ่น) ส่งเสียงหากคุณมีข้อความรหัสผ่านในคีย์ส่วนตัวของคุณและป้อนข้อความรหัสผ่านผิดเมื่อคุณพยายามเชื่อมต่อ

(โดยเฉพาะสิ่งนี้เกิดขึ้นกับฉันด้วย: OpenSSH_7.6p1, LibreSSL 2.6.2 ซึ่งเป็น SSH ในตัวสำหรับ Mac OS X 10.13.6)

ดังนั้นตรวจสอบอีกครั้งว่าคุณกำลังใช้วลีรหัสผ่านที่ถูกต้องและ CAPS LOCK ปิดอยู่


-2

ตรวจสอบให้แน่ใจว่าคุณเปลี่ยนชื่อคีย์ส่วนตัวของคุณและลบนามสกุลไฟล์ที่เป็นปัญหา

ขั้นตอนที่ฉันทำ

สร้างกุญแจสาธารณะของคุณ:

ตรวจสอบให้แน่ใจว่าคุณอยู่ในไดเรกทอรีเดียวกับที่คุณมีคีย์ส่วนตัว

วิธีสร้างรหัสสาธารณะ:

ssh-keygen -y -f Private-Key.pem > Public-key.pub

ตรวจสอบให้แน่ใจว่าคีย์สาธารณะมีนามสกุลไฟล์. pub

หลังจากนั้นให้สิทธิ์ที่เหมาะสมด้วยเหตุผลด้านความปลอดภัย:

chmod 600 Private-Key.pem
chmod 400 Public-key.pub

ส่วนที่สำคัญที่สุดและสาเหตุที่คุณได้รับข้อผิดพลาด "รูปแบบที่ไม่ถูกต้อง"

ตรวจสอบให้แน่ใจว่าคุณเปลี่ยนชื่อคีย์ส่วนตัวและลบนามสกุลไฟล์:

เอา. pem ออกจากคีย์ส่วนตัวของคุณ

mv Private-Key.pem Private-Key

หรือถ้าในคอมพิวเตอร์ที่ใช้ windows เปลี่ยนชื่อไพรเวตคีย์ชื่อเดิมก็แค่ลบ .pem

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.