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

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

ไม่มีใครรู้วิธีแก้ปัญหาการอนุญาตถูกปฏิเสธข้อผิดพลาด?

answer

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

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

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

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

นอกจากนี้ หาก/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 แบบเดเบียน/var/log/secureบน RHEL/CentOS/Scientific)

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

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

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

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

ปัญหาของฉันคือฉันไม่ได้ใช้ผู้ใช้ที่ถูกต้อง ด้วยการรัน ssh ด้วย[email protected] มันทำงานได้ตามปกติ

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

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

User [username] from xx.yy.com not allowed because none of user's groups are listed in AllowGroups

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

PasswordAuthentication no

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

sudo /etc/init.d/ssh restart

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

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

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

Uploading Personal ssh Keys to Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

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

หากคุณกำลังพยายามเชื่อมต่อกับโทรศัพท์ 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

สิ่งนี้แก้ไขได้สำหรับฉัน ไม่เช่นนั้นจะไม่มีอะไรเชื่อมต่อได้

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

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

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

ซูเปอร์เลือดที่น่ารำคาญที่ผิดพลาดที่คุณได้รับจะอนุญาตปฏิเสธหมายความว่ามีชนิดของการเชื่อมต่อบางทำ GRR

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

$ ec2-authorize default -p 22

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

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

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

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

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

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

TL;DR - ตรวจสอบให้แน่ใจว่าคุณใช้ชื่อผู้ใช้ที่ถูกต้อง - ubuntu/ec2-user/etc

ฉันใช้ bastion-host (ec2) ซึ่งเป็น Amazon Linux OS ( ec2-user) และพยายามจาก bastion-host เป็น private-host (ec2) ซึ่งเป็น Ubuntu 18.04 OS ( ubuntu)

นี่อาจฟังดูตลกเพราะคุณควรรู้ชื่อผู้ใช้ของเครื่องที่คุณกำลังใช้ SSHing แต่เนื่องจากฉันใช้ SSH กับเครื่องหลายเครื่อง บางครั้งฉันจึงทำผิดพลาด

หาก.sshdirของคุณมีมากกว่า 1 คีย์ (เช่น: an id_rsa.pub, และ an id_ed25519.pub) ให้ลองตรวจสอบให้แน่ใจว่าคุณกำลังดำเนินการsshกับ<correct_key_file>, โดยเพิ่มพา ธ ของมันเป็นการ arg อย่างชัดเจน (และในขณะที่คุณอยู่ที่นั้น อาจผ่านอย่างชัดแจ้ง<correct_username>ด้วยเช่นกัน):

ssh -i ~/.ssh/<correct_key_file> <correct_username>@<host_server_address>

ค่าเริ่มต้นที่ใช้โดยไม่ได้ระบุอย่างชัดเจนอาจไม่ถูกต้อง