เหตุใดฉันยังคงได้รับพรอมต์รหัสผ่านด้วย ssh พร้อมการพิสูจน์ตัวตนรหัสสาธารณะ?

ฉันทำงานจาก URL ที่ฉันพบที่นี่:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

ไคลเอ็นต์ ssh ของฉันคือ Ubuntu 64 บิต 11.10 เดสก์ท็อปและเซิร์ฟเวอร์ของฉันคือ Centos 6.2 64 บิต ฉันได้ทำตามคำแนะนำ ฉันยังได้รับพรอมต์รหัสผ่านบน ssh

ฉันไม่แน่ใจว่าจะทำอย่างไรต่อไป

ตรวจสอบให้แน่ใจว่าสิทธิ์ใน~/.sshไดเรกทอรีและเนื้อหานั้นถูกต้อง เมื่อฉันตั้งค่าคีย์ ssh ของฉันครั้งแรกฉันไม่ได้~/.sshตั้งค่าโฟลเดอร์อย่างถูกต้องและมันก็ตะโกนใส่ฉัน

• ไดเรกทอรีบ้านของคุณ~, คุณ~/.sshไดเรกทอรีและ~/.ssh/authorized_keysไฟล์บนเครื่องระยะไกลจะต้องสามารถเขียนได้เท่านั้นโดยคุณ: rwx------และrwxr-xr-xจะมีการปรับ แต่rwxrwx---ไม่มีgood¹แม้ว่าคุณจะเป็นผู้ใช้เฉพาะในกลุ่มของคุณ (ถ้าคุณต้องการโหมดตัวเลข: 700หรือ755ไม่775) .
  หาก~/.sshหรือauthorized_keysมีการเชื่อมโยงสัญลักษณ์, เส้นทางที่ยอมรับ (ที่มีการเชื่อมโยงสัญลักษณ์ขยาย) มีการตรวจสอบ
• ~/.ssh/authorized_keysไฟล์ของคุณ(บนเครื่องระยะไกล) จะต้องสามารถอ่านได้ (อย่างน้อย 400) แต่คุณจะต้องใช้ไฟล์นั้นเพื่อให้สามารถเขียนได้ (600) หากคุณจะเพิ่มปุ่มเพิ่มเติมอีก
• ไฟล์สำคัญของคุณเอกชน (ในเครื่องท้องถิ่น) จะต้องอ่านและเขียนได้โดยคุณ: คือrw-------600
• นอกจากนี้หาก SELinux ตั้งค่าเป็นบังคับใช้คุณอาจต้องเรียกใช้restorecon -R -v ~/.ssh(ดูเช่นข้อผิดพลาดของ Ubuntu 965663และรายงานข้อผิดพลาด Debian # 658675นี่คือการแก้ไขใน CentOS 6 )

¹ _{ยกเว้นบางดิสทริบิวชัน (Debian และอนุพันธ์) ที่มีการแก้ไขรหัสเพื่อให้สามารถเขียนกลุ่มได้หากคุณเป็นผู้ใช้คนเดียวในกลุ่มของคุณ}

หากคุณมีสิทธิ์เข้าถึงรูทไปยังเซิร์ฟเวอร์วิธีที่ง่ายในการแก้ปัญหาดังกล่าวคือการรัน sshd ในโหมดดีบั๊กโดยการออกบางอย่างเช่น/usr/sbin/sshd -d -p 2222บนเซิร์ฟเวอร์ (ต้องใช้พา ธ เต็มไปยังไฟล์ sshd ที่จำเป็นสำหรับปฏิบัติการ) which sshdสามารถช่วยssh -p 2222 user@hostได้ สิ่งนี้จะบังคับให้ SSH daemon อยู่ในเบื้องหน้าและแสดงข้อมูลการดีบักเกี่ยวกับทุกการเชื่อมต่อ มองหาสิ่งที่ชอบ

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

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

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(ขึ้นอยู่กับการกระจาย Linux ของคุณบรรทัดแรก / บรรทัดสุดท้ายอาจเป็นsystemctl stop sshd.service/ systemctl start sshd.serviceแทน)

บ้านของคุณเข้ารหัสหรือไม่? ถ้าเป็นเช่นนั้นสำหรับเซสชั่นแรกของคุณคุณจะต้องให้รหัสผ่าน เซสชัน ssh ที่สองไปยังเซิร์ฟเวอร์เดียวกันกำลังทำงานกับคีย์รับรองความถูกต้อง หากเป็นกรณีนี้คุณสามารถย้ายของคุณไปยังผบที่ไม่ได้เข้ารหัสและเปลี่ยนเส้นทางในauthorized_keys~/.ssh/config

สิ่งที่ฉันทำลงไปคือการสร้าง/etc/ssh/usernameโฟลเดอร์ที่เป็นเจ้าของโดยชื่อผู้ใช้ด้วยสิทธิ์ที่ถูกต้องและวางauthorized_keysไฟล์ไว้ในนั้น จากนั้นเปลี่ยนคำสั่ง AuthorizedKeysFile /etc/ssh/configเป็น:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

สิ่งนี้อนุญาตให้ผู้ใช้หลายคนสามารถเข้าถึง ssh นี้โดยไม่กระทบต่อสิทธิ์

หลังจากคัดลอกคีย์ไปยังเครื่องระยะไกลและวางไว้ในสิ่งที่authorized_keysคุณต้องทำดังนี้:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

ลองคำสั่งต่อไปนี้

1. ssh-keygen

   กดปุ่ม Enter จนกว่าคุณจะได้รับพรอมต์

2. ssh-copy-id -i root@ip_address

   (มันจะขอรหัสผ่านของระบบโฮสต์อีกครั้ง)

3. ssh root@ip_address

   ตอนนี้คุณควรจะสามารถเข้าสู่ระบบได้โดยไม่ต้องใช้รหัสผ่านใด ๆ

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

SELinux บน RedHat / CentOS 6 มีปัญหากับการรับรองความถูกต้อง pubkeyอาจเกิดขึ้นเมื่อไฟล์บางไฟล์ถูกสร้างขึ้น selinux ไม่ได้ตั้งค่า ACLs อย่างถูกต้อง

ในการแก้ไข SElinux ACLs ด้วยตนเองสำหรับผู้ใช้รูท:

restorecon -R -v /root/.ssh

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

ดังนั้นเราต้องไปอีกขั้นหนึ่ง ด้วยการรันคำสั่ง ssh ในโหมด verbose คุณจะได้รับข้อมูลจำนวนมาก

ssh -vv user@host

สิ่งที่เราค้นพบคือว่าคีย์เริ่มต้น (id_rsa) ไม่ได้รับการยอมรับและลูกค้า ssh เสนอคีย์ที่ตรงกับชื่อโฮสต์ของไคลเอ็นต์:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

เห็นได้ชัดว่านี่จะไม่ทำงานจากลูกค้ารายอื่น

ดังนั้นวิธีแก้ปัญหาในกรณีของเราคือเปลี่ยนคีย์ rsa เริ่มต้นเป็นคีย์ที่มี user @ myclient เมื่อคีย์เป็นค่าเริ่มต้นจะไม่มีการตรวจสอบชื่อลูกค้า

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

'Agent admitted failure to sign using the key'

สิ่งนี้ได้รับการแก้ไขโดยการโหลดกุญแจไปยังตัวแทน ssh:

ssh-add

มันจะเป็นการตั้งค่าพลาด SSH ที่ปลายเซิร์ฟเวอร์ ต้องแก้ไขไฟล์ sshd_config ฝั่งเซิร์ฟเวอร์ /etc/ssh/sshd_configตั้งอยู่ใน ในไฟล์นั้นให้เปลี่ยนตัวแปร

• 'ใช่' ถึง 'ไม่' สำหรับ ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• 'ไม่' เป็น 'ใช่' สำหรับ PubkeyAuthentication

อ้างอิงจากhttp://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

ตรวจสอบให้แน่ใจว่าAuthorizedKeysFileชี้ไปยังตำแหน่งที่ถูกต้องใช้%uเป็นตัวยึดสำหรับชื่อผู้ใช้:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

อาจเป็นได้ว่าคุณเพียงแค่ต้องไม่แสดงข้อคิดเห็นบรรทัด

AuthorizedKeysFile .ssh / authorized_keys

โปรดทราบว่าคุณต้องโหลดบริการ ssh ใหม่เพื่อให้การเปลี่ยนแปลงมีผล:

service sshd reload

สองความคิดเห็น: สิ่งนี้จะเขียนทับไฟล์ต้นฉบับ ฉันแค่คัดลอกกุญแจสาธารณะที่สร้างขึ้นและทำสิ่งที่ชอบ:

cat your_public_key.pub >> .ssh/authorized_keys

นี่จะเป็นการเพิ่มคีย์ที่คุณต้องการใช้ในรายการคีย์ที่มีอยู่ก่อนหน้า นอกจากนี้บางระบบใช้ไฟล์authorized_keys2ดังนั้นจึงเป็นความคิดที่ดีที่จะสร้างฮาร์ดลิงก์ที่ชี้ระหว่างauthorized_keysและauthorized_keys2ในกรณี

ทางออกของฉันคือบัญชีถูกล็อค ข้อความที่พบใน / var / log / secure: ผู้ใช้ไม่ได้รับอนุญาตเนื่องจากบัญชีถูกล็อควิธีการแก้ไข: ให้รหัสผ่านใหม่แก่ผู้ใช้

ฉันพบปัญหาที่คล้ายกันและทำตามขั้นตอนโดยใช้โหมดแก้ไขข้อบกพร่อง

/usr/sbin/sshd -d

สิ่งนี้แสดงให้เห็นผลลัพธ์ต่อไปนี้

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

มันสับสนจริงๆ

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

มันแสดงให้เห็นว่าไดเรกทอรีรากมีสิทธิ์สำหรับทุกคน เราเปลี่ยนเพื่อไม่ให้ผู้อื่นมีสิทธิ์

[root@sys-135 ~]# chmod 750 /root

การรับรองความถูกต้องที่สำคัญเริ่มทำงาน

ในไฟล์ / etc / selinux / config การเปลี่ยน SELINUX เป็นปิดใช้งานจากการบังคับใช้ ssh ที่ไม่มีรหัสผ่านจะทำงานได้สำเร็จ

ก่อนหน้านี้ฉันสามารถทำได้ทางเดียว ตอนนี้จากทั้งสองทางฉันสามารถทำ ssh ได้โดยไม่ต้องใช้รหัสผ่าน

สิ่งหนึ่งที่ฉันทำผิดคือความเป็นเจ้าของในโฮมไดเรกทอรีของฉันบนระบบเซิร์ฟเวอร์ ระบบเซิร์ฟเวอร์ถูกตั้งค่าเป็นค่าเริ่มต้น: default ดังนั้นฉัน:

chown -R root:root /root

และมันก็ใช้งานได้ วิธีแก้ปัญหาราคาถูกอื่นคือปิดใช้งาน StrictModes: StirctModes no. ใน sshd_config อย่างน้อยจะบอกคุณว่าการแลกเปลี่ยนคีย์และโปรโตคอลการเชื่อมต่อดีหรือไม่ จากนั้นคุณสามารถไปตามการอนุญาตที่ไม่ถูกต้อง

สำหรับผมแล้วการแก้ปัญหาคือตรงข้ามWojtek Rzepala ของ : ผมไม่ได้สังเกตเห็นผมก็ยังคงใช้authorized_keys2ซึ่งได้รับการคัดค้าน การตั้งค่า ssh ของฉันหยุดทำงานในบางจุดน่าจะเป็นเมื่อเซิร์ฟเวอร์อัพเดท การเปลี่ยนชื่อ.ssh/authorized_keys2เป็น.ssh/authorized_keysแก้ไขปัญหา

D'โอ้!

ในอดีตที่ผ่านมาฉันเจอบทเรียนบางอย่างที่อธิบายถึงวิธีการตั้งค่ารหัสผ่านที่ไม่ใช้ ssh แต่บางอย่างผิดพลาดไปอย่างน่าเศร้า
เริ่มใหม่อีกครั้งและตรวจสอบทุกขั้นตอน:

1. จากลูกค้า - สร้างกุญแจ: กุญแจssh-keygen -t rsa
   สาธารณะและกุญแจส่วนตัว ( id_rsa.pubและid_rsa) จะถูกเก็บไว้ใน~/.ssh/ไดเรกทอรีโดยอัตโนมัติ
   การตั้งค่าจะง่ายขึ้นหากคุณใช้วลีรหัสผ่านที่ว่างเปล่า หากคุณไม่เต็มใจที่จะทำเช่นนั้นให้ทำตามคำแนะนำต่อไปนี้ แต่ให้ตรวจสอบที่หัวข้อย่อยด้านล่าง
   
   
2. จากลูกค้า - คัดลอกคีย์สาธารณะเพื่อเซิร์ฟเวอร์ : ssh-copy-id user@server
   ลูกค้าคนสำคัญของประชาชนจะถูกคัดลอกไปยังสถานที่ตั้งของเซิร์ฟเวอร์ ~/.ssh/authorized_keys
   
   
3. จากลูกค้า - เชื่อมต่อกับเซิร์ฟเวอร์:ssh user@server
   
   

ตอนนี้ถ้ามันยังไม่ทำงานหลังจาก 3 ขั้นตอนที่อธิบายไว้ลองทำสิ่งต่อไปนี้:

• ตรวจสอบ~/sshสิทธิ์ของโฟลเดอร์ในไคลเอนต์และเซิร์ฟเวอร์เครื่อง
• ตรวจสอบ/etc/ssh/sshd_configในเซิร์ฟเวอร์เพื่อให้แน่ใจว่าRSAAuthentication, PubkeyAuthenticationและตัวเลือกไม่ได้ปิดการใช้งานพวกเขาสามารถเปิดใช้งานโดยเริ่มต้นด้วยUsePAMyes
• หากคุณป้อนข้อความรหัสผ่านในขณะที่สร้างรหัสลูกค้าของคุณคุณอาจลองssh-agent& ssh-addเพื่อให้ได้การเชื่อมต่อที่ไม่มีรหัสผ่านในเซสชันของคุณ
• ตรวจสอบเนื้อหาของ/var/log/auth.logบนเซิร์ฟเวอร์เพื่อค้นหาปัญหาว่าทำไมการตรวจสอบสิทธิ์คีย์จึงถูกข้ามไปเลย

ฉันประสบปัญหาเดียวกันกับ PuTTY ที่เชื่อมต่อกับเครื่อง Ubuntu 16.04 มันน่าสงสัยเพราะโปรแกรม pscp ของ PuTTY ทำงานได้ดีกับคีย์เดียวกัน (และคีย์เดียวกันทำงานใน PuTTY เพื่อเชื่อมต่อกับโฮสต์อื่น)

ขอบคุณความคิดเห็นที่มีค่าจาก @UtahJarhead ฉันตรวจสอบไฟล์ /var/log/auth.log ของฉันและพบสิ่งต่อไปนี้:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

ปรากฎว่ารุ่นใหม่ของ OpenSSH ไม่ยอมรับคีย์ DSA โดยค่าเริ่มต้น เมื่อฉันเปลี่ยนจาก DSA เป็นคีย์ RSA มันก็ใช้ได้ดี

วิธีการอื่น: คำถามนี้อธิบายวิธีกำหนดค่าเซิร์ฟเวอร์ SSH เพื่อยอมรับคีย์ DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

ขั้นตอนเหล่านี้ควรช่วยคุณ ฉันใช้สิ่งนี้เป็นประจำในหลาย ๆ เครื่อง 64 บิต Ubuntu 10.04

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

คุณสามารถใส่สิ่งนี้ลงในสคริปต์โดยมีข้อความแจ้งเตือนและเรียกใช้เป็น

script_name username remote_machine

ฉันมีปัญหาคล้ายกับ ssh ในกรณีของฉันปัญหาคือว่าฉันติดตั้ง hadoop cloudera (จากรอบต่อนาทีใน CentOS 6) และมันสร้างผู้ใช้ hdfs กับไดเรกทอรีบ้าน

/var/lib/hadoop-hdfs(ไม่ได้มาตรฐาน/home/hdfs)

ฉันเปลี่ยนเป็น / etc / passwd /var/lib/hadoop-hdfsเป็น/home/hdfsย้ายโฮมไดเร็กตอรี่ไปยังตำแหน่งใหม่และตอนนี้ฉันสามารถเชื่อมต่อกับการพิสูจน์ตัวตนด้วยรหัสสาธารณะ

ฉันเพิ่งมีปัญหาเดียวกันนี้และสำหรับฉันการแก้ปัญหาคือการตั้งค่าไปUsePAM noดูแม้ว่าจะมีการPasswordAuthenticationตั้งค่าไว้noคุณจะยังคงได้รับkeyboard-interactiveและในกรณีของฉันโปรแกรม ssh ในพื้นที่ของฉันยังคงเป็นค่าเริ่มต้นด้วยเหตุผลบางประการ

พื้นหลังพิเศษเพื่อช่วยให้ทุกคนในสถานการณ์เดียวกัน: ฉันกำลังเชื่อมต่อจากโฮสต์ที่กำลังใช้งาน Dropbear กับ OpenSSH หนึ่งตัว เมื่อใช้PasswordAuthenticationและUsePAMตั้งค่าทั้งสองnoบนเครื่องระยะไกลฉันจะได้รับข้อความต่อไปนี้หากฉันป้อนssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

ให้ไฟล์ข้อมูลประจำตัวด้วย-iทุกอย่างทำงานตามที่คาดไว้

อาจมีข้อมูลเพิ่มเติมเล็กน้อยที่นี่

หลังจากตรวจสอบการอนุญาตและลองใช้วิธีแก้ไขปัญหาอื่น ๆ ที่ระบุไว้ที่นี่ในที่สุดฉันก็ลบไดเรกทอรี ssh บนเซิร์ฟเวอร์ตั้งค่ากุญแจสาธารณะของฉันอีกครั้ง

คำสั่งเซิร์ฟเวอร์:

# rm -rf ~/.ssh

คำสั่งท้องถิ่น:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

ที่เซิร์ฟเวอร์:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

directory permission issueมันเป็น มันเป็น 777 I changed it back to 700ที่เซิร์ฟเวอร์ดังนั้น นี้fixedปัญหาของฉันกับssh password less login failureแม้หลังจากการคัดลอกไปยังเซิร์ฟเวอร์$USER/.ssh/id_rsa.pub$USER/.ssh/authorized_keys

อีกตัวเลือกหนึ่งคือคำตอบที่แตกต่างของ @Jagadish : ไปstraceยัง ssh daemon

มันมีข้อได้เปรียบที่สำคัญคือเราไม่จำเป็นต้องหยุด sshd สิ่งที่จะส่งผลให้เกิดการล็อคที่สมบูรณ์หากมีบางสิ่งไม่ดี

ก่อนอื่นเราจะพบ pid ของกระบวนการ sshd หลัก pstree -pa|lessที่นี่เราสามารถดูได้โดยการดำเนินการ

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

หลังจากรู้แล้วว่า pid คือ 633 เราทำได้straceโดยติดตามลูก ๆ ของมัน:

strace -p 633 -s 4096 -f -o sux

ผลลัพธ์ที่ได้คือทุกสิ่งที่สิ่งนี้ sshd และกระบวนการลูกได้ทำไว้จะถูก strace-ed ลงในไฟล์ที่มีชื่อsuxในโลคอลไดเร็กทอรี

จากนั้นสร้างปัญหาขึ้นอีกครั้ง

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

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

มันเป็นเรื่องสำคัญที่ sshd พยายามที่จะเข้าสู่ระบบข้อความผู้ใช้ cica ไม่ได้รับอนุญาตเพราะบัญชีถูกล็อค - มันไม่สามารถเพียงเพราะการบันทึกไม่เพียงพอ verbose สำหรับที่ แต่เรารู้แล้วว่า pubkey ถูกปฏิเสธเพราะบัญชีถูกล็อค

ยังไม่ได้แก้ปัญหา - ตอนนี้เราจำเป็นต้อง google สิ่งที่หมายถึง "บัญชีที่ถูกล็อค" ในกรณีของ sshd อาจเป็นไปได้ว่ามีบางอย่างที่ไม่สำคัญ/etc/passwdนัก/etc/shadowเวทย์มนตร์ แต่สิ่งที่สำคัญทำ - ปัญหาไม่ได้เป็นเรื่องลึกลับ แต่เป็น debuggable / googlable ได้อย่างง่ายดาย

ในกรณีของฉันฉันมีสิทธิ์ทั้งหมดถูกต้องและแม้กระทั่งเมื่อใช้งาน ssh ด้วย -vvv flag ฉันไม่สามารถเข้าใจได้ว่าปัญหาคืออะไร

ดังนั้นฉันจึงสร้างใบรับรองใหม่บนรีโมตโฮสต์

ssh-keygen -t rsa -C "your_email@example.com"

และคัดลอกคีย์ที่สร้างไปยังเครื่องท้องถิ่นและเพิ่มกุญแจสาธารณะใหม่ไปที่ ~ / .ssh / authorized_keys บนโฮสต์ระยะไกล

cat id_rsa.pub >> authorized_keys

การใช้คีย์ที่สร้างจากการเชื่อมต่อเครื่องโฮสต์ระยะไกลใช้งานได้ ดังนั้นหากการแก้ปัญหาอื่นล้มเหลวนี่เป็นอีกสิ่งที่ควรลอง

สถานการณ์ของฉันคือฉันมีเซิร์ฟเวอร์ NAS ที่ฉันสร้างbackupbotผู้ใช้หลังจากการสร้างบัญชีหลักของฉันซึ่งสามารถเข้าสู่ระบบเพื่อสร้างbackupbotผู้ใช้ครั้งแรก หลังจากที่เล่นซอกับsudo vim /etc/ssh/sshd_configและการสร้างbackupbotผู้ใช้vimสามารถสร้างอย่างน้อยบน Ubuntu 16.04 และอยู่บนพื้นฐานของ~/.vimrcการตั้งค่าการแลกเปลี่ยนไฟล์/etc/ssh/sshd_configที่เหลือจากการแก้ไขเซสชั่นที่เป็นกลุ่มของคุณของ

ตรวจสอบว่า/etc/ssh/.sshd_config.swpมี: และมีการลบออกแล้วรีสตาร์ทsshddaemon:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

สิ่งนี้สามารถแก้ไขปัญหาของฉันได้อย่างน่าอัศจรรย์ ก่อนหน้านี้ฉันได้ตรวจสอบสิทธิ์ทั้งหมดของฉันและแม้แต่ลายนิ้วมือ RSA ของกุญแจสาธารณะและกุญแจส่วนตัว นี่เป็นสิ่งที่แปลกและอาจเป็นจุดบกพร่องของsshdรุ่นนี้โดยเฉพาะ:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 มี.ค. 2559