ทำไมฉันถึงได้รับ“ การอนุญาตถูกปฏิเสธ (publickey)” เมื่อพยายามที่จะ SSH จากอูบุนตูท้องถิ่นไปยังเซิร์ฟเวอร์ Amazon EC2?

218

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

ฉันกำลังคิดว่ามีปัญหาบางอย่างเกี่ยวกับการตั้งค่าความปลอดภัยใน Amazon EC2 ซึ่งมีการ จำกัด การเข้าถึง IP ของอินสแตนซ์เดียวหรือใบรับรองอาจต้องสร้างใหม่

ไม่มีใครรู้วิธีการแก้ปัญหา?

linux ssh amazon-ec2

— วรศักดิ์ไชย
แหล่งที่มา

11

"มันใช้ในการทำงานก่อน" - ก่อนที่สิ่งที่ ?

— womble

ฉันมีอินสแตนซ์ Elastic Beanstalk EC2 ณ เดือนสิงหาคมปี 2013 การแก้ปัญหาคือการเข้าถึงอินสแตนซ์ในฐานะผู้ใช้ ec2 ซึ่งทำให้ข้อผิดพลาดการอนุญาต (publicKey) หายไป ได้แก่ : ssh -i ./mike-key-pairoregon.pem ec2-user@ec2-some-address.us-west-2.compute.amazonaws.com แน่นอนคุณต้องทำสิ่งอื่น ๆ ทั้งหมดตามstackoverflow.com/questions/4742478/…

— mikemay

3

คุณได้รับปัญหานี้หากคุณระบุชื่อผู้ใช้ผิด เอกสาร aws ( docs.aws.amazon.com/AWSEC2/latest/UserGuide/ … ) ให้ตัวอย่างกับชื่อผู้ใช้ ec2-user [ssh -i /path/my-key-pair.pem ec2-user @ ec2-198 -51-100-1.compute-1.amazonaws.com] ในขณะที่กล่องอูบุนตู (เก่า) ของฉันมีชื่อผู้ใช้ของ Ubuntu ดังนั้นเมื่อฉันใช้ตัวอย่างฉันได้รับข้อผิดพลาดนี้การเปลี่ยนเป็นการแก้ไขชื่อผู้ใช้ที่ถูกต้อง

— david.barkhuizen

@ david.barkhuizen ความคิดเห็นของคุณช่วยฉันได้ ฉันมีปัญหาที่คล้ายกัน มันกลับกลายเป็นว่ามันเกี่ยวข้องกับชื่อผู้ใช้ ขอบคุณ

— NaijaProgrammer

143

สิ่งแรกที่ต้องทำในสถานการณ์นี้คือการใช้-vตัวเลือกเพื่อsshให้คุณสามารถดูชนิดของการรับรองความถูกต้องพยายามและผลลัพธ์คืออะไร นั่นช่วยให้เข้าใจสถานการณ์ได้หรือไม่?

ในการอัปเดตคำถามของคุณคุณพูดถึง "ใน Ubuntu ท้องถิ่นอื่น" คุณคัดลอกคีย์ส่วนตัว ssh ไปยังเครื่องอื่นหรือไม่

— เกร็กฮิวกิล
แหล่งที่มา

2

ฉันได้คัดลอกคีย์ส่วนตัว ssh ไปยังเครื่องอื่นตามที่ @Greg แนะนำ มันใช้งานได้แล้ว ขอบคุณ!

— Vorleak Chy

3

FYI คุณสามารถใช้แฟล็ก -i เพื่อชี้ไปยังเส้นทางของคีย์โดยไม่ต้องติดตั้ง

— Jorge Vargas

20

ในกรณีของฉันฉันถูกใช้ .ami BitNami และไม่ได้ตระหนักว่าคุณต้องเข้าสู่ระบบในฐานะผู้ใช้ที่เรียกว่า BitNami ssh -i <keyfile> bitname@<ec2-address>เช่น: น่าเสียดายที่-vตัวเลือกไม่ได้ช่วยฉันค้นหาสิ่งนี้ แต่ก็ยังมีประโยชน์อย่างมากในการตรวจสอบ!

— แมตต์คอน

7

ในกรณีของฉันฉันใช้ชื่อผู้ใช้ผิด ใช้ "Ubuntu" แทน "bitnami" เช่นนี้: ssh -i key.pem bitnami @ hostaddress

— Lucas Pottersky

3

โอกาสในการขายที่ดีคือโหนดระยะไกลตัวเองดู/var/log/auth.logบางครั้งคุณจะเห็นข้อความต่อไปนี้: Authentication refused: bad ownership or modes for file /var/lib/jenkins/.ssh/authorized_keysหรือสิ่งอื่น ๆ

— Jonas Libbrecht

76

เนื่องจากไม่ได้มีการกล่าวถึงอย่างชัดเจน sshd เป็นค่าเริ่มต้นที่เข้มงวดมากเกี่ยวกับการอนุญาตสำหรับauthorized_keysไฟล์ ดังนั้นถ้าauthorized_keysเป็นแบบเขียนได้สำหรับใครอื่นที่ไม่ใช่ผู้ใช้หรือสามารถทำเขียนได้โดยใครอื่นที่ไม่ใช่ผู้ใช้ก็จะปฏิเสธที่จะรับรองความถูกต้อง (ยกเว้นกรณีที่มีการกำหนดค่า sshd ด้วยStrictModes no)

สิ่งที่ฉันหมายถึงโดย "สามารถเขียนได้" คือถ้ามีไดเรกทอรีหลักใด ๆ ที่สามารถเขียนได้สำหรับผู้อื่นที่ไม่ใช่ผู้ใช้ผู้ใช้ที่ได้รับอนุญาตให้แก้ไขไดเรกทอรีเหล่านั้นสามารถเริ่มแก้ไขสิทธิ์ในวิธีที่พวกเขาสามารถแก้ไข / แทนที่

นอกจากนี้หาก/home/username/.sshไดเรกทอรีไม่ได้เป็นของผู้ใช้และทำให้ผู้ใช้ไม่มีสิทธิ์ในการอ่านคีย์คุณสามารถพบปัญหา:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

โปรดทราบว่าเจนไม่ได้เป็นเจ้าของ.sshไฟล์ แก้ไขผ่านทางนี้

chown -R jane:jane /home/jane/.ssh

ปัญหาเกี่ยวกับการอนุญาตระบบไฟล์เหล่านี้จะไม่ปรากฏขึ้นssh -vและพวกเขาจะไม่ปรากฏในบันทึก sshd (!) จนกว่าคุณจะตั้งค่าระดับการบันทึกเป็น DEBUG

/etc/ssh/sshd_configแก้ไข คุณต้องการบรรทัดที่อ่านLogLevel DEBUGตรงนั้น โหลดเซิร์ฟเวอร์ SSH อีกครั้งโดยใช้กลไกที่มีให้โดย distro ( service sshd reloadบน RHEL / CentOS / Scientific) การรีโหลดที่ดีจะไม่ทำให้เซสชันที่มีอยู่ลดลง
ลองตรวจสอบสิทธิ์อีกครั้ง
กำหนดที่บันทึกสิ่งอำนวยความสะดวกของคุณไปและอ่าน (IIRC /var/log/auth.logบน Distros แบบ Debian; /var/log/secureบน RHEL / CentOS / Scientific)

ง่ายกว่ามากในการตรวจสอบสิ่งที่ผิดปกติกับผลลัพธ์การดีบักซึ่งรวมถึงข้อผิดพลาดในการอนุญาตระบบไฟล์ อย่าลืมเปลี่ยนกลับเป็น/etc/ssh/sshd_configเมื่อเสร็จแล้ว!

— Kjetil Joergensen
แหล่งที่มา

5

บิตที่ "สามารถเขียนได้" เป็นสิ่งที่ทำให้ฉันได้รับ

— บุต

7

FWIW การอนุญาตที่ถูกต้องสำหรับไฟล์คีย์คือ 600 (ดูที่นี่ )

— Matt Lyons

1

ใช่ไฟล์ .authorized_keys ของฉันเขียนได้โดยกลุ่มดังนั้นจึงไม่ยอมรับ

— Aditya MP

2

ฉันตีหัวของฉันกับผนัง! โฟลเดอร์ผู้ใช้ของฉันมีสิทธิ์ที่ไม่ถูกต้อง ขอขอบคุณ!

— XJones

4

กันไปสำหรับโฟลเดอร์ ~ / .ssh คุณอาจได้รับข้อความแสดงข้อผิดพลาดดังต่อไปนี้:Authentication refused: bad ownership or modes for directory

— Yevgeniy M.

37

ฉันได้รับข้อผิดพลาดนี้เพราะฉันลืมเพิ่ม-lตัวเลือก ชื่อผู้ใช้ท้องถิ่นของฉันไม่เหมือนกับในระบบระยะไกล

นี่ไม่ตอบคำถามของคุณ แต่ฉันมาที่นี่เพื่อค้นหาคำตอบสำหรับปัญหาของฉัน

— pkmk
แหล่งที่มา

25

ssh host -l userเหมือนกับssh user@hostใช่มั้ย

— Znarkus

3

@Zarkark ใช่มันเหมือนกัน

— cregox

ใช่สิ่งนี้แก้ปัญหาของฉันทำให้เกิดข้อผิดพลาด "สิทธิ์ที่ถูกปฏิเสธ (publickey)" เช่นกัน

— Brooks Moses

1

นี่เป็นปัญหาสำหรับฉัน ฉันคาดหวังให้ผู้ใช้ "รูท" ทำงาน แต่ฉันใช้อิมเมจ Ubuntu EC2 ซึ่งมีผู้ใช้เริ่มต้น "อูบุนตู"

— Cerin

20

ฉันได้รับข้อความนี้ในอินสแตนซ์ใหม่ซึ่งอ้างอิงจาก Ubuntu AMI ฉันใช้ตัวเลือก -i เพื่อให้ PEM แต่มันก็ยังแสดง "สิทธิ์การใช้งานถูกปฏิเสธ (publickey)"

ปัญหาของฉันคือฉันไม่ได้ใช้ผู้ใช้ที่ถูกต้อง ด้วยการรัน ssh ด้วย ubuntu @ ec2 ... มันทำงานได้เหมือนปกติ

ใช่ ... ฉันกำลังสั่งงานด้วยsudoซึ่งเป็นสาเหตุที่มันไม่ทำงาน

— thaddeusmt

16

สิ่งที่ง่ายต่อการอ่านกว่าssh -v(ในความคิดของฉันแน่นอน) tail -f /var/log/auth.logเป็น ควรเรียกใช้บนเซิร์ฟเวอร์ที่คุณพยายามเชื่อมต่อในขณะที่พยายามเชื่อมต่อ มันจะแสดงข้อผิดพลาดในข้อความล้วน

สิ่งนี้ช่วยฉันแก้ปัญหาของฉัน:

ผู้ใช้ [ชื่อผู้ใช้] จาก xx.yy.com ไม่ได้รับอนุญาตเนื่องจากไม่มีกลุ่มผู้ใช้ที่ระบุไว้ใน AllowGroups

— Znarkus
แหล่งที่มา

นี่เป็นบันทึกเซิร์ฟเวอร์ สำหรับ RHEL / CentOS 7:tail -f /var/log/secure

— Gianfranco P.

10

ตรวจสอบไฟล์/ etc / ssh / sshd_config ของคุณ หาบรรทัดที่บอกว่า

PasswordAuthentication no

บรรทัดนั้นต้องได้รับการแก้ไขให้ตอบว่าใช่แทนที่จะไม่ใช่ นอกจากนี้ให้รีสตาร์ทเซิร์ฟเวอร์ sshd หลังจากนั้น

sudo /etc/init.d/ssh restart

— Sudipta Chatterjee
แหล่งที่มา

18

นั่นจะทำให้เซิร์ฟเวอร์ปลอดภัยน้อยลง

— Znarkus

นี่เป็นปัญหาที่ฉันมี: ฉันต้องการตั้งค่าบัญชีสำหรับผู้ใช้รายอื่นรับรองความถูกต้องด้วยรหัสผ่าน ฉันยังต้องการที่จะสามารถเข้าสู่ระบบในขณะที่ตัวเองจากสถานที่ที่ฉันไม่มีรหัสส่วนตัวของฉัน

— Daniel

1

เราจะไปได้/etc/ssh/sshd_configอย่างไร - ถ้าเราไม่สามารถเข้าไปในเซิร์ฟเวอร์ได้?

— kyo

ในการเข้าสู่เซิร์ฟเวอร์คุณต้องใช้ไฟล์ PEM ที่ให้มาเมื่อสร้างอินสแตนซ์ คำแนะนำหลังจากนั้น

— Sudipta Chatterjee

สิ่งนี้ใช้ได้ผลสำหรับฉันแม้ว่าการรีสตาร์ท sshd ต้องใช้คำสั่งต่อไปนี้:sudo service sshd reload

— pacoverflow

6

อาจไม่เกี่ยวข้องกับผู้โพสต์ปัจจุบัน แต่อาจช่วยเหลือผู้อื่นที่พบสิ่งนี้เมื่อค้นหาคำตอบของสถานการณ์ที่คล้ายกัน แทนที่จะปล่อยให้ Amazon สร้าง ssh keypair ฉันขอแนะนำให้อัปโหลดคีย์ ssh สาธารณะมาตรฐานของคุณเองไปที่ Amazon แล้วระบุว่าเมื่อคุณเรียกใช้อินสแตนซ์ EC2

สิ่งนี้ช่วยให้คุณวางไวยากรณ์ของประเภท "-i" ใน ssh ใช้ rsync พร้อมกับตัวเลือกมาตรฐานและให้คุณใช้คีย์ ssh เดียวกันในทุกภูมิภาค EC2

ฉันเขียนบทความเกี่ยวกับกระบวนการนี้ที่นี่:

การอัปโหลดคีย์ ssh ส่วนตัวไปที่ Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

— Eric Hammond
แหล่งที่มา

+1 ค้นหาคำถามนี้อย่างแม่นยำด้วยเหตุผลนี้

— John Riselvato

ฉันเห็นข้อผิดพลาดนี้ในการติดตามบทความของคุณ ภูมิภาค = $ (ec2- คำอธิบาย - ภูมิภาค | ตัด -f2) ตัวเลือกที่ต้องการ '-K, - คีย์ส่วนตัว' หายไป (-h สำหรับการใช้งาน)

— KashifAli

@KashifAli คุณจะต้องตั้งค่าข้อมูลประจำตัวของเครื่องมือบรรทัดคำสั่ง EC2 API ดังนั้นคุณไม่จำเป็นต้องส่งข้อมูลรับรองในทุกบรรทัดคำสั่ง

— Eric Hammond

5

น่าแปลกที่ปัญหาของฉันกลับกลายเป็นว่าเซิร์ฟเวอร์เริ่มต้นใหม่แล้วและได้รับชื่อ DNS ใหม่ ฉันใช้ชื่อ DNS เก่า ฉันรู้ว่ามันฟังดูงี่เง่า แต่ฉันใช้เวลาพอจะคิดออก

— แพทริคคอลลินส์
แหล่งที่มา

ขอขอบคุณ! นี่เป็นปัญหาของฉันอย่างแน่นอน ฉันไม่ทราบว่ามีการเปลี่ยนแปลงชื่อ DNS เมื่อคุณรีสตาร์ทอินสแตนซ์

— Tim Swast

ในกรณีของฉัน URL * .compute.amazonaws.com จะเปลี่ยนไปเมื่อฉันกำหนด IP แบบยืดหยุ่น

— บูธเจฟฟรีย์

2

หากคุณกำลังพยายามเชื่อมต่อกับโทรศัพท์ CyanogenMod ที่ใช้งาน Dropbear คุณควรเรียกใช้บรรทัดต่อไปนี้เพื่อให้แน่ใจว่าทุกอย่างได้รับอนุญาตอย่างถูกต้อง:

chmod 600 /data/dropbear/.ssh/authorized_keys

หรือ

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

และ

chmod 755 /data/dropbear/ /data/dropbear/.ssh

มันทำให้ฉันไม่สามารถเชื่อมต่อได้

— Naftuli Kay
แหล่งที่มา

"เมื่อพยายามเข้าถึง SSH ไปยัง EC2 บน Ubuntu ท้องถิ่นอื่น"

— Grammargeek

1

จะเกิดอะไรขึ้นถ้าฉันไม่ได้รับอนุญาตคีย์ ?

— IgorGanapolsky

2

หากคุณกำลังใช้ CentOS 5 คุณอาจต้องการที่จะตั้งในStrictModes no /etc/ssh/sshd_configฉันกำลังแชร์ / โฮมไดเรกทอรีโดยใช้ NIS / NFS และฉันตั้งค่าสิทธิ์ทั้งหมดอย่างถูกต้อง แต่จะแจ้งรหัสผ่านให้ฉันเสมอ หลังจากที่ผมได้ตั้งStrictModes noปัญหาหายไป!

— uichin
แหล่งที่มา

1

คำตอบของ Greg อธิบายถึงวิธีแก้ปัญหาในการถ่ายภาพให้ดีขึ้นอย่างไรก็ตามปัญหาที่แท้จริงคือคุณมีชุดคีย์ ssh ที่ด้านหนึ่งของการทำธุรกรรม (ไคลเอนต์) ซึ่งพยายามตรวจสอบกุญแจสาธารณะแทนการตรวจสอบด้วยรหัสผ่าน เนื่องจากคุณไม่มีคีย์สาธารณะที่เกี่ยวข้องในอินสแตนซ์ EC2 สิ่งนี้จะไม่ทำงาน

— ตาแดง
แหล่งที่มา

2

คุณจะแก้ไขปัญหาได้อย่างไร?

— Julien Grenier

1

ฉันมีปัญหาเดียวกันและหลังจากลองวิธีการแก้ปัญหาหลายอย่างซึ่งไม่สามารถใช้งานได้ฉันเปิดพอร์ต SSH บนไฟร์วอลล์ของเราเตอร์ของฉัน (แผงควบคุมไฟร์วอลล์ของเราเตอร์ของฉันยุ่งเหยิงดังนั้นจึงยากที่จะบอกว่าเกิดอะไรขึ้น) ยังไงก็ตามมันคง :)

Super bloody น่ารำคาญที่ข้อผิดพลาดที่คุณได้รับคือ Permission Denied ซึ่งหมายความว่ามีการเชื่อมต่อบางอย่างที่ทำไปแล้ว grr

— chichilatte
แหล่งที่มา

1

ฉันมีปัญหาเดียวกันแม้ว่าฉันควรจะทำตามขั้นตอนทั้งหมดรวมถึง

$ ec2-authorize default -p 22

อย่างไรก็ตามฉันได้เริ่มต้นอินสแตนซ์ของฉันในภูมิภาค us-west-1 ดังนั้นคำสั่งดังกล่าวควรระบุด้วย

$ ec2-authorize default -p 22 --region us-west-1

หลังจากคำสั่งนี้ฉันสามารถ ssh เป็นอินสแตนซ์ ฉันใช้เวลาซักพักก่อนที่ฉันจะรู้ปัญหาและหวังว่าโพสต์นี้จะช่วยเหลือผู้อื่น

— อจิต Verma
แหล่งที่มา

0

นี่เป็นกรณีที่เกิดขึ้นได้ยาก แต่ถ้าคุณเปิดใช้งาน selinux และคุณใช้ nfs สำหรับไดเรกทอรีที่ได้รับอนุญาต (เช่นไดเรกทอรีบ้านที่ใช้ร่วมกัน) คุณจะต้องปิดการใช้งาน selinux (ไม่แนะนำสำหรับเหตุผลด้านความปลอดภัย แต่คุณสามารถปิดการใช้งานชั่วคราว เพื่อดูว่านี่เป็นสาเหตุของปัญหาหรือไม่หรืออนุญาตให้ selinux ใช้โฮมไดเร็กตอรี่ของ nfs ฉันไม่ชัดเจนเกี่ยวกับรายละเอียด แต่สิ่งนี้ใช้ได้สำหรับฉัน setsebool -P use_nfs_home_dirs 1

— รีส
แหล่งที่มา

0

ฉันเพิ่งพบปัญหาเดียวกันหลังจากเพิ่มสิทธิ์การเขียนกลุ่มไปยังไดเรกทอรีบ้านของผู้ใช้โดยไม่ตั้งใจ

ผมค้นพบนี้เป็นสาเหตุโดยการรันบนเครื่องและเห็นข้อผิดพลาดtail -f /var/log/secureAuthentication refused: bad ownership or modes for directory /home/<username>

— ยาโคบทอมลินสัน
แหล่งที่มา