OpenSSH
Fra Wikipedia, den frie encyklopedi.
OpenSSH er en fri implementasjon av SSH-protokollen (Secure Shell). Den overtar plassen til eldre verktøy som telnet, rsh, rlogin, rcp og ftp – ved å erstatte dem med nye verktøy som benytter kryptografi og som i tillegg er mer avanserte. OpenSSH har i tillegg også svært mange andre fiffige funksjoner, som vi kommer tilbake til — deriblant X11-forwarding, tunnelering, osv.
I all enkelhet brukes ssh-kommandoen til å logge på eksterne maskiner:
$ ssh brukernavn@domene.com
| Innholdsfortegnelse |
Inkluderte programmer
Historie
OpenSSH er utviklet av OpenBSD-teamet som et alternativ til SSH — som nå er proprietær programvare. Utviklerne påstår at OpenSSH er sikrere enn originalen, på grunn av OpenBSD-teamets fokus på ren og gransket kode. Selv om kildekoden til den originalen SSH-distribusjonen er tilgjengelig, har den ikke en fri lisens, og det er mange begrensninger på bruk og videredistribusjon. Derfor er OpenSSH et bedre valg for de fleste utviklere.
Installasjon
For å installere OpenSSH bør du bruke pakkestyreren til operativsystemet ditt. Du kan også kompilere manuelt fra kildekode. Les mer om dette i artikkelen om å installere programmer.
Klienter
ssh-klientens konfigurasjonsfil
Også ssh-klienten har en konfigurasjonsfil, nemlig ~/.ssh/config
Svært mange tenker ikke over at også ssh-klienten har en konfigurasjonsfil der informasjon om tjenere du bruker svært ofte kan og bør lagres.
ssh henter innstillinger i følgende rekkefølge:
- Fra kommandolinjen, f.eks
ssh -l brukernavn .... - Fra brukers konfigurasjonsfil – ~/.ssh/config.
- Fra global konfigurasjonsfil – /etc/ssh_config.
I steden for å stadig skrive for eksempel ssh bruker@tjener.com, så kan du lagre den nødvendige informasjonen i konfigurasjonsfila og heller skrive ssh tjener.
Enkelt eksempel:
$ cat ~/.ssh/config Host tjener Hostname tjener.com #Port 22 er sperret, men en annen port er åpen: Port 8080 User alex $ ssh tjener
Flere innstillinger: (De avanserte innstillinge forklares senere i artikkelen.)
$ cat ~/.ssh/config Host tjener Hostname tjener.com User alex ForwardX11 yes ForwardAgent yes #Gjør SMTP og IMAP-protokoller sikre: LocalForward 10025 127.0.0.1:25 LocalForward 10143 127.0.0.1:143 $ ssh tjener
En annen nyttig mulighet er å ha forskjellige private nøkler på forskjellige tjenere – for eksempel når du jobber i et prosjekt der flere har samme nøkkel:
$ cat ~/.ssh/config Host megara Hostname 1.2.3.4 User foobar IdentityFile ~/.ssh/id_dsa2 $ ssh megara
Klienter for Windows
- PuTTY er en fri SSH-klient for Windows.
- WinSCP (http://winscp.sourceforge.net/eng/) er en fri SCP-klient for Windows.
SSH og brannmurer
SSH er en protokoll som ikke er noe vanskelig å ha med å gjøre, sett fra en brukers perspektiv. For nettverksadministratorer kan den derimot være litt mer til bry, med tanke på hvor mye avansert man kan gjøre med SSH (se delen om portforwarding). Hvis du derimot er din egen nettverksadministrator og vil kunne SSH-e forbi f.eks. en bredbåndsrouter trenger du ikke gjøre annet enn å forwarde porten sshd lytter på – som er 22 som standard. Trass i hvor avansert OpenSSH er, bruker den kun én port.
X11-forwarding
Hvis du har en X-server kjørende på maskina du bruker, kan du, ved hjelp av SSH, kjøre grafiske programmer på andre maskiner og vise dem på din maskin.
Det er fullt mulig å gjøre tilsvarende uten SSH, men SSH gjør det både sikrere og enklere da den blant annet setter DISPLAY-variablen så den blir riktig.
Gitt at maskina du kobler til er konfigurert riktig, skriver du ssh -X brukernavn@maskin for å koble på. Du kan da kjøre grafiske programmer på den maskina og vise dem på din maskin.
Et artig triks er å kjøre Xnest – en selvstendig X-server i et eget vindu, og henvise X11-forwardinga dit – se bildet.
Eksempel:
$ Xnest :1 #Starte XNest-serveren på et annet display. $ DISPLAY=:1 ssh -X brukernavn@maskin #Bruke det display-et. $ startkde #Eksempel.
Hvis eksempelet over ikke virker, kan du prøve å kjøre Xnest på følgende måte i stedet:
$ Xnest :1 -auth /dev/null -nolisten tcp #Ninjatriks mot auth-errors
 | Bruk kun X11-forwarding mot maskiner du stoler på! Hvis ikke kan du gjøre deg sårbar for X11-baserte angrep, som «avlytting» av tastetrykk, osv. |
Serverkonfigurasjon
Serveren må tillate X11-forwarding for at det skal fungere.
Rediger /etc/ssh/sshd_config og se til at følgende er tilstede:
X11Forwarding yes
Krypterte tunneler og Port forwarding
OpenSSH er redningen i nøden når du skal bruke usikre protokoller i nettverk du ikke stoler på, men også når din lokale BOFH har sperret porter du gjerne vil bruke.
Fra man ssh:
-L port:host:hostport
Specifies that the given port on the local (client) host is to
be forwarded to the given host and port on the remote side.
-R port:host:hostport
Specifies that the given port on the remote (server) host is to
be forwarded to the given host and port on the local side.
Et par eksempler sier mer enn tusen ord :-)
Jeg har for vane å bruke 10000 + originalport for porter jeg forwarder – for eksempel 10025 for SMTP. Denne praksisen blir brukt i eksemplene. --Alex Brasetvik
Eksempel 1. Sikker IMAP
IMAP er en fin og flott protokoll, men den er ukryptert. En del e-postlesere har ingen eller dårlig støtte for IMAPs – og ikke alle har satt opp IMAPs.
ssh -L 10143:127.0.0.1:143 bruker@domene.tld
Tilkoblinger gjort til port 10143 på maskinen du kjører ssh fra, vil nå sendes til 127.0.0.1:143 sett fra domene.tld. Altså vil tilkoblinger til din maskin på port 10143 i praksis gå til domene.tld:143.
Eksempel 2. Sikker SMTP
Ikke bare er det greit å vite at folk med fritidsproblemer, som ønsker å lese e-posten din, får en vanskeligere oppgave – en SSH-tunnel er svært praktisk når det er snakk om SMTP. Når man er på tur med bærbar og skal sende mail, går det ikke å bruke SMTP-en til din lokale ISP hvis du er på andre siden av landet. Det går ofte an å bruke noe alá /usr/sbin/sendmail, men en del ISP-er blokkerer dette – og mange e-posttjenere nekter å motta e-post fra maskiner uten gyldig PTR-oppslag. Dvs. at selv om du kanskje får sendt mail, tilfredstiller ikke maskinen din nødvendigvis de krav mange SMTP-tjenere setter.
ssh -L 10025:127.0.0.1:25 bruker@domene.tld
Tilkoblinger gjort til port 10025 på maskinen du kjører ssh fra, vil nå sendes til 127.0.0.1:25 sett fra domene.tld. Altså vil tilkoblinger til din maskin på port 10025 i praksis gå til domene.tld:25.
| Dette er derimot på ingen måte noen garanti mot at uvedkommende ikke leser e-posten! Les mer om The GNU Privacy Guard for informasjon om kryptert e-post. |
Konfigurer e-postleseren din til å sende mail via 127.0.0.1:10025.
Eksempel 3. Nå innsiden fra utsiden
Svært mange nettverk bruker NAT – en del mange forskjellige lag med NAT. Å forwarde porter gjennom flere lag med NAT kan være en omstendelig prosess – ikke er det sikkert din lokale BOFH vet hvordan man gjør det, gidder finne det eller vil.
ssh -R 10022:127.0.0.1:22 bruker@domene.tld
Tilkoblinger gjort til port 10022 på domene.tld, vil nå sendes til 127.0.0.1:22 sett fra maskinen du kjører kommandoen på. Altså vil tilkoblinger til din domene.tld:10022 i praksis gå til 127.0.0.1:22 på maskina du kjører ssh på.
Eksempel 4. Fattigmanns VPN
I mange tilfeller har du tjenester på et lukket nettverk, gjerne på jobben eller andre steder. Disse tjenestene skulle du gjerne hatt tak i med for eksempel emacs sin ange-ftp eller lignende – driftavdelinga har selvsagt ikke satt opp VPN, så da er du overlatt til deg selv. Heldigvis kan vi da installere programpakken tsocks fra http://tsocks.sourceforge.net/.
Hovedpoenget er at ssh kan fungere som en socks4-proxy (med kryptering til endepunktet, ja), og tsocks kan fange opp alle nettverkskall frå en applikasjon og sende dem gjennom denne proxyen.
Den enkle kommandoen
ssh -D <lokal port> bruker@maskin.på.jobben.din
gjør biffen. Så peker du bare tsocks til localhost port <lokal port>, og kjører programmet ditt som for eksempel
tsocks emacs
og du har en superenkel versjon av VPN.
Nøkkelpar
I steden for å stadig vekk skrive passord, kan du bruke et nøkkelpar til å ta seg av autentiseringen.
OpenSSH bruker såkalt «public key»-kryptografi – dvs. at hver part har en privat og en offentlig nøkkel. De offentlige nøklene blir utvekslet, og partene bruker disse til å kryptere data sendt til hverandre. Dvs. at når a og b snakker sammen, kan ikke a dekryptere informasjon kryptert med b sin offentlige nøkkel – og omvendt.
Dette prinsippet kan også brukes i godkjenning av brukere – altså i steden for passord. Man lager et nøkkelpar, og kopierer den offentlige nøkkelen over på maskiner som maskiner man bruker ofte for å slippe å stadig skrive passordet.
For å lage et DSA-nøkkelpar (DSA er hva som brukes i SSH protokoll 2), kjør følgende:
$ ssh-keygen -t dsa
Nå kan du enten skrive inn et passord, eller du la være å skrive inn et passord. Hvis du oppgir et passord, må passordet oppgis hver gang den skal brukes, hvis man ikke bruker ssh-agent (se lenger ned). Hvis du ikke oppgir et passord, er det ikke nødvendig å oppgi noe passord når du logger inn på maskiner med en kopi av din offentlige nøkkel. Dette kan være veldig praktisk, men utgjør en sikkerhetsrisiko som må vurderes.
Passord på nøklene kan endres med ssh-keygen -p.
To nøkler blir generert:
- En offentlig nøkkel: ~/.ssh/id_dsa.pub
- En privat nøkkel: ~/.ssh/id_dsa
Den offentlige nøkkelen kopieres over til maskinene du skal kunne logge inn på, og legges til i ~/.ssh/authorized_keys på respektive maskin.
Hvis du har ssh-copy-id installert, kjører du
$ ssh-copy-id brukernavn@maskin
Hvis du ikke har ssh-copy-id, gjør du følgende:
$scp ~/.ssh/id_dsa.pub bruker@foobar://Se lenger ned for info om scp $ssh bruker@foobarPassword: foobar $cat id_dsa.pub >> ~/.ssh/authorized_keysfoobar $logout$ssh bruker@foobarfoobar $ // Nå logget inn uten å måtte skrive passord.
Dette kan også gjøres i en kommando:
$ cat ~/.ssh/id_dsa.pub | ssh bruker@foobar "cat - >> ~/.ssh/authorized_keys"
(Se #SSH og skallet for en forklaring på hvordan sistnevnte kommando fungerer.)
| Den private nøkkelen må du passe på at ingen andre får tak i – med den, kan en inntrenger logge seg inn på alle maskinene som den offentlige nøkkelen er lagt inn på. Dette er ekstra viktig hvis du har en passordløs nøkkel. |
ssh-agent
SSH-nøkler fjerner behovet for å oppgi passord – dette kan være praktisk og gjøre bruk av SSH i shellscript enklere, men det kan også utgjøre en sikkerhetsrisiko dersom noen får tak i privatnøkkelen.
ssh-agent kan bøte på dette problemet – når du bruker ssh-agent, trenger du kun oppgi passordet til nøkkelen første gangen du bruker den.
I tillegg gjør ssh-agent det mulig å logge inn på maskiner med din offentlige nøkkel fra en maskin uten den private nøkkelen. Hvis du har din private nøkkel på maskin a og du er logget inn på maskin b, kan du med ssh-agent logge deg inn på maskin c med nøkkelen på maskin a.
En ulempe med ssh-agent, er at du må sette noen miljøvariabler for skallet hver gang du skal bruke den – en vanlig løsning har vært å starte en ssh-agent for hvert skall man starter, men dette blir fort uelegant og lite praktisk – du må skrive passordet for hver nye ssh-agent.
keychain er et verktøy laget for å håndtere ssh-agenter. Man starter keychain for hvert skall man starter, og keychain tar seg av å sette opp de nødvendige variablene.
Hvis du ikke har keychain installert, kan du se på keychain-siden (http://www.gentoo.org/proj/en/keychain/index.xml) til Gentoo. (keychain er et bashscript.)
Legg følgende til i f.eks. ~/.bash_profile for å starte keychain for hver økt:
#Start keychain -- program for å håndtere ssh-agenter. keychain id_dsa #Sleng på -q for å fjerne oppstartsmeldingen, altså keychain id_dsa -q #Last inn nødvendige miljøvariabler: . ~/.keychain/$HOSTNAME-sh
Neste gang du da starter et nytt skall, vil følgende dukke opp:
* Initializing /Users/alex/.keychain/v064a.studby.ntnu.no-sh file... * Initializing /Users/alex/.keychain/v064a.studby.ntnu.no-csh file... * Starting ssh-agent * Adding 1 key(s)... Enter passphrase for /Users/alex/.ssh/id_dsa: //skriv inn passordet * Identity added: /Users/alex/.ssh/id_dsa (/Users/alex/.ssh/id_dsa)
Når du senere starter et nytt skall etter å skrevet inn passordet tidligere, vil følgende dukke opp:
* Found running ssh-agent (4799) * Key: id_dsa
Du kan nå ssh-e til maskiner med din offentlige nøkkel uten å skrive inn passord. Ved å bruke «agent-forwarding», kan du også ssh-e fra a til b til c, hvor c bruker nøkkelen som ligger på a via ssh-agenten.
| Ikke bruk agent-forwarding til maskiner du ikke kan stole på, da root på en slik maskin kan kunne ta i bruk dine nøkler til å komme seg inn på andre maskiner. |
scp – secure copy
scp er cp over SSH – enkel og sikker filoverføring mellom maskiner. Kombinert med nøkler (se over), er den svært enkel i bruk.
Bruken er svært lik bruken av cp, med unntak av at en eller begge argumentene er på en annen maskin.
Eksempler:
Kopiering til annen maskin
$scp fil bruker@maskin:$scp -r katalog/ maskin: //brukernavnet vil være det samme som den som utfører kommandoen.
Kopiering fra en annen maskin
$scp maskin:fil .///brukernavnet vil være det samme som den som utfører kommandoen. $scp -r annen_bruker@maskin:katalog /var/www/pub
Kopiering mellom maskiner
$ scp maskin1:fil foo@maskin2: //brukernavnet på maskin1 vil være det samme som den som utfører kommandoen og «foo» på maskin2.
Overføringen vil gå direkte mellom maskin1 og maskin2.
sftp – secure ftp
Som mange allerede er klar over, er FTP en usikker protokoll. Passord sendes i klartekst. Hvis du ikke er overbevist, prøv å kjøre
sudo tcpdump -l -w - src or dst port 21
og få en til å logge seg inn via FTP.
sftp løser disse problemene. sftp er svært lik en vanlig FTP-klient som brukes i kommandolinja.
En annen fordel med sftp, er at du kan bruke autentiseringsmekanismene beskrevet overfor.
sftp kommer stort sett ut av boksen på de fleste installasjoner av OpenSSH.
SSH og skallet
Kjøre kommandoer på andre maskiner
Du trenger ikke logge inn på maskina, skrive en kommando og logge ut igjen hvis du bare skal kjøre en kommando. Etter alle andre opsjoner, kan du gi ssh navnet på en kommando som skal kjøres – med argumenter.
Eksempel:
$ ssh host.com uname Linux
Pipe til SSH
På samme måte som du kan pipe til kommandoer, kan du pipe til kommandoer som kjøres på andre maskiner.
Eksempel:
$ echo foo | ssh host.com cat \> bar //> escapes slik at skallet du kjører kommandoen på ikke tolker tegnet. $ ssh host.com cat bar foo
Pipe fra SSH
Man kan selvfølgelig også pipe fra ssh. Et kjekt bruksområde til dette kan til eksempel være å overføre data fra en maskin til en annen og samtidig ta vare på eier og tilganger.
Eksempel:
$ ssh host.com tar1 cjpf - /home/alex | tar2 xjvpf - (tallene er ikke en del av kommandoen)
«-» betyr her flere ting. tar1 på host.com vil sende dataene til STDOUT, som blir pipet via ssh til den lokale maskina hvor tar2 tolker - som STDIN og pakker ut dataene.
SSH-tjener
Nesten alle distribusjoner inkluderer en SSH-tjener i sitt pakkeutvalg, og pr. standard er denne ofte på. Det betyr at hvem som helst kan logge seg inn på maskinen din dersom de klarer å gjette root-passordet eller et annet passord for f.eks. brukeren test med passord test.
Problemet med å ha denne på, er at standardinstillingene ofte er noe usikker mot internett. Det fins nemlig ormer på nettet som skanner etter maskiner med SSH-tjener kjørende. Dersom ormen finner deg, vil den prøve en mengde brukernavn- og passordkombinasjoner for å forsøke å komme seg inn. Du må altså beskytte maskinen din.
Dersom du ikke trenger innlogging utenfra via SSH slår du av SSH-serveren og problemet er løst. I motsatt fall anbefales følgende:
- Tillatt kun protokoll 2
- Ikke tillatt root til å logge inn (utenfra)
- Bruk AllowUsers til begrense hvem som kan logge inn
- Sett antall forsøk en har på å logge seg inn
- Knapp inn på tidsrommet en bruker kan bruke for å logge seg inn
- Ikke tillatt tomme passord
- Tillatt få samtidige brukere
Som transformeres til følgende i /etc/sshd/sshd_config:
Protocol 2 PermitRootLogin no MaxAuthTries 2 LoginGraceTime 30 PermitEmptyPasswords no MaxStartups 1 AllowUsers <din-kjære-bruker>
Husk og starte SSH-tjeneren på nytt etter endringen:
service sshd restart
Man kan videre legge til brannmurfunksjonalitet for å beskytte seg mer.
Eksterne ressurser
- Doing it all with OpenSSH, Part 1 (http://www.linuxjournal.com/article.php?sid=6909)
- Doing it all with OpenSSH, Part 2 (http://www.linuxjournal.com/article.php?sid=6960)
- The 101 uses of OpenSSH: Part I (http://www.linuxjournal.com/article.php?sid=4412)
- The 101 uses of OpenSSH: Part II (http://www.linuxjournal.com/article.php?sid=4413)
- Protect your data with OpenSSH (http://www.linux-mag.com/2000-12/openssh_01.html)
- SSH tunneling (http://www.linux-mag.com/2004-07/guru_01.html)
- Running commands on many nodes (http://www.linux-mag.com/2002-12/extreme_01.html)
- Keychain: Hassle-free SSH (http://www.linux-mag.com/2002-08/potm_01.html)
- Smb over ssh (http://vegard.loekken.org/howtos/smb_over_ssh.pdf)
