Kutolewa kwa OpenSSH 8.0

Baada ya miezi mitano ya maendeleo imewasilishwa kutolewa OpenSSH 8.0, mteja wazi na utekelezaji wa seva kwa kufanya kazi kupitia itifaki za SSH 2.0 na SFTP.

Mabadiliko kuu:

  • Usaidizi wa kimajaribio wa mbinu muhimu ya kubadilishana ambayo ni sugu kwa mashambulizi ya nguvu kwenye kompyuta ya kiasi umeongezwa kwa ssh na sshd. Kompyuta za quantum zina kasi zaidi katika kutatua tatizo la kuoza nambari asilia kuwa sababu kuu, ambazo ni msingi wa algoriti za kisasa za usimbaji fiche zisizolinganishwa na haziwezi kutatuliwa kwa ufanisi kwenye vichakataji vya classical. Njia iliyopendekezwa inategemea algorithm NRU Mkuu (kazi ntrup4591761), iliyotengenezwa kwa mifumo ya siri ya baada ya quantum, na njia ya ubadilishanaji wa ufunguo wa elliptic curve X25519;
  • Katika sshd, maagizo ya ListenAddress na PermitOpen hayatumii tena syntax ya urithi ya "mwenyeji/bandari", ambayo ilitekelezwa mwaka wa 2001 kama njia mbadala ya "host:port" ili kurahisisha kufanya kazi na IPv6. Katika hali ya kisasa, sintaksia β€œ[::6]:1” imeanzishwa kwa IPv22, na β€œmwenyeji/bandari” mara nyingi huchanganyikiwa na kuonyesha subnet (CIDR);
  • ssh, wakala wa ssh na ssh-add funguo za usaidizi sasa ECDSA katika PKCS#11 tokeni;
  • Katika ssh-keygen, ukubwa wa ufunguo chaguo-msingi wa RSA umeongezwa hadi biti 3072, kwa mujibu wa mapendekezo mapya ya NIST;
  • ssh inaruhusu matumizi ya mpangilio wa "PKCS11Provider=none" kubatilisha agizo la PKCS11Provider lililobainishwa katika ssh_config;
  • sshd hutoa onyesho la kumbukumbu la hali wakati muunganisho umekatishwa wakati wa kujaribu kutekeleza amri zilizozuiwa na kizuizi cha "ForceCommand=internal-sftp" katika sshd_config;
  • Katika ssh, wakati wa kuonyesha ombi la kuthibitisha kukubalika kwa ufunguo mpya wa mwenyeji, badala ya jibu la "ndio", alama ya vidole sahihi ya ufunguo sasa inakubaliwa (kwa kukabiliana na mwaliko wa kuthibitisha muunganisho, mtumiaji anaweza kunakili heshi ya marejeleo iliyopokelewa kando kupitia ubao wa kunakili, ili usiilinganishe mwenyewe);
  • ssh-keygen hutoa uongezaji wa kiotomatiki wa nambari ya mlolongo wa cheti wakati wa kuunda saini za dijiti kwa cheti nyingi kwenye safu ya amri;
  • Chaguo jipya "-J" limeongezwa kwa scp na sftp, sawa na mpangilio wa ProxyJump;
  • Katika ssh-agent, ssh-pkcs11-helper na ssh-add, usindikaji wa chaguo la mstari wa amri "-v" umeongezwa ili kuongeza maudhui ya habari ya pato (ikibainishwa, chaguo hili hupitishwa kwa michakato ya mtoto, kwa mfano, wakati ssh-pkcs11-helper inaitwa kutoka ssh-agent );
  • Chaguo la "-T" limeongezwa kwa ssh-add ili kujaribu kufaa kwa funguo katika ssh-ajenti kwa kutekeleza uundaji sahihi wa saini za dijiti na shughuli za uthibitishaji;
  • sftp-server hutekeleza usaidizi wa kiendelezi cha itifaki cha "lsetstat kwenye openssh.com", ambacho huongeza usaidizi kwa uendeshaji wa SSH2_FXP_SETSTAT kwa SFTP, lakini bila kufuata viungo vya ishara;
  • Imeongeza chaguo la "-h" kwa sftp kutekeleza amri za chown/chgrp/chmod na maombi ambayo hayatumii viungo vya ishara;
  • sshd hutoa mpangilio wa $SSH_CONNECTION kutofautisha kwa mazingira kwa PAM;
  • Kwa sshd, modi ya kulinganisha ya "Fainali ya Mechi" imeongezwa kwa ssh_config, ambayo ni sawa na "Linganisha kanuni", lakini haihitaji urekebishaji wa jina la mpangishaji kuwashwa;
  • Imeongeza usaidizi wa kiambishi awali cha '@' kwa sftp ili kuzima utafsiri wa matokeo ya amri zinazotekelezwa katika hali ya bechi;
  • Unapoonyesha yaliyomo kwenye cheti kwa kutumia amri
    "ssh-keygen -Lf /path/certificate" sasa inaonyesha algoriti inayotumiwa na CA ili kuthibitisha cheti;

  • Usaidizi ulioboreshwa kwa mazingira ya Cygwin, kwa mfano kutoa ulinganisho usiojali kesi wa majina ya kikundi na watumiaji. Mchakato wa sshd katika mlango wa Cygwin umebadilishwa hadi cygsshd ili kuepuka kuingiliwa na mlango wa OpenSSH unaotolewa na Microsoft;
  • Imeongeza uwezo wa kujenga kwa kutumia tawi la majaribio la OpenSSL 3.x;
  • Imeondolewa kuathirika (CVE-2019-6111) katika utekelezaji wa matumizi ya scp, ambayo inaruhusu faili kiholela katika saraka lengwa kuandikwa juu ya upande wa mteja wakati wa kufikia seva inayodhibitiwa na mshambulizi. Shida ni kwamba wakati wa kutumia scp, seva huamua ni faili gani na saraka za kutuma kwa mteja, na mteja huangalia tu usahihi wa majina ya kitu kilichorejeshwa. Kukagua kwa upande wa mteja kunazuia tu kusafiri zaidi ya saraka ya sasa (β€œ../”), lakini hakuzingatii uhamishaji wa faili zilizo na majina tofauti na yale yaliyoombwa awali. Katika kesi ya kunakili kwa kurudia (-r), pamoja na majina ya faili, unaweza pia kudhibiti majina ya subdirectories kwa njia sawa. Kwa mfano, ikiwa mtumiaji atanakili faili kwenye saraka ya nyumbani, seva inayodhibitiwa na mvamizi inaweza kutoa faili zilizo na majina .bash_aliases au .ssh/authorized_keys badala ya faili zilizoombwa, na zitahifadhiwa kwa matumizi ya scp katika mtumiaji. saraka ya nyumbani.

    Katika toleo jipya, matumizi ya scp yamesasishwa ili kuangalia mawasiliano kati ya majina ya faili yaliyoombwa na yale yaliyotumwa na seva, ambayo hufanywa kwa upande wa mteja. Hii inaweza kusababisha matatizo na usindikaji wa barakoa, kwa kuwa vibambo vya upanuzi wa barakoa vinaweza kuchakatwa kwa njia tofauti kwenye seva na pande za mteja. Iwapo tofauti kama hizo zitasababisha mteja kuacha kupokea faili katika scp, chaguo la "-T" limeongezwa ili kuzima ukaguzi wa upande wa mteja. Ili kurekebisha tatizo kikamilifu, urekebishaji wa dhana ya itifaki ya scp inahitajika, ambayo yenyewe tayari imepitwa na wakati, kwa hivyo inashauriwa kutumia itifaki za kisasa zaidi kama vile sftp na rsync badala yake.

Chanzo: opennet.ru

Kuongeza maoni