Projektikansiossa on yhä vanha ylläpitäjän avain. Se toimii useilla palvelimilla, mutta kukaan ei tiedä tarkasti, kenellä on siitä kopio. Siirtyminen salasanoista SSH-avaimiin muutti kirjautumista selventämättä vastuuta.
Toimiva SSH-hallinta yhdistää henkilökohtaiset identiteetit, sopivat kohdeoikeudet ja luotettavan pääsyn poistamisen. Ympäristöstä riippuen ylläpidetyt julkiset avaimet ja huolellinen luettelo voivat riittää. Suuremmat tai usein muuttuvat ympäristöt voivat hyötyä lyhytikäisistä SSH-varmenteista. Molemmat tavat tarvitsevat ylläpidettävän toimintamallin.
Neljä asiaa, joita ei pidä sekoittaa
Käyttäjän yksityinen avain mahdollistaa oman identiteetin todistamisen. Se säilytetään suojattuna eikä sitä jaeta chatissa, sähköpostissa tai suojaamattomassa projektikansiossa. Sitä vastaava julkinen avain voidaan tallentaa tarkoitettuihin kohdejärjestelmiin sallimaan pääsy. Sen sormenjälki auttaa yksilöimään avaimen luettelossa.
Palvelimen avain puolestaan tunnistaa palvelimen, johon otetaan yhteyttä. Palvelimen tarkistus estää yhteyden päätymisen huomaamatta väärälle vastapuolelle. SSH-varmenne lisää julkiseen avaimeen allekirjoitetun tiedon esimerkiksi identiteetistä ja voimassaolosta. OpenSSH-varmenteilla on oma muotonsa, eivätkä ne ole tavallisia TLS-/X.509-varmenteita.
Erota henkilökohtaiset kirjautumiset teknisistä tehtävistä
Ylläpitotyö kohdistetaan henkilöihin ja heidän sallittuihin tehtäviinsä. Yhteinen pitkäikäinen root-avain vaikeuttaa tarpeettomasti lähtötilanteita, avainten vaihtoa ja jäljitettävyyttä. Henkilökohtaiset kirjautumiset asianmukaisesti määritetyin ylläpito-oikeuksin antavat paremman pohjan.
Varmuuskopiointi- tai käyttöönottotehtävä tarvitsee oman teknisen identiteetin ja dokumentoidun vastuun. Mahdollisuuksien mukaan pääsy rajataan tiettyyn toimintoon, esimerkiksi pakotetulla komennolla ja sopivilla edelleenlähetyssäännöillä. Työntekijän yksityinen avain ei saa huomaamatta muodostua automaattisen tehtävän pysyväksi edellytykseksi.
Avainluettelosta lyhytikäisiin varmenteisiin
Pienessä järjestelmäjoukossa julkisten avainten hallittu jakelu voi riittää. Luetteloon kirjataan henkilö tai palvelu, sormenjälki, kohdejärjestelmät, laajuus ja suunniteltu tarkistus- tai vaihtopäivä. Ratkaisevaa on oikeuksien luotettava ylläpito kaikissa asianomaisissa kohteissa.
SSH-varmentaja voi vaihtoehtoisesti allekirjoittaa julkisia avaimia rajatuksi ajaksi ja määritetyille identiteeteille. Palvelimet luottavat tarkoitettuun CA:han ja tarkistavat muut sääntönsä. Yksityistä kirjautumisavainta ei tarvitse lähettää CA:lle. CA:n avaimet ja myöntämissäännöt suojataan erityisen huolellisesti.
Lyhyt voimassaolo rajoittaa myönnetyn tunnisteen käyttöaikaa. Se ei kuitenkaan päätä jo käynnissä olevaa istuntoa eikä korvaa pääsyn perumista. Henkilön lähtiessä myös uusien varmenteiden myöntäminen on estettävä. Keskitetty salaisuuksien hallinta-alusta on yksi toimintamalli; sen on oikeasti tuettava kyseistä SSH-prosessia.
| Hallintatapa | Sopiva käyttökohde | Ylläpidon vaatimukset |
|---|---|---|
| Julkisten avainten ylläpito | Rajallinen, hyvin luetteloitu kohdejoukko. | Jakelu, vanhojen oikeuksien poistaminen ja sijaisjärjestelyt. |
| SSH-varmenteiden myöntäminen | Rajattu voimassaolo ja määritetyt identiteetit. | CA:n suojaus, myöntämissäännöt, palvelinten luottamus ja peruminen. |
| Tekniset identiteetit | Automaatio, jolla on selkeä tehtävä. | Rajatut kohdeoikeudet, vastuu ja vaihtomenettely. |
| Agentti tai laitteistoavain | Sopivat henkilökohtaiset kirjautumistavat. | Edelleenlähetyksen rajat, versioiden tarkistus ja palautuminen. |
Käytä agenttia ja laitteistoavaimia harkiten
SSH-agentti mahdollistaa kirjautumisen ladatuilla avaimilla kopioimatta yksityistä avaintiedostoa jokaiselle kohdepalvelimelle. Agentin edelleenlähetys antaa kuitenkin etäjärjestelmälle pääsyn sen allekirjoitustoimintoihin. OpenSSH varoittaa nimenomaisesti, että hyökkääjä, jolla on riittävä pääsy kyseiseen järjestelmään, voi kirjautua ladatuilla identiteeteillä lukematta itse avainmateriaalia.
Agentin edelleenlähetys määritetään siksi vain tarvittavalle reitille. Tuetut aika- tai kohderajaukset voivat asettaa lisärajoja. Laitteistopohjaiset turva-avaimet ovat toinen vaihtoehto sopiviin vuorovaikutteisiin kirjautumisiin. Asiakkaan, palvelimen, avaintyypin ja kosketus- tai PIN-vaatimusten on sovittava yhteen; valvomattomalla tehtävällä on eri tarpeet kuin henkilökohtaisella kirjautumisella.
Avainten vaihdon ja perumisen on ulotuttava kohteeseen
Avaimen vaihtaminen kannettavalla ei poista vanhaa pääsyä palvelimelta. Kun julkiset avaimet on tallennettu kohteisiin, oikeudet on päivitettävä kaikissa asianomaisissa järjestelmissä. Varmenteille voidaan käyttää lisäksi esimerkiksi OpenSSH Key Revocation List -sulkulistoja. Sulku tehoaa vasta, kun tarkoitetut palvelimet noudattavat sitä oikein.
Menettely kattaa myös kadonneen laitteen, vaarantuneen avaimen ja hallintapalvelun häiriön. Riippumaton hätäyhteys suojataan, dokumentoidaan ja testataan hallitusti. Palautuminen ei saa riippua juuri siitä pääsyreitistä, joka on lakannut toimimasta.
Käsittele Linux- ja Proxmox-ympäristöjä erikseen
Sekaympäristöissä selvitetään versiot ja todella tuetut OpenSSH-toiminnot. Ajantasainen käsikirja ei takaa samoja valintoja jokaiseen olemassa olevaan Linux-asennukseen. Uudet säännöt otetaan käyttöön nimetyllä testiyhteydellä ja varmennetulla paluureitillä.
Proxmox VE käyttää SSH:ta myös omiin klusteritoimintoihinsa, kuten tiettyihin konsoli-, siirto- ja replikointiyhteyksiin. Nämä tekniset luottamussuhteet arvioidaan erillään ylläpitäjien henkilökohtaisesta pääsystä. Avaintiedostojen yleinen siivoaminen tai ylikirjoittaminen voi häiritä toimintaa. Muutokset tarkistetaan siksi asennetun version dokumentaatiosta.
Mitä hallittava aloitus sisältää
DAXS kartoittaa nykyiset SSH-yhteydet, määrittää vastuut ja suunnittelee sopivan hallinnan. Pilotissa testataan kirjautuminen, oikeudet, pääsyn peruminen, lokitus ja palautuminen. Pelkkä onnistunut kirjautuminen ei riitä hyväksymisperusteeksi. Pelkät kirjautumislokit eivät myöskään automaattisesti tallenna kaikkia suoritettuja komentoja täydellisesti.
Infrastruktuuripalvelut ja artikkeli Proxmoxista yrityskäytössä taustoittavat ylläpitoa. Yhteiskäyttöisten portaalien näkökulmaa täydentää artikkeli holveista, rooleista ja työntekijän lähdöstä . Voit pyytää ylläpitoyhteyksien kartoitusta.
Usein kysytyt kysymykset
Saanko jakaa julkisen avaimen?
Julkinen osa on tarkoitettu asianmukaiseen jakeluun. Sen kytkentä oikeaan henkilöön ja kohteeseen on silti tarkistettava. Yksityinen osa suojataan eikä sitä kierrätetä yhteisenä pääsytiedostona.
Riittääkö lyhytikäinen varmenne pääsyn välittömään perumiseen?
Ei. Myöntäminen, jäljellä oleva voimassaolo, sulkutarkistukset ja käynnissä olevat istunnot on arvioitava yhdessä. Lyhyt voimassaolo ei korvaa tätä menettelyä.
Tarvitaanko aina keskitetty varmentaja?
Ei. Sopiva ratkaisu määräytyy laajuuden, muutostiheyden, automaation ja ylläpitokyvyn mukaan. Huolellisesti ylläpidetty avainhallinta voi soveltua rajalliseen ympäristöön.
Lähteet: OpenSSH: kirjautuminen ja valtuutetut avaimet (ulkoinen linkki) · OpenSSH: varmenteet ja sulkulistat (ulkoinen linkki) · OpenSSH: palvelimen luottamus- ja sulkusäännöt (ulkoinen linkki) · OpenSSH: agentin edelleenlähetys (ulkoinen linkki) · OpenSSH: agentin avaimet ja rajoitukset (ulkoinen linkki) · Proxmox VE: ylläpito-opas, SSH klusterissa (ulkoinen linkki)
Käsitteellinen opastus; konkreettiset toiminnot riippuvat asennetuista versioista ja suunnitellusta hallinnasta.
