ການປ່ອຍ OpenSSH 8.2 ດ້ວຍການຮອງຮັບ FIDO/U2F tokens authentication tokens ສອງປັດໃຈ

ຫຼັງຈາກສີ່ເດືອນຂອງການພັດທະນາ ນຳ ສະ ເໜີ ປ່ອຍຕົວ OpenSSH 8.2, ລູກຄ້າເປີດແລະການປະຕິບັດເຄື່ອງແມ່ຂ່າຍສໍາລັບການເຮັດວຽກຜ່ານໂປໂຕຄອນ SSH 2.0 ແລະ SFTP.

ການປັບປຸງທີ່ສໍາຄັນໃນການປ່ອຍ OpenSSH 8.2 ແມ່ນຄວາມສາມາດໃນການນໍາໃຊ້ການກວດສອບສອງປັດໃຈໂດຍໃຊ້ອຸປະກອນທີ່ສະຫນັບສະຫນູນໂປໂຕຄອນ U2F, ພັດທະນາໂດຍພັນທະມິດ Fido. U2F ອະ​ນຸ​ຍາດ​ໃຫ້​ການ​ສ້າງ tokens ຮາດ​ແວ​ລາ​ຄາ​ຖືກ​ຕ​່​ໍ​າ​ເພື່ອ​ກວດ​ສອບ​ການ​ມີ​ທາງ​ດ້ານ​ຮ່າງ​ກາຍ​ຂອງ​ຜູ້​ໃຊ້​, ການ​ພົວ​ພັນ​ກັບ​ເຂົາ​ເຈົ້າ​ໂດຍ​ຜ່ານ USB​, Bluetooth ຫຼື NFC​. ອຸປະກອນດັ່ງກ່າວຖືກສົ່ງເສີມເປັນວິທີການພິສູດຢືນຢັນສອງປັດໃຈຢູ່ໃນເວັບໄຊທ໌, ໄດ້ຮັບການສະຫນັບສະຫນູນຈາກຕົວທ່ອງເວັບທີ່ສໍາຄັນແລະຖືກຜະລິດໂດຍຜູ້ຜະລິດຕ່າງໆ, ລວມທັງ Yubico, Feitian, Thetis ແລະ Kensington.

ເພື່ອໂຕ້ຕອບກັບອຸປະກອນທີ່ຢືນຢັນການປະກົດຕົວຂອງຜູ້ໃຊ້, ປະເພດຫຼັກໃໝ່ “ecdsa-sk” ແລະ “ed25519-sk” ໄດ້ຖືກເພີ່ມໃສ່ OpenSSH, ເຊິ່ງໃຊ້ລະບົບເຄື່ອງໝາຍລາຍເຊັນດິຈິຕອນຂອງ ECDSA ແລະ Ed25519, ສົມທົບກັບ SHA-256 hash. ຂັ້ນຕອນການພົວພັນກັບ tokens ແມ່ນຖືກຈັດໃສ່ໃນຫ້ອງສະໝຸດກາງ, ເຊິ່ງຖືກໂຫຼດໃນແບບດຽວກັນກັບຫ້ອງສະໝຸດສຳລັບການສະໜັບສະໜຸນ PKCS#11 ແລະເປັນ wrapper ຢູ່ເທິງຫໍສະໝຸດ. libfido2, ເຊິ່ງສະຫນອງເຄື່ອງມືສໍາລັບການສື່ສານກັບ tokens ຜ່ານ USB (FIDO U2F/CTAP 1 ແລະ FIDO 2.0/CTAP 2 protocols ໄດ້ຮັບການສະຫນັບສະຫນູນ). ຫ້ອງສະໝຸດລະດັບປານກາງ libsk-libfido2 ກະກຽມໂດຍຜູ້ພັດທະນາ OpenSSH ລວມ ເຂົ້າໄປໃນ libfido2 ຫຼັກ, ເຊັ່ນດຽວກັນກັບ ໄດເວີ HID ສໍາລັບ OpenBSD.

ເພື່ອກວດສອບຄວາມຖືກຕ້ອງ ແລະສ້າງລະຫັດ, ທ່ານຕ້ອງລະບຸພາລາມິເຕີ “SecurityKeyProvider” ໃນການຕັ້ງຄ່າ ຫຼືຕັ້ງຕົວແປສະພາບແວດລ້ອມ SSH_SK_PROVIDER, ຊີ້ບອກເສັ້ນທາງໄປຫາຫ້ອງສະໝຸດພາຍນອກ libsk-libfido2.so (ສົ່ງອອກ SSH_SK_PROVIDER=/path/to/libsk-libfido2. ດັ່ງນັ້ນ). ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງ openssh ດ້ວຍການສະຫນັບສະຫນູນໃນຕົວສໍາລັບຫ້ອງສະຫມຸດຊັ້ນ (--with-security-key-builtin), ໃນກໍລະນີນີ້ທ່ານຈໍາເປັນຕ້ອງກໍານົດພາລາມິເຕີ "SecurityKeyProvider = ພາຍໃນ".
ຕໍ່ໄປ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ດໍາເນີນການ "ssh-keygen -t ecdsa-sk" ຫຼື, ຖ້າລະຫັດໄດ້ຖືກສ້າງແລະກໍາຫນົດຄ່າແລ້ວ, ເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍໂດຍໃຊ້ "ssh". ເມື່ອທ່ານເປີດໃຊ້ ssh-keygen, ຄູ່ກະແຈທີ່ສ້າງຂຶ້ນຈະຖືກບັນທຶກໄວ້ໃນ “~/.ssh/id_ecdsa_sk” ແລະສາມາດນຳໃຊ້ໄດ້ຄືກັນກັບກະແຈອື່ນໆ.

ກະແຈສາທາລະນະ (id_ecdsa_sk.pub) ຄວນຖືກສຳເນົາໃສ່ເຊີບເວີໃນໄຟລ໌ authorized_keys. ໃນດ້ານເຊີຟເວີ, ມີພຽງແຕ່ລາຍເຊັນດິຈິຕອນເທົ່ານັ້ນທີ່ຖືກຢືນຢັນ, ແລະການພົວພັນກັບ tokens ແມ່ນດໍາເນີນຢູ່ໃນຝ່າຍລູກຄ້າ (ທ່ານບໍ່ຈໍາເປັນຕ້ອງຕິດຕັ້ງ libsk-libfido2 ໃນເຄື່ອງແມ່ຂ່າຍ, ແຕ່ເຄື່ອງແມ່ຂ່າຍຕ້ອງສະຫນັບສະຫນູນປະເພດ "ecdsa-sk"). . ກະແຈສ່ວນຕົວທີ່ສ້າງຂຶ້ນ (id_ecdsa_sk) ແມ່ນເປັນຕົວຈັບກະແຈທີ່ຈຳເປັນ, ປະກອບເປັນກະແຈທີ່ແທ້ຈິງພຽງແຕ່ປະສົມປະສານກັບລໍາດັບລັບທີ່ເກັບໄວ້ໃນດ້ານ U2F token. ຖ້າລະຫັດ id_ecdsa_sk ຕົກຢູ່ໃນມືຂອງຜູ້ໂຈມຕີ, ເພື່ອຜ່ານການກວດສອບຄວາມຖືກຕ້ອງ, ລາວຍັງຈະຕ້ອງໄດ້ເຂົ້າເຖິງ token ຮາດແວ, ໂດຍທີ່ລະຫັດສ່ວນຕົວທີ່ເກັບໄວ້ໃນໄຟລ໌ id_ecdsa_sk ແມ່ນບໍ່ມີປະໂຫຍດ.

ນອກຈາກນັ້ນ, ໂດຍຄ່າເລີ່ມຕົ້ນ, ເມື່ອປະຕິບັດການໃດໆທີ່ມີກະແຈ (ທັງລະຫວ່າງການຜະລິດແລະໃນລະຫວ່າງການກວດສອບ), ການຢືນຢັນທ້ອງຖິ່ນກ່ຽວກັບລັກສະນະທາງດ້ານຮ່າງກາຍຂອງຜູ້ໃຊ້ແມ່ນຕ້ອງການ, ຕົວຢ່າງ, ມັນຖືກສະເຫນີໃຫ້ແຕະ sensor ໃນ token, ເຊິ່ງເຮັດໃຫ້ມັນຍາກທີ່ຈະ ປະຕິບັດການໂຈມຕີທາງໄກໃນລະບົບທີ່ມີ token ເຊື່ອມຕໍ່. ໃນຖານະອື່ນຂອງການປ້ອງກັນ, ລະຫັດຜ່ານຍັງສາມາດຖືກກໍານົດໃນໄລຍະເລີ່ມຕົ້ນຂອງ ssh-keygen ເພື່ອເຂົ້າເຖິງໄຟລ໌ທີ່ສໍາຄັນ.

ເວີຊັນໃໝ່ຂອງ OpenSSH ຍັງໄດ້ປະກາດການຍົກເລີກການສະເໜີຕົວທີ່ຈະມາເຖິງຂອງ algorithms ໂດຍໃຊ້ SHA-1 hashes ເນື່ອງຈາກ ເພີ່ມ​ຂຶ້ນ ປະສິດທິຜົນຂອງການໂຈມຕີການປະທະກັນກັບຄໍານໍາຫນ້າ (ຄ່າໃຊ້ຈ່າຍໃນການເລືອກເອົາການປະທະກັນແມ່ນປະມານ 45 ພັນໂດລາ). ໃນຫນຶ່ງໃນການປ່ອຍທີ່ຈະມາເຖິງ, ພວກເຂົາວາງແຜນທີ່ຈະປິດການໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນຄວາມສາມາດໃນການນໍາໃຊ້ລະບົບການເຊັນຊື່ດິຈິຕອນສາທາລະນະ "ssh-rsa", ເຊິ່ງໄດ້ກ່າວເຖິງໃນ RFC ຕົ້ນສະບັບສໍາລັບໂປໂຕຄອນ SSH ແລະຍັງແຜ່ຂະຫຍາຍຢູ່ໃນການປະຕິບັດ (ເພື່ອທົດສອບການນໍາໃຊ້. ຂອງ ssh-rsa ໃນລະບົບຂອງທ່ານ, ທ່ານສາມາດພະຍາຍາມເຊື່ອມຕໍ່ຜ່ານ ssh ດ້ວຍທາງເລືອກ "-oHostKeyAlgorithms =-ssh-rsa").

ເພື່ອເຮັດໃຫ້ການຫັນປ່ຽນໄປສູ່ສູດການຄິດໄລ່ໃຫມ່ໃນ OpenSSH ລຽບງ່າຍ, ໃນການປ່ອຍຕົວໃນອະນາຄົດ ການຕັ້ງຄ່າ UpdateHostKeys ຈະຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ, ເຊິ່ງຈະໂອນລູກຄ້າໄປສູ່ລະບົບລະບົບທີ່ເຊື່ອຖືໄດ້ຫຼາຍຂຶ້ນໂດຍອັດຕະໂນມັດ. ສູດການຄິດໄລ່ທີ່ແນະນຳສຳລັບການເຄື່ອນຍ້າຍລວມມີ rsa-sha2-256/512 ໂດຍອີງໃສ່ RFC8332 RSA SHA-2 (ຮອງຮັບຕັ້ງແຕ່ OpenSSH 7.2 ແລະ ຖືກໃຊ້ເປັນຄ່າເລີ່ມຕົ້ນ), ssh-ed25519 (ຮອງຮັບຕັ້ງແຕ່ OpenSSH 6.5) ແລະ ecdsa-sha2-nisp256/384 ໃນ RFC521 ECDSA (ຮອງຮັບຕັ້ງແຕ່ OpenSSH 5656).

ໃນ OpenSSH 8.2, ຄວາມສາມາດໃນການເຊື່ອມຕໍ່ໂດຍໃຊ້ "ssh-rsa" ຍັງມີຢູ່, ແຕ່ algorithm ນີ້ໄດ້ຖືກລຶບອອກຈາກລາຍການ CASignatureAlgorithms, ເຊິ່ງກໍານົດສູດການຄິດໄລ່ທີ່ອະນຸຍາດໃຫ້ສໍາລັບການເຊັນໃບຢັ້ງຢືນໃຫມ່ດິຈິຕອນ. ເຊັ່ນດຽວກັນ, ສູດການຄິດໄລ່ diffie-hellman-group14-sha1 ໄດ້ຖືກໂຍກຍ້າຍອອກຈາກລະບົບການປ່ຽນລະຫັດເລີ່ມຕົ້ນທີ່ຮອງຮັບ. ມັນໄດ້ຖືກສັງເກດເຫັນວ່າການນໍາໃຊ້ SHA-1 ໃນໃບຢັ້ງຢືນແມ່ນກ່ຽວຂ້ອງກັບຄວາມສ່ຽງເພີ່ມເຕີມ, ເນື່ອງຈາກວ່າຜູ້ໂຈມຕີມີເວລາບໍ່ຈໍາກັດໃນການຄົ້ນຫາການປະທະກັນສໍາລັບໃບຢັ້ງຢືນທີ່ມີຢູ່ແລ້ວ, ໃນຂະນະທີ່ເວລາຂອງການໂຈມຕີໃນກະແຈຂອງເຈົ້າພາບແມ່ນຖືກຈໍາກັດໂດຍການຫມົດເວລາການເຊື່ອມຕໍ່ (LoginGraceTime ).

ການແລ່ນ ssh-keygen ດຽວນີ້ເປັນຄ່າເລີ່ມຕົ້ນຂອງ rsa-sha2-512 algorithm, ເຊິ່ງຖືກຮອງຮັບຕັ້ງແຕ່ OpenSSH 7.2, ເຊິ່ງອາດຈະສ້າງບັນຫາຄວາມເຂົ້າກັນໄດ້ໃນເວລາທີ່ພະຍາຍາມປະມວນຜົນໃບຢັ້ງຢືນທີ່ເຂົ້າສູ່ລະບົບ OpenSSH 8.2 ໃນລະບົບທີ່ໃຊ້ OpenSSH ລຸ້ນເກົ່າ (ເພື່ອແກ້ໄຂບັນຫາເມື່ອເວລາໃດ. ການສ້າງລາຍເຊັນ, ທ່ານສາມາດລະບຸຢ່າງຊັດເຈນ “ssh-keygen -t ssh-rsa” ຫຼືໃຊ້ ecdsa-sha2-nistp256/384/521 algorithms, ສະຫນັບສະຫນູນຕັ້ງແຕ່ OpenSSH 5.7).

ການປ່ຽນແປງອື່ນໆ:

• ຄໍາສັ່ງ Include ໄດ້ຖືກເພີ່ມເຂົ້າໃນ sshd_config, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດລວມເອົາເນື້ອໃນຂອງໄຟລ໌ອື່ນໆຢູ່ໃນຕໍາແຫນ່ງປະຈຸບັນຂອງໄຟລ໌ການຕັ້ງຄ່າ (ຫນ້າກາກ glob ສາມາດໃຊ້ໃນເວລາທີ່ກໍານົດຊື່ໄຟລ໌);
• ທາງເລືອກ "ບໍ່ຕ້ອງການແຕະຕ້ອງ" ໄດ້ຖືກເພີ່ມເຂົ້າໃນ ssh-keygen, ເຊິ່ງປິດການໃຊ້ງານເພື່ອຢືນຢັນການເຂົ້າເຖິງ token ທາງດ້ານຮ່າງກາຍໃນເວລາສ້າງລະຫັດ;
• ຄໍາສັ່ງ PubkeyAuthOptions ໄດ້ຖືກເພີ່ມເຂົ້າໃນ sshd_config, ເຊິ່ງລວມທາງເລືອກຕ່າງໆທີ່ກ່ຽວຂ້ອງກັບການກວດສອບລະຫັດສາທາລະນະ. ໃນປັດຈຸບັນ, ພຽງແຕ່ທຸງ "ບໍ່ຕ້ອງແຕະຕ້ອງ" ເທົ່ານັ້ນທີ່ຖືກສະຫນັບສະຫນູນເພື່ອຂ້າມການກວດສອບການມີຕົວຕົນສໍາລັບການພິສູດຢືນຢັນໂຕເຄນ. ໂດຍການປຽບທຽບ, ທາງເລືອກ "ບໍ່ຕ້ອງແຕະຕ້ອງ" ໄດ້ຖືກເພີ່ມໃສ່ໄຟລ໌ authorized_keys;
• ເພີ່ມຕົວເລືອກ "-O write-attestation=/path" ໃສ່ ssh-keygen ເພື່ອອະນຸຍາດໃຫ້ຂຽນໃບຢັ້ງຢືນ FIDO ເພີ່ມເຕີມເມື່ອສ້າງລະຫັດ. OpenSSH ຍັງບໍ່ທັນໃຊ້ໃບຮັບຮອງເຫຼົ່ານີ້ເທື່ອ, ແຕ່ຕໍ່ມາເຂົາເຈົ້າສາມາດໃຊ້ເພື່ອກວດສອບວ່າກະແຈຖືກວາງໄວ້ໃນຮ້ານຮາດແວທີ່ເຊື່ອຖືໄດ້;
• ໃນການຕັ້ງຄ່າ ssh ແລະ sshd, ຕອນນີ້ສາມາດກໍານົດຮູບແບບການບູລິມະສິດການຈະລາຈອນຜ່ານຄໍາແນະນໍາ IPQoS. LE DSCP (ຄວາມ​ພະ​ຍາ​ຍາມ​ຕ​່​ໍ​າ​ຕໍ່​-Hop ພຶດ​ຕິ​ກໍາ​)​;
• ໃນ ssh, ເມື່ອກໍານົດຄ່າ "AddKeysToAgent=yes", ຖ້າຄີບໍ່ມີຊ່ອງຄໍາເຫັນ, ມັນຈະຖືກເພີ່ມໃສ່ ssh-agent ທີ່ຊີ້ບອກເສັ້ນທາງໄປຫາກະແຈເປັນຄໍາຄິດຄໍາເຫັນ. IN
  ssh-keygen ແລະ ssh-agent ໃນປັດຈຸບັນຍັງໃຊ້ປ້າຍຊື່ PKCS#11 ແລະຊື່ຫົວຂໍ້ X.509 ແທນເສັ້ນທາງຫ້ອງສະຫມຸດເປັນຄໍາຄິດຄໍາເຫັນໃນກະແຈ;

• ເພີ່ມຄວາມສາມາດໃນການສົ່ງອອກ PEM ສໍາລັບ DSA ແລະ ECDSA keys ກັບ ssh-keygen;
• ເພີ່ມ ssh-sk-helper ທີ່ສາມາດປະຕິບັດໄດ້ໃຫມ່, ໃຊ້ເພື່ອແຍກຫ້ອງສະຫມຸດການເຂົ້າເຖິງ token FIDO/U2F;
• ເພີ່ມ "--with-zlib" ທາງເລືອກໃນການສ້າງ ssh ແລະ sshd ສໍາລັບການລວບລວມກັບສະຫນັບສະຫນູນຫ້ອງສະຫມຸດ zlib;
• ອີງຕາມຂໍ້ກໍານົດຂອງ RFC4253, ຄໍາເຕືອນກ່ຽວກັບການຂັດຂວາງການເຂົ້າເຖິງເນື່ອງຈາກການເກີນຂອບເຂດຈໍາກັດ MaxStartups ໄດ້ຖືກສະຫນອງໃຫ້ຢູ່ໃນປ້າຍໂຄສະນາທີ່ສະແດງໃນລະຫວ່າງການເຊື່ອມຕໍ່. ເພື່ອເຮັດໃຫ້ການວິນິດໄສງ່າຍ, ຫົວຂໍ້ຂະບວນການ sshd, ສັງເກດເຫັນໃນເວລາທີ່ໃຊ້ ps utility, ປະຈຸບັນສະແດງຈໍານວນການເຊື່ອມຕໍ່ທີ່ຖືກຢືນຢັນໃນປະຈຸບັນແລະສະຖານະຂອງຂອບເຂດຈໍາກັດ MaxStartups;
• ໃນ ssh ແລະ ssh-agent, ເມື່ອໂທຫາໂຄງການເພື່ອສະແດງຄໍາເຊີນໃນຫນ້າຈໍ, ທີ່ລະບຸຜ່ານ $SSH_ASKPASS, ທຸງທີ່ມີປະເພດຂອງການເຊື້ອເຊີນໄດ້ຖືກສົ່ງຜ່ານຕື່ມອີກ: "ຢືນຢັນ" - ກ່ອງໂຕ້ຕອບການຢືນຢັນ (ແມ່ນ / ບໍ່), "ບໍ່ມີ". ” - ຂໍ້​ຄວາມ​ຂໍ້​ມູນ​ຂ່າວ​ສານ​, “ຫວ່າງ​ເປົ່າ​” — ການ​ຮ້ອງ​ຂໍ​ລະ​ຫັດ​ຜ່ານ​;
• ເພີ່ມການດໍາເນີນການລາຍເຊັນດິຈິຕອນໃຫມ່ "find-principals" ໄປຫາ ssh-keygen ເພື່ອຊອກຫາໄຟລ໌ທີ່ອະນຸຍາດໃຫ້ເຊັນຊື່ສໍາລັບຜູ້ໃຊ້ທີ່ກ່ຽວຂ້ອງກັບລາຍເຊັນດິຈິຕອນທີ່ກໍານົດ;
• ປັບປຸງການຮອງຮັບການແຍກຂະບວນການ sshd ໃນ Linux ໂດຍໃຊ້ກົນໄກ seccomp: ການປິດການໂທລະບົບ IPC, ອະນຸຍາດໃຫ້ clock_gettime64(), clock_nanosleep_time64 ແລະ clock_nanosleep().

ແຫຼ່ງຂໍ້ມູນ: opennet.ru