1. Generell informasjon

SSH (Secure SHell) er en nettverksprotokoll som lar deg koble til en ekstern server og utføre kommandoer på den, laste opp filer og opprette TCP-tilkoblinger. Nøkkelfunksjonen er krypteringen av den overførte informasjonen. Som standard bruker hostingen bash-skallet.

2. Tilkoblingsinformasjon

Informasjon for å koble til serveren via SSH og SFTP kan du få i seksjonen " Internett server " — « Adgangskontroll " — « SSH " kontrollpanel (https://www.r01.ru, delen "For kunder").

• Serveradresse (vert): ssh.identifier.r01host.ru- spesifisert i "Domenenavn"-blokken.
• "Identifier"- det unike navnet på vertstjenesten, angitt øverst på kontrollpanelet ved siden av kontraktsnummeret.
• SSH brukernavn (pålogging): identifikator.
• For å få passordet til SSH-brukeren, klikk på knappen "Bytt passord"... Det nye passordet vises på skjermen. For å få passordet sendt til e-postadressen din, merk av i boksen "Spesifiser passordet i brevet".

For å koble til via SSH til vertsserveren, installer en ssh-klient på datamaskinen din.

• Konfigurerer PuTTY ssh-klienten

Bruk en SFTP-klient til å laste opp filer til hosting.

• Tilgang til virtuell server via SFTP

3. Arbeide med hosting med Midnight Commander.

Midnight Commander er en filbehandler med to ruter. Har en innebygd tekstredigerer.

For å starte Midnight Commander, koble til hostingen din via SSH og skriv inn kommandoen

Grunnleggende hurtigtaster:

• F1: Hjelp;
• F3: Innebygd filviser;
• F4: Innebygd tekstredigerer;
• F5: Kopier fil;
• F6: Flytt (gi nytt navn) fil;
• F8: Slett fil;
• F9: Vis rullegardinmeny;
• F10: Avslutt programmet;
• Tab: Overgang mellom paneler;
• Sett inn: Merk en fil for flere filoperasjoner som kopiering.

4. Arbeide med hosting fra kommandolinjen

4.1. Får hjelpeinformasjon

For å få hjelp informasjon om kommandoen av interesse kommando skriv inn kommandolinjen:

trykk på q for å avslutte hjelpen.

En rask referanse til kommandoen kan vanligvis fås ved å kjøre den med --help eller -h alternativet:

4.2. Flytte rundt i filsystemet

List opp gjeldende katalog:

Gå til brukerens hjemmekatalog:

Bytt til tmp-katalogen som ligger i gjeldende katalog:

Gå til katalogen ved å bruke hele banen /home/login/sitename.ru/docs (rotkatalogen til sitename.ru-nettstedet):

cd /home/login/sitename.ru/docs

Flytt til overordnet katalog (ett nivå opp):

Flytt til forrige katalog:

4.3. Se kataloginnhold

List innholdet i gjeldende katalog (bortsett fra skjulte filer):

List opp hele innholdet i gjeldende katalog med detaljert informasjon:

Liste alt innholdet i tmp-katalogen med detaljert informasjon:

Skriv ut størrelsen på tmp-katalogen:

4.4. Opprette og slette filer og kataloger

Opprett en ny katalog foo i gjeldende katalog:

Lag katalogstruktur foo / bar / baz i gjeldende katalog:

mkdir -p foo / bar / baz

Slett katalog foo i gjeldende katalog. Katalogen må være tom:

Fjern katalog foo med alle filer og underkataloger:

Opprett tom fil foo:

Slett fil foo:

4.5. Vise og redigere filinnhold

Se innholdet i tekstfilen (nettstedets loggfil) (Trykk "q" for å avslutte):

mindre sitename.ru/logs/access_log

Åpne fil foo i et tekstredigeringsprogram:

4.6. Kopiering og flytting av filer

Kopier filfoo til fillinje:

Kopier innholdet i den gamle katalogen til den nye katalogen:

Gi nytt navn til filfoo til fillinje:

Flytt filen foo til den eksisterende kataloglinjen under navnet baz:

4.7. Endring av tilgangsrettigheter

Gjør foo kjørbar:

Gjør filen foo skrivebeskyttet:

Endre tillatelser for alle kataloger nestet i katalog foo til 755:

finn foo -type d -exec chmod 755 () \;

Endre tillatelsene for alle filer nestet i foo-katalogen til 644:

finn foo -type f -exec chmod 644 () \;

4.8. Prosessledelse

Vis informasjon om prosesser i sanntid (Trykk "q" for å avslutte):

Vis detaljert informasjon om alle kjørende prosesser:

Avslutt en prosess med prosessidentifikatoren (PID) 1234:

Avslutt prosessen med navnet:

Start Apache webserver på nytt:

~ / etc / rc.d / httpd omstart

Start Nginx webserver på nytt:

~ / etc / rc.d / nginx omstart

4.9. Jobber med arkiver

Opprett et arkiv av dokumentkatalogen:

tar -czf archive.tar.gz docs

Pakk ut archive.tar.gz-arkivet:

tar -xzf archive.tgz

Pakk ut arkivet archive.zip:

unzip archive.zip

Pakk ut archive.rar-arkivet:

unrar x archive.rar

Pakk ut archive archive.gz:

gunzip archive.gz

4.10. Søk etter filer

Finn blant nettstedfilene som inneholder teksten "login.mysql" (serveradresse for tilgang til databasen):

grep -R "login.mysql" sitename.ru/docs

Finn filer kalt index.php i gjeldende katalog og underkataloger.

I denne artikkelen skal vi se på moderne og praktiske måter å jobbe med en server via SSH med en VPS fra Infobox og en sky.

Vi vil fortelle deg ikke bare om den vanlige måten å koble til, men også om å organisere en stabil tilkobling via et ustabilt Internett (for eksempel 3G-modem), samt om tilleggsverktøy som hjelper deg med å jobbe over SSH.

Hvis du er en Windows-bruker og trenger å enkelt og raskt koble til en Linux-server - gå til delen "Putty eller hvordan du raskt kobler til SSH fra Windows".

Hva du trenger å vite for å koble til via SSH

For å koble til trenger du:

• Server IP-adresse
• Logg Inn
• passord

Hvor kan du hente dataene for å koble til VPS NG-serveren fra Infobox

Etter å ha bestilt tjenesten, gå inn på kontrollpanelet https://panel.infobox.ru.
Velg "VPS NG"-tjenesten i øvre høyre hjørne av kontrollpanelet i rullegardinlisten.
Gå deretter til "VPS"-fanen.

I denne delen vil du se server ip-adresse og du kan installere passord for å få tilgang til serveren.

Bruk brukernavnet ditt for å koble til rot, IP adresse fra denne siden og installert passord.
Hvis du har glemt passordet ditt, klikk på "Rediger tilgangsinnstillinger"-elementet vist i skjermbildet ovenfor.

Hvor henter du dataene for å koble til VPS-serveren fra Infobox

Logg på kontrollpanelet https://panel.infobox.ru.
Velg VPS-tjenesten i øvre høyre hjørne av kontrollpanelet i rullegardinlisten (navnet på tjenesten inneholder navnet på det bestilte operativsystemet og området for plassering).

Gå deretter til fanen "VPS Management".

Bruk brukernavn rot, passord og server ip-adresse fra denne siden.

Hvor kan du hente data for å koble til InfoboxCloud-serveren

Etter å ha opprettet serveren vil tilkoblingsdataene bli sendt til deg på e-post. Dette er nok for tilkoblingen.

Hvis du har mistet e-posten med tilgangsdata og ønsker å få tilgang til serveren

Som standard er påloggingen for serveradministratoren: root

Logg inn på kontrollpanelet på: https://panel.infobox.ru.
Velg tjenesten "Cloud Servers" i øvre høyre hjørne av kontrollpanelet i nedtrekkslisten.

Den dedikerte IP-adressen til serveren kan sees i "Skyinfrastruktur"-fanen på kontrollpanelet.

Hvis feltet " Dedikert IP-adresse"tom, betyr det at når du opprettet serveren, la du ikke til minst 1 dedikert ip-adresse til serveren (og derfor er det ingen tilgang til serveren via Internett, det er kun fra det lokale nettverket).

For å legge til en dedikert IP-adresse, klikk på servernavnet.

I "Nettverk"-gruppen med innstillinger klikker du på "Konfigurer".

Sørg for at båndbredden (hastigheten) til nettverket er tilstrekkelig (eller still inn mer om nødvendig).
Klikk deretter på Legg til IPv4-adresse og klikk på Lagre endringer.

Serveren har nå en dedikert IP-adresse.

For å endre passordet for tilgang til serveren, klikk "Endre", som vist på skjermbildet ovenfor. Slik kan du angi et passord for å få tilgang til serveren.
Nå vet du server ip-adresse, Logg Inn ( rot) og passord.

Konfigurere SSH-klienter

For Windows

For å koble til serveren trenger du en SSH-klient. Hvis du trenger å koble til raskt, anbefales Putty. Hvis du trenger å jobbe med unix-verktøy som scp, rsync og ssh-copy-id, bruk Cygwin.

Putty eller hvordan du raskt kobler til SSH fra Windows

Last ned Putty-installasjonsprogrammet for Windows fra delen med den nyeste versjonen og installer Putty med standardinnstillingene.

Start Putty (Start -> Alle applikasjoner -> PuTTY -> PuTTY).

Skriv inn IP-adressen til serveren. Kontroller at port 22 er valgt og tilkoblingstypen er SSH og klikk "Åpne".

Du vil bli spurt om du stoler på serveren du kobler til. Du må svare "Ja".

Et tilkoblingsvindu åpnes. Bruk root som pålogging, og serverpassordet som passord. Passordet kan limes inn fra utklippstavlen med høyre museknapp. Den vises ikke når du skriver og limer inn av sikkerhetsgrunner.

Forbindelsen ble opprettet.

Cygwin eller Unix-miljø på din Windows-datamaskin

Når du arbeider med Linux-servere, kan det hende du trenger et lignende miljø på datamaskinen. Det er veldig praktisk å bruke det samme settet med verktøy på serveren og på arbeidsdatamaskinen, så sørg for å prøve Cygwin. Linux virker komplisert ved første øyekast. Gradvis mestring av dette operativsystemet, vil du i økende grad trenge Cygwin. Godt avhengighetsskapende.

Ustabil internettforbindelse ved tilkobling via SSH - hva skal jeg gjøre?

Ofte, når du jobber over et ustabilt nettverk (for eksempel via 3G / 4G mobilt Internett eller forskjellige WiFi-tilgangspunkter), blir SSH-tilkoblingen avbrutt. La oss ta en titt på hva som kan gjøres på klientnivå for å forhindre behov for ny tilkobling. Disse verktøyene er ikke egnet for å utføre kritiske operasjoner på serveren (for eksempel oppgradering av operativsystemet). For å utføre kritiske operasjoner, må du i tillegg bruke verktøyene beskrevet i neste del av artikkelen. Hensikten med verktøyene i denne delen er å gjøre SSH-arbeid mer praktisk for brukeren.

AutoSSH

AutoSSH starter en kopi av ssh-klienten og overvåker tilkoblingen, og starter ssh-klienten på nytt om nødvendig.

Autossh bruker ssh for å bygge en ssh-omdirigeringssløyfe (kobler fra lokal til ekstern og omvendt) og videresender testdata, og forventer at de kommer tilbake. Den støtter også bruk av en ekstern ekkotjeneste for å sende tilbake testdata.

AutoSSH støtter kun 3 parametere:

• -M<порт>[: ekkoport]- brukes til å spesifisere overvåkingsporten eller overvåkingsporten og ekkotjenesteporten. Hvis porten til ekkotjenesten ikke er spesifisert, brukes neste portnummer for det. For eksempel, hvis -M 20000-flagget er satt, vil testdata sendes på port 20000 og mottas på port 20001. Hvis du spesifiserer -M 0, vil tilkoblingsovervåking bli deaktivert og autossh vil bare starte ssh på nytt når du avslutter ssh (du kan bruke dette med ServerAliveInterval-alternativene og ServerAliveCountMax i OpenSSH hvis overvåking ikke kan brukes i din situasjon);
• -f- sender autossh til bakgrunnen selv før du starter ssh (du kan ikke angi et passord i denne modusen);
• -V- viser versjonen av autossh.

Alle andre argumenter sendes som ssh-parametere.

For å unngå å måtte angi passordet på nytt når du gjenoppretter tilkoblingen, la denne brukeren gå inn på serveren med nøkkelen, som vist i avsnittet ovenfor.

Installere AutoSSH i Cygwin på Windows

Når du bruker Cygwin på Windows, skriv inn:
apt-cyg oppdatering
apt-cyg installer autossh

Nå kan du koble til serveren:
autossh -M 20000 [e-postbeskyttet] _server adresse


Tilkoblingen er etablert.

Generelt er autossh et ganske praktisk verktøy for å jobbe gjennom ustabile Internett-tilkoblinger og for å organisere ssh-tunneler på serveren (vi vil vurdere dette scenariet i en egen artikkel). Ulempen med autossh er at dette verktøyet ikke løser problemet hvis det oppstår betydelige forsinkelser på tidspunktet for inntasting av kommandoer på nettverket (som skjer på et 3G-nettverk). I dette tilfellet vil du vente på svar fra serveren for å legge inn hvert tegn, noe som bremser arbeidet noe. Under normale driftsforhold er autossh imidlertid svært nyttig for å opprettholde en ssh-forbindelse.

Mosh løser muligheten til å legge inn kommandoer uten å vente på et serversvar, men kompatibiliteten til dette verktøyet er fortsatt svært begrenset, og dets pålitelighet er lav, så det anbefales ikke å bruke det ennå.

Hvordan utføre kritiske og tidkrevende serveroperasjoner: Terminalmultipleksere

Hvis du oppdaterer operativsystemet, installerer programvare eller bare redigerer en fil på serveren, etter tilkobling via ssh eller autossh, fungerer ikke direkte. Hvis SSH-tilkoblingen avsluttes, vil du miste økten som ble startet når du kobler til via SSH. For å forhindre at dette skjer og når du kobler til igjen via SSH, vil du definitivt finne deg selv i en pågående operasjon på serveren eller i et åpent filredigeringsvindu fra samme øyeblikk, bruk terminalmultipleksere på serveren: GNU Screen eller tmux.

GNU-skjerm

Screen ble opprinnelig designet for å kjøre flere terminaløkter innenfor en enkelt terminal. Skjermen har imidlertid en annen nyttig egenskap: muligheten til å koble virtuelle økter fra en fysisk terminal og koble til en annen. Spesielt dette lar deg kjøre langvarige prosesser på eksterne maskiner, uten å være konstant logget på dem.

1. Logg inn på den eksterne serveren via SSH.
2. Kjør skjermen der
3. Du vil se en hilsen, trykk Enter.
4. Nå kan du gjøre hva du vil som om du nettopp var koblet til serveren via SSH (start for eksempel en lang prosess).
5. Du kan koble fra økten ved å trykke CTRL + a og deretter d. Du kan til og med avslutte SSH-tilkoblingen til serveren.
6. For å gå tilbake til økten, koble til på nytt via SSH (eller autossh vil gjøre det) og gå inn på skjermen -r
Du vil bli returnert til løpeøkten, og prosessen du startet tidligere fortsetter i den. Vi vil analysere terminalmultipleksere mer detaljert i påfølgende artikler.

Konklusjon

I denne artikkelen prøvde vi å dekke det grunnleggende som kreves for å bli komfortabel med å bruke SSH fra forskjellige operativsystemer. Dette er selvfølgelig ikke alt som er mulig, men et godt utgangspunkt å starte. Hvis du finner en feil i artikkelen, tror du at du må legge til noe viktig, eller du har bare et spørsmål -

SSH er en teknologi for å utføre kommandoer eksternt, samt for å logge på en annen datamaskin over et nettverk. Ved å bruke SSH kan du laste opp og kopiere filer mellom datamaskiner, men oftest brukes det til å overføre nettstedfiler på en sikker måte mellom datamaskinen din og vertsleverandørens server.

Secure Shell er forkortelsen for SSH. Takket være bruken av denne teknologien oppnås pålitelig autorisasjon og sikker overføring av informasjon gjennom åpne kommunikasjonskanaler. SSH har erstattet protokoller som telnet, rlogin, rcp og rsh. Fordi bruken av de listede teknologiene er forbundet med noen sikkerhetsproblemer:

1. Dataoverføring over et nettverk utføres i klartekst, slik at enhver bruker av en datamaskin koblet til dette nettverket kan fange opp disse dataene. Sikkerhetsproblemet forverres av at passord også overføres i klar (ukryptert) form.
2. Dessuten er autorisasjon ved hjelp av IP-adresser (rlogin) og passord (telnet og FTP) svært sårbart fra et sikkerhetssynspunkt. SSH gjør en utmerket jobb med oppgavene oppført ovenfor. Selv med tanke på det faktum at inngangen til en annen datamaskin utføres ved å skrive inn et passord. Dette passordet kan ikke fanges opp, siden overføringen er kryptert.

Hvordan SSH fungerer

For å forstå mer tydelig hvordan SSH fungerer, vil et visuelt eksempel hjelpe oss. For å gjøre dette vil vi bruke en analogi for eksemplet med den velkjente Stirlitz.

Anta at Stirlitz trenger å overføre viktige data til senteret, men den gamle koden er allerede kjent for fiendene. Hva bør gjøres i denne situasjonen? Det beste alternativet kan være å organisere et møte for å overføre et nytt chiffer til Stirlitz (det vil si lage en ny kode). Men hvis et møte er umulig, gjenstår bare en åpen kommunikasjonskanal, som kan lyttes til av fiender. Men denne situasjonen kan også løses.

På midten av 1970-tallet ble RSA-algoritmen utviklet av matematikere. Ved å bruke den kan du bruke "offentlige nøkler" i kryptografi. Essensen av denne algoritmen er at det er to kryptonøkler: en brukes til kryptering, og den andre brukes til dekryptering. Den "offentlige nøkkelen" er krypteringskoden fordi den ikke er hemmelig og fritt kan overføres. I motsetning til krypteringsnøkler er dekrypteringsnøkler hemmelige (jeg kaller dem også private) og dette betyr at kun eieren av denne nøkkelen kan dekryptere meldingen.

Driften av RSA-algoritmen er basert på umuligheten av å få en privat nøkkel fra den offentlige nøkkelen, som er nødvendig for dekryptering. Derfor, hvis handlingen til den kjente filmen «Seventeen Moments of Spring» fant sted nå, ville senteret ha nok til å sende Stirlitz en ny offentlig nøkkel, og Mueller ville ikke være i stand til å tyde meldingene deres, uansett hvor mye han prøvde.

Hvilken er den beste SSH-klienten å velge?

For å bruke Secure Shell-tilgang trenger du bare å laste ned og deretter installere en hvilken som helst SSH-klient. Eksperter anbefaler å gi preferanse til den populære og gratis Filezilla-klienten. Det er også WinSCP2, siden det er et av de mest effektive programmene som kan kjøres over SSH2-protokollen. Programmet ligner visuelt på en ganske kjent FTP-klient - CuteFTP, det har et godt grafisk grensesnitt, og gir også muligheten til å sammenligne kataloginnhold. Den tredje i denne listen er PuTTY-programmet (hvordan konfigurere PuTTY), som også har sine fans, ekspertene våre likte minst av alt.

For å konfigurere SSH-klienten trenger du bare å spesifisere ditt domenenavn (eller bruker-ID), IP-adresse, passord og velge SHH-protokollen. Du kan la andre innstillinger være standard. Etter at tilkoblingen er opprettet, vil serveren sende en forespørsel om passord og brukernavn. du bør skrive inn data som ligner på de du bruker for å få FTP-tilgang (de sendes vanligvis av vertsleverandøren i første bokstav etter at du har opprettet en konto).

Det hender ofte at en hostingleverandør har SSH-tilgang som en ekstra betalt tjeneste. Derfor, hvis du ikke er i stand til å konfigurere noe, kontakt hosterens støtte for å finne ut årsakene.

Denne artikkelen er merket som uferdig. Se notatet på slutten av artikkelen.

Denne artikkelen handler om den sikre shell-klienten og serveren i Ubuntu, hvordan du konfigurerer og bruker dem. SSH er en spesiell nettverksprotokoll som lar deg eksternt få tilgang til en datamaskin med en svært sikker tilkobling. Du kan lese mer om ssh-protokollen.

Beskrivelse av prinsippene for drift og brukte applikasjoner

I utgangspunktet er SSH implementert som to applikasjoner - en SSH-server og en SSH-klient Ubuntu bruker en gratis implementering av en SSH-klient og -server - OpenSSH. Ved tilkobling går klienten gjennom autorisasjonsprosedyren på serveren og det etableres en kryptert forbindelse mellom dem. OpenSSH-serveren kan fungere med både ssh1- og ssh2-protokoller. ssh1-protokollen anses for øyeblikket som usikker, så bruken av den frarådes sterkt. Jeg utelater bevisst ulike tekniske detaljer i protokollen, siden hovedformålet med denne håndboken er å beskrive dens konfigurasjon og bruk. Det er mange artikler på Internett om selve protokollen, dens operasjonsprinsipper, krypteringsalgoritmer, etc., for eksempel kan du lese om den i detalj.

Installasjon

Installere OpenSSH du kan bruke kommandoen fra terminalen:

sudo apt-get install ssh

ssh-metapakken inneholder både klienten og serveren, men denne vil mest sannsynlig bare installere serveren da klienten allerede er inkludert i Ubuntu som standard.

Server Tuning

Under installasjonen blir SSH-serveren automatisk registrert for oppstart. Du kan kontrollere start, stopp eller omstart ved å bruke kommandoene:

sudo service ssh stop | start | omstart

Hovedkonfigurasjonsfilen for SSH-serveren er / etc / ssh / sshd_config, som kun kan leses eller redigeres av superbrukeren. Etter hver endring av denne filen, må du starte ssh-serveren på nytt for å bruke slike endringer.

Et eksempel på en standard SSH-serverkonfigurasjon i Ubuntu:

# Et eksempel på en åpen ssh-serverkonfigurasjon med russiske # # kommentarer..2010. # # # # # # Forklaring: # # Som standard er sshd ment å oppføre seg når # # et eksplisitt direktiv ikke er spesifisert. Det er verdt å merke seg at i Ubuntu # # inneholder sshd_config-filen allerede en rekke innstillinger, som # # er standardinnstillingene for Ubuntu spesifikt. # # Disse innstillingene er spesifisert i denne filen. # # # ############################################ ############ ################ Adresse-/portinnstillinger osv. ############ #################################### ##################### # # ## Havn ######################## ############################ # # # Port brukt. Du kan spesifisere flere, for eksempel: # # Port 22 # # Port 23 # # Port 24 # # Det anbefales å bruke en ikke-standard port, fordi # # standard skannes ofte av roboter for # # potensielle "hull". Kan utelates hvis # # er spesifisert via adresse. Se også ListenAddress-parameteren. # # # Port 22 # # ## ListenAddress ####################################### ## # # # Nettverksadressen som serveren "lytter" på. Adressen kan # # skrives slik: # # ListenAddress-vert | IPv4_addr | IPv6_addr # # ListenAddress-vert | IPv4_addr: port # # ListenAddress: port # # Hvis ingen port er spesifisert, vil sshd lytte på denne adressen og # # på port spesifisert i alternativet Port. Hvis du # # bruker ListenAddress uten å spesifisere en port, må # # Port-alternativet gå foran ListenAddress-alternativet. Hvis # # ikke er spesifisert, lytter som standard på alle lokale # # adresser. Flere adresser kan spesifiseres. # # # ## AdresseFamilie ############################################## # Spesifiserer hvilken IP-adressefamilie # # som skal brukes av sshd. Mulige alternativer: # # "any" - enhver # # "inet" (kun IPv4) # # "inet6" (kun IPv6) # # Standard er "any". # AddressFamily inet # # ## UseDNS ######################################## ####### # # # Spesifiserer om sshd skal sjekke vertsnavnet og # # ved å bruke dette navnet sjekke IP-adressen overført av klienten med # # hentet fra DNS. # # Standard er "ja". # # # ############################################ ############ ############# Brukertilgangsinnstillinger ############## ####### ############################################### ## # # # Start / blokker en bruker definert av # # DenyUsers, AllowUsers, DenyGroups og AllowGroups-direktivene. # # i dette tilfellet går sjekken fra topp til bunn langs kjeden: # # ## DenyUsers ## # # || # # ## Tillat brukere ## # # || # # ## DenyGroups ## # # || # # ## AllowGroups ## # # Bare brukernavn og gruppenavn aksepteres, numeriske # # identifikatorer (bruker-ID) gjenkjennes ikke. Riktig # # skriv flere brukere / grupper etter tur, atskilt med # # mellomrom. Hvis skrevet i formen user @ host - så er # # bruker og host merket separat, dette lar # # avgrense tilgangen til visse brukere med # # for visse verter. Det er verdt å huske at # # DenyUsers og AllowUsers-direktivene tar # # et brukernavn som en parameter, og DenyGroups og AllowGroups tar et # # gruppenavn. Se MØNSTER i man ssh_config for mer # # informasjon om hvordan bruker- og gruppenavn skrives. # # # ## DenyUsers ############################################### ## # # # Liste over BRUKERE som IKKE KAN bruke sshd. # # Som standard - ikke spesifisert = ingen er forbudt. De. hvis # # en bruker er spesifisert her, vil han bli nektet tilgang # # til ssh-serveren. # # # ## Tillat brukere ########################################## # # # # Liste over BRUKERE som KAN brukes av sshd, # # Som standard - ikke spesifisert = alle er tillatt. De. hvis # # minst én bruker er spesifisert, er ssh-tilgang til serveren # # kun tilgjengelig for ham. # # # ## DenyGroups ############################################## # # # # Liste over GRUPPER som IKKE KAN brukes av sshd. # # Som standard - ikke spesifisert = ingen gruppe er forbudt. # # Dvs hvis minst én gruppe er spesifisert, vil brukere # # inkludert i denne gruppen bli nektet tilgang til ssh # #-serveren. # # # ## Tillat grupper ########################################## # # # Liste over GRUPPER som kan brukes av sshd. # # Som standard - ikke spesifisert = tillatt for alle. De. hvis # # minst én gruppe er spesifisert, vil bare de brukerne # # som er i den få tilgang til ssh-serveren # # # ################# ## ############################################### Alternativer som bestemmer tilkoblingsstatus ########### ################################# # ###################### # # ## TCPKeepAlive ################### ## ##################### # # # Angir om systemet skal sende TCP-meldinger til klienten # # for å opprettholde forbindelsen. Hvis du sender disse pakkene, # # kan du finne ut om forbindelsen er brutt. Det betyr imidlertid også # # at forbindelsen kan bli avbrutt i tilfelle # # av et kortvarig avbrudd i ruting og # # dette er veldig irriterende for noen. På den annen side, hvis # # slike meldinger ikke sendes, kan økter på serveren # # fortsette på ubestemt tid, og skape # # brukere - "spøkelser", # # og sluke serverressurser. Standard er "ja", # # dvs. sende slike meldinger. For å deaktivere sending av # # av slike meldinger, sett verdien til "nei". Dette # # alternativet ble tidligere kalt KeepAlive. Det er verdt å merke seg at # # det er sikrere måter å sjekke # # tilkoblingsstatus på (se nedenfor). # # # TCPKeepAlive ja # # ## ClientAliveCountMax ###################################### #################### # # # Spesifiserer antall meldinger til klienter som sshd # # sender på rad uten å motta noe svar fra # # klient. Hvis terskelen er nådd og # # klienten fortsatt ikke har svart, vil sshd koble fra klienten og avbryte # # ssh-økten. Det skal bemerkes at bruken av slike # # meldinger er fundamentalt forskjellig fra TCPKeepAlive-direktivet. # # Meldinger til / fra klienter sendes over en kryptert # # kanal og er derfor ikke gjenstand for forfalskning. Meldinger # # TCPKeepAlive er utsatt for forfalskning. Klienten i live # #-mekanismen er spesielt verdifull i tilfeller der serveren og klienten trenger # # for å vite når en tilkobling har blitt inaktiv. Standardverdien # # er 3. Hvis ClientAliveInterval # # er satt til 15 og ClientAliveCountMax står på # # standard, vil ikke-svarende klienter kobles fra omtrent # # etter 45 sekunder. Dette direktivet fungerer bare for # # ssh2-protokollen. # # # ## ClientAliveInterval ################################### # # # Stiller inn tidsintervallet i sekunder. Hvis det i løpet av dette # # intervallet ikke har vært noen kommunikasjon med klienten, sender sshd # # en melding over en kryptert kanal, # # ber om et svar fra klienten. Standard er 0, dvs. # # ikke send slike meldinger. Dette direktivet fungerer bare # # for ssh2-protokollen. # # # ############################################ ########################### Generelle autentiseringsalternativer ################# ## ############################################### ####### # # ## AuthorizedKeysFile ################################### # # # # Spesifiserer en fil som inneholder offentlige nøkler # # som brukes til å autentisere brukere. # #-direktivet kan inneholde markører som % M, som erstattes med # # under etablering av tilkobling. # # Følgende tokens er definert: # # %% - erstattet av bokstavelig "%" # #% h - erstattet av hjemmekatalogen # # til autentiseringsbrukeren # #% u - erstattet av navnet til autentiseringsbrukeren # # Dermed kan nøkkelfilen spesifiseres som # # absolutt bane (dvs. én delt fil med nøkler) og # # dynamisk - avhengig av brukeren (dvs. # # fil for hver bruker). # # Standard er “.ssh / authorized_keys”. # # Eksempel på en nøkkelfil i brukerens hjemmemappe: # # AuthorizedKeysFile% h / .ssh / authorized_key # # Eksempel på en delt fil: # # AuthorizedKeysFile / etc / ssh / authorized_keys # # Se authorized_keys filbeskrivelse for mer # # informasjon. # # # ## ChallengeResponse Authentication ####################### # # # Spesifiserer om autentisering av utfordringssvar skal aktiveres # # (utfordring-svar-autentisering ) . Alle # # autentiseringstyper fra login.conf støttes. Som standard - "yes", # # dvs. tillate. # # I Ubuntu, deaktivert av sikkerhetsgrunner. # # # ChallengeResponse Authentication no # # ## HostbasedUsesNameFromPacketOnly ####################### # # # # Angir hvordan serveren skal få klientens vertsnavn # # når et autentiseringsskjema basert på vertsvalidering. # # Hvis satt til "yes", vil sshd # # bruke det klientleverte vertsnavnet når det sjekkes for samsvar i filene # # ~ / .shosts, ~ / .rhosts eller /etc/hosts.equiv. # # (gjør omvendt DNS-oppløsning) Hvis satt til "nei" # # - vil sshd løse navnet fra selve TCP-tilkoblingen. # # Standard er "nei". # # # ## IgnorerRhosts ########################################## # # Forhindrer bruk av .rhosts og.shosts # # filer under vertsbasert autentisering. # # (RhostsRSAAautentisering eller vertsbasert autentisering). # # Filene /etc/hosts.equiv og /etc/ssh/shosts.equiv er fortsatt # # i bruk. # # Standard er "ja". # # # IgnoreRhosts yes # # ## IgnoreUserKnownHosts ################################# # # # Indikerer om sshd skal ignorere brukeren # # "known hosts"-filen ~ / .ssh / known_hosts under # # vertsbasert autentisering # # (RhostsRSAAuthentication eller Hostbased Authentication). # # Standard er "nei". # # # ## PermitBlacklistedKeys ################################ # # # Angir om sshd-nøkler skal godtas svartelistet # # som kompromittert (kjent-kompromitterte # # nøkler (se ssh-vulnkey)). Hvis verdien er "ja" - # # vil autentiseringsforsøk med slike nøkler bli logget # # og akseptert, hvis verdien er "nei" - vil autentiseringsforsøk # # bli avvist. # # Standard er "nei". # # # ## PermitEmptyPasswords ################################# # # # I tilfelle tillatt autentisering med ved hjelp av et passord, indikerer # # om det er mulig å logge på med et tomt passord. # # Standard er "nei". # # # PermitEmptyPasswords no # # ## PermitRootLogin ##################################### # # # Indikerer om ssh-pålogging er mulig som superbruker # # (root). Kan ta følgende verdier: # # "ja" - superbruker kan logge inn. # # Det gjeldende globale autentiseringsskjemaet brukes. # # # # "Uten passord" - superbruker kan logge på. # # Passordautentisering vil bli deaktivert for det. # # # # "Forced-commands-only" - superbrukeren vil kunne logge på, # # ved å bruke offentlig nøkkelautentisering og # # bare hvis han gir kommandoen som skal utføres. # # Dette er nyttig for å utføre sikkerhetskopier, # # selv når normal (dvs. ikke via ssh) # # rotpålogging nektes. Alle andre # # autentiseringsmetoder for superbrukeren vil bli blokkert # # # # “Nei” - superbrukeren kan ikke bruke ssh til # # pålogging. # # # # Standard er "ja". # # # PermitRootLogin ja # # ## Protokoll ###################################### ####### # # # Spesifiserer hvilken protokoll sshd skal bruke. # # Mulige verdier for '1' og '2' er henholdsvis ssh1 og ssh2 # #. Samtidig skriving er mulig, med # # som skiller verdiene med komma. # # Standard er “2.1”. # # Det er verdt å merke seg at rekkefølgen på protokollene i # # poster ikke angir prioritet, siden klienten velger hvilken # # av flere protokoller som tilbys av serveren den # # skal bruke. "2,1"-oppføringen er helt identisk # # med "1,2"-oppføringen. # # # Protokoll 2 # # ## UsePAM ####################################### ######## # # # Aktiverer pluggbar autentiseringsmodul # #-grensesnitt. Hvis satt til "ja" - for alle autentiseringstyper # # i tillegg til øktmodul og kontohåndtering # # PAM-autentisering vil bli brukt basert på # # forespørsel -respons (ChallengeResponseAuthentication og # # PasswordAuthentication) # # challenge-response-autentisering i PAM utfører vanligvis den samme rollen # # som passordautentisering, du bør # # deaktivere enten PasswordAuthentication eller # # ChallengeResponseAuthentication. Det er verdt å merke seg at # # hvis UsePAM-direktivet er aktivert, vil du ikke kunne kjøre # # sshd som en annen bruker enn root. # # Standard er "nei". # # # UsePAM yes # # ## Passordautentisering ############################### # # # Angir om autentisering bruker # # passord. # # Standard er "ja". # # # ## Vertsnøkkel ######################################### #### # # # Spesifiserer filen som inneholder den private vertsnøkkelen # # som brukes av SSH. Standard er / etc / ssh / ssh_host_key # # for ssh1-protokollen og / etc / ssh / ssh_host_rsa_key og # # / etc / ssh / ssh_host_dsa_key for ssh2-protokollen. Merk # # at sshd ikke vil bruke en fil som er # # tilgjengelig for andre enn brukeren. Du kan # # bruke flere filer med nøkler, nøklene "rsa1" - # # for ssh1-protokollen og "dsa" / "rsa" for ssh2-protokollen. # # # HostKey / etc / ssh / ssh_host_rsa_key HostKey / etc / ssh / ssh_host_dsa_key # # ############################ ############################################## SSH-protokoll alternativer versjon 1 (ssh1) ### ########## ############################# ######## #################### # Det anbefales på det sterkeste IKKE å bruke ssh1-protokollen # # ssh2-protokollen er mye sikrere enn ssh1 # ############ ################################## ############ # # ## KeyRegenerationInterval ############################### ########## # # For ssh1-protokollen - én gang på et bestemt tidspunkt # # genereres en ny midlertidig servernøkkel # # automatisk (hvis brukt). Dette gjøres for å # # forhindre dekryptering av avlyttede sesjoner, med sikte på # # senere å logge inn på maskinen med parameterne for disse øktene og # # stjele nøklene. En slik nøkkel er ikke lagret noe sted (lagret i # # RAM). Dette direktivet spesifiserer # # nøkkel "liv"-perioden i sekunder, hvoretter den vil # # bli generert på nytt. Hvis verdien er satt lik 0 - # #, vil ikke nøkkelen bli generert igjen. # # Standard er 3600 (sekunder). # # # KeyRegenerationInterval 3600 # # ## RhostsRSAAautentisering ############################## # # # Indikerer om filbasert autentisering # # rhosts eller /etc/hosts.equiv i forbindelse med # # vellykket vertsautentisering via RSA. # # Bare relevant for ssh1-protokollen. # # Standard er "nei". # # # RhostsRSAAautentisering nr # # ## RSAAautentisering ##################################### ###################### # # Angir om ren RSA-autentisering er tillatt. # # Bare relevant for ssh1-protokollen. # # Standard er "ja". # # # RSAAautentisering ja # # ## ServerKeyBits ###################################### ## # # # Angir antall biter i serverens midlertidige nøkkel for # # ssh1-protokollen. Minimumsverdi 512. # # Standardverdi er 1024. # ServerKeyBits 768 # # ############################## ########################################## SSH-protokollalternativer versjon 2 (ssh2) #### ######## ################################# ###### ################## # # ## Chiffer ################### ####### ##################### # # # Spesifiserer krypteringsalgoritmene som er tillatt for # # ssh2-protokollen. Flere algoritmer må være # # atskilt med komma. Støttede algoritmer: # # “3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, # # “aes128-ctr”, “aes192-ctr”, “aes256-ctr”, “ arcfour128 ", # #" arcfour256 "," arcfour "," blowfish-cbc "," cast128-cbc ". # # Standardinnstillingene er: # # aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, arcfour128, # # arcfour256, arcfour, aes192-cbc, aes256-cbc, aes128, aes128, #actr9, #actr, # aes256-ctr # # # ## Vertsbasert autentisering ############################# # # # Angir om autentisering er tillatt basert på # # vertsvalidering. Sjekk rhosts eller /etc/hosts.equiv, # # og hvis vellykket, kombinert med en vellykket kontroll # # av den offentlige nøkkelen, er tilgang tillatt. Dette direktivet # # er det samme som RhostsRSAAautentiseringsdirektivet og # # er kun egnet for ssh2-protokollen. # # Standard er "nei". # # # Vertsbasert autentisering nr # # ## MAC-er ###################################### ########### # # # Spesifiserer en gyldig MAC-algoritme (melding # # autentiseringskode). MAC-algoritmen brukes # # av ssh2-protokollen for å beskytte dataintegriteten. Flere # # algoritmer må skilles med komma. # # Standarder brukes: # # hmac-md5, hmac-sha1, [e-postbeskyttet] , hmac-ripemd160, # # hmac-sha1-96, hmac-md5-96 # # # ## PubkeyAuthentication ########################## # ######### # # # Indikerer om # # basert offentlig nøkkelautentisering er tillatt. Bare relevant for ssh2-protokollen. # # Standard er "ja". # # # Pubkey-autentisering ja ########################################### ############ ################### GSSAPI-alternativer ############# ### ########## ####################################### ################## # # ############ Gjelder bare for ssh2-protokollen ######### ### # # ## GSSAPIAutentisering ################################# # # # Angir om brukerautentisering er # # basert på GSSAPI. Standard er "nei", dvs. forbudt. # # # ## GSSAPIKeyExchange ################################### # # # Indikerer om # # GSSAPI-basert nøkkelutveksling er tillatt. Nøkkelutveksling med GSSAPI er ikke avhengig av # # ssh-nøkler for å bekrefte vertsidentiteten. # # Standard er "nei" - dvs. utveksling er forbudt. # # # ## GSSAPICleanup-legitimasjon ############################# # # # Spesifiserer om # # tilpasset autentiseringslegitimasjon skal ødelegges automatisk cache når # # økt avsluttes. # # Standard er "ja" - dvs. må destrueres. # # # ## GSSAPIStrictAcceptorCheck ############################ # # # Spesifiserer hvor streng identitetssjekken skal være # # klient ved autentisering med GSSAPI. # # Verdien "yes" tvinger klienten til å autentisere til # # den mottakende vertstjenesten på den gjeldende verten. Verdien "nei" # # lar klienten autentisere med hvilken som helst # # tjenestenøkkel. # # Standard er "ja". # # Merk at å sette verdien til "nei" kan # # bare fungere med sjeldne Kerberos GSSAPI-biblioteker. # # # ############################################ ########### ################## Kerberos-alternativer ############### ## ####### ######################################### ################ # # ## Kerberos-autentisering ######################### ## ###### # # # Spesifiserer om passordet gitt # # av brukeren for autentisering # # (PasswordAuthentication) krever validering i Kerberos KDC. # # For å bruke dette alternativet trenger serveren # # for å bekrefte at KDC er sann. (Tjeneren trenger en # # Kerberos servtab som tillater verifisering av # # KDCs identitet) # # Standard er "nei". # # # ## KerberosGetAFSToken ################################# # # # Hvis AFS er aktiv og brukeren fikk en Kerberos 5 TGT, # # om han skal prøve å få AFS-tokenet før brukeren # # får tilgang til hjemmemappen sin. # # Standard er "nei". # # # ## KerberosOrLocalPasswd ################################ # # # Angir hvordan man skal håndtere hvis # # autentisering via Kerberos mislyktes. Hvis # # verdi = "ja" - vil passordet bli verifisert ved å bruke # # en hvilken som helst annen lokal autorisasjonsmekanisme, # # for eksempel - / etc / passwd. # # Standard er "ja". # # # ## KerberosTicketCleanup ################################ # # # Spesifiserer om c # skal ødelegges automatisk # fil med brukerens billettbuffer ved øktavslutning. # # Standard er "ja". # # # ############################################ ########### ################# Viderekoblingsalternativer ################# # # ############################################# ########### # # ## AllowAgentForwarding ################################# ## # # # Spesifiserer om omdirigering skal aktiveres eller deaktiveres # # ssh-agent "a. Standard er“ yes ”, dvs. tillat. # # Det skal bemerkes at deaktivering av omdirigering ikke vil # # øke sikkerheten før brukerne også # # shell-tilgang vil bli nektet siden de alltid vil kunne installere # # sine egne agentmotparter # # # ## AllowTcpForwarding ####################### ############## # # # Spesifiserer om TCP-omdirigering skal aktiveres eller deaktiveres. # # Standard er "ja", dvs. å aktivere. i tilfelle av AllowAgentForwarding, deaktivering av # # omdirigering vil ikke øke sikkerheten så lenge # # brukere har konsolltilgang, siden de kan # # installere sine motparter # # # # # ## GatewayPorts ########## ## ############################### # # # Spesifiserer om eksterne verter skal tillate tilgang til # # videresendte porter. Som standard lytter sshd # # for tilkoblinger til videresendte porter bare på det lokale # #-grensesnittet (loopback). Dette forhindrer andre eksterne # # verter fra å koble til de videresendte portene. Du kan # # bruke GatewayPorts for å la sshd # # gjøre dette. Direktivet kan ha 3 verdier: # # "nei" - bare tilbakekobling. # # "ja" - alle adresser. # # "klientspesifisert" - adresser spesifisert av klienten. # # # ## PermitOpen ########################################## # # # # Spesifiserer hvor TCP-portvideresending er tillatt. # # En omdirigeringsspesifikasjon må ha en av de # # følgende formene: # # PermitOpen-vert: port # # PermitOpen IPv4_addr: port # # PermitOpen: port # # Flere oppføringer kan spesifiseres ved å skille dem med mellomrom. # # Argumentet "any" kan brukes til å fjerne alle # # portvideresendingsforbud. Som standard er enhver # # omdirigering tillatt. # # # ## PermitTunnel ############################################# # # Indikerer om omdirigering av tun-enhet er tillatt. # # Mulige verdier: # # “yes” # # “point-to-point” (tredje nettverkslag) # # “ethernet” (andre nettverkslag) # # “nei” # # Verdi “yes” lar både peke-til -punkt # # og ethernet. Standard er "nei". # # # ############################################ ########### ################## Loggingsalternativer ################ # ## ############################################# ########### # # ## SyslogFacility ############################## ### ####### # # # Spesifiserer loggobjekt-ID for å skrive meldinger til # # sshd. Mulige verdier: # # DAEMON # # USER # # AUTH # # LOCAL0 # # LOCAL1 # # LOCAL2 # # LOCAL3 # # LOCAL4 # # LOCAL5 # # LOCAL6 # # LOCAL7 # # Standard er AUTH. # # # SyslogFacility AUTH # # ## LogLevel #################################### ## ###### # # # Angir omfangsnivået til sshd-loggen. # # Mulige valg: # # STILLE # # STILLE # # FATAL # # FEIL # # INFO # # VERBOSE # # DEBUG # # DEBUG1 # # DEBUG2 # # DEBUG3 # # Standard er INFO. # # DEBUG og DEBUG1 er ekvivalente med hverandre. # # DEBUG2 og DEBUG3 setter de høyeste nivåene av debug # #-utdata. Å skrive logger med DEBUG-nivå truer # # brukerens personvern og anbefales ikke. # # # LoggLevel INFO # # ####################################### ############## ################### Omdirigere X11 ########### ## ###### ########################################## ############## # # ## X11Videresending ########################## ### ############ # # # Spesifiserer om X11-grafikk # # omdirigering er tillatt. Det kan være "ja" eller "nei". # # Standard er "nei". # # Forsiktig - muliggjør enkel X11-omdirigering - # # stor risiko for både server og klienter som i # # en slik omdirigering, aksepterer sshd proxy-skjermen # # tilkoblinger fra hvilken som helst adresse. Bruk # # X11UseLocalhost-direktivet for å begrense tilgangen til # # xx-omdirigeringsserveren. Det er verdt å merke seg at # # deaktivering av omdirigering ikke vil garantere at # # brukere ikke vil kunne omdirigere X11, siden med # # konsolltilgang setter de alltid # # omdirigereren. X11 omdirigering blir # # automatisk deaktivert hvis # # UseLogin-direktivet er aktivert. # # # X11Videresending ja # # ## X11UseLocalhost ##################################### #################### # # # Spesifiserer om sshd skal begrense X11-omdirigeringsområdet # # til en lokal tilbakekoblingsadresse, eller # # skal tillate adresser. Standarden er sshd # # "hooker" X11-omdirigeringsserveren til den lokale adressen # # og setter den delen av DISPLAY-miljøvariabelen # # som er ansvarlig for vertsnavnet som "localhost". Det er verdt å merke seg at # # noen eldre X11-klienter kanskje ikke fungerer med denne # # innstillingen. Standard er "ja", dvs. omdirigering # # begrenset av localhost, verdi - "no" - deaktiverer # # restriksjoner. # # # ## XAuthLocation ######################################## # Spesifiserer hele banen til xauth-programmet. # # Standard er / usr / bin / X11 / xauth. # # # ## X11DisplayOffset #################################### # # # Angir nummeret av den første skjermen tilgjengelig med sshd i # # som en X11-viderekobling. Dette er # # slik at de omdirigerte x-ene ikke krysser # # ekte. Standard er 10. # # # X11DisplayOffset 10 # # #################################### #################### ################## Ulike alternativer ####### ## ############## ################################## ####################### # # ## LoginGraceTime ################# ## ############################### # # # Tid etter at serveren kobler fra # # brukeren hvis han ikke kunne logg på tilfredsstillende # #. Verdi 0 - lar brukeren # # logge på på ubestemt tid. Standard er 120 (sekunder). # # # Logg innGraceTime 120 # # ## MaxAuthTries ###################################### ### # # # Angir maksimalt antall autentiseringsforsøk # # tillatt per tilkobling. # # Når antallet mislykkede forsøk overstiger halvparten # # av den angitte verdien, vil alle påfølgende forsøk # # bli logget. Standard er 6. # # # ## MaxSessions ###################################### #### # # # Angir maksimalt antall samtidige tilkoblinger # # for hver nettverkstilkobling. Standard er 10. # # # ## MaxStartups #################################### ## #### # # # Spesifiserer maksimalt antall samtidige # # uautoriserte tilkoblinger til sshd. Hvis # # antall tilkoblinger overskrider grensen, vil alle ytterligere # # tilkoblinger bli droppet inntil gjeldende # # tilkoblinger er fullført enten ved vellykket autorisasjon, # #, eller ved utløpet av tidsperioden spesifisert i # # LoginGraceTime-direktivet . Standardverdien er 10. # # I tillegg kan du stille inn tidlig tilbakestilling av tilkoblingen ved å # # spesifisere tre verdier som en parameter, # # atskilt med et kolon "start: rate: full" (for eksempel: "10:30: 60"). # # sshd vil avvise tilkoblingsforsøket med en sannsynlighet på # # "rate / 100" (dvs. i vårt eksempel - 30%), hvis det allerede er # # "start" (10) uautoriserte tilkoblinger. # # Sannsynligheten øker lineært og eventuelle # # tilkoblingsforsøk vil bli avvist hvis antallet uautoriserte # # tilkoblinger når "full" (60). # # # ## Komprimering ######################################### # # # Indikerer om datakomprimering er aktivert. Kan være # # "ja" - komprimering er aktivert. # # "forsinket" - komprimering er forsinket til # # brukeren er vellykket autentisert. # # "nei" - ingen komprimering. # # Standard er "forsinket". # # # ## BrukLogg på ######################################## ## # # # Spesifiserer om pålogging skal brukes for # # en interaktiv økt. Standard er "nei". # # Det er verdt å merke seg at pålogging aldri ble brukt til å # # utføre eksterne kommandoer. Merk også at # # bruk av pålogging vil gjøre det umulig å # # bruke X11Forwarding-direktivet, fordi pålogging ikke vet # # hva du skal gjøre med xauth. Hvis # # UsePrivilegeSeparation-direktivet er aktivert, vil det bli deaktivert etter # # autorisasjon. # # # ## UsePrivilegeSeparation ########################################## Spesifiserer om sshd skal dele privilegier ... Hvis ja # # - vil en uprivilegert underordnet # # prosess bli opprettet først for innkommende nettverkstrafikk. Etter vellykket # # autorisasjon vil en annen prosess bli opprettet med rettighetene # # til den påloggede brukeren. Hovedformålet med # # rettighetsdeling er å forhindre at tilgangsrettigheter overskrides. # # Standard er "ja". # # # UsePrivilegeSeparation yes # # ## StrictModes ###################################### ############# ##### # # # Spesifiserer om sshd skal sjekke tilgangsmodusene og # # eierskap til brukermapper og filer før # # lar brukeren logge på. Dette er vanligvis fordi # # nybegynnere ofte gjør filene skrivbare # # av alle. Standard er "ja". # # # StrictModes ja # # ## AcceptEnv ####################################### ###### # # # Spesifiserer hvilke miljøvariabler som # # sendes av klienten som vil bli akseptert. Se SendEnv-alternativet på klienten. # # Det skal bemerkes at overføring av variabler kun er mulig # # for ssh2-protokollen. Variabler er spesifisert etter navn, # # du kan bruke masker (‘*’ og ‘?’). Du kan spesifisere # # flere variabler atskilt med et mellomrom, eller dele opp i # # flere AcceptEnv-linjer. Vær forsiktig - noen # # miljøvariabler kan brukes til å omgå # # forbudte brukermiljøer. Bruk dette # #-direktivet nøye. Som standard godtas ingen # # brukerdefinerte miljøvariabler. # # # AcceptEnv LANG LC_ * # # ## PermitUserEnvironment ################################ # # # Spesifiserer om sshd skal akseptere # # ~ / .ssh / miljø og miljø = alternativet i # # ~ / .ssh / authorized_keys. Standard er "nei". Det er verdt # # å merke seg at å tillate # # miljøbehandling kan gi brukerne muligheten til å omgå restriksjoner i noen # # konfigurasjoner ved å bruke mekanismer som # # LD_PRELOAD. # # # # # ## PidFile ######################################## ###### # # # Spesifiserer filen som inneholder prosess-ID # # (prosess-ID, PID) til SSH-demonen. # # Standard er /var/run/sshd.pid # # # # # ## PrintLastLog ############################ ############# # # # Spesifiserer om sshd skal vise dato og klokkeslett # # for siste tjeneste når en bruker logger på interaktivt. # # Standard er "ja". # # # PrintLastLog yes # # ## PrintMotd ###################################### ###### # # # Spesifiserer om sshd skal vise / etc / motd # # når en bruker logger på interaktivt. På noen # # systemer (f.eks. Ubuntu) vises denne informasjonen også # # av skallet. # # Standard er "ja". # # # PrintMotd no # # ## Banner ###################################### ######### # # # Spesifiserer hvilken fil som inneholder et tekstbanner som # # skal vises til brukeren FØR # # autentiseringsprosedyre. Dette alternativet er kun tilgjengelig for ssh2-protokollen # # Som standard viser det ikke noe. # # På Ubuntu inneholder issue.net-filen uttrykket Ubuntu (versjon), # # for eksempel, for karmic er det "Ubuntu 9.10". Kan # # brukes til å desorientere potensielle angripere, # # ved å skrive der f.eks. "My D-Link Interet Router" =) # # # Banner /etc/issue.net # # ## ChrootDirectory ######### ## ############################################# Hvis spesifisert, gir banen der # # vil bli brukt til å chroot etter autentisering. Banen og alt dens # # innhold må samsvare med mappene som eies # # av superbrukeren og # # kunne skrives av andre brukere. # # Banen kan inneholde etiketter som er erstattet i # # autentiseringsprosessen: # # %% - erstattes av bokstavelig "%" # #% h - erstattes av hjemmekatalogen # # til den autentiserte brukeren # #% u - erstattes av navnet på den autentiserte brukeren # # chroot -mappen skal inneholde alle nødvendige filer og # # mapper for brukerøkten. En interaktiv økt # # krever minst: # # et skall, vanligvis sh # # grunnleggende enheter i / dev som: # # null, zero, stdin, stdout, stderr, arandom og tty # # for en dataoverføringsøkt med sftp ingen tilleggsinnstillinger # # kreves hvis du bruker # # en intern sftp-serverprosess. Se undersystem for # # mer informasjon. Som standard blir ingen chroot utført. # # # ## ForceCommand ########################################## # # Tvinger den angitte kommandoen til å utføre. Ignorerer # # alle kommandoer gitt av klienten eller skrevet i # # ~ / .ssh / rc. Kommandoen påkalles fra et bruker # #-skall med alternativet -c. Egnet for å starte et skall, # # kommando eller et undersystem. Mest nyttig i en # # Match-blokk. Kommandoen som opprinnelig ble utstedt av klienten er lagret # # i miljøvariabelen SSH_ORIGINAL_COMMAND. Hvis # # spesifiserer "internal-sftp"-kommandoen, vil # # en intern sftp-server bli lansert, som ikke trenger de ekstra # # filene og mappene beskrevet i ChrootDirectory-direktivet. # # # ## Undersystem ########################################## ## # # # Definerer og konfigurerer et eksternt delsystem (for eksempel # # filoverføringsdemon). # # Argumentene er navnet og kommandoen (med mulige # # argumenter) som vil bli utført under forespørselen # # til undersystemene. Kommandoen sftp-server starter "sftp" - # # filoverføringsundersystemet. I tillegg kan du spesifisere # # som "intern-sftp"-undersystemet - som vil starte # # den interne sftp-serveren. Dette kan i stor grad forenkle # # konfigurasjon når du bruker # # ChrootDirectory-direktivet. Som standard blir ingen undersystemer # # påkalt. Bare relevant for ssh2-protokollen. # # # Undersystem sftp / usr / lib / openssh / sftp-server # # ############################### #################################################### ############################################### ###### ##################################### # # # # # skrive kampregler. # # MadKox. # # # # Match-direktivet er begynnelsen på en betinget # # blokk. Hvis alle kriteriene som er spesifisert i # # Match-linjen er oppfylt, utføres direktivene i de påfølgende linjene i blokken, # # tillater å omgå verdiene til de globale direktivene i # # sshd_config-filen for saken som er kriteriet for # # Match-direktivet. Alle linjer etter linjen # # med kriteriet (Match - lines) til neste matchlinje # # eller til slutten av filen regnes som en blokk. Argumentet til samsvarsdirektivet er ett eller # # flere par med kriterieposter. Mulige typer poster: # # Bruker # # Gruppe # # Vert # # Adresse # # Poster kan inneholde både enkeltverdier # # (for eksempel Bruker = bruker), og flere verdier, # # atskilt med kommaer (Bruker = bruker1) , bruker2). Også # # regulære uttrykk kan brukes som beskrevet i # # PATTERNS-delen av ssh_config-filen. Oppføringer i # # Adressekriterier kan inneholde adresser i CIDR # #-notasjon (Adresse / Maskelengde, for eksempel “192.0.2.0/24” eller # # “3ffe: ffff :: / 32”). Det er verdt å merke seg at den gitte # # maskelengden må samsvare med adressen, og for # # lang / kort for en adresse vil ikke fungere. # # Som direktiver Match kan bare bruke # # et bestemt sett med direktiver: # # AllowTcpForwarding # # Banner # # ChrootDirectory # # ForceCommand # # GatewayPorts # # GSSAPIAuthentication # # Vertsbasert autentisering # # KbdInteractiveAuthentication # # KerberosOptAuthentication #PassordAutentisering #PassordAutentisering # # # PermitRootLogin # # RhostsRSAAautentisering # # RSAAautentisering # # X11DisplayOffset # # X11Videresending # # X11UseLocalHost #

Du kan kopiere teksten ovenfor til din egen sshd_config og bruke den senere for konfigurasjon.

I seg selv er en feilkonfigurert SSH-server en enorm sårbarhet i systemsikkerhet, siden en potensiell angriper har muligheten til å få nesten ubegrenset tilgang til systemet. I tillegg har sshd mange ekstra nyttige alternativer som du bør aktivere for økt brukervennlighet og sikkerhet.

Port, ListenAddress og AddressFamily

Disse tre parameterne bestemmer på hvilke porter og adresser serveren din vil vente på innkommende tilkoblinger. For det første er det fornuftig, hvis mulig, å begrense familien av adresser som behandles til de som faktisk brukes, det vil si hvis du bare bruker IPv4, deaktiver IPv6 og omvendt. Dette kan gjøres ved å bruke AddressFamily-parameteren, for eksempel (for å aktivere IPv4 og deaktivere IPv6):

AdresseFamilie inet

For det andre er det tilrådelig å endre standardporten (22) som sshd lytter til. Dette skyldes det faktum at mange nettverksskannere hele tiden prøver å koble til den 22. porten og i det minste få tilgang med brute-force-pålogginger / passord fra databasen deres. Selv om du har deaktivert passordautentisering, tetter disse forsøkene loggene kraftig og (i stort antall) kan påvirke hastigheten til ssh-serveren negativt. Hvis du av en eller annen grunn ikke ønsker å endre standardporten, kan du bruke både ulike eksterne verktøy for å kjempe mot brute-forcing, for eksempel fail2ban, og innebygde, som for eksempel MaxStartups.
Porten kan settes enten som en absolutt verdi for alle grensesnitt som bruker Port-direktivet, eller som en spesifikk verdi for hvert grensesnitt ved å bruke ListenAddress-direktivet. For eksempel:

Port 2002

ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004

Nekt ekstern tilgang for superbruker

Som standard nektes root-tilgang av passord (med nøkkel - du kan) - alternativet PermitRootLogin er satt til uten passord. Men forutsatt at brukeren som er lagt til under installasjonen av systemet som standard i Ubuntu har muligheten til å løse alle administrative oppgaver gjennom sudo, virker det urimelig å opprette muligheten til å root-tilgang til systemet gjennom ssh (selv med nøkkelautentisering). Det anbefales å deaktivere det helt. dette alternativet, eller bruk det bare i tvungen kommandomodus. Du kan deaktivere root-tilgang slik:

PermitRootLogin-nr

Passordautentisering

Standard passordautentisering er nesten den mest primitive måten å logge på sshd på. På den ene siden forenkler dette konfigurasjonen og tilkoblingen av nye brukere (brukeren trenger bare å kjenne sin systempålogging / passord), på den annen side kan passordet alltid velges, og brukere forsømmer ofte opprettelsen av komplekse og lange passord. Spesielle roboter skanner konstant ssh-servere som er tilgjengelige fra Internett og prøver å logge på dem med brute-force-pålogginger/passord fra databasen deres. Bruk av passordautentisering frarådes på det sterkeste. Du kan deaktivere det slik:

Passordautentiseringsnr

Hvis du av en eller annen grunn fortsatt ønsker å bruke passordautentisering, sørg for at ingen kan logge på med et tomt passord. For å gjøre dette, sett PermitEmptyPasswords-direktivet:

PermitEmptyPasswords no

SSH1 og SSH2 protokoller

Som allerede nevnt, kan sshd håndtere SSH1- og SSH2-protokollene. Imidlertid frarådes bruk av usikker SSH1 sterkt. Du kan tvinge sshd til å fungere bare med SSH2-protokollen slik:

Autentisering basert på SSH2 RSA-nøkler

Den mest foretrukne autentiseringsmetoden er SSH2 RSA-nøkkelautentisering. Med denne metoden genererer brukeren på sin side et par nøkler, hvorav den ene nøkkelen er hemmelig og den andre offentlig. Den offentlige nøkkelen kopieres til serveren og tjener til å bekrefte brukerens identitet. For mer informasjon om hvordan du oppretter et par nøkler og hvordan du plasserer dem på serveren, se beskrivelsen av SSH-klienten. Du kan aktivere offentlig nøkkelautentisering som følger:

PubkeyAuthentication ja

Serveren må vite hvor den skal se etter brukerens offentlige nøkkel. Spesialfilen authorized_keys brukes til dette. Syntaksen kan være som følger:

# Kommentarer skrives kun på en ny linje # generell oversikt over oppføringer i filen authorized_keys # [options] key_type (ssh-rsa eller ssh-dss) very_long_string_incomprehensible_for_imple_human [login @ host] ssh-rsa AAAAB3Nza ... LiPk == [e-postbeskyttet] fra = "*. sales.example.net,! pc.sales.example.net" ssh-rsa AAAAB2 ... 19Q == [e-postbeskyttet] kommando = "dump / home", no-pty, no-port-videresending ssh-dss AAAAC3 ... 51R == example.net permitopen = "192.0.2.1:80", permitopen = "192.0.2.2:25" ssh -dss AAAAB5 ... 21S == tunnel = "0", kommando = "sh / etc / netstart tun0" ssh-rsa AAAA ... == [e-postbeskyttet]

Du kan spesifisere enten én delt fil med nøkler, eller én fil for hver bruker. Sistnevnte metode er mer praktisk og sikker, fordi du for det første kan spesifisere forskjellige kombinasjoner av nøkler for hver bruker, og for det andre begrense tilgangen til brukerens offentlige nøkkel. Du kan angi en fil med nøkler ved å bruke AuthorizedKeysFile-direktivet:

AuthorizedKeysFile% h / .ssh / my_keys

for skjemabruker - fil
eller

AuthorizedKeysFile / etc / ssh / authorized_keys

for et skjema med en delt fil. Som standard ser SSH-klienten etter nøkler i filen ~ / .ssh / authorized_keys.

Mer om sikkerhet

Tilleggsinnstillinger

Brukere og grupper.

Hvis du har mange brukere på serveren, og du vil tillate tilgang via ssh til bare noen få av dem, kan du bruke DenyUsers, AllowUsers, DenyGroups og AllowGroups-direktivene. For flere detaljer om disse direktivene, se kommentarene i sshd_config-eksemplet.

Alternativer for tilkoblingstilstand

Som standard, av metodene for å bestemme tilstanden til tilkoblingen, er bare metoden for å sjekke TCP-tilkoblingen inkludert - TCPKeepAlive, men sshd er i stand til å bestemme tilstanden til tilkoblingen på mer praktiske og sikre måter. For detaljer, se den relaterte delen i sshd_config-eksemplet.

Opptreden. MaxStartups

Port forwarding

X11 omdirigering

På serveren setter du parameteren i filen / etc / ssh / sshd_config (aktivert som standard):

ForwardX11 ja

På klienten setter du parameterne i filen / etc / ssh / ssh_config (deaktivert som standard):

ForwardAgent ja ForwardX11 ja

Du kan kjøre på klienten som denne ssh [e-postbeskyttet] firefox. Eller gå til ssh først [e-postbeskyttet] kjør deretter, for eksempel sudo synaptic.

SFTP

Sshd har en SFTP-server innebygd som standard. SFTP (SSH File Transfer Protocol) er en SSH-filoverføringsprotokoll. Den er designet for å kopiere og utføre andre filoperasjoner over en pålitelig og sikker tilkobling. Vanligvis brukes SSH2-protokollen som den underliggende tilkoblingsprotokollen. For å aktivere SFTP-støtte, legg til linjen til sshd_config

Undersystem sftp / usr / lib / openssh / sftp-server

Som standard er SFTP-støtte aktivert.

Ved å bruke kriterier. Match direktiv

Sette opp en SSH-klient

Den sikreste påloggingen er med nøkkel, og i de fleste tilfeller er denne funksjonen aktivert på serversiden, så det kreves ingen superbrukerrettigheter for å bruke den. Generer en nøkkel på klientmaskinen:

ssh-keygen -t rsa

Vi får tilbud om å legge inn et passord for å beskytte nøkkelfilen (det viser seg å være nyttig når filen kommer i feil hender). Hvis vi skal kjøre skript via SSH, lar vi det stå tomt. Vi overfører den offentlige nøkkelen til serveren med kommandoen

Ssh-copy-id -i ~ / .ssh / id_rsa.pub [e-postbeskyttet] server

Alt, du kan gå.

Når ssh kjører på en ikke-standard port:

Ssh-copy-id -i ~ / .ssh / id_rsa.pub "-p port [e-postbeskyttet]"

Hvis det oppstår en feil: Dårlig port "umask 077; test -d .ssh || mkdir .ssh; cat >> .ssh / authorized_keys"

prøv å ta parametere i anførselstegn:

Ssh-kopi-id "-i /home/user/.ssh/id_rsa.pub" -p port [e-postbeskyttet]""

Det er praktisk å bruke skjermverktøyet når du kobler til et eksternt system.

Sette opp en ekstern ssh-katalog i Nautilus

Montering av en ekstern katalog ved hjelp av sshfs

Monter ekstern katalog til lokal katalog

sshfs [e-postbeskyttet] hostingserver.ru:/ home / userdir ~ / sshfsdir

Avmontering

Fusermount -u ~ / sshsfdir

SSH-aliaser

Når du bruker flere servere med forskjellige tilgangsparametere (ikke-standard port, langt vertsnavn, pålogging annet enn lokal, etc.), er det noen ganger kjedelig å legge inn alle tilkoblingsinnstillingene på nytt hver gang. Du kan bruke aliaser for å lette dette.

Innstillinger lagres i ~ / .ssh / config for én bruker og / etc / ssh / ssh_config globalt for alle brukere.

Et eksempel på en konfigurasjon. Mange servere kan beskrives. Mer i mann ssh_config(ikke å forveksle med sshd_config)

Vertsaliasnavn # Vilkårlig vertsnavn Vertsnavn 1.2.3.4 # Du kan spesifisere både IP og vertsnavn (hvis DNS fungerer) User YourUserName # Hvis brukeren ikke samsvarer med den lokale brukeren Port YourSSHPort # Hvis en ikke-standard port

Etter det kan du koble til serveren med kommandoen

ssh AliasName

ssh-agent

Diagnostisere tilkoblingsproblemer

Analyse av tilkoblingsloggen:

ssh -vvv [e-postbeskyttet] vert

Analyse av klient- og serverkonfigurasjonsfiler.

Plasseringen av konfigurasjonsfilene finner du fra

Mann ssh mann sshd

Bruke smartkort

1. Oppretting av et sertifikat og eksport av en offentlig nøkkel, samt klientdelen på Windows + Putty SC, er beskrevet på nettstedet: http://habrahabr.ru/post/88540/ Key Manager-tillegget beskrevet det er kun tilgjengelig i eldre versjoner av Firefox. Testet på versjon 3.5 for Windows. Direkte lenke til tillegget: https://addons.mozilla.org/en/firefox/addon/key-manager/

2. Klargjøring av serveren. Du må sørge for at sshd-konfigurasjonen tillater autentisering ved hjelp av offentlige nøkler. For å gjøre dette, sett verdien av parameteren PubkeyAuthentication til yes i sshd_config-filen. Deretter legger du til vår offentlige nøkkel hentet tidligere (på én linje) til filen "~ / .ssh / authorized_keys". Vær oppmerksom på at filen ".ssh / authorized_keys" ligger i hjemmekatalogen til brukeren som da vil logge på med den offentlige nøkkelen.

3. Klientdel på Linux. Du må gjenoppbygge OpenSSH-pakken uten parametere. Det anbefales kun å spesifisere katalogprefikser, for eksempel –prefix = / usr. Det bør også bemerkes at konfigurasjonsfilene vil være i / usr / etc. Før du starter trenger du følgende pakker: opensc-lite-devel, zlib-devel, openssl-devel. Installere smartkortdriveren. For enkelhets skyld, i ssh_config-konfigurasjonen (må ikke forveksles med sshd_config) spesifiser banen til pkcs-biblioteket: PKCS11Provider =<путь к библиотеке>

4. Kjør ssh på klienten [e-postbeskyttet] Hvis et smartkort (token) er tilkoblet, vil det be om et passord og logge på SSH-sesjonen.

Mulige problemer ved bruk

Den velkjente Ctrl + S-tastekombinasjonen som brukes i mange redaktører for å lagre rettelser, når du arbeider i en terminal med en ssh-server, vil føre til utførelse av XOFF-kommandoen, som ser ut som en sesjonsheng. Det er det imidlertid ikke. Serveren fortsetter å godta inndatategn og kommandoer, men viser dem ikke på skjermen. For å komme ut av denne vanskeligheten er det nok å bruke Ctrl + Q-kombinasjonen, og dermed slå på XON-modusen igjen.

Lenker

Det vil si at bruker1 kan registreres både i seg selv - i filen /home/user1/.ssh/keys) og i en annen bruker, som vil tillate ham å logge inn fra datamaskinen sin både "under seg selv" og under "annet"

abstrakt: Denne artikkelen beskriver avanserte funksjoner i OpenSSH som gjør livet mye enklere for systemadministratorer og programmerere som ikke er redde for skallet. I motsetning til de fleste manualer, som ikke beskriver noe annet enn bryterne og -L / D / R-alternativene, prøvde jeg å samle alle de interessante funksjonene og bekvemmelighetene som ssh bringer med seg.

Advarsel: innlegg veldig voluminøs, men for enkel bruk bestemte jeg meg for å ikke kutte den i biter.

Innholdsfortegnelse:

• nøkkelledelse
• kopiere filer over ssh
• Videresending av I/O-strømmer
• Monter fjernkontroll FS via ssh
• Ekstern kjøring av kode
• Aliaser og alternativer for tilkoblinger i .ssh / config
• Standardalternativer
• Videresending av X-server
• ssh som sokker-proxy
• Port Forwarding - Forover og bakover
• Omvendt Sox Proxy
• tunnelering av L2 / L3 trafikk
• Videresending av autorisasjonsagent
• Tunneler ssh over ssh gjennom en ikke-klarert server ( mest sannsynlig vet du ikke dette)

Nøkkelledelse

Teori i noen få ord: ssh kan logge på ikke med passord, men med nøkkel. Nøkkelen består av en åpen og en lukket del. Den åpne legges i hjemmekatalogen til brukeren "som" logger på serveren, den lukkede - i hjemmekatalogen til brukeren som går til den eksterne serveren. Halvdelene sammenlignes (jeg overdriver) og hvis alt er ok slipper de det. Viktig: ikke bare klienten er autorisert på serveren, men også serveren i forhold til klienten (det vil si at serveren har sin egen nøkkel). Hovedfunksjonen til nøkkelen i sammenligning med passordet er at den ikke kan "stjåles" ved å hacke serveren - nøkkelen overføres ikke fra klienten til serveren, og under autorisasjon beviser klienten overfor serveren at han eier nøkkelen (den samme kryptografiske magien).

Nøkkelgenerering

Du kan generere din egen nøkkel ved å bruke ssh-keygen-kommandoen. Hvis du ikke angir parametrene, vil den lagre alt som det skal.

Nøkkelen kan lukkes med passord. Dette passordet (i konvensjonelle grafiske grensesnitt) blir spurt én gang og lagret i en stund. Hvis passordet er tomt, vil det ikke bli spurt når du bruker det. Det er umulig å gjenopprette et glemt passord.

Du kan endre passordet for en nøkkel ved å bruke kommandoen ssh-keygen -s.

Nøkkelstruktur

(hvis spørsmålet om plasseringen ble besvart som standard).
~ / .ssh / id_rsa.pub- offentlig nøkkel. Den kopieres til serverne du trenger for å få tilgang til.
~ / .ssh / id_rsa- privat nøkkel. Det må ikke vises til noen. Hvis du kopierer og limer den inn i et brev / chat i stedet for på pub, må du generere en ny nøkkel. (Jeg tuller ikke, omtrent 10 % av personene som blir bedt om å gi ssh-nøkkelposten id_rsa, og av disse er ti prosent menn, 100 %).

Kopierer nøkkelen til serveren

I katalogen til brukeren du vil logge inn under, hvis du oppretter en fil ~ / .ssh / autoriserte_nøkler og legg den offentlige nøkkelen der, så kan du logge på uten passord. Vær oppmerksom på at tillatelsene på filen ikke skal tillate uautoriserte brukere å skrive til denne filen, ellers vil ikke ssh godta den. I nøkkelen er det siste feltet [e-postbeskyttet] Det har ingenting med autorisasjon å gjøre og tjener bare for å finne ut hvor nøkkelen er. Merk at dette feltet kan endres (eller til og med slettes) uten å bryte strukturen til nøkkelen.

Hvis du kjenner brukerens passord, kan prosessen forenkles. Kommando ssh-copy-id [e-postbeskyttet] lar deg kopiere nøkkelen uten å manuelt redigere filene.

Merk: De gamle ssh-manualene nevner authorized_keys2. Grunn: det var den første versjonen av ssh, så var det den andre (nåværende), de lagde sitt eget sett med konfigurasjoner for den, alle var veldig slitne, og den andre versjonen byttet til versjoner uten noen "2" for lenge siden. Det vil si alltid autoriserte_nøkler og ikke tenke på forskjellige versjoner.

Hvis du har ssh på en ikke-standard port, krever ssh-copy-id litt lureri: ssh-copy-id "-p 443 [e-postbeskyttet]"(oppmerksomhet på sitatene).

Servernøkkel

Første gang du logger på serveren, spør ssh deg om du stoler på nøkkelen. Svarer du nei, er forbindelsen stengt. Hvis ja - nøkkelen er lagret i en fil ~ / .ssh / kjente_verter... Finn ut hvor hvilken nøkkel ikke kan være (fordi den ikke er hemmelig).

Hvis servernøkkelen har endret seg (for eksempel serveren har blitt installert på nytt), roper ssh til å forfalske en nøkkel. Vær oppmerksom på at hvis serveren ikke ble berørt, og ssh roper, bryter du deg inn på feil server (for eksempel dukket det opp en annen datamaskin med samme IP på nettverket, alle slags lokale nettverk med 192.168.1.1, hvorav det er er flere millioner i verden, spesielt lider av dette) ... Scenariet med "ond mann i midten angrep" er usannsynlig, oftere er det bare en feil med IP, men hvis "alt er bra" og nøkkelen har endret seg, er dette en grunn til å øke nivået av paranoia med en et par nivåer (og hvis du har nøkkelautorisasjon og serveren plutselig spurte om et passord - så kan paranoia slås på 100 % og passordet skal ikke skrives inn).

Du kan fjerne den kjente servernøkkelen med kommandoen ssh-keygen -R server... I dette tilfellet må du også slette IP-nøkkelen (de lagres separat): ssh-keygen -R 127.0.0.1.

Servernøkkelen er lagret i / etc / ssh / ssh_host_rsa_key og /etc/ssh/ssh_host_rsa_key.pub... De kan være:
a) kopier fra den gamle serveren til den nye.
b) generere med ssh-keygen. Du trenger ikke angi et passord (dvs. tomt). ssh-serveren kan ikke bruke nøkkelen med passordet.

Merk at hvis du kloner en server (for eksempel i virtuelle maskiner), må serverens ssh-nøkler regenereres.

Samtidig er det bedre å fjerne de gamle nøklene fra know_hosts, ellers vil ssh banne til duplicate key.

Kopierer filer

Å overføre filer til serveren kan til tider være slitsomt. Foruten å fikle med sftp og andre rare ting, gir ssh oss kommandoen scp som kopierer filen via ssh-sesjon.

Scp-bane / min fil [e-postbeskyttet]: / full / sti / til / ny / plassering /

Du kan også gjøre det motsatte:
scp [e-postbeskyttet]: / full / sti / til / fil / bane / til / putte / her

Fiskeadvarsel: Til tross for at mc kan koble til via ssh, vil kopiering av store filer være svært smertefullt. fish (mc-modulen for å jobbe med ssh som virtuell fs) er veldig treg. 100-200kb er grensen, så begynner tålmodighetsprøven. (Jeg husket min veldig tidlige ungdom, da jeg, uten å vite om scp, kopierte ~ 5 GB via fisk til mc, det tok litt mer enn 12 timer på FastEthernet).

Evnen til å kopiere er stor. Men du vil "lagre som" - og umiddelbart til serveren. Og for å kopiere i grafisk modus ikke fra et spesielt program, men fra et hvilket som helst kjent.

Dette er også mulig:

sshfs

Teori: Sikringsmodulen lar deg "eksportere" forespørsler til filsystemet fra kjernen tilbake til brukerområdet for det aktuelle programmet. Dette gjør det enkelt å implementere "pseudo-filsystemer". For eksempel kan vi gi tilgang til et eksternt filsystem via ssh slik at alle lokale applikasjoner (med noen få unntak) ikke mistenker noe.

Faktisk, unntaket: O_DIRECT støttes ikke, dessverre (dette er ikke et problem med sshfs, det er et sikringsproblem generelt).

Bruk: installer sshfs-pakken (den vil bringe selve sikringen).

Faktisk, et eksempel på skriptet mitt som monterer desunote.ru (plassert på min hjemmedatamaskin - bilder er vist fra det i denne artikkelen) til min bærbare datamaskin:

#! / bin / bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o koble til på nytt

Vi lager en fil + x, kaller den, går til hvilken som helst applikasjon, sier lagre og ser:

Sshfs-alternativer som kan være viktige: -o koble til på nytt (forteller å prøve å koble til på nytt i stedet for feil).

Hvis du jobber mye med data fra root, kan du (trenger) lage en idmap:

-o idmap = bruker... Det fungerer som følger: hvis vi kobler til som bruker [e-postbeskyttet], og lokalt jobber vi som bruker vasiliy, da sier vi "tenk på at pupkin-filer er vasiliy-filer". vel, eller "root" hvis vi kobler til som root.

I mitt tilfelle er ikke idmap nødvendig, siden brukernavnene (lokale og eksterne) er de samme.

Merk at det viser seg å fungere komfortabelt bare hvis vi har en ssh-nøkkel (se begynnelsen av artikkelen), hvis ikke, tar passordautentisering 2-3 tilkoblinger.

Du kan slå den av igjen med kommandoen fusermount -u / bane, men hvis tilkoblingen er fast (for eksempel, det er ikke noe nettverk), så kan / må du gjøre det fra under roten: sudo umount -f / path.

Ekstern kjøring av kode

ssh kan utføre en kommando på en ekstern server og umiddelbart lukke forbindelsen. Enkleste eksempel:

Ssh [e-postbeskyttet] ls / etc /

Vil sende ut innholdet av / etc / til serveren, mens vi vil ha en lokal kommandolinje.

Noen applikasjoner ønsker en kontrollterminal. De bør kjøres med -t-alternativet:
ssh [e-postbeskyttet]-t remove_command

Forresten, vi kan gjøre noe slikt:
ssh [e-postbeskyttet] cat / some / file | awk "(print $ 2)" | local_app

Dette bringer oss til følgende funksjon:

Stdin / ut videresending

La oss si at vi vil sende en forespørsel til programmet eksternt, og deretter legge utdataene i en lokal fil

Ssh [e-postbeskyttet] kommando> min_fil

La oss si at vi ønsker å plassere den lokale utgangen eksternt

Min kommando | scp - [e-postbeskyttet]: / bane / ekstern_fil

La oss komplisere eksemplet - vi kan overføre filer fra serveren til serveren: Vi lager en kjede for å sette stdin på 10.1.1.2, som ikke er tilgjengelig for oss fra utsiden:

Min kommando | ssh [e-postbeskyttet]"Scp - [e-postbeskyttet]: / bane / til / fil "

Det er også en så latterlig metode for å bruke en pipe (vennligst foreslått i kommentarene i LJ):

Tar -c * | ssh [e-postbeskyttet]"cd && tar -x"

Tar pakker filer etter maske lokalt, skriver dem til stdout, hvorfra ssh leser dem, overfører dem til stdin på den eksterne serveren, hvor cd ignorerer dem (leser ikke stdin), og tar leser og pakker dem ut. Scp er for de fattige, for å si det sånn.

Aliaser

Helt ærlig, inntil nylig visste jeg ikke og brukte ikke. Viste seg å være veldig behagelig.

I et mer eller mindre stort selskap viser det seg ofte at servernavnene ser slik ut: spb-MX-i3.extrt.int.company.net. Og brukeren der er ikke lik den lokale. Det vil si at du må logge på slik: ssh [e-postbeskyttet] Skriver hver gang – du kan ikke få nok av tunnelsyndromer. I små selskaper er problemet det motsatte - ingen tenker på DNS, og anropet til serveren ser slik ut: ssh [e-postbeskyttet] Kort sagt, men fortsatt irriterende. Enda mer dramatikk hvis vi har en ikke-standard port, og for eksempel den første versjonen av ssh (hei til cisks). Da ser alt slik ut: ssh -1 -p 334 [e-postbeskyttet] Kveler deg selv. Jeg vil ikke engang snakke om scp-dramaet.

Det er mulig å registrere systemomfattende aliaser for IP (/ etc / hosts), men dette er en skjev vei ut (og print bruker og alternativer uansett) Det er en kortere vei.

Fil ~ / .ssh / config lar deg angi tilkoblingsparametere, inkludert de som er spesifikke for servere, som er viktigst, for hver server sin egen. Her er et eksempel på konfigurasjon:

Vert ric Vertsnavn ooo-roga-i-kopyta.rf Brukeradministrator ForwardX11 ja Komprimering ja Vertshjem Vertsnavn myhome.dyndns.org Bruker vasya PassordAutentisering nei

Alle tilgjengelige alternativer for bruk kan sees i mann ssh_config(ikke å forveksle med sshd_config).

Standardalternativer

Som bedt av BRUKER: du kan spesifisere standard tilkoblingsinnstillinger ved å bruke Host *-konstruksjonen, dvs. for eksempel:

Vert * Brukerrotkomprimering ja

Det samme kan gjøres i / etc / ssh / ssh_config (må ikke forveksles med / etc / ssh / ssh d _config), men dette krever root-rettigheter og gjelder for alle brukere.

Videresending av X-server

Egentlig ødela jeg denne delen litt i eksempelkonfigurasjonen ovenfor. ForwardX11 er bare det.

Teori: Unix grafiske applikasjoner bruker vanligvis en X-server (wayland er på vei, men fortsatt ikke klar). Dette betyr at applikasjonen starter opp og kobles til X-serveren for tegning. Med andre ord, hvis du har en bar server uten gui og har en lokal x-server (som du jobber i), så kan du aktivere applikasjoner fra serveren til å tegne på skrivebordet ditt. Vanligvis er ikke det sikreste og mest trivielle å koble til en ekstern X-server. SSH forenkler denne prosessen og gjør den helt sikker. Og muligheten til å høste trafikk lar deg også klare deg med mindre trafikk (dvs. redusere kanalutnyttelsen, det vil si redusere ping (mer presist, latens), det vil si redusere etterslep).

Taster: -X - videresending av X-serveren. -Y autorisasjons videresending.

Det er lett nok å huske kombinasjonen ssh -XYC [e-postbeskyttet]
I eksemplet ovenfor (selskapsnavnene er fiktive), kobler jeg til ooo-roga-and-hooves.rf-serveren av en grunn, men for å få tilgang til Windows-serveren. Vi kjenner alle sikkerheten til Microsoft når vi jobber på nettverket, så det er ubehagelig å eksponere bare RDP på ​​utsiden. I stedet kobler vi til serveren via ssh, og kjører deretter rdesktop-kommandoen der:
ssh rik
rdesktop -k en-us 192.168.1.1 -g 1900x1200

Og mirakel, påloggingsvinduet i windows på skrivebordet vårt. Merk at den er nøye kryptert og kan ikke skilles fra vanlig ssh-trafikk.

Sokker-proxy

Når jeg befinner meg på et annet hotell (kafé, konferanse), viser den lokale wifi seg ofte å være forferdelig - stengte porter, ingen vet hvilket sikkerhetsnivå. Ja, og det er ikke så mye tillit til andres tilgangspunkter (dette er ikke paranoia, jeg så godt på hvordan passord og informasjonskapsler ble fjernet ved å bruke en banal bærbar datamaskin, distribuere 3G til alle med navnet på en kafé i nærheten (og skrive interessant ting i prosessen)).

Lukkede porter er et spesielt problem. Den jabberen vil bli lukket, deretter IMAP, så noe annet.

En vanlig VPN (pptp, l2tp, openvpn) fungerer ikke i slike situasjoner – den slipper rett og slett ikke gjennom. Det er eksperimentelt kjent at port 443 oftest er igjen, og i CONNECT-modus, det vil si at den sendes "som den er" (normal http kan fortsatt pakkes transparent på en blekksprut).

Løsningen er sokker-proxy ssh driftsmodus. Prinsippet: ssh-klienten kobles til serveren og lytter lokalt. Etter å ha mottatt forespørselen, sender den den (via en åpen tilkobling) til serveren, serveren oppretter en tilkobling i henhold til forespørselen og sender alle dataene tilbake til ssh-klienten. Og han svarer den som søkte. For å fungere må du fortelle applikasjonene "bruk sokker-proxy". Og spesifiser IP-adressen til proxyen. Når det gjelder ssh, er dette oftest localhost (på denne måten vil du ikke gi kanalen din til fremmede).

Tilkobling i sock-proxy-modus ser slik ut:
ssh -D 8080 [e-postbeskyttet]

På grunn av det faktum at andres wifi oftest ikke bare er fig, men også laggy, kan det være greit å aktivere -C-alternativet (komprimere trafikk). Det blir nesten som opera turbo (bare bildene er ikke for stramme). I ekte surfing på http trykker du omtrent 2-3 ganger (les - hvis du har en ulykke på 64kbit, så vil du åpne megabyte-sider ikke på to minutter, men på 40 sekunder. Sukkert, men det er bedre). Men viktigst av alt: ingen stjålne informasjonskapsler eller overhørte økter.

Det var ikke forgjeves jeg sa om stengte havner. Den 22. porten er stengt på nøyaktig samme måte som den "unødvendige" jabberporten. Løsningen er å henge serveren på port 443. Du bør ikke skyte med 22, noen ganger er det systemer med DPI (deep packet inspection) som din "pseudo-ssl" ikke slipper deg inn.

Slik ser konfigurasjonen min ut:

/ etc / ssh / sshd_config:
(fragment)
Port 22
Port 443

Og her er et stykke ~ / .ssh / config fra en bærbar datamaskin som beskriver vpn

Host vpn Vertsnavn desunote.ru Bruker vasya Komprimering ja DynamicForward 127.1: 8080 Port 443

(merk den "late" notasjonen localhost - 127.1, dette er en helt lovlig måte å skrive 127.0.0.1 på)

Port forwarding

Vi går videre til en ekstremt vanskelig å forstå del av SSH-funksjonaliteten, som lar deg utføre forvirrende TCP-tunneloperasjoner "fra serveren" og "til serveren".

For å forstå situasjonen vil alle eksemplene nedenfor referere til dette diagrammet:

Kommentarer: To grå nettverk. Det første nettverket ligner et typisk kontornettverk (NAT), det andre er en "gateway", det vil si en server med et hvitt og grått grensesnitt som ser inn i sitt eget private nettverk. I det følgende antar vi at "vår" bærbar PC er A, og "serveren" er B.

Oppgave: vi har en applikasjon som kjører lokalt, vi må aktivere en annen bruker (utenfor nettverket vårt) til å se på den.

Løsning: videresende den lokale porten (127.0.0.1:80) til en offentlig tilgjengelig adresse. La oss si at vår "offentlig tilgjengelige" B har okkupert den 80. porten med noe nyttig, så vi vil videresende den til en ikke-standard port (8080).

Endelig konfigurasjon: forespørsler for 8.8.8.8:8080 vil gå til den lokale verten for bærbar A.

Ssh -R 127.1: 80: 8.8.8.8: 8080 [e-postbeskyttet]

Alternativ -R tillater omdirigering fra en fjernkontroll ( R emote) serverport til din (lokale) port.
Viktig: hvis vi ønsker å bruke adressen 8.8.8.8, må vi aktivere GatewayPorts i server B-innstillingene.
Oppgave... På server "B" lytter en viss demon (for eksempel sql-server). Vår applikasjon er ikke kompatibel med serveren (forskjellig bitness, OS, evil admin, forby og pålegge grenser, etc.). Vi ønsker lokal tilgang til den eksterne lokale verten "y.

Endelig konfigurasjon: forespørsler til localhost: 3333 på "A" skal betjenes av en demon på localhost: 3128 "B".

Ssh -L 127,1: 3333: 127,1: 3128 [e-postbeskyttet]

Alternativ -L tillater lokale samtaler ( L ocal) for å sende til den eksterne serveren.

Oppgave: På server "B" lytter en bestemt tjeneste på det grå grensesnittet og vi ønsker å gi en kollega (192.168.0.3) muligheten til å se på denne applikasjonen.

Endelig konfigurasjon: forespørsler om vår grå IP-adresse (192.168.0.2) går til det grå grensesnittet til Server B.

Ssh -L 192.168.0.2:8080:10.1.1.1:80 [e-postbeskyttet]

Nestede tunneler

Tunneler kan selvfølgelig omdirigeres.

La oss komplisere oppgaven: nå vil vi vise en kollega en applikasjon som kjører på localhost på serveren med adressen 10.1.1.2 (på port 80).

Løsningen er vanskelig:
ssh -L 192.168.0.2:8080:127.1:9999 [e-postbeskyttet] ssh -L 127.1: 9999: 127.1: 80 [e-postbeskyttet]

Hva skjer? Vi ber ssh om å omdirigere lokale forespørsler fra adressen vår til lokalverten til server B, og umiddelbart etter tilkobling starter vi ssh (det vil si en ssh-klient) på server B med muligheten til å lytte på localhost og sende forespørsler til server 10.1.1.2 ( hvor klienten skal koble seg til). Port 9999 velges vilkårlig, det viktigste er at den samsvarer i det første anropet og i det andre.

Omvendt Sox Proxy

Hvis det forrige eksemplet virket enkelt og åpenbart for deg, prøv å gjette hva dette eksemplet vil gjøre:
ssh -D 8080 -R 127.1: 8080: 127.1: 8080 [e-postbeskyttet] ssh -R 127,1: 8080: 127,1: 8080 [e-postbeskyttet]

Hvis du er en sikkerhetsansvarlig som har som oppgave å forby bruk av Internett på server 10.1.1.2, kan du begynne å trekke ut håret på baken din, fordi denne kommandoen organiserer Internett-tilgang for server 10.1.1.2 gjennom en sox-proxy som kjører på datamaskin "A". Trafikken er fullstendig kryptert og kan ikke skilles fra annen SSH-trafikk. Og utgående trafikk fra datamaskinen fra 192.168.0 / 24-nettverkets synspunkt kan ikke skilles fra den normale trafikken til datamaskin A.

Tunneldrift

Hvis sikkerhetsavdelingspresten på dette tidspunktet ikke er skallet, og ssh fortsatt ikke er oppført som sikkerhetsfiende nummer én, er her den ultimate morderen for alt og alle: IP-tunneling eller til og med ethernet. I de mest radikale tilfellene tillater dette dhcp-tunneling, ekstern arp-spoofing, vekking på LAN og annen stygghet på andre nivå.

(Jeg selv, dessverre, brukte ikke dette).

Det er lett å forstå at under slike forhold er det umulig for noen DPI (deep packet inspection) å fange slike tunneler - enten er ssh tillatt (les - gjør hva du vil), eller ssh er forbudt (og du kan trygt forlate en slik selskap av idioter uten å føle den minste anger).

Videresending av autorisasjon

Hvis du tror at dette er alt, så ... ... derimot, i motsetning til forfatteren, hvis "bunn" ennå ikke er skrevet, ser leseren på forhånd at det er mange bokstaver under og det er ingen intriger.

OpenSSH lar servere brukes som et springbrett for å koble til andre servere, selv om disse serverne ikke er klarert og kan misbrukes på hvilken som helst måte de vil.

Jeg gjentar bildet:

La oss si at vi ønsker å koble til server 10.1.1.2, som er klar til å akseptere nøkkelen vår. Men vi ønsker ikke å kopiere det til 8.8.8.8, fordi det er en passasje og halvparten av personene har sudo og kan bla gjennom andres kataloger. Et kompromiss ville være å ha en "annerledes" ssh-nøkkel som autoriserer [e-postbeskyttet] på 10.1.1.2, men hvis vi ikke ønsker å la noen fra 8.8.8.8 til 10.1.1.2, så er ikke dette et alternativ (spesielt siden nøkkelen ikke bare kan brukes, men også kopieres for seg selv "for en regnværsdag ").

Ssh tilbyr muligheten til å videresende ssh-agenten (dette er en tjeneste som ber om et passord for en nøkkel). Alternativ ssh -A videresender autorisasjon til en ekstern server.

Samtalen ser slik ut:

Ssh -A [e-postbeskyttet] ssh [e-postbeskyttet]

Den eksterne ssh-klienten (på 8.8.8.8) kan bevise til 10.1.1.2 at vi er oss bare hvis vi er koblet til denne serveren og har gitt ssh-klienten tilgang til sin autorisasjonsagent (men ikke nøkkelen!).

Mesteparten av tiden fungerer det.

Men hvis serveren er virkelig dårlig, kan serverroten bruke kontakten til å etterligne når vi er tilkoblet.

Det er en enda kraftigere metode - den gjør ssh til et enkelt rør (i betydningen et "rør") som vi jobber gjennom og gjennom med en ekstern server.

Den største fordelen med denne metoden er fullstendig uavhengighet fra proxy-serveren. Han kan bruke en falsk ssh-server, logge alle bytes og alle handlinger, avskjære alle data og falske den som han vil – interaksjonen går mellom den "endelige" serveren og klienten. Hvis dataene på terminalserveren tukles med, vil ikke signaturen konvergere. Hvis dataene ikke tukles med, etableres økten i sikker modus, så det er ingenting å avskjære.

Jeg kjente ikke til denne kule settingen, så jeg gravde opp dens omdreininger.

Konfigurasjonen er knyttet til to funksjoner i ssh: -W-alternativet (gjør ssh til en "pipe") og konfigurasjonsalternativet ProxyCommand(kommandolinjealternativer, ser det ut til, nei), som sier "kjør programmet og hold deg til stdin / ut". Disse alternativene har dukket opp nylig, så centos-brukere er uaktuelt.

Det ser slik ut (tall for bildet over):

Ssh / config:
Host raep HostName 10.1.1.2 Bruker bruker2 ProxyCommand ssh -W% h:% p [e-postbeskyttet]

Vel, forbindelsen er triviell: ssh raep.

Igjen, et viktig poeng: Server 8.8.8.8 kan ikke fange opp eller forfalske trafikk, bruke en brukerautorisasjonsagent eller på annen måte endre trafikk. Nekt - ja, det kan det. Men hvis det er tillatt, vil det passere gjennom seg selv uten dekryptering eller modifikasjon. For at konfigurasjonen skal fungere, må du ha den offentlige nøkkelen din i authorized_keys som for [e-postbeskyttet] og i [e-postbeskyttet]

Selvfølgelig kan tilkoblingen utstyres med alle andre kuler - portvideresending, filkopiering, sox-proxyer, L2-tunneler, X-server-tunnelering, etc.
ssh tunneling legg til tagger