การพิสูจน์ตัวตนคีย์สาธารณะล้มเหลวเฉพาะเมื่อ sshd คือ daemon


33

ฉันไม่รู้ว่าจะเกิดอะไรขึ้น distro คือ Scientific Linux 6.1 และทุกอย่างถูกตั้งค่าเพื่อทำการตรวจสอบความถูกต้องด้วยรหัสสาธารณะ แต่เมื่อ sshd ทำงานเป็น daemon (service sshd start) จะไม่รับกุญแจสาธารณะ (เพื่อให้ได้บันทึกชิ้นนี้ฉันได้เปลี่ยนสคริปต์ sshd เพื่อเพิ่มตัวเลือก -ddd)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

หาก sshd ทำงานในโหมดแก้ไขข้อผิดพลาดการ/usr/sbin/sshd -dddตรวจสอบจะทำงานเหมือนทางลัด:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

ความคิดใด ๆ ?? มีใครเห็นอะไรแบบนี้บ้าง?

หมายเหตุ:

ตรวจสอบการอนุญาตไฟล์แล้ว:

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

ฉันถูกถามว่า sshd สามารถเข้าถึงไฟล์ของรูทใน "โหมด daemon" ได้หรือไม่ คำตอบที่ใกล้ที่สุดสำหรับคำถามนี้คือ:

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

หาก sshd ทำงานเป็น root ฉันไม่รู้ว่าจะไม่สามารถเข้าถึงไฟล์ของตัวเองได้อย่างไร SELinux เป็นสาเหตุได้หรือไม่


1
สคริปต์ init ของ sshd ทำอะไรที่น่าสนใจหรือไม่? (ควรเป็น /etc/init.d/sshd?) ที่คุณไม่ได้ทำในบรรทัดคำสั่งหรือไม่ แทน 'service sshd start' ลอง 'sh -x /etc/init.d/ssh start'
PT

คำตอบ:


42

ใช่ SELinux น่าจะเป็นสาเหตุ .sshdir อาจเรียกไม่ถูก /var/log/audit/audit.logดูที่ ssh_home_tมันควรจะมีป้ายกำกับ ls -laZตรวจสอบกับ วิ่งrestorecon -r -vv /root/.sshถ้าจำเป็นต้องเป็น


1
ใช่ SELinux เป็นสาเหตุ: type = AVC msg = audit (1318597097.413: 5447): avc: ถูกปฏิเสธ {read} สำหรับ pid = 19849 comm = "sshd" ชื่อ = "authorized_keys" dev = dm-0 ino = 262398 scontext = unmconfined_u : system_r: sshd_t: s0-s0: c0.c1023 tcontext = unconfined_u: object_r: admin_home_t: s0 tclass = ไฟล์ทำงานหลังจากเรียกใช้ "restorecon -r -vv /root/.ssh" ขอบคุณมาก.
user666412

1
ขอบคุณขอบคุณสำหรับการแก้ไขบรรทัดคำสั่ง selinux ฉันพยายามค้นหามานานแล้วว่าทำไมฉันถึงสามารถใช้ ssh เป็นรูทของเซิร์ฟเวอร์ redhat enterprise 6.2 server โดยใช้การรับรองความถูกต้องของคีย์ ssh แต่ฉันไม่สามารถ ssh ได้ในฐานะผู้ใช้ที่ไม่ใช่รูท โดยไม่ต้องใส่รหัสผ่าน "ssh -v" ไม่ได้ระบุสิ่งผิดปกติ แต่อย่างใด ฉันตรวจสอบและตรวจสอบการป้องกันไฟล์อีกครั้งใน /home/example/.ssh มันไม่ได้จนกว่าฉันจะวิ่ง "/ usr / sbin / sshd -d" และด้วยเหตุผลบางอย่างที่ทำงานได้ตามปกติซึ่งฉันรู้ว่ามีสิ่งอื่นกำลังเกิดขึ้นและ ลองใช้การค้นหา google แบบอื่นและพบสิ่งนี้ ดังนั้นอาการที่ฉันสามารถทำได้ในฐานะ ro
Paul M

1
ฉันต้องทำสิ่งนี้กับระบบไฟล์ทั้งหมดเช่นrestorecon -r /YMMV
Irfy

1
ฉันลองสิ่งนี้ - แต่ก็ยังไม่ทำงาน ในบันทึกการตรวจสอบที่ฉันมีtype=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir- ไม่แน่ใจว่ามันหมายถึงอะไร
Yehosef

1
คำตอบคือในname="/"- ฉันต้องเรียกใช้restorecon -r /ตามที่ @Irfy แนะนำ
Yehosef

3

ฉันมีปัญหาเดียวกัน ในกรณีของฉัน restorecon และ chcon ไม่ทำงาน

ฉันไม่ต้องการปิดใช้งาน selinux หลังจากการวิจัยจำนวนมากในที่สุดฉันก็พบว่ามันเป็นเพราะไดเรกทอรีบ้านของฉันถูกติดตั้งจากที่อื่น (NFS) ฉันพบรายงานข้อผิดพลาดนี้ซึ่ง clued ฉันมา

ฉันวิ่ง:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

เพื่อยืนยัน use_nfs_home_dirs ถูกปิดแล้ว:

sudo setsebool -P use_nfs_home_dirs 1

เพื่อเปิด

ตอนนี้ฉันสามารถ ssh ไปยังเครื่องโดยใช้รหัสของฉันและไม่ต้องป้อนรหัสผ่าน การสลับบูลีน use_home_nfs_dirs เป็นสิ่งที่ฉันต้องทำ


1

ในการเพิ่มคำตอบของ Mark Wagner หากคุณกำลังใช้พา ธ โฮมไดเร็กตอรี่ที่กำหนดเอง (เช่นไม่ใช่/home) คุณต้องแน่ใจว่าคุณได้ตั้งค่าบริบทความปลอดภัยของ SELinux แล้ว หากต้องการทำเช่นนั้นหากคุณมีไดเรกทอรีโฮมของผู้ใช้อยู่ให้/myhomeรัน:

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

หากคุณอยู่บน CentOS คุณจะต้องเรียกใช้สิ่งนี้เพื่อรับsemanage:sudo yum install policycoreutils-python
sm4rk0

0

ดูเหมือนว่าคุณจะใช้ปุ่มที่แตกต่างกันเมื่อทำการทดสอบการเชื่อมต่อ 0x7f266e1a8840 กับ 0x7f85527ef230 ลองเชื่อมต่อโดยใช้ 'ssh -v example.com' เพื่อ sshd ทำงานเป็น daemon และอยู่ในโหมดดีบั๊กและค้นหาคีย์ที่ใช้โดย ssh รอบ ๆ สตริง "เสนอคีย์สาธารณะ RSA"


ใช่มี id_rsa และ id_dsa คีย์ DSA หายไปและฉันจะทำการทดสอบซ้ำ
user666412

ค่าที่กล่าวถึงในdebug3: mm_answer_keyallowed: key 0xFFFFFFFFFFจะเปลี่ยนทุกครั้งที่ sshd ได้รับการเชื่อมต่อใหม่ หากต้องการกำหนดสิ่งนี้ให้ค้นหาเซิร์ฟเวอร์ที่ SSH ใช้งานยกระดับ sshd LOGLEVEL เพื่อ debug3 รีสตาร์ท sshd เรียกใช้tail -f /var/log/secure |grep mm_answer_keyallowedแล้วเข้าสู่ระบบสองสามครั้งรอสองสามวินาที (หรือนาที) ระหว่างแต่ละการเชื่อมต่อ คุณจะเห็นว่าค่ามีการเปลี่ยนแปลงในแต่ละครั้ง และที่จริงมันดูเหมือนเคาน์เตอร์สำหรับฉัน
Stefan Lasiewski
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.