SSH หยุดทำงานหลังจากอัปเดตเซิร์ฟเวอร์หรือไม่ เกิดอะไรขึ้น?


9

ฉันใช้การเชื่อมต่อ SSH ที่ใช้ PKI มานานกว่า 10 ปีแล้ว ทันใดนั้นหลังจากการอัพเดทเซิร์ฟเวอร์ - การเชื่อมต่อบางอย่างหยุดทำงาน ฉันใช้คีย์ PKI เดียวกันกับที่ฉันใช้มาหลายปี (เซิร์ฟเวอร์แต่ละเครื่องมีรหัสของตัวเองฉันมีชุดคีย์ส่วนตัวขนาดเล็ก)

การทำงาน - มีลักษณะเช่นนี้:

C:\Users\michael>ssh2 -p 2222 root@192.168.129.64 date
Authentication successful.
Fri Nov 25 10:30:42  2016

ดูเหมือนว่าจะไม่ทำงาน:

C:\Users\michael>ssh2 root@192.168.129.64 date
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).

มีอะไรเปลี่ยนแปลง


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

1
ฉันสามารถเข้าถึงเซิร์ฟเวอร์ได้เสมอโชคดี โดยทั่วไปเมื่อใช้การอัปเดตฉันพยายามที่จะเป็น 'บนคอนโซล' ด้วยเหตุผลเช่นที่คุณพูดถึง สิ่งที่ฉันพยายามแสดงที่นี่คือวิธีการดีบักเมื่อทำงานกับบางอย่าง (เช่นผงสำหรับอุดรูเมื่อเร็ว ๆ นี้) แต่ไม่ใช่อื่น ๆ (เช่น ssh-client อายุ 14 ปีที่ไม่ทราบอัลกอริธึม ciphers, kex และ mac ที่ปรับปรุงแล้ว
Michael Felt

คำตอบ:


14

หลังจากอัปเดต - ผลข้างเคียงอาจเข้ามาเล่น ด้วย OpenSSH - ค่าเริ่มต้นจะเปลี่ยนบ่อยครั้ง OpenBSD (ผู้ดูแล / พัฒนา OpenSSH) มีนโยบายของ OpenBSD ที่จะไม่ต้องกังวลเกี่ยวกับความเข้ากันได้ย้อนหลัง สิ่งนี้สามารถ 'ทำลาย' สิ่งที่อ่านแล้วทำงานได้ดี

มีคำใบ้ขนาดใหญ่ - ที่ฉันไม่ได้สังเกตเห็นเมื่อสิ่งนี้เกิดขึ้นกับฉันเป็นครั้งแรก (โดยใช้ส่วนต่อประสาน GUI และฉันคลิกมันออกไปและ 'โกรธ' กับ 'อัปเดตที่โง่เขลา - รุ่นใหม่ใช้งานไม่ได้' เปิดรุ่นใหม่ ไม่ได้หัก - แต่ OpenBSD / OpenSSH เริ่มเปลี่ยนค่าเริ่มต้นการแลกเปลี่ยนคีย์ที่เริ่มต้นด้วย OpenSSH-6.7p1 ดู: http://www.openssh.com/txt/release-6.7อย่างน่าสังเกต:

การเปลี่ยนแปลงตั้งแต่ OpenSSH 6.6

การเปลี่ยนแปลงที่อาจเข้ากันไม่ได้

  • sshd (8): ชุด ciphers และ MAC เริ่มต้นได้รับการแก้ไขเพื่อ
    ลบอัลกอริทึมที่ไม่ปลอดภัย โดยเฉพาะ CBC ciphers และ arcfour *
    จะถูกปิดใช้งานตามค่าเริ่มต้น

    อัลกอริทึมชุดเต็มยังคงมีอยู่หากกำหนดค่า
    อย่างชัดเจนผ่านตัวเลือก Ciphers และ MACs sshd_config

ปัญหาของฉันคือฉันมีลูกค้าเก่าที่ไม่มีค่าเริ่มต้นใหม่ดังนั้นจึงไม่สามารถเชื่อมต่อได้

สองเส้นทางโซลูชัน: แก้ไข / แก้ไขเซิร์ฟเวอร์หรือ - แก้ไข / แก้ไขไคลเอ็นต์

วิธีแก้ปัญหาเซิร์ฟเวอร์: นำการตั้งค่า "เก่า" กลับมาเพื่อให้ลูกค้า "เก่า" สามารถเชื่อมต่อนั่นคือ - เป็นมิตรกับลูกค้าที่มีอยู่ - แก้ไขไฟล์ sshd_config และเพิ่มกลับ (พอ) ของ ciphers เก่า

สายสำคัญในการเปลี่ยน / เพิ่มใน sshd_config เป็น:

ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-cbc
KexAlgorithms  curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1

เพียงเพิ่ม:

# Ciphers
# The dafaults starting with OpenSSH 6.7 are:
# aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com
# older clients may need an older cipher, e.g.
# ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
# only adding aes256-cbc as an "old" cipher

ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-cbc

# KEX Key Exchange algorithms
# default from openssh 6.7 are:
# curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,\
#  diffie-hellman-group14-sha1
# an older kex are: none,KexAlgorithms diffie-hellman-group1-sha1

# only adding diffie-hellman-group-sha1  as an "old" KEX
# and this should be deleted ASAP as it is clearly "one of the problems" with SSL based encryption
KexAlgorithms  curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

# MAC message authentification code
# the new defaults are:
# umac-64-etm@openssh.com,umac-128-etm@openssh.com,
# hmac-sha2-256-etm@openssh.com,hmac-sha2-512-
# etm@openssh.com,
# umac-64@openssh.com,umac-128@openssh.com,
# hmac-sha2-256,hmac-sha2-512

# older defaults (still supported) are:
# macs hmac-sha1,hmac-md5

# consider removing hmac-sha1-96,hmac-sha1,hmac-md5 "Soon!"
macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1

โซลูชัน # 2 - แก้ไข / แทนที่ไคลเอ็นต์

วิธีง่ายๆในการดูว่าลูกค้าปัจจุบันสนับสนุนลูกค้า (สมมติว่า CLI) คืออะไรssh -hและดูว่ามีสิ่งใดบ้างที่:

Supported ciphers:
  3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,des-cbc@ssh.com,cast128-cbc,rc2-cbc@ssh.com,arcfour,none
Supported MAC algorithms:
  hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-sha256@ssh.com,hmac-sha256-96@ssh.com,hmac-ripemd160@ssh.com,hmac-ripemd160-96@ssh.com,hmac-tiger128@ssh.com,hmac-tiger128-96@ssh.com,hmac-tiger160@ssh.com,hmac-tiger160-96@ssh.com,hmac-tiger192@ssh.com,hmac-tiger192-96@ssh.com,none

อีกคำสั่งที่มีประโยชน์คือ: ssh -V

ssh2: SSH Secure Shell 3.2.9 Windows Client
Product: SSH Secure Shell for Workstations
License type: none (non-commercial)

Mine - เป็น - ลูกค้าเก่ามาก - สำหรับเดสก์ท็อปของฉัน เมื่อมองจากด้านบนคุณจะเห็นว่ามันไม่รองรับอัลกอริธึมที่ต้องการ - 15 ปีต่อมาไม่ว่าจะเป็น -cbr (หมุน), -cbc (block-copy) เพียงอย่างเดียว

หากลูกค้าของคุณไม่มีตัวเลือกในการจัดหากุญแจ ฯลฯ สนับสนุน (OpenSSH ควรมีตัวเลือก-Q) เพียงแค่เริ่มการเชื่อมต่อกับตัวคุณเองเช่นssh -v localhostและมีสายเช่นนี้เพื่อบอกคุณว่าเป็นที่รู้จักกัน:

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-grousha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysatiu.se
...

และสิ่งที่พบ (และใช้):

debug2: mac_setup: found hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none

พิเศษ: ข้อมูลการดีบักจากการเชื่อมต่อที่ล้มเหลว - รายละเอียดเพิ่มเติม

หรือสิ่งที่พยายาม แต่พลาด

debug: OpenSSH: Major: 7 Minor: 3 Revision: 0
debug: Ssh2Transport: All versions of OpenSSH handle kex guesses incorrectly.
debug: Ssh2Transport: Algorithm negotiation failed for c_to_s_cipher: client list: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour vs. server list : chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug: Ssh2Transport: Algorithm negotiation failed for s_to_c_cipher: client list: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour vs. server list : chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug: Ssh2Transport: lang s to c: `', lang c to s: `'
debug: Ssh2Transport: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host_key = ssh-rsa)
debug: Ssh2Common: DISCONNECT received: Algorithm negotiation failed.

แก้ไข: เพิ่ม 02-jan-2017

ส่วนใหม่ - ปุ่มใดบ้างที่หยุดทำงาน

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

กล่าวโดยสรุป openssh-7 (.3) จะไม่ส่งคีย์สาธารณะ DSA อีกต่อไป

ด้านล่างฉันเปรียบเทียบผลลัพธ์ของ openssh
/ usr / bin / ssh สองเวอร์ชัน(เวอร์ชันเก่าด้านซ้าย) และ
/ opt / bin / ssh (เวอร์ชั่นใหม่ด้านขวา) - คำสั่งคือ:

${version}/ssh -v user@host date

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

สิ่งที่ฉันต้องการให้คุณสังเกตคือรุ่นเก่าเสนอ (และได้รับการยอมรับจากเซิร์ฟเวอร์ 'เก่า' - คู่คีย์ DSA ในขณะที่เซิร์ฟเวอร์ใหม่ไม่เสนอคีย์ DSA

หมายเหตุ: 'โซลูชัน' สำหรับสิ่งนี้คือการเพิ่มคู่อย่าง rsa, ecdsa หรือคู่ PKI ที่ใช้ ed25519

OpenSSH_6.0p1, OpenSSL 1.0.2h  3 May 2016                     | OpenSSH_7.3p1, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config        | debug1: Reading configuration data /var/openssh/etc/ssh_confi
debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): <
        0509-026 System error: A file or directory in the pat <
                                                              <
debug1: Error loading Kerberos, disabling Kerberos auth.      <
debug1: Connecting to x061 [192.168.129.61] port 22.            debug1: Connecting to x061 [192.168.129.61] port 22.
debug1: Connection established.                                 debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type 1          debug1: identity file /home/michael/.ssh/id_rsa type 1
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1    debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type 2          debug1: identity file /home/michael/.ssh/id_dsa type 2
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1    debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: identity file /home/michael/.ssh/id_ecdsa type 3        debug1: identity file /home/michael/.ssh/id_ecdsa type 3
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_ecdsa-cert type -   debug1: identity file /home/michael/.ssh/id_ecdsa-cert type -
debug1: Remote protocol version 2.0, remote software version  | debug1: key_load_public: No such file or directory
debug1: match: OpenSSH_6.0 pat OpenSSH*                       | debug1: identity file /home/michael/.ssh/id_ed25519 type -1
                                                              > debug1: key_load_public: No such file or directory
                                                              > debug1: identity file /home/michael/.ssh/id_ed25519-cert type
debug1: Enabling compatibility mode for protocol 2.0            debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0              | debug1: Local version string SSH-2.0-OpenSSH_7.3
                                                              > debug1: Remote protocol version 2.0, remote software version
                                                              > debug1: match: OpenSSH_6.0 pat OpenSSH* compat 0x04000000
                                                              > debug1: Authenticating to x061:22 as 'padmin'
debug1: SSH2_MSG_KEXINIT sent                                   debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received                               debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none          | debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: client->server aes128-ctr hmac-md5 none          | debug1: kex: host key algorithm: ssh-rsa
                                                              > debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@o
                                                              > debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@o
debug1: sending SSH2_MSG_KEX_ECDH_INIT                          debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY                       debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 9f:0a:4d:a8:1b:ba:e6:d4:1a:b2:cd | debug1: Server host key: ssh-rsa SHA256:ORf5UVI7mRm/9MthM2qXM
debug1: Host 'x061' is known and matches the RSA host key.      debug1: Host 'x061' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:57          debug1: Found key in /home/michael/.ssh/known_hosts:57
debug1: ssh_rsa_verify: signature correct                     | debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent                                   debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS                              debug1: expecting SSH2_MSG_NEWKEYS
                                                              > debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received                               debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server                         | debug1: Skipping ssh-dss key /home/michael/.ssh/id_dsa - not
debug1: SSH2_MSG_SERVICE_REQUEST sent                         <
debug1: SSH2_MSG_SERVICE_ACCEPT received                        debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password   debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey                   debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/michael/.ssh/id_rsa      debug1: Offering RSA public key: /home/michael/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password   debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/michael/.ssh/id_dsa    | debug1: Offering ECDSA public key: /home/michael/.ssh/id_ecds
debug1: Server accepts key: pkalg ssh-dss blen 433            | debug1: Authentications that can continue: publickey,password
debug1: read PEM private key done: type DSA                   | debug1: Trying private key: /home/michael/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).                 | debug1: Next authentication method: keyboard-interactive
Authenticated to x061 ([192.168.129.61]:22).                  | debug1: Authentications that can continue: publickey,password
debug1: channel 0: new [client-session]                       | debug1: Next authentication method: password
debug1: Requesting no-more-sessions@openssh.com               | padmin@x061's password:
debug1: Entering interactive session.                         |

ฉันยังมีผู้ใช้ที่นี่บ่นเกี่ยวกับคีย์ที่มีโปรโตคอลล้าสมัยตามเวลาที่ฉันอัพเกรดเป็น Debian 8
Rui F Ribeiro

1
ฉันลืมที่จะพูดถึง - ว่าสำหรับ windows ของฉันฉันเปลี่ยนไปเป็นสีโป๊ว (ssh.com ขายให้กับธุรกิจเท่านั้น) - จะอยู่ด้วยssh2ถ้าพวกเขายอมรับฉัน - ส่วนใหญ่เพื่อความสะดวกในการscpถ่ายโอนจากหน้าต่างเดียวกันssh
Michael Felt

1
อัปเดตลูกค้าของคุณแทนที่จะใช้ไคลเอนต์โบราณเป็นเวลาหลายปีและเปิดใช้งานอัลกอริทึมที่อาจผิดปกติ
Jakuje

1
ดูอัพเกรดคีย์ SSH ของคุณ! สำหรับรายละเอียดเพิ่มเติม แต่ตามที่ @Jakuje กล่าวว่าเป็นความคิดที่ดีที่จะเก็บคีย์เก่าไคลเอนต์เก่าและอัลกอริทึมเก่าไว้
Stephen Kitt

อายุของคีย์ไม่ใช่ปัญหา imho - แต่เป็นชนิดและขนาด "DSA" หมด "RSA" อย่างน้อย 2048 บิต 'ดีกว่า' คือ ecdsa ตามที่ @Jakuje กล่าวถึง - และสิ่งที่ถามเกี่ยวกับเรื่องนี้ - อัพเดทไคลเอ็นต์ - แต่ยังปรับปรุงการตั้งค่าเริ่มต้น ในฐานะลูกค้าคุณสามารถ 'เรียกร้อง' เซิร์ฟเวอร์ใช้อัลกอริธึมที่ดีกว่าโดยไม่เสนอข้อบกพร่องที่อ่อนแอ
Michael Felt
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.