Passordløs SSH-oppkobling

Under utvikling! Denne siden er under utvikling og ble sist oppdatert 28.06.2011 av St01368 . Artikkelen kan eksistere på engelsk. Se etter en språklenke i menyen til venstre.

Det finnes mange grunner til å gjøre passordløse oppkoblinger mot ssh-tjenere. Skripting, klyngeregning og sikkerhet er eksempler. Det antas i denne sammenheng at ssh-tjenesten kjører under Linux, men dette er også mulig mot andre OS. Klientsiden kan være både Linux og Windows og vi vil her gi noen eksempler på slik bruk.

På UiB finnes det to metoder for passordløs oppkobling mot ssh-tjenere; Kerberos og SSH-nøkler. Vi vil forklare dem hver for seg.

SSH med Kerberosautentisering

Alle UiBs Linuxklienter er satt opp til å fungere med kerberosautentisering, men dette krever også innstillinger på klientsiden som ikke alltid kan tilfredsstilles. Av denne grunn vil dette kun fungere fra Linux eller fra selvdriftet maskin, det vil også kun fungere når klienten står på UiBs 129.177/16-nett. Man kan også endre oppsettet på serversiden per bruker (i filen $HOME/.ssh/config), men de globale reglene er definert i /etc/ssh/sshd_config og /etc/ssh/ssh_config. Her er et utdrag fra disse

Utdrag fra /etc/ssh/sshd_config

# Kerberos options
KerberosAuthentication yes
#KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Utdrag fra /etc/ssh/ssh_config

# Rekkefolgen er vesentlig
# First FQDNs at UiB
Host 129.177.* *.uib.no
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes
  GSSAPIKeyExchange yes
  GSSAPITrustDNS yes
  SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
  SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
  SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
  SendEnv XMODIFIERS
  ForwardX11Trusted yes

# Then FQDNs not at UiB
Host *.*
  GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
  ForwardX11Trusted yes
# Send locale-related environment variables
  SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
  SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
  SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
  SendEnv XMODIFIERS

# And at last short names (non-FQDNs)
Host *
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes
  GSSAPIKeyExchange yes
  GSSAPITrustDNS yes 
  SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
  SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
  SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
  SendEnv XMODIFIERS
  ForwardX11Trusted yes

Mer info

Man kan lese mer om disse filene i deres manualsider: man ssh_config og man sshd_config. Man overstyrer /etc/ssh_config i $HOME/.ssh/config ved at rekkefølgen er relevant og brukerens fil leses først.

Krav

For at kerberosautentisering skal virke må man:

1. Ha støtte for dette på server og klient skrudd på
2. Ha en gyldig kerberosticket
3. Være på UiBs 129.177/16-nett.

Skru av

For å skru av kerberosautentisering for alle eller enkelte maskiner legg dette i din $HOME/.ssh/config

Host *
#Host maskin1 maskin2
  GSSAPIAuthentication no

SSH med nøkkelautentisering

Nøkkelautentisering virker slik at man har en hemmelig og en offentlig nøkkel i par. Den offentlige delen av nøkkelparet kan man fritt distribuere da denne i seg selv ikke er hemmelig. Den hemmelige delen av nøkkelparet er naturligvis hemmelig.

SSH-tjenesten man kobler seg opp mot må ha tilgang til den offentlige nøkkelen og SSH-klienten må ha tilgang til den hemmelige nøkkelen.

Generering av nøkkelpar

Kryptert med passord eller ikke?

Før man lager et nøkkelpar må man bestemme seg for om det skal være kryptert på disk med passord (passphrase) eller om det skal ligge ukryptert. Vi anbefaler på det sterkeste å kryptere med passord, fortrinnsvis et veldig vanskelig passord med mindre man har eksplisitte behov som krever at nøkkelen lagres ukryptert (f.eks. skriptet bruk).

Kommando

Her er mange varianter og muligheter, men her er et greit utgangspunkt:

ssh-keygen -t dsa -C "kommentar" -f $HOME/.ssh/id_dsa

Du kan velge å ta bort -f og navnet på nøkkelen, da velges standardnavnet. Det er også standardnavnet som brukes om man ikke spesifiserer stien når man bruker ssh. Man kan også legge på en hel masse begrensninger på nøkkelparet, les man ssh-keygen for mer informasjon. Kommandoen vil spørre etter passphrase, her kan man bruke mellomrom for å generere setninger o.l. som "passord". Den lager to filer; id_dsa og id_dsa.pub i $HOME/.ssh/. Filen som slutter på .pub er den offentlige.

Distribusjon av offentlig nøkkel

For å distribuere en nøkkel til en annen maskin gjør man slik:

ssh-copy-id -i $HOME/.ssh/id_dsa.pub bruker@maskin

Man kan også kopiere filen og legge den til manuelt:

cat min_nøkkel.pub >> $HOME/.ssh/authorized_keys

Men den første kommandoen vil sette rettigheter og lage nødvendige mapper slik at alt blir korrekt.

Du kan nå bruke nøkkelen for å koble deg til, men du må fortsatt taste passphrasen hver gang, se lenger ned for hvordan du kan lagre nøkkelen i minnet og dermed taste passphrasen kun én gang (nøkkelagent).

Begrensing av tilgang

Man kan definere i $HOME/.ssh/authorized_keys flere begrensninger på en spesifikk nøkkel. Merk at alle nøklene i filen er på én enkeltlinje, og begrensninger legges til i begynnelsen av denne. Et eksempel er å begrense hvor klienten kan komme fra, enten til enkeltmaskiner, ip-er eller domener, eller flere slike:

from="localhost,*.uib.no" ssh-dss ...

En annet nyttig begrensning er å tvinge kommando med command="kommando". Flere eksempler er no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty. Flere begrensninger separeres med komma.

from="*.eng.cam.ac.uk",no-X11-forwarding,noagent-forwarding ssh-rsa ...

Nøkler som brukes i skripter bør det legges kraftige begrensninger på da de ellers vil gi fulle tilganger dersom den hemmelige nøkkelen kommer på avveie.

Nøkkelagent

Det kan være tungvindt å måtte taste passphrasen sin hver gang, så derfor har man ssh-agent. De fleste linuxdistribusjoner i dag starter ssh-agenten automatisk når man logger på grafisk, men om du vil starte den selv gjør du det slik:

eval $(ssh-agent -s)
<pre>
Da dekrypteres nøkkelen din og lagres i minnet for bruk under gjeldende sesjon. Du kan også starte et nytt skall hvor du bruker en agent:
<pre>
ssh-agent /bin/bash

Når du så har agenten må du legge til nøkler i den: Legge til standardnøkkelfiler; ~/.ssh/id_rsa, ~/.ssh/id_dsa og ~/.ssh/identity:

ssh-add

Legge til spesifikk nøkkel:

ssh-add ~/.ssh/nøkkelfil

Når du nå prøver å koble til med ssh mot en klient du har distribuert den offentlige nøkkelen til vil du logges på uten spørsmål om passphrasen.

Mange grafiske miljø har ssh-agenter innebygget i systemet og spør grafisk etter passord første gang du prøver å koble til med en ny nøkkel og slik legge den til ssh-agenten.

Igjen anbefaler vi å lese man ssh-agent og man ssh-add.

Ofte stilte spørsmål

Hvorfor virker ikke ssh-nøkler mot linuxklientene på UiB?

Linuxklientene på UiB er satt opp med et ekstra lag sikkerhet (Kerberos). Dette sikkerhetslaget gjør at ikke engang root (administrator) på en klient kan lese ditt hjemmeområde på nettverket! Uten denne sikkerheten vil en kompromittert klient eksponere alle brukeres hjemmekataloger, så dette er nødvendig! Men siden SSH med nøkkelautentisering baserer seg på at SSH-tjenesten (som root) kan lese din ~/.ssh/authorized_keys så vil ikke dette fungere. Det finnes noen unntak fra denne regelen og det er servere og (regne-)klienter som IT-avdelingen har innelåst på sine serverrom, da mangel på fysisk tilgang vanskeliggjør kompromittering vesentlig. Eksempel på dette er nx.uib.no og login.uib.no.