การรับรองความถูกต้องของคีย์ SSH ล้มเหลว

30

ฉันพยายามที่จะ ssh ลงในเซิร์ฟเวอร์ CentOS ที่ฉันไม่สามารถควบคุมได้ .. ผู้ดูแลระบบได้เพิ่มกุญแจสาธารณะของฉันไปที่เซิร์ฟเวอร์และยืนยันความผิดอยู่กับฉัน แต่ฉันไม่สามารถหาสิ่งที่ผิด

กำหนดค่าใน. ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

การอนุญาตไฟล์คีย์ของฉัน:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

บันทึกการเชื่อมต่อที่ฉันไม่สามารถรับรู้ได้:

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
ssh  sshd  ssh-keys 
— ทิม
แหล่งที่มา
จากฝาดูเหมือนว่าจะมีการส่งคีย์ แต่ไม่มีการตอบสนองใด ๆ เลย - คุณควรจะเข้าสู่ระบบในฐานะ root หรือคุณเข้าสู่ระบบเป็นทิมแล้วใช้ sudo? บางครั้งการเข้าสู่ระบบ ssh เนื่องจากรูทถูกปิดการใช้งาน - สิทธิ์ของไดเรกทอรี. ssh คืออะไร - คุณมีเซิร์ฟเวอร์ใช่ไหม การแก้ไข DNS นั้นถูกต้องหรือไม่ - คุณสามารถสร้างคีย์ได้อีกครั้งจากนั้นใช้ ssh-copy-id เพื่อคัดลอกคีย์สาธารณะใหม่ไปยังไฟล์ authorized_keys ในกรณีที่คีย์เสียหายอย่างใด
— Kyle H
ขอบคุณที่พยายามช่วย! สิทธิ์ในโฟลเดอร์. ssh ของฉันคือ: drwx ------ 2 tim tim 4096 Okt 20 22:13 .ssh เข้าสู่ระบบในฐานะที่ถูกต้อง - มันใช้งานได้จริงเมื่อสองสามสัปดาห์ก่อนที่ฉันจะฟอร์แมตคอมพิวเตอร์ใหม่ ผู้ดูแลระบบกล่าวว่าเขาได้เพิ่มปุ่มใหม่อย่างถูกต้อง แต่ฉันไม่รู้ว่ามันเป็นความผิดของฉันได้อย่างไร ณ จุดนี้
— ทิม
ดังที่ @KyleH พูดถึงคุณได้ลองด้วยssh tim@10.0.12.28บันทึกที่กล่าวถึง Kerberos แล้วเซิร์ฟเวอร์ CentOS อาจเป็น Domain Integrated (AD, IPA, ... ) คุณต้องค้นหาผู้ใช้ที่คุณควรใช้ สอบถามผู้ดูแลระบบ ตัวอย่างเช่นเรากำลังใช้ IPA เพื่อให้ผู้ใช้สามารถเชื่อมต่อกับเซิร์ฟเวอร์บางตัวด้วยบัญชีโดเมน IPA และคู่คีย์และหากจำเป็นพวกเขาสามารถ sudo ไม่มีการเข้าถึงรูท :)
— Zina

คำตอบ:

18

โดยปกติจะแก้ปัญหาการอนุญาตคีย์ SSH ที่ได้รับอนุญาตส่วนใหญ่ทางฝั่งเซิร์ฟเวอร์โดยสมมติว่ามีคนไม่ทำการเปลี่ยนแปลงการอนุญาตเพิ่มเติม

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

หากผู้ดูแลระบบของคุณสร้างไฟล์. ssh / directory หรือ. ssh / authorized_keys เป็นรูท (ซึ่งโดยทั่วไปจะเป็นวิธีการที่สำเร็จ) แล้วให้มีไฟล์ที่ผู้ใช้อื่นเป็นเจ้าของ (แม้ว่าจะเป็นรูท!)

ผู้ใช้ (ปฏิเสธความรับผิดชอบ: ผู้ร่วมก่อตั้ง) ทำสิ่งนี้โดยอัตโนมัติในลักษณะเดียวกัน .. https://github.com/userify/shim/blob/master/shim.py#L285

— Jamieson Becker
แหล่งที่มา
หากนี่เป็นปัญหาลูกค้าจะไม่พยายามส่งรหัสไปยังเซิร์ฟเวอร์ตั้งแต่แรก บันทึกที่ให้ในคำถามนั้นชัดเจนว่าเป็นเช่นนั้น
— Charles Duffy
สิ่งนี้จะแก้ไขปัญหาด้านเซิร์ฟเวอร์ คุณถูกต้องว่าลูกค้าฝั่งไม่เป็นไร
— Jamieson Becker
1
ในที่สุดนี้ก็แก้ปัญหาของฉัน ใช้เวลาหลายชั่วโมงพยายามคิดว่าเพราะเหตุใดคีย์สาธารณะ / ส่วนตัวของฉันจึงไม่ได้รับการยอมรับ
— Daniel Harris
ผู้ใช้คนอื่นแนะนำsudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Rซึ่งจะประหยัดเวลาในการพิมพ์ แต่อาจเป็นเรื่องยากสำหรับมือใหม่ที่จะเข้าใจ
— Jamieson Becker
11

ฉันมีปัญหาเดียวกันที่แน่นอนบนเซิร์ฟเวอร์สองเครื่อง: Linux ที่ใช้ Debian stretch และ NAS (Synology DS715)

มันกลับกลายเป็นว่าในทั้งสองกรณีการอนุญาตโฮมไดเรกทอรีบนเซิร์ฟเวอร์ผิด

auth.log บนเซิร์ฟเวอร์มีประโยชน์มาก

Authentication refused: bad ownership or modes for directory /home/cyril

บน Linux มันมีบิตเขียน / กลุ่มบน (drwxrwxr - x) ดังนั้นฉันต้องลบอย่างน้อยเขียนบนกลุ่ม (chmod gw ~ /) และจากนั้นก็ทำงาน

ใน Synology ไม่ว่าด้วยเหตุผลใดก็ตาม

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

ฉันต้องเปลี่ยนมันด้วย

chmod -t ~/

และฉันสามารถเชื่อมต่อได้โดยไม่ต้องใช้รหัสผ่าน

— Cyril Chaboisseau
แหล่งที่มา
ขอบคุณที่chmod -t... ฉันลงเอยด้วย:admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hosts
— Stéphane
6

เมื่อใช้ CentOS 7 และฉันมั่นใจว่าจะใช้กับระบบปฏิบัติการ Linux อื่น ๆ ที่ใช้ sshd ด้วย ด้วยการเข้าถึงรูทคุณสามารถกำหนดเพิ่มเติมเกี่ยวกับสาเหตุที่การพิสูจน์ตัวตนอาจล้มเหลว เพื่อทำสิ่งนี้:

  1. เปิดใช้งานการบันทึกสำหรับ sshd: vi /etc/ssh/sshd_config
  2. ภายใต้การบันทึกข้อคิดเห็น:

SyslogFacility AUTH LogLevel INFO

  1. เปลี่ยน LogLevel INFO เป็น LogLevel DEBUG
  2. บันทึกและออก
  3. รีสตาร์ท sshd systemctl restart sshd
  4. ดูไฟล์ข้อความ tail -l /var/log/messages
  5. ใช้เทอร์มินัลอื่นพยายามเชื่อมต่อกับ ssh
  6. พยายามเชื่อมต่อกับ ssh
  7. ตรวจสอบบันทึกการรับรองความถูกต้องสำหรับสาเหตุที่แน่นอน

ตัวอย่างเช่นฉันกำลังประสบปัญหาเดียวกับที่กล่าวไว้ข้างต้น 

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

การใช้ขั้นตอนเหล่านี้ฉันสามารถยืนยันได้ว่าปัญหาคือสิทธิ์ในไฟล์ authorized_keys โดยการตั้งค่า chmod เป็น 644 ในไฟล์คีย์ที่ได้รับอนุญาตของผู้ใช้ของฉันปัญหาได้รับการแก้ไข

— JonCav
แหล่งที่มา
4

ดูเหมือนว่าสิทธิ์ใน.sshโฟลเดอร์ของคุณไม่ได้คัดลอก + วางอย่างถูกต้อง คุณกรุณาเพิ่มอีกครั้งได้ไหม

หากเปิดใช้งานโหมดเข้มงวดเราจะต้องตรวจสอบว่า.sshมีสิทธิ์ที่ถูกต้องของ:

  • .ssh/ ควรมี perms 0700/rwx------
  • .ssh/*.pub ไฟล์ควรจะเป็น 644/rw-r--r--
  • .ssh/* (ไฟล์อื่น ๆ ใน. ssh) 0600/rw-------

สิ่งที่มองหาคุณได้รับอนุญาตที่ชาญฉลาด?

— ไคล์เอช
แหล่งที่มา
สิทธิ์ในโฟลเดอร์บ้านของฉัน (เวลา) คือ 755 (drwxr-xr-x) และสิทธิ์ในโฟลเดอร์. ssh เองคือ 700 (drwx) id_rsa 600 และไฟล์ผับเป็น 644 .. : / ขอบคุณอีกครั้งหวังว่าจะช่วยให้ข้อมูล
— ทิม
ฉันทำงานกับเซิร์ฟเวอร์หลายตัว โฮมไดเร็กตอรี่ของฉันคือ drwxr-xr-x (0755), .ssh คือ rwx ------ (0700), ภายใน. ssh รหัสผับของฉันคือ -rw-r - r-- (0644), และที่เหลือ ในโฟลเดอร์นั้นคือ -rw ------- (0600) ดังนั้นการอนุญาตของคุณดีและควรผ่านการตรวจสอบโฮสต์ที่เข้มงวด ไฟล์ / etc / ssh_config ของคุณคืออะไร มีอะไรใน ~ / .ssh / config? ฉันมีการสร้างคีย์ ssh ด้วยเหตุผลหนึ่งอย่างอื่นไม่ทำงานแม้ว่าจะไม่มีข้อผิดพลาด คุณลองใช้ ssh-keygen เพื่อสร้างคีย์ของคุณ, ssh-copy-id เพื่อคัดลอก pub key ของคุณไปยังเซิร์ฟเวอร์ระยะไกลที่เปิดใช้งานการตรวจสอบรหัสผ่านหรือไม่?
— Kyle H
น่าเสียดายที่ฉันไม่สามารถเข้าถึงเซิร์ฟเวอร์ได้ แต่ฉันจะพยายามให้ผู้ดูแลระบบคัดลอก pub key ของฉันไปยังเซิร์ฟเวอร์อีกครั้งในวันจันทร์ .. ฉันคัดลอกเนื้อหาของไฟล์ config ไปยัง pastebin: pastebin.com/eEaVMcvtขอขอบคุณอีกครั้งสำหรับคุณ ช่วยด้วย!
— ทิม
ไม่เป็นไร ฉันยินดีที่จะช่วย! ฉันยังสนุกกับการแก้ปัญหาและช่วยเหลือผู้อื่นด้วย Linux มีหนึ่งบรรทัดคี่ใน ssh-config ของคุณที่อาจทำให้เกิดปัญหาที่มันอยู่ IP 10.0.12.28 คืออะไร
— Kyle H
@ KyleH ถูกต้อง .. มันเกือบจะเป็นปัญหาแน่นอน ฉันเพิ่มคำตอบอื่นที่แสดงวิธีแก้ไขด้วยการเข้าถึงรูท หากคุณควบคุม homedir ของคุณคุณสามารถแก้ไขได้ด้วยตัวเอง แต่แน่นอนว่าคุณต้องสามารถเข้าสู่ระบบได้ :)
— Jamieson Becker
4

ในกรณีที่มีคนสะดุดคำตอบนี้ - ไม่มีคำแนะนำใดที่ทำงานในสถานการณ์ของฉัน ในที่สุดปัญหาคือว่าฉันได้สร้างบัญชีที่ไม่มีการตั้งรหัสผ่าน เมื่อฉันตั้งรหัสผ่านโดยใช้usermod -p "my password" usernameแล้วบังคับให้ปลดล็อคusermod -U usernameทุกอย่างในบัญชีเป็นเรื่องเหลวไหล

— Nathan Crause
แหล่งที่มา
คำตอบของคุณตั้งค่าสถานะฉันเป็นคนอื่น แต่กรณีที่เกี่ยวข้องกับผู้ใช้ของฉันพยายามเข้าสู่ระบบเมื่อไดเรกทอรีบ้านที่ฉันได้รับนั้นซ้อนกันมากกว่าที่ฉันลงชื่อเข้าใช้ด้วย ... เยี่ยมมากที่จะต้องแก้ไขขอบคุณ!
— Brett Zamir
2

ฉันมีปัญหาที่คล้ายกันซึ่งการเชื่อมต่อ ssh พยายามที่สำคัญ~/.ssh/id_rsaก่อนที่จะหยุดโดยไม่คาดคิด:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

ในกรณีของฉันมันเป็นเพราะไฟล์กุญแจสาธารณะอันเก่าวางอยู่ใน.sshไดเรกทอรี:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

การย้าย / ลบid_rsa.pubจาก.sshไดเรกทอรีแก้ปัญหาได้

จากสิ่งที่ฉันเข้าใจ: เมื่อมีคีย์สาธารณะปรากฏบนฝั่งไคลเอ็นต์ SSH 1st จะตรวจสอบคีย์ส่วนตัวกับมัน หากล้มเหลวจะไม่พยายามใช้ไพรเวตคีย์เพื่อเชื่อมต่อจากระยะไกล

ผมส่ง e-mail มาที่ openssh รายการทางไปรษณีย์: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html

— Elouan Keryell-Even
แหล่งที่มา
Yeaaahhhh อย่างจริงจัง! ฉันจะไม่ได้ดูที่ openssh-8.0p1-5.fc30.x86_64BTW ฉันมีพับลิกคีย์จากเซิร์ฟเวอร์ก่อนหน้านี้ที่มีชื่อเดียวกับที่อยู่ใหม่fedora@(baloo).sshkey.pubซึ่งfedora@(baloo).sshkeyผ่านไปบนบรรทัดรับคำสั่งพร้อมกับ-iตัวเลือก การตรวจสอบสิทธิ์ล้มเหลวด้วยคีย์เซิร์ฟเวอร์ใหม่ที่พบในใหม่fedora@(baloo).sshkey- คีย์ RSA
— David Tonhofer
2

เราพบปัญหานี้ สิทธิ์และความเป็นเจ้าของในไฟล์. ssh นั้นถูกต้องทั้งหมด ใน / var / log / ข้อความที่เราพบ:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

ดังนั้นโซลูชันสำหรับนักพัฒนา vm ที่เราไม่สนใจเกี่ยวกับความปลอดภัยคือปิดใช้งาน selinux แก้ไข / etc / sysconfig / selinux และเปลี่ยน SELINUX = ปิดใช้งานและรีบูต

— gaoithe
แหล่งที่มา
2

ในกรณีนี้ยังช่วยคน ฉันพยายามคัดลอกคีย์จากเครื่อง Ubuntu 18.04 ไปยังเซิร์ฟเวอร์ 2 CentOS 7 ฉันใช้ssh-copy-idเพื่อถ่ายโอน หนึ่งทำงานหนึ่งไม่ได้ ดังนั้นฉันจึงผ่านการดีบักสิทธิ์ทั้งหมดและไม่พบสิ่งใดเลย ในที่สุดฉันก็เลยดึงไฟล์ขึ้นมา/etc/ssh/sshd_configบนเซิร์ฟเวอร์ทั้งสองแล้วก็ทีละบรรทัด ในที่สุดฉันก็พบว่าอาจมีบางสิ่งบางอย่างที่ใครบางคนดัดแปลงมานานก่อนที่ฉันจะทำงาน

หนึ่งอ่าน: AuthorizedKeysFile .ssh/authorized_keys

และอีกอ่าน: AuthorizedKeysFile ~/.ssh/authorized_keysซึ่งอยู่บนเซิร์ฟเวอร์ที่ไม่ยอมรับคีย์ของฉัน เห็นได้ชัดว่าการค้นหาระหว่างสองไฟล์และสังเกตความคิดเห็นที่ระบุว่ารูปแบบการค้นหาเริ่มต้นไม่รวมส่วนนำที่~/ฉันลบออกและรีสตาร์ท sshd แก้ไขปัญหา.

— แอรอนแชมเบอร์เลน
แหล่งที่มา
1

พบปัญหานี้ด้วย setroubleshoot ดูเหมือนจะไม่ทำงานในสภาพแวดล้อมของฉันดังนั้นจึงไม่มีบันทึกบันทึกดังกล่าวใน / var / log / ข้อความ การปิดใช้งาน SELinux ไม่ใช่ตัวเลือกสำหรับฉันดังนั้นฉันจึงทำได้

restorecon -Rv ~/.ssh

หลังจากนั้นล็อกอินด้วยคีย์ rsa ก็ใช้ได้ดี

— lapin_
แหล่งที่มา
1

เหตุผลในกรณีของฉันเป็นตัวเลือกที่ตั้ง customly ในแฟ้มAuthorizedKeysFile /etc/ssh/sshd_configมันถูกตั้งค่าเป็น dir ที่บ้านของผู้ใช้คนอื่น ( /home/webmaster/.ssh/authorized_keys) ดังนั้นผู้ใช้ที่ฉันพยายามเข้าสู่ระบบจึงไม่สามารถเข้าถึงไฟล์ / ไดเรกทอรีนั้นได้

หลังจากเปลี่ยนแล้วรีสตาร์ท ssh-server ( service ssh restart) ทุกอย่างกลับมาเป็นปกติ ฉันสามารถเข้าสู่ระบบด้วยรหัสส่วนตัวของฉันตอนนี้

— ihoru
แหล่งที่มา
1

ในกรณีของเราปัญหาเกี่ยวข้องกับความจริงที่ว่าไฟร์วอลล์และกฎ NATing ของเราไม่ได้ตั้งค่าอย่างถูกต้อง

พอร์ต 22 กำลังถูกนำไปยังเซิร์ฟเวอร์ที่ไม่ถูกต้องซึ่งไม่รู้จักคีย์และผู้ใช้ของเรา

หากบางคนถึงจุดนี้ tcpdump และ telnet สามารถเป็นเพื่อนของคุณได้

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

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

Ssh สามารถสร้างปริมาณการใช้งานจำนวนมากซึ่งทำให้ tcpdump ออกยากที่จะค้นหาสิ่งที่คุณกำลังมองหา

สิ่งนี้ช่วยฉัน

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

ลอง telnet จากเซิร์ฟเวอร์ 3 ตัวไม่ใช่คอมพิวเตอร์ปัจจุบันของคุณ @ [mylocalip] คุณต้องการดูว่าทราฟฟิกใดถึงเซิร์ฟเวอร์ของคุณ

— nelaaro
แหล่งที่มา
0

บันทึกข้อผิดพลาดฝั่งไคลเอ็นต์สิ้นสุดดังนี้:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@x.x.x.x's password:

อาจเกิดจากข้อ จำกัด ฝั่งเซิร์ฟเวอร์ (รีโมต) ในการล็อกอินรูทเมื่อไฟล์คอนฟิกูเรชันsshdมี:

PermitRootLogin: no

ข้อเสนอแนะของ JonCav ในการเปิดใช้งานการบันทึกมีประโยชน์ในการแก้ไขข้อบกพร่องของปัญหา ในขณะที่การดีบักฝั่งไคลเอ็นต์ไม่ช่วยอย่างน่าทึ่งให้วางสิ่งต่อไปนี้ในไฟล์sshd_configของเซิร์ฟเวอร์sshd :

SyslogFacility AUTH
LogLevel DEBUG

จบลงด้วยการผลิตข้อความบันทึกที่เป็นประโยชน์:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

ในกรณีที่การล็อกอินรูทล้มเหลวและการอนุญาตให้ใช้การพิสูจน์ตัวตนแบบใช้คีย์เท่านั้นสำหรับการล็อกอินรูทได้รับอนุญาตจากนโยบายความปลอดภัยของคุณการเปลี่ยนไฟล์sshd_configสามารถช่วยได้:

 PermitRootLogin without-password

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

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

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

— kbulgrien
แหล่งที่มา
0

ฉันเห็นได้ว่าทำไมความปลอดภัยสามารถรบกวนผู้คน ฉันเพิ่งมีssh won't use my keyปัญหาอีกครั้ง ฉันแก้ไขมันโดยลงชื่อเข้าใช้เซิร์ฟเวอร์ระยะไกลและเรียกใช้

/usr/sbin/sshd -sDp 23456

และจากเดสก์ท็อปของฉัน (พยายาม ssh ไปยังเซิร์ฟเวอร์)

ssh -vvvv server -p 23456

บนเซิร์ฟเวอร์ฉันได้รับ Authentication refused: bad ownership or modes for directory /

ดูแลระบบใหม่บางอย่างทำให้การอนุญาตและกรรมสิทธิ์เป็นสิ่งที่ฉันแก้ไขด้วย:

chmod 0755 / ; chown root:root /

(ฉันเคยต้องการ chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubแต่การตรวจสอบ sshd / ค้นหาการอนุญาตรากเป็นสิทธิ์ใหม่สำหรับฉัน) ตอนนี้ฉันจะตรวจสอบ rootkit แล้วเช็ดและติดตั้งใหม่อีกครั้ง

— Alexx Roche
แหล่งที่มา
0

ในกรณีของฉันปัญหาเกิดขึ้นกับผู้บริหารเชลล์ที่ไม่ถูกต้อง

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

เปลี่ยนไฟล์ / etc / passwd สำหรับผู้ใช้นั้น

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....
— nelaaro
แหล่งที่มา
0

ฉันมีปัญหานี้ใน CentOS 7 ฉันเป็นผู้ใช้ Linux ที่ใช้เดเบียนเป็นประจำดังนั้นฉันจึงเป็นปลาจากน้ำ ฉันสังเกตเห็นว่าในเซิร์ฟเวอร์บางตัวมันใช้งานได้ audit.log บอกว่าไม่มีประโยชน์และ secure.log ก็ไม่ได้ให้อะไรเลย ฉันพบว่าความแตกต่างที่แท้จริงเพียงอย่างเดียวคือความแตกต่างของบริบทความปลอดภัยในไฟล์และไดเรกทอรีระหว่างสิ่งที่ทำงานและสิ่งที่ไม่ได้ทำ รับความปลอดภัยด้วย

sudo ls -laZ <user-home>/.ssh

ของไดเรกทอรี (ฉันสมมติว่าเป็นค่าเริ่มต้นจำนวนมากใน sshd_config)

คุณควรเห็นบ้าง ssh_home_tและuser_home_tคุณสมบัติ หากคุณไม่ใช้chconคำสั่งเพื่อเพิ่มคุณสมบัติที่ขาดหายไป

ตัวอย่างเช่น

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

ในกรณีของฉันสงสัยของฉันคือผู้ใช้ที่สร้างขึ้นในลักษณะที่ไม่ได้มาตรฐาน /var/libบ้านของเขาเป็นไดเรกทอรีใน

ข้อมูลเพิ่มเติมใน: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

— hanzo2001
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.