Kui proovite kaugserveriga ühenduse võtmiseks kasutada ssh-i, võite saada vea, mis ei loe ühtegi vastavat võtmevahetusmeetodit, enne kui teile soovitatakse, millist krüpteerimisalgoritmi soovite kasutada. Kui tõrge ilmneb, ei saa te kaugserveriga ühendust luua. See protsess võib olla tõesti pettumust valmistav, kuid viga on nii tavaline, et leiate sageli Unixi tüübid, kes räägivad sellest, kuidas nad seda kogevad, ja annavad samu nõuandeid metsast väljumiseks.
Järgmisi vea parandamise meetodeid on testitud kõigel, millel ssh töötab, kuid tõenäoliselt leiate selle probleemi Unixi ja Linuxi süsteemidest. Peaksite saama selle parandamiseks kasutada sama protsessi, kui kasutate Windowsis ssh või midagi muud eksootilist, kuid võite avastada, et lüliti valikud on veidi erinevad.
1. meetod: serveriga uuesti ühendust võtmine ja võtmete taastamine
Enne millegi muu tegemist veenduge, et saaksite vea taasesitada. Mõnikord on see tõrketeade lihtsalt sellepärast, et on mõni kaugpoolne teenus, mis praegu ei tööta, mis võib olla vahepeal parandatud. Sel ajal, kui käitasime ssh-d virtuaalses masinas, mis lubas ühenduse luua võltsserveri aadressiga, mis oli määratud dokumentatsiooniga kinnitatud example.org-ga, kuid soovite selle asemel asendada tõelise võrguaadressi.
Kui saate selle ikkagi kätte, proovige võtmeid taastada ssh-keygen -A käsuviibalt. See värskendab vahemälu, mida ssh-rakendus kasutab kaugserveriga ühenduse loomiseks. Kui seda ei lubata, võiksite proovida ssh taaskäivitamist käivitades teenuse ssh taaskäivitamine ja annan sellele mõne hetke.
Kui teil on endiselt probleeme, tähendab see, et server ja klient ei suutnud kunagi leppida õige protokolliga, mida kasutada. OpenSSH rakendab peadpööritava hulga erinevaid protokolle, kuid keelab mitmed neist, kuna need on nüüd teadaolevalt ohustatud ja seetõttu ohtlikud. Värskenduse serveri lõpus soovite värskendada kõiki ssh-pakette, seega veenduge, et süsteemiadministraator oleks toimuvast teadlik. Kui see on teie enda server, leidke mõni hetk nende värskendamiseks.
Kui see pole valik ja mõistate ohustatud algoritmi kasutamise ohtusid, on sellest tõrketeadest mööda hiilimiseks kliendipoolne viis.
2. meetod: pärandvalikute lubamine OpenSSH-s
Heitke pilk sellele, mida veateade pärast sõnu Nende pakkumine loeb: et näha, millist algoritmi kaugserver eelistab. Kuigi enamik süsteeme peaks kasutama openssh7, mis on juba keelanud vanema vananenud diffie-hellman-group1-sha1 tehnoloogia, öeldakse teile sha1 kasutamist, kui nad on endiselt opensh6 või muu sarnase külge kinni jäänud.
Jookse ssh -oKexAlgorithms = + diffie-hellman-group1-sha1 testhost@example.org olenemata sellest, mis kaugserveri tegelik võrguhosti või IP-aadress on, lahendage see probleem kliendipoolsel küljel. Kui see probleemi lahendab, otsis ta ühenduse loomiseks vanemat sha1-põhist protokolli. See vanem sha1-põhine lahendus keelati mõjuval põhjusel, kuid saate sellest püsivamalt mööda minna, kasutades nano- või vim-redaktoreid ~ / .ssh / config faili avamiseks ja ridade lisamiseks:
Võõrustaja example.org
KexAlgorithms + diffie-hellman-group1-sha1
Pidage meeles, et soovite veenduda, et plussmärk on olemas, kuna see tähendab, et ssh lisab, mitte ei asenda turvalisemaid vaikesätteid. Kui server pakette värskendab, kasutate enamikul juhtudel turvalisemaid protokolle.
Kui teile ilmnes tõrge enne seda, kui mainiti sha1 versiooni asemel protokolli ssh-dss, võite selle asemel proovida seda käsku, millele järgneb hosti nimi: ssh -oHostKeyAlgorithms = + ssh-dss , mis kui see töötab, peate uuesti muutma faili ~ / .ssh / config. Pärast rida Host lisage vaheleht ja järgmine:
HostKeyAlgorithms + ssh-dss
Pidage meeles, et nii nagu sha1 süsteem, on ka ssh-dss võti sellega seotud äärmiselt ratsionaalsete turbeprobleemide tõttu aegunud. Selle kasutamine võib teie ühendusse tuua haavatavusi, nii et seda tuleks vaadelda ainult ajutise parandusena, isegi kui see on nii. Veenduge, et serverit värskendataks võimalikult kiiresti.
3 minutit loetud
