การตรวจสอบความถูกต้อง SSH โดยใช้ gssapi-keyex หรือ gssapi-with-mic (ไม่อนุญาต publickey)

บริษัท ของฉันปิดใช้งานการรับรองความถูกต้องกุญแจสาธารณะ SSH ดังนั้นฉันต้องป้อนด้วยตนเองทุกครั้งที่รหัสผ่านของฉัน (ฉันไม่คิดว่าจะเปลี่ยนแปลง/etc/ssh/sshd_config)

อย่างไรก็ตามgssapi-keyexและการgssapi-with-micรับรองความถูกต้องเปิดใช้งาน (โปรดดูด้านล่างsshdebug output)

ฉันจะใช้การเข้าสู่ระบบอัตโนมัติในกรณีนี้ได้อย่างไร
ฉันสามารถใช้ประโยชน์จากgssapi-keyexและ / หรือการgssapi-with-micตรวจสอบสิทธิ์ได้หรือไม่

> ssh -v -o PreferredAuthentications=publickey hostxx.domainxx
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to hostxx.domainxx [11.22.33.44] port 22.
debug1: Connection established.
debug1: identity file /home/me/.ssh/identity type -1
debug1: identity file /home/me/.ssh/id_rsa type -1
debug1: identity file /home/me/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostxx.domainxx' is known and matches the RSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (gssapi-keyex,gssapi-with-mic,password).

อาจจะ.

• คุณสามารถรับตั๋วสำหรับเงินต้นในระบบลูกค้าของคุณซึ่งเป็นส่วนหนึ่งของกระบวนการเข้าสู่ระบบมาตรฐานหรือด้วยตนเอง ( kinit, MIT Kerberos สำหรับ Windows) ได้หรือไม่
• เซิร์ฟเวอร์มีหลักการ kerberos หรือคุณสามารถให้มันได้หรือไม่ host/server.example.com@EXAMPLE.COMมันควรจะเป็นในรูปแบบ
• การGSSAPIตรวจสอบเปิดใช้งานกับลูกค้าของคุณหรือไม่
• ลูกค้าของคุณทราบหรือไม่ว่า realm ที่เซิร์ฟเวอร์เป็นเจ้าของโดยระเบียนทรัพยากร TXT ของ DNS หรือการแมปท้องถิ่น

ถ้าคุณบอกว่า "ใช่" ทั้งหมดGSSAPIAuthenticationที่กล่าวมาแล้วขอแสดงความยินดีคุณสามารถใช้

• คุณอาจต้องเปิดใช้งานการมอบหมายข้อมูลประจำตัวขึ้นอยู่กับการตั้งค่าของคุณ

ขั้นตอนการทดสอบ:
(สมมติว่า: โดเมน = example.com; realm = EXAMPLE.COM)

1. kinit username@EXAMPLE.COM
   • จะเป็นการดีนี้จะถูกจัดการโดยกระบวนการเข้าสู่ระบบมาตรฐานของคุณโดยรวมทั้งสองpam_krb5หรือpam_sss(กับauth_provider = krb5) pam stackในที่เหมาะสม
2. kvno host/server.example.com@EXAMPLE.COM
   • นี่คือขั้นตอนการดีบัก sshนี้ไม่ได้โดยอัตโนมัติหากคุณมีแคชที่ถูกต้องและคุณกำลังพูดคุยกับsshdที่สนับสนุนหรือgssapi-with-micgssapi-keyex
3. dig _kerberos.example.com txt ควรกลับมา "EXAMPLE.COM"
   • อีกทางเลือกหนึ่งการทำแผนที่สามารถเก็บไว้ใน[domain_realm]ส่วนของ/etc/krb5.confเป็น.example.com = EXAMPLE.COMแต่dnsวิธีการปรับขนาดที่ดีกว่ามาก
4. ssh -o GSSAPIAuthentication=yes username@server.example.com
   • ในการเข้าสู่ระบบชื่อผู้ใช้อื่นนอกเหนือจากอาจารย์ใหญ่ของคุณบนเซิร์ฟเวอร์จะต้องรู้ว่าจะทำแผนที่รายละเอียดที่ฉันไม่ได้เข้ามาที่นี่

วิธีการ 4 ขั้นตอนถูกต้อง (นอกจากนี้ยังมีระเบียน Kerberos SRV ใน DNS ที่ดูสง่างามกว่าและมีอยู่ในทุก Active Directory) ฉันใช้สิ่งนี้ตลอดเวลาและได้ให้การสนับสนุนวิธีการ pubkey ข้างต้นเป็นส่วนใหญ่ด้วยเหตุผลด้านความปลอดภัยและการควบคุม

ที่กล่าวมานี้ให้การเข้าสู่ระบบแบบโต้ตอบเท่านั้นแม้ว่ามันจะเป็นแบบอินเทอร์แอคทีฟเมื่อคุณได้รับตั๋วบนเวิร์กสเตชันของคุณ ตั๋ว Kerberos ทำหน้าที่คล้ายกับตัวแทน SSH มาก เมื่อคุณมีแล้วการเชื่อมต่อใหม่นั้นเป็นแบบทันทีและไม่มีรหัสผ่าน แม้ว่าจะมีเวลา จำกัด

ในการรับการเข้าสู่ระบบแบบแบตช์คุณต้องได้รับไฟล์ keytab ซึ่งเป็นไฟล์ที่มีรหัสผ่านสำหรับบัญชี Kerberos ซึ่งคล้ายกับรหัสส่วนตัวของ SSH ครึ่งหนึ่ง ตามข้อควรระวังความปลอดภัยใช้; โดยเฉพาะอย่างยิ่งเนื่องจากแท็บคีย์ไม่ได้เข้ารหัสหรือป้องกันด้วยรหัสผ่าน

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

สามารถสร้าง Keytabs ได้โดยใช้ ktutil บน Unix หรือ KTPASS.EXE บน Windows (อันหลังจากบริการ AD Kerberos) โปรดทราบว่า ktutil มีอยู่สองรสชาติคือ Heimdal และ MIT และไวยากรณ์ของพวกเขาแตกต่างกัน การอ่าน manpage บนระบบที่เกี่ยวข้องช่วยได้