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.