ssh“ การอนุญาตเปิดเกินไป” ข้อผิดพลาด


2053

ฉันมีปัญหากับ mac ของฉันที่ฉันไม่สามารถบันทึกไฟล์ประเภทใด ๆ บนดิสก์อีกต่อไป ฉันต้องรีบูต OSX lion และรีเซ็ตสิทธิ์ของไฟล์และ acls

แต่ตอนนี้เมื่อฉันต้องการคอมมิทที่เก็บฉันได้รับข้อผิดพลาดต่อไปนี้จาก ssh:

Permissions 0777 for '/Users/username/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

ฉันควรให้สิทธิ์ระดับใดแก่ไฟล์ id_rsa


19
ขอบคุณสำหรับการถาม quesiton ประสบการณ์ที่ดีขึ้นสำหรับผู้ที่เขียนข้อความแสดงข้อผิดพลาดนี้เพื่อแนะนำการกำหนดค่าที่ถูกต้องบางอย่าง (เช่น 600 หรือ 400 ตามที่แนะนำด้านล่าง) โปรแกรมเมอร์ไม่ได้เขียนข้อความแสดงข้อผิดพลาดที่เพียงพอซึ่งเป็นประโยชน์ทำให้เราทุกคนทรมานเป็นเวลาหลายปี!
George Pligoropoulos

FWIW สิ่งนี้เกี่ยวข้องกับStrictModesการเปิดใช้งานบนsshdเซิร์ฟเวอร์จากหน้าคน : "StrictModes ระบุว่า sshd (8) ควรตรวจสอบโหมดไฟล์และการเป็นเจ้าของไฟล์ของผู้ใช้และโฮมไดเรกทอรีก่อนยอมรับการลงชื่อเข้าใช้" - คุณสามารถปิดใช้งานสิ่งนี้ได้ แต่ไม่แนะนำ
masseyb

คำตอบ:


3470

กุญแจจะต้องอ่านได้โดยคุณเท่านั้น:

chmod 400 ~/.ssh/id_rsa

หากคุณจำเป็นต้องอ่านคีย์ได้:

chmod 600 ~/.ssh/id_rsa

600ดูเหมือนจะใช้ได้เช่นกัน (ในความเป็นจริงแล้วส่วนใหญ่ดีกว่าเพราะคุณไม่จำเป็นต้องเปลี่ยนการอนุญาตไฟล์ในภายหลังเพื่อแก้ไข)

ส่วนที่เกี่ยวข้องจาก manpage ( man ssh)

 ~/.ssh/id_rsa
         Contains the private key for authentication.  These files contain sensitive 
         data and should be readable by the user but not
         accessible by others (read/write/execute).  ssh will simply ignore a private 
         key file if it is              
         accessible by others.  It is possible to specify a
         passphrase when generating the key which will be used to encrypt the sensitive 
         part of this file using 3DES.

 ~/.ssh/identity.pub
 ~/.ssh/id_dsa.pub
 ~/.ssh/id_ecdsa.pub
 ~/.ssh/id_rsa.pub
         Contains the public key for authentication.  These files are not sensitive and 
         can (but need not) be readable by anyone.

299
400 ต่ำเกินไปเนื่องจากผู้ใช้ของคุณไม่สามารถเขียนได้ แนะนำให้ใช้จริง 600 เพราะช่วยให้เจ้าของอ่าน - เขียนไม่ใช่แค่อ่าน
jfreak53

8
ฉันค้นพบวันนี้มีบางครั้งที่เกี่ยวข้อง 400 สมมติว่าคุณมีไฟล์ authorized_keys ที่มีการตั้งค่าฟีเจอร์no-pty และ al หากไฟล์นั้นสามารถเขียนได้ผู้ใช้สามารถเขียนทับไฟล์ที่ได้รับอนุญาตและได้รับสิทธิ์การเข้าถึงเชลล์แบบโต้ตอบ! สิ่งที่ต้องจำไว้ แต่ก็ไม่ใช่กรณีทั่วไปสำหรับคนส่วนใหญ่
quickshiftin

17
AWS แนะนำให้อนุญาตจริง 400 บนเว็บไซต์ของพวกเขา นั่นคือสิ่งที่ฉันทำบน OS X และใช้งานได้
George Mylonas

5
วิธีนี้ใช้ได้ผลและปลอดภัยกว่า ข้อเสียเพียงอย่างเดียวคือคุณต้องเปลี่ยนเป็น 600 เพื่อแก้ไข สำหรับ id_rsa และ id_rsa.pub ฉันสงสัยว่าสำคัญเพราะคุณไม่ค่อยจะแก้ไขไฟล์เหล่านั้น แต่สำหรับ authorized_keys อาจเป็นเรื่องที่น่ารำคาญ ดีที่สุดในการทำความเข้าใจการแลกเปลี่ยนและกำหนดค่าแต่ละระบบอย่างเหมาะสม
quickshiftin

3
ฉันคิดว่ามันยังขึ้นอยู่กับว่าคุณแก้ไขบ่อยแค่ไหน หลายคนตั้งค่าและลืมมันดังนั้น 400 จะปลอดภัยกว่าจากผู้อื่นและการกระทำของคุณเอง แก้ไขเป็น 600 เมื่อจำเป็น ถ้ามันเป็นส่วนหนึ่งของเวิร์กโฟลว์และ ssh-savy ของคุณบางทีมันอาจจะเป็นอุปสรรคในการเปลี่ยนการอนุญาต
vol7ron

99

การใช้ Cygwin ใน Windows 8.1 จะต้องมีคำสั่งให้เรียกใช้:

ผู้ใช้ chgrp ~ / .ssh / id_rsa

จากนั้นโซลูชันที่โพสต์ที่นี่สามารถใช้ได้ 400 หรือ 600 ก็โอเค

chmod 600 ~ / .ssh / id_rsa

Ref: http://vineetgupta.com/blog/cygwin-permissions-bug-on-windows-8


8
สถานที่เกิดเหตุขึ้น ฉันต้องเรียกใช้ "chgrp Użytkownicy ~ / .ssh / id_rsa" เนื่องจาก "ผู้ใช้" ไม่มีข้อผิดพลาดในกลุ่มดังกล่าว
Marcos

ฉันต้องทำเช่นนี้เช่นกัน ไดเรกทอรี cygwin ของฉันอยู่ในตำแหน่งเริ่มต้น ( C:\cygwin64) ดังนั้นจึงอาจสืบทอดสิทธิ์ แปลกที่สิ่งนี้ไม่ได้เกิดขึ้นกับแล็ปท็อปเครื่องอื่นที่ฉันเป็นเจ้าของ
Zach Thacker

3
@Marcos ฉันได้เพิ่มคำตอบที่ทำงานโดยไม่คำนึงถึงสถานที่: stackoverflow.com/a/28647713/67013
thehouse

4
Windows 10. ใช้คำสั่งที่สองเท่านั้น ทำงานเหมือนจับใจ
StalkAlex

โปรดทราบว่าสำหรับการติดตั้งในภาษาอื่นกลุ่ม 'ผู้ใช้' มีตัวระบุสำรอง
John Rumpel

43

โซลูชันที่ไม่ขึ้นกับตำแหน่งที่ตั้งที่ทำงานบน Windows 8.1 คือ:

chgrp 545 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

GID 545 เป็นรหัสพิเศษที่อ้างอิงถึงกลุ่ม 'ผู้ใช้' เสมอแม้ว่าคุณจะใช้ภาษาอื่นสำหรับผู้ใช้



24

AFAIK ค่าคือ:

700 สำหรับไดเรกทอรีที่ซ่อนอยู่ ".ssh" ซึ่งเป็นที่ตั้งของไฟล์คีย์

600 สำหรับ keyfile "id_rsa"


19

ฉันมีข้อผิดพลาดใน windows 10 ของฉันดังนั้นฉันจึงตั้งค่าการอนุญาตดังต่อไปนี้และทำงาน

การอนุญาตสำหรับ id_rsa ของ windows 10

ในรายละเอียดลบผู้ใช้ / กลุ่มอื่น ๆ จนกว่าจะมีเพียง 'ระบบ' และ 'ผู้ดูแลระบบ' จากนั้นเพิ่ม windows ของคุณเข้าสู่ระบบด้วยสิทธิ์ในการอ่านเท่านั้น

ให้สังเกตว่าid_rsaไฟล์นั้นอยู่ในc:\users\<username>โฟลเดอร์


ฉันมีปัญหาเดียวกันกับ Win-10 จากคำอธิบายของคุณไม่ชัดเจนว่าคุณอนุญาตและปฏิเสธอะไรจริง ๆ - ฉันมี "ผู้ใช้" และ "ผู้ใช้ที่ได้รับการรับรองความถูกต้อง" และ "ผู้ใช้เฉพาะ" เป็นตัวเลือก + ระบบและผู้ดูแลระบบ นอกจากนี้ฉันไม่สามารถคิด cygwin - เพื่อติดตั้งหรือใช้ (?)
Sam-T

2
สำหรับ Win10 ต้องย้ายกุญแจของคุณไปที่บ้านของผู้ใช้ - สิ่งนี้ทำงานได้อย่างสมบูรณ์ ฉันพยายามให้เต็มเส้นทางกับคีย์และ messing กับสิทธิ์ - ไม่มีอะไรทำงาน
Sam-T

@ Sam-T หากคุณไม่เห็นชื่อของคุณในรายการคุณสามารถเพิ่มได้โดยกด Edit...แล้วกดAdd...จากนั้นพิมพ์ชื่อของคุณในกล่องข้อความ"Enter the object names to select"จากนั้นกดCheck Namesปุ่ม (และกดOKและอื่น ๆOK) จากนั้นชื่อของคุณควรจะแสดงรายการในSecurityแท็บ
Supawat Pusavanno

ฉันอาจเพิ่มชื่อเฉพาะ - ตามคำแนะนำของคุณ แต่คำถามหลักของฉันเป็น - สิ่งที่แน่นอนสิทธิ์ที่จะปฏิเสธและอนุญาตให้สำหรับทุก ในขณะเดียวกันดังกล่าวฉันสามารถแก้ปัญหาได้โดยเพียงเพิ่ม.pemไปที่myuser directory
Sam-T

15

มีข้อยกเว้นหนึ่งข้อสำหรับสิทธิ์การใช้ "0x00" บนคีย์ หากคีย์นั้นเป็นเจ้าของโดยรูทและเป็นเจ้าของกลุ่มโดยกลุ่มที่มีผู้ใช้อยู่ในนั้นก็อาจเป็น "0440" และผู้ใช้ในกลุ่มนั้นสามารถใช้คีย์ได้

ฉันเชื่อว่าสิ่งนี้จะใช้ได้กับการอนุญาตใด ๆ ในชุด "0xx0" แต่ฉันไม่ได้ทดสอบทุกชุดค่าผสมกับทุกรุ่น ฉันลอง 0660 กับ 5.3p1-84 บน CentOS 6 และกลุ่มไม่ใช่กลุ่มหลักของผู้ใช้ แต่เป็นกลุ่มรองและทำงานได้ดี

โดยทั่วไปจะไม่สามารถทำได้สำหรับคีย์ส่วนตัวของใครบางคน แต่สำหรับคีย์ที่ใช้สำหรับระบบอัตโนมัติในสถานการณ์ที่คุณไม่ต้องการให้แอปพลิเคชันยุ่งกับกุญแจ

กฎที่คล้ายกันนำไปใช้กับข้อ จำกัด ของไดเรกทอรี. ssh



11

สำหรับ Windows 10 chmod และ chgrp ของ cygwin ไม่เพียงพอสำหรับฉัน ฉันต้องคลิกขวาที่ไฟล์ -> คุณสมบัติ -> ความปลอดภัย (แท็บ) และลบผู้ใช้และกลุ่มทั้งหมดยกเว้นผู้ใช้ที่ใช้งานอยู่


นี่เป็นวิธีเดียวที่ใช้งานได้ดี :) ขอบคุณคุณประหยัดเวลา
Atul

ฉันพบว่าหลังจากทำเช่นนี้ฉันสามารถทำ ssh จากพรอมต์คำสั่ง Windows ปกติได้เช่นกัน ไม่จำเป็นต้องใช้ Cygwin ที่ดี!
Atul

8

นี่คือสิ่งที่ได้ผลสำหรับฉัน (บน mac)

sudo chmod 600 path_to_your_key.pem 

จากนั้น:

ssh -i path_to_your_key user@server_ip

หวังว่ามันจะช่วย


5

อะไรที่เหมาะกับฉัน

chgrp ผู้ใช้โฟลเดอร์

chmod 600 โฟลเดอร์


chgrp: grupo inválido: « Users »

ฉันพยายาม แต่ยังคงละทิ้ง 'กลุ่มที่ไม่ถูกต้อง': ผู้ใช้ '' ทำไม ใช้ Windows 10, powershell
Jason Goal


4

ฉันมีปัญหาเดียวกันหลังจากการย้ายจากแม็คเครื่องอื่น และมันถูกบล็อคไม่ให้เชื่อมต่อ Github ด้วยกุญแจของฉัน

ฉันรีเซ็ตการอนุญาตตามด้านล่างและทำงานได้ดีในขณะนี้

chmod 700 ~/.ssh     # (drwx------)
cd ~/.ssh            
chmod 644 *.pub      # (-rw-r--r--)
chmod 600 id_rsa     # (-rw-------)

4

ข้อผิดพลาด“ สิทธิ์อนุญาตเปิดเกินไป” บน Windows 10 ใน Ubuntu EC2 ของ AWS

ฉันมีปัญหานี้พยายาม ssh เป็นอินสแตนซ์ Ubuntu EC2 โดยใช้ไฟล์. pem จาก AWS

ใน windows นี้ทำงานเมื่อฉันใส่คีย์นี้ในการสร้างภายใต้โฟลเดอร์. ssh

C:\Users\USERNAME\.ssh\private_key

วิธีเปลี่ยนการตั้งค่าการอนุญาตใน Windows 10:

การตั้งค่าไฟล์> ความปลอดภัย> ขั้นสูง

ปิดใช้งานการสืบทอด

แปลงสิทธิ์ที่สืบทอดมาให้เป็นสิทธิ์ที่ชัดเจน

ลบรายการการอนุญาตทั้งหมดยกเว้นสำหรับผู้ดูแลระบบ

สามารถเชื่อมต่อได้อย่างปลอดภัย


4

สำหรับฉัน (ใช้ระบบย่อย Ubuntu สำหรับ Windows) ข้อความแสดงข้อผิดพลาดเปลี่ยนเป็น:

 Permissions 0555 for 'key.pem' are too open

หลังจากใช้ chmod 400 ปรากฎว่าการใช้รูทเป็นผู้ใช้เริ่มต้นคือเหตุผล

เปลี่ยนสิ่งนี้โดยใช้คำสั่ง:

 ubuntu config --default-user your_username

3

ข้อความที่น่าสนใจที่นี่ ระบบปฏิบัติการฉลาดพอที่จะปฏิเสธการเชื่อมต่อระยะไกลหากคีย์ส่วนตัวของคุณเปิดอยู่ มันเข้าใจถึงความเสี่ยงที่สิทธิ์สำหรับ id_rsa เปิดกว้าง (ทุกคนสามารถอ่านได้สามารถแก้ไขได้)

{หนึ่งอาจเปลี่ยนล็อคของคุณก่อนแล้วเปิดด้วยกุญแจที่เขามีอยู่แล้ว}

cd ~/.ssh
chmod 400 id_rsa

ในขณะที่ทำงานกับเซิร์ฟเวอร์หลายเครื่อง (ไม่ใช่การผลิต) เราส่วนใหญ่รู้สึกว่าจำเป็นต้องเชื่อมต่อเซิร์ฟเวอร์ระยะไกลด้วย ssh ความคิดที่ดีคือการมีโค้ดระดับแอปพลิเคชัน (อาจเป็นจาวาโดยใช้ jsch) เพื่อสร้าง ssh trusts ระหว่างเซิร์ฟเวอร์ การเชื่อมต่อด้วยวิธีนี้จะใช้รหัสผ่านน้อย ในกรณีที่มีการติดตั้ง Perl - หนึ่งอาจใช้โมดูล Net ssh เช่นกัน


1

ฉันพบข้อผิดพลาดนี้ขณะที่ฉันเล่นกับ Ansible ฉันได้เปลี่ยนการอนุญาตของไพรเวตคีย์เป็น600เพื่อแก้ไขปัญหานี้ และมันก็ใช้งานได้!

chmod 600 .vagrant/machines/default/virtualbox/private_key

1

ฉันลองใช้สิทธิ์ระดับ 600 สำหรับคีย์ส่วนตัวของฉันแล้วก็ใช้ได้สำหรับฉัน chmod 600 privateKey [dev] $ ssh -i privateKey user @ ip ทำงาน

chmod 755 privateKey [dev] $ ssh -i privateKey ผู้ใช้ @ ip มันให้ด้านล่างปัญหา: สิทธิ์ 0755 สำหรับ 'privateKey' เปิดเกินไป จำเป็นต้องให้ผู้อื่นไม่สามารถเข้าถึงไฟล์กุญแจส่วนตัวของคุณได้ คีย์ส่วนตัวนี้จะถูกละเว้น โหลดคีย์ "privateKey": สิทธิ์ที่ไม่ถูกต้อง


0
I have got the similar issue when i was trying to login to remote ftp server using public keys..        
To solve this issue initially i have done the following process
    ก่อนอื่นให้หาที่ตั้งของกุญแจสาธารณะเพราะเมื่อคุณพยายามเข้าสู่ ftp โดยใช้กุญแจสาธารณะนี้ ก่อนอื่นเราต้องสร้างคีย์และตั้งค่าให้อนุญาตการตั้งค่าคีย์เป็น 600
            ตรวจสอบให้แน่ใจว่าคุณอยู่ในตำแหน่งที่ถูกต้อง
            ขั้นตอนที่ 1:
            ไปยังตำแหน่งที่ถูกต้อง
            ขั้นตอนที่ 2:
            หลังจากคุณอยู่ในตำแหน่งที่ถูกต้อง
 คำสั่ง: 
     chmod 600 id_rsa

        This has solved my issue.

-1

ฉันกำลังใช้ VPC บน EC2 และได้รับข้อความแสดงข้อผิดพลาดเดียวกัน ฉันสังเกตว่าฉันใช้ DNS สาธารณะ ฉันเปลี่ยนเป็น DNS ส่วนตัวและ vola !! มันทำงานได้ ...


Amazon แนะนำ chmod 400 และใช้ DNS สาธารณะ อ้างถึงเอกสารที่นี่: docs.aws.amazon.com/AWSEC2/latest/UserGuide/…
ddri

-2

สำหรับ Win10 ต้องย้ายคีย์ของคุณไปยัง dir บ้านของผู้ใช้สำหรับ linuxlike os คุณต้องการ chmod เป็น 700 like หรือ 600 เป็นต้น


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