Retningslinjer for sikker bruk av SSH ved Universitetet i Oslo
1. Generelle prinsipper
- Passord er sensitiv informasjon og skal aldri sendes ukryptert over nett.
- Personlig passord skal aldri lagres i klartekst i script eller konfigurasjonsfiler.
- SSH skal prim?rt brukes for terminaltilgang. Grafisk tilgang skal normalt skje via UiO Programkiosk, UiO Drifts VDI eller annen godkjent l?sning.
- Bruk sunn fornuft; kontakt n?rmeste leder eller IT-sikkerhet ved usikkerhet rundt tillatt praksis.
2. Hostn?kler og verifikasjon av serveridentitet
SSH bruker hostn?kler for ? verifisere identiteten til servere. F?rste gang du kobler til en ny maskin, vil du f? en advarsel om at hostn?kkelen er ukjent.
- IT-avdelingen samler og distribuerer hostn?kler internt. For maskiner administrert av UiO skal du derfor normalt aldri motta advarsel om ukjent n?kkel.
- Dersom du likevel f?r en advarsel om ukjent eller endret hostn?kkel ved oppkobling mot en intern maskin, sjekk n?kkel via andre kanaler eller varsle som en sikkerhetshendelse.
- Ved oppkobling til eksterne systemer, verifiser alltid n?kkelfingeravtrykket med kjent, p?litelig informasjon f?r du godtar tilkoblingen.
3. Autentisering med passord eller n?kler
Passord er sensitiv informasjon og skal aldri sendes ukryptert over nett. F?lgende krav gjelder:
- Private (som i privatekey) SSH-n?kler skal alltid beskyttes med sterke passord.
- Bruk separate n?kler for privat og jobbrelatert bruk (se veilledning for hvordan sette dette opp i .ssh/config)
- Begrens n?klenes gyldighetsomr?de med `from=""`-opsjonen i `authorized_keys` der det er praktisk mulig.
- Der n?kkel brukes til ? kj?re en enkelt kommando, begrens den ved ? bruke `command=...` - slik at bare den kommandoen kan kj?res.
- SSH-n?kler brukt med `ssh-agent` skal ha maksimal levetid p? 24 timer. T?m alltid ssh-agenten ved arbeidsdagens slutt.
- Ikke bruk samme SSH-n?kler for flere brukere (ikke samme n?kler for -drift og vanlig bruker osv.)
- Ikke gjenbruk privat-n?kler p? flere maskiner. Lag nytt n?kkel-par for hver maskin.
- Sikre at passord ikke lagres i SSH klienter eller applikasjoner.
4. Bruk av SSH-agent forwarding
Bruk av SSH-agent forwarding (`ssh -A`) inneb?rer betydelig sikkerhetsrisiko og skal begrenses:
- SSH-agent forwarding skal kun brukes til maskiner der du stoler p? root-brukeren.
- Unng? forwarding av SSH-agent gjennom flere mellomledd (hopp-servere). Bruk heller direkte tilkoblinger eller alternative l?sninger dersom mulig.
- Bruk jumphost ( -J opsjon) der du kan.
5. X11-forwarding (grafiske applikasjoner)
X11-forwarding gir mulighet til ? kj?re grafiske applikasjoner gjennom SSH, men inneb?rer sikkerhetsrisiko:
- X11-forwarding skal som hovedregel v?re deaktivert. Bruk kun ved behov.
- Bruk `ssh -X` (standard X-forwarding) dersom grafisk tilgang er n?dvendig. Denne opsjonen gir noe beskyttelse, men v?r fortsatt forsiktig.
- Unng? bruk av `ssh -Y` (trusted X-forwarding). Dette skal kun benyttes der det er eksplisitt behov, og da med h?y aktsomhet p? grunn av ?kt risiko.
- X11-forwarding som krever root-tilgang skal kun brukes som siste utvei, eksempelvis ved installasjon eller drift n?r ingen annen l?sning er mulig.
6. SSH-tunneler og TCP-forwarding
SSH-forwarding inneb?rer risiko for utilsiktet eksponering av interne tjenester:
- SSH-forwarding (TCP-forwarding) for administrasjon og drift skal normalt ikke benyttes. Drifts- og administrasjonsoppgaver som utf?res med h?ye privilegier skal prim?rt utf?res via terminaltilgang gjennom godkjente jumphosts eller UiO sin DriftVDI-l?sning.
- Bruk av SSH-forwarding er tillatt som midlertidig reservel?sning dersom DriftVDI ikke fungerer.
- Unng? permanente eller langvarige tunneler. Kun enkeltporter og spesifikke m?lmaskiner skal eksponeres, og kun s? lenge behovet varer.
- Automatisk oppsett av SSH-baserte VPN eller tunnell?sninger som `sshuttle`, `autossh` eller lignende skal ikke benyttes uten eksplisitt tillatelse og gjennomf?rt risikovurdering (ROS).
- Sensitive data (r?de data) skal aldri hentes eller eksponeres via tunneler til ikke-administrerte eller private maskiner.
- SSH port forwarding / SOCKS proxy kan benyttes for ? n? test- eller utviklings-instanser, API-er og andre tjenester p? innsiden s? lenge den initielle SSH forbindelsen er sikret med multifaktor autentisering, det sikres at de ikke eksponeres for andre brukere og de andre punktene i 6. f?lges.
- Der du m? logge inn via jump-host eller flere hopp - benytt '-J' opsjon der du kan, ikke logg inn p? maskin A, for s? ? logge inn p? maskin B. Dette for ? redusere hvor passord eksponeres.
Bruk av SSH-forwarding til drift og utvikling skal alltid dokumenteres og godkjennes av n?rmeste leder.
7. Bruk av SSH som systembruker eller ved automasjon
Der SSH n?kler brukes for automatisering, ved systembrukere eller for ? tillate innlogging innenfor ett begrenset omr?de:
- N?kler skal alltid ha restriksjoner som sikrer at de bare kan brukes i det gitte milj?et.
- N?kler skal v?re unike for den integrasjonen.
- Brukernavn/passord skal aldri brukes ved automasjon uten egen godkjenning.
8. Gode sikkerhetsrutiner
- Kontroller jevnlig innhold i `authorized_keys`.
- Oppbevar aldri private n?kler eller passord ukryptert eller i delte mapper (for eksempel NFS).
- Unng? bruk av SSH fra offentlige eller uadministrerte maskiner.
- Varsle UiO-CERT ved mistanke om kompromitterte passord eller SSH-n?kler.
- Ved bruk av mosh og/eller tmux/screen ol. - s?rg for at sesjoner ikke blir langvarige og un?dig eksponerering av interne maskiner.
9. Eksempler p? hva vi ?nsker ? unng?
- Permanente eller automatiserte SSH-tunneler uten eksplisitt godkjenning.
- Ukontrollert forwarding som eksponerer interne ressurser eller data. F.eks. om porten forwardes til en host der andre har tilgang, eller til din egen maskin der andre faner i browseren kan ha tilgang.
- Bruk av SSH uten passordbeskyttede n?kler.
- Bruk av SSH eller VPN som gj?r at omg?r sperrer, 2FA eller andre sikkerhetsmekanismer.
10. Anbefalinger ved SSH-bruk
- Bruk alltid siste versjon av SSH-klienten og prim?rt den som er innebygget i os'et, om alternative klienter benyttes - s?rg for at de er oppdatert og fra en troverdig kilde.
- V?r obs p? forslag til lagring av passord. S?rg for at ditt UiO passord ikke lagres i klienter eller profiler.
- Om tunnelering benyttes for ? n? indre web-grensesnitt, benytt egen nettleser for dette - eller andre mekanismer som skiller indre og ytre bruk fra hverandre.
- Vurder bruk av `ControlMaster` og `ControlPath` i SSH-config for sikrere og enklere sesjonsh?ndtering n?r flere tilkoblinger brukes samtidig.