known_hosts -tiedoston avulla asiakas voi todentaa palvelimen tarkistaakseen, että sitä ei ole yhdistetty toisena henkilönä. authorized_keys -tiedoston avulla palvelin todentaa käyttäjän.

Palvelimen todennus

Yksi ensimmäisistä asioista, joita tapahtuu, kun SSH-yhteys muodostetaan, on, että palvelin lähettää julkisen avaimen asiakkaalle ja todistaa (kiitos julkisen avaimen salauksesta ) asiakkaalle, että se tietää liittyvän yksityisen avaimen. Tämä todentaa palvelimen: jos tämä protokollan osa onnistuu, asiakas tietää, että palvelin on se, jonka se väittää olevansa.

Asiakas voi tarkistaa, että palvelin on tunnettu eikä joku huijauspalvelin yrittää päästä eroon oikealta. SSH tarjoaa vain yksinkertaisen mekanismin palvelimen laillisuuden tarkistamiseksi: se muistaa palvelimet, joihin olet jo yhteydessä, asiakaskoneen ~/.ssh/known_hosts -tiedostossa (siellä on myös järjestelmä -laa tiedosto /etc/ssh/known_hosts). Kun muodostat yhteyden palvelimeen ensimmäisen kerran, sinun on tarkistettava jollakin muulla tavalla, että palvelimen esittämä julkinen avain on todella palvelimen julkinen avain halusit muodostaa yhteyden. Jos sinulla on palvelimen julkinen avain, johon olet muodostamassa yhteyden, voit lisätä sen manuaalisesti asiakkaan ~/.ssh/known_hosts -kohtaan.

Muuten, known_hosts voi sisältää minkä tahansa tyyppisen julkisen avaimen, jota SSH-toteutus tukee, ei vain DSA: ta (myös RSA: ta ja ECDSA: ta).

palvelin on tehtävä ennen luottamuksellisten tietojen lähettämistä sille. Erityisesti, jos käyttäjän todennukseen liittyy salasana, salasanaa ei saa lähettää todentamattomalle palvelimelle.

Käyttäjätodennus

Palvelin antaa etäkäyttäjän kirjautua sisään vain, jos kyseinen käyttäjä voivat todistaa, että heillä on oikeus käyttää kyseistä tiliä. Palvelimen kokoonpanosta ja käyttäjän valinnasta riippuen käyttäjä voi esittää yhden useista tunnistetyypeistä (alla oleva luettelo ei ole tyhjentävä).

• Käyttäjä voi esittää salasanan tili, johon hän yrittää kirjautua; palvelin tarkistaa sitten, että salasana on oikea.
• Käyttäjä voi esittää julkisen avaimen ja todistaa, että hänellä on julkiseen avaimeen liittyvä yksityinen avain. Tämä on täsmälleen sama menetelmä, jota käytetään palvelimen todentamiseen, mutta nyt käyttäjä yrittää todistaa henkilöllisyytensä ja palvelin vahvistaa sen. Sisäänkirjautumisyritys hyväksytään, jos käyttäjä todistaa tietävänsä yksityisen avaimen ja julkisen avaimen olevan tilin valtuutusluettelossa (~/.ssh/authorized_keys palvelimella).
• Erään toisen tyyppisen menetelmän mukaan osa käyttäjän todentamistyöstä delegoidaan asiakaskoneelle.Tämä tapahtuu valvotuissa ympäristöissä, kuten yrityksissä, kun monilla koneilla on samat tilit. Palvelin todentaa asiakaskoneen samalla mekanismilla, joka on käytti päinvastoin, luottaa sitten asiakkaan todentamaan käyttäjän.

Kommentit

• kiitos, että tämä on erittäin hyödyllistä. on oikein sanoa, että tiedossa olevat isäntätiedostot säilytetään asiakkaalla, kun taas valtuutettu_avaintiedosto säilytetään palvelimella
• @Ankit Kyllä, näin on.
• Minulla on molemmat tiedostot palvelimella ja ssh sille sen testaamiseksi. Mutta kahdella tiedostolla on erilainen sisältö. Joten avaimet ovat erilaiset näissä tiedostoissa?
• @Timo Avaimet ovat täysin unr riemuissaan. Yksi on koneen avain, toinen käyttäjän avain.
• @Gilles Joten kun palvelimen merkintä ’ lisätään julkinen avain known_hosts -tiedostoon asiakkaan ’ -tietokoneessa, kahden myöhemmän ssh-istunnon välillä ei ole ’ t vaatia palvelinta todistamaan, että sillä on oikea yksityinen avain?

Molempia tiedostoja käyttää molemmat SSH , mutta täysin eri tarkoituksiin, mikä voi helposti selittää hämmennyksesi.

Valtuutetut avaimet

SSH käyttää oletusarvoisesti käyttäjätilejä ja salasanoja, joita isäntä-käyttöjärjestelmä hallitsee. (No, tosiasiallisesti hallinnoi PAM , mutta tämä ero ei todennäköisesti ole tässä liian hyödyllinen.) Tämä tarkoittaa sitä, että kun yrität muodostaa yhteyden SSH: hon käyttäjätunnuksella ”bob” ja salasanan, SSH-palvelinohjelma kysyy käyttöjärjestelmältä ” Sain tämän kaverin nimeltä ”bob”, joka kertoo minulle salasanansa ”wonka”. Voinko päästää hänet sisään? ” Jos vastaus on kyllä, SSH sallii sinun todentamisen ja jatkat hauskaa.

Salasanojen lisäksi SSH antaa sinun käyttää tunnistamiseen sinua myös nimellä ”div” julkisen avaimen salaus . Erityinen salausalgoritmi voi vaihdella, mutta se on yleensä RSA tai DSA tai äskettäin ECDSA . Joka tapauksessa, kun määrität avaimet, käytä ssh-keygen -ohjelmalla luot kaksi tiedostoa. Yksi on yksityinen avain ja toinen julkinen avain. Nimet ovat melko itsensä – selitys. Suunnittelulla julkinen avain voidaan piilottaa kuin voikukan siemenet tuulessa vaarantamatta sinua. Yksityinen avain on aina pidettävä tiukimmalla luottamuksella.

Joten mitä teet, sijoita julkinen näppäile authorized_keys -tiedosto. Kun yrität muodostaa yhteyden SSH: hon käyttäjätunnuksella ”bob” ja yksityinen avain kysyy käyttöjärjestelmältä ” Sain tämän kaverin nimen ”bob”, voinko olla täällä? ” Jos vastaus on kyllä, SSH tarkistaa yksityisen avaimesi ja tarkistaa, onko authorized_keys -tiedoston julkinen avain sen pari. Jos molemmat vastaukset ovat kyllä, sinut sallitaan sisään.

Tunnetut isännät

Aivan kuten authorized_keys -tiedoston avulla käyttäjien todentamiseen. known_hosts -tiedostoa käytetään palvelimien todentamiseen. Aina kun SSH määritetään uudelle palvelimelle, se luo palvelimelle aina julkisen ja yksityisen avaimen, aivan kuten teitkin käyttäjällesi. Joka kerta, kun muodostat yhteyden SSH-palvelimeen, se näyttää sinulle julkisen avaimen ja todistuksen siitä, että sillä on vastaava yksityinen avain. Jos sinulla ei ole julkista avainta, tietokoneesi pyytää sitä ja lisää sen known_hosts -tiedostoon. Jos sinulla on avain ja se sopii, muodostat yhteyden heti. Jos avaimet eivät täsmää, saat suuren ikävän varoituksen. Täällä asiat kiinnostavat. Kolme avaimen ristiriitatilannetta yleensä ovat:

1. avain vaihdettu palvelimella. Tämä voi johtua -käyttöjärjestelmän asentamisesta uudelleen tai joissakin käyttöjärjestelmissä avain luodaan uudelleen SSH: tä päivitettäessä.
2. Yhdistämäsi isäntänimi tai IP-osoite. joskus kuului toiseen palvelimeen. Tämä voi olla osoitteen uudelleenmääritys, DHCP tai jotain vastaavaa.
3. Haitallinen man- keskellä oleva hyökkäys tapahtuu. Tämä on suurin asia, jota avainten tarkistus yrittää suojata sinua.

Molemmissa tapauksissa known_hosts ja authorized_keys, SSH-ohjelma käyttää julkisen avaimen salausta tunnistamaan joko asiakkaan tai palvelimen.

Kommentit

• ” Joka kerta, kun muodostat yhteyden SSH-palvelimeen, se esittelee yksityisen avaimen henkilöllisyytensä todistamiseksi. ” Toivottavasti en! Oletan, että tarkoitit sen julkista avainta . Jos palvelin esitteli minulle asiakkaalle yksityisen avaimensa – se (A) ei toimisi minulle todentamaan sitä ja (B) on osoitus siitä, että palvelin on niin huonosti määritetty, että minun pitäisi lopettaa liiketoiminta sen kanssa välittömästi. Yksityisten avainten tulisi olla vain nimettyjen käyttäjien käytettävissä alkuperäiskoneella. Se ’ on tavallaan asia. 😉
• Tämä vastaus auttoi minua enemmän kuin hyväksytty (:
• Jos siirrän ssh paikalliselle palvelimelle (paikallinen IP) ja sitten myöhemmin samalta tietokoneelta, mutta nyt etänä muodosta yhteys samaan palvelimeen (julkinen IP), laukaiseeko se avaimet, jotka eivät täsmää? Kuinka voit lieventää tätä?

Tietoja julkisista avaimista sisältävistä suojatuista tiedostoista

Tässä on joitain asiayhteyksiä, jotka selittävät, kuinka tiedostot sopivat ”ssh”: een, jotta tunnetut isännät ja valtuutetut avaimet eroavat toisistaan. ; ”ssh”: llä on paljon enemmän ominaisuuksia ja komplikaatioita kuin tässä mainitaan.

Yhdistykset ovat luotetuissa lähteissä

Vaikka on sanottu, että julkisen avaimen arvot ”voidaan turvallisesti levittää kuin siemenet tuulessa”, pidä mielessä, että se on puutarhuri, ei siemenpensas, joka päättää, mitkä siemenet istutetaan puutarhaan. Vaikka julkinen avain ei ole salaisuus, tarvitaan voimakasta suojaa avaimen luotettavan yhdistämisen säilyttämiseksi sen kanssa, jonka avain todistaa. Tähän yhdistykseen on uskottu sisällyttää ”tunnettu_isännät”, ”valtuutetut_näppäimet” ja ”varmenteen myöntäjä” -luettelot.

”ssh” käyttää luotettavia lähteitä

Julkisen avaimen ollessa käytettävissä ”ssh”: n kannalta oleellinen, avain on rekisteröitävä etukäteen ja tallennettava asianmukaiseen suojattuun tiedostoon. (Tällä yleisellä totuudella on yksi tärkeä poikkeus, josta keskustellaan myöhemmin.) Palvelimella ja asiakkaalla on kullakin oma, turvallisesti tallennettu luettelo julkisista avaimista; sisäänkirjautuminen onnistuu vain, jos molemmat osapuolet on rekisteröity toistensa kanssa.

• ”known_hosts” asuu clien nt
• ”Valtuutetut avaimet” sijaitsee palvelimella

Asiakkaan suojattu tiedosto on nimeltään ”tunnetut_palvelimet” ja palvelimen suojattu tiedosto on ”valtuutetut avaimet”. . Nämä tiedostot ovat samankaltaisia, koska jokaisella on tekstiä, jossa on yksi julkinen avain riviä kohden, mutta niillä on pieniä eroja muodossa ja käytössä.

Avaintapoja käytetään todentamiseen

Julkinen – yksityisiä avainpareja käytetään ”epäsymmetrisen salauksen” suorittamiseen. ”Ssh” -ohjelma voi käyttää todentamiseen epäsymmetristä salausta, jolloin yksikön on vastattava haasteeseen todistaakseen henkilöllisyytensä. Haaste luodaan koodaamalla yhdellä avaimella ja vastataan dekoodaamalla toisella avaimella. (Huomaa, että epäsymmetristä kryptografiaa käytetään vain kirjautumisvaiheessa; sitten ”ssh” (TSL / SSL) vaihtaa toiseen salaustapaan tietovirran käsittelemiseksi.)

Yksi avainpari palvelimelle, toinen asiakkaalle

”ssh”: ssä molemmat osapuolet (asiakas ja palvelin) ovat epäilyttäviä toiselle; tämä on parannus edeltäjään ”ssh”, joka oli ”telnet”. ”Telnet” -asiakkaalla asiakkaan oli annettava salasana, mutta palvelinta ei tarkistettu. Tarkastuksen puute antoi mahdollisuuden ”ihminen keskellä” -hyökkäyksiin, joilla oli katastrofaalisia seurauksia turvallisuudelle. Sen sijaan ”ssh” -prosessissa asiakas ei luovuta tietoja ennen kuin palvelin vastaa ensin haasteeseen.

”ssh” -todennuksen vaiheet

Ennen kirjautumistietojen jakamista, ”ssh” -asiakas ensin poistaa mahdollisuuden välimies-hyökkäykseen haastamalla palvelimen todistamaan ”Oletko todella kuka luulen olevasi?” Tämän haasteen suorittamiseksi asiakkaan on tiedettävä kohdepalvelimeen liittyvä julkinen avain. Asiakkaan on löydettävä palvelimen nimi tiedossa olevista isännöintitiedostoista; siihen liittyvä julkinen avain on samalla rivillä palvelimen nimen jälkeen. Palvelimen nimen ja julkisen avaimen välinen yhteys on pidettävä loukkaamattomana; siksi käyttöoikeudet ”known_hosts” -tiedoston on oltava 600 – kukaan muu ei voi kirjoittaa (eikä lukea).

Kun palvelin on todennettu, se saa haasteen asiakkaalle. Todentamiseen liittyy yksi julkisista avaimet löytyivät valtuutetuista avaimista. (Kun mikään näistä avaimista ei toimi, ”sshd” -prosessi palaa salasanatyyppiseen todennukseen.)

Tiedostomuodot

Joten varten ” ssh ”, kuten missä tahansa sisäänkirjautumisprosessissa, on luettelo” ystävistä ”, ja vain luettelossa olevat henkilöt voivat yrittää läpäistä haasteen. Asiakkaalle” tunnettu_isännät ”-tiedosto on luettelo ystävistä, jotka voivat toimia palvelimet (isännät); nämä on lueteltu nimen mukaan. Palvelimelle vastaava kaveriluettelo on ”valtuutetut_näppäimet” -tiedosto, mutta tiedostossa ei ole nimiä, koska c-avaimet itse toimivat tunnisteina. (Palvelimella ei ole väliä, mistä sisäänkirjautuminen tulee, vaan vain mihin se menee. Asiakas yrittää käyttää tiettyä tiliä, tilin nimi määritettiin parametrina, kun ”ssh” kutsuttiin. Muista, että ”Author_keys” -tiedosto on kyseiselle tilille ominainen, koska tiedosto on kyseisen tilin kotihakemistossa.)

Vaikka konfigurointimerkinnässä voidaan ilmaista monia ominaisuuksia, perus, yleisin käyttö on seuraavat parametrit. Huomaa, että parametrit erotetaan välilyönneillä.

”Tunnetut_isännät”:

{server-id} ssh-rsa {public-key-string} {comment} 

”Valtuutetut avaimet”:

ssh-rsa {public-key-string} {comment} 

Huomaa, että tunnus ssh-rsa osoittaa, että koodaukseen käytetty algoritmi on ”rsa”. Muut kelvolliset algoritmit sisältää ”dsa” ja ”ecdsa”. Siksi eri tunnus voi korvata tässä esitetyn ssh-rsa -kohdan.

Anna ”ssh” määrittää automaattisesti ”known_hosts” merkintä

Molemmissa tapauksissa, jos th Julkista avainta ei löydy suojatusta tiedostosta, assymetristä salausta ei tapahdu. Kuten aiemmin mainittiin, tästä säännöstä on yksi poikkeus.Käyttäjä saa tietoisesti päättää vaarantaa man-in-the-middle-hyökkäyksen kirjautumalla palvelimeen, jota ei ole lueteltu käyttäjän ”known_hosts” -tiedostossa. ”Ssh” -ohjelma varoittaa käyttäjää, mutta Jos käyttäjä haluaa mennä eteenpäin, ”ssh” -asiakas sallii sen ”vain kerran”. Varmistaakseen, että se tapahtuu vain kerran, ”ssh” -prosessi määrittää ”known_hosts” -tiedoston automaattisesti tarvittavilla tiedoilla pyytämällä palvelimelta julkinen avain ja kirjoittamalla se tiedostoon ”known_hosts”. Tämä poikkeus horjuttaa tietoturvaa täysin sallimalla vastustajan liittää palvelimen nimen julkiseen avaimeen. Tämä turvallisuusriski on sallittu, koska se tekee asioista niin paljon helpompaa niin monille ihmisille. Tietenkin oikea ja turvallinen tapa olisi ollut, että käyttäjä lisäsi manuaalisesti rivin palvelimen nimellä ja julkisella avaimella ”known_hosts” -tiedostoon ennen kuin yritti koskaan kirjautua palvelimelle. (Mutta matalan riskin tilanteissa lisätyö voi olla turhaa.)

Yksi-moniin-suhteet

Asiakkaan ”tiedossa olevat isännät” -tiedostossa olevalla merkinnällä on palvelimen nimi ja palvelinkoneeseen sovellettava julkinen avain. Palvelimella on yksi yksityinen avain, jota käytetään vastaamaan kaikkiin haasteisiin, ja asiakkaan ”tiedossa olevat isännät” -merkinnällä on oltava vastaava julkinen avain. Siksi kaikilla asiakkailla, jotka koskaan käyttävät tiettyä palvelinta, on sama julkinen avain merkintä tiedostossa ”known_hosts”. 1: N-suhde on, että palvelimen julkinen avain voi esiintyä monissa asiakkaan ”known_hosts” -tiedostoissa.

”Author_keys” -tiedostossa oleva merkintä tunnistaa että ystävällinen asiakas saa käyttää tiliä. Ystävä voi käyttää samaa julkisen ja yksityisen avaimen paria useiden eri palvelimien käyttämiseen. Tämä sallii yhden avainparin todentamisen kaikille palvelimille, joihin koskaan on yhteyttä. Niillä on sama julkisen avaimen merkintä ”valtuutetut_näppäimet” -tiedostoissa. 1: N-suhde on, että yhden asiakkaan julkinen avain voi esiintyä ”valtuutetut avaimet” -tiedostoissa useille tileille useilla palvelimilla.

Joskus usealta asiakaskoneelta työskentelevät käyttäjät kopioivat saman avainparin; tyypillisesti tämä tapahtuu, kun käyttäjä työskentelee pöydällä ja kannettavalla. Koska asiakaskoneet todentavat identtisillä avaimilla, ne vastaavat samaa merkintää palvelimen ”valtuutetuissa avaimissa”.

Yksityisten avainten sijainti

Palvelinpuolella järjestelmäprosessi , tai daemon, käsittelee kaikki saapuvat ”ssh” kirjautumispyynnöt. Daemon on nimeltään ”sshd”. Yksityisen avaimen sijainti riippuu SSL-asennuksesta, esimerkiksi Apple asettaa sen kohtaan /System/Library/OpenSSL, mutta kun olet asentanut oman OpenSSL-version, sijainti on /opt/local/etc/openssl.

Asiakaspuolella kutsutaan ”ssh” (tai ”scp”). ), kun tarvitset sitä. Komentorivisi sisältää useita parametreja, joista yksi voi valinnaisesti määrittää käytetyn yksityisen avaimen. Oletusarvoisesti asiakaspuolen avainparia kutsutaan usein $HOME/.ssh/id_rsa ja $HOME/.ssh/id_rsa.pub.

Yhteenveto

Tärkeintä on, että sekä tunnetut_palvelimet että valtuutetut avaimet sisältävät julkisia avaimia, mutta …

• known_hosts – asiakas tarkistaa, onko isäntä aito
• valtuutetut_näppäimet – isäntä tarkistaa, onko asiakkaan sisäänkirjautuminen sallittu

Kommentit

• SSH-asiakkaat eivät yleensä ’ ei ole avaimia. Kohdassa authorized_keys luetellut julkiset avaimet tunnistavat käyttäjät, eivät koneita.
• Kiitos. Tämä on erittäin selkeä ja helposti ymmärrettävä selitys tiedostojen ja avainten välisistä suhteista.

Ei lainkaan totta.

Tiedossa_hostitiedosto on isännän sormenjälki. Se ei ole etäisännän julkinen tai yksityinen avain.

Se luodaan heidän avaimestaan – mutta se ei ole painokkaasti EI avain itse.

Jos SFTP-osoite lähetetään osoitteeseen, saattaa ratkaista useita (vaihtelevia) isäntiä (kuormituksen tasapaino jne.), sinun on lisättävä sormenjäljet kaikista mahdollisista päätepisteistä, tai se toimii aluksi ja epäonnistuu, kun se reititetään toiseen (tai seuraavaan) isäntään.

Kommentit

• erm tarkastele tiedossa olevia isäntätiedostojasi ja vertaa sitä isännän sormenjälkeen, kun muodostat yhteyden …. Tämän pitäisi puhdistaa se hieman. Lisäksi esimerkkisi olisi täsmälleen sama riippumatta siitä, ovatko sormenjäljet vai julkiset avaimet tiedossa_hosts-tiedostossa.