Navn
sshd - OpenSSH SSH-dæmon
Synopsis
sshd -deiqtD46 -b bits -f config_file -g login_grace_time -h host_key_file -k key_gen_time -o mulighed -p Havn -u len
Beskrivelse
sshd (SSH Daemon) er daemonprogrammet for ssh (1). Sammen erstatter disse programmer rlogin og rsh, og sørge for sikker krypteret kommunikation mellem to usikre værter over et usikkert netværk. Programmerne er beregnet til at være lige så nem at installere og bruge som muligt.
sshd er dæmonen, der lytter til forbindelser fra klienter. Det startes normalt ved opstart fra / etc / rc. Det gaffler en ny dæmon for hver indgående forbindelse. De forked-dæmoner håndterer nøgleudveksling, kryptering, autentificering, kommandoudførelse og dataudveksling. Denne gennemførelse afsshd understøtter både SSH-protokol version 1 og 2 samtidigt.
SSH-protokol version 1
Hver vært har en værtsspecifik RSA-nøgle (normalt 1024 bits), som bruges til at identificere værten. Når daemonen starter, genererer den desuden en server RSA-nøgle (normalt 768 bit). Denne nøgle regenereres normalt hver time, hvis den er blevet brugt og aldrig gemt på disken.
Når en klient forbinder dæmonen reagerer med dens offentlige vært og server nøgler. Klienten sammenligner RSA-værtsnøglen mod sin egen database for at verificere, at den ikke er ændret. Klienten genererer derefter et 256-bit tilfældigt tal. Det krypterer dette tilfældige tal ved hjælp af både værtsnøglen og servernøglen og sender det krypterede nummer til serveren. Begge sider bruger derefter dette tilfældige tal som en sessionstast, som bruges til at kryptere alle yderligere meddelelser i sessionen. Resten af sessionen krypteres ved hjælp af en konventionel kryptering, i øjeblikket Blowfish eller 3DES, hvor 3DES bruges som standard. Klienten vælger krypteringsalgoritmen til at bruge fra dem, der tilbydes af serveren.
Derefter indtaster serveren og klienten en godkendelsesdialog. Klienten forsøger at autentificere sig selv ved hjælp af .hosts-godkendelse, .hosts-godkendelse kombineret med RSA-værtsautentificering, RSA-udfordring-svar-godkendelse eller adgangskodebaseret godkendelse.
Rhosts-godkendelse er normalt deaktiveret, fordi det er grundlæggende usikkert, men kan aktiveres i serverkonfigurationsfilen, hvis det ønskes. Systemets sikkerhed forbedres ikke, medmindrershdrlogind og rexecd er deaktiveret (dermed deaktiverer rlogin og rsh fuldstændigt i maskinen).
SSH Protokol Version 2
Version 2 fungerer på samme måde: Hver vært har en værtsspecifik nøgle (RSA eller DSA), der bruges til at identificere værten. Men da daemonen starter, genererer den ikke en server nøgle. Videresend sikkerhed gives via en Diffie-Hellman nøgleaftale. Denne nøgleaftale resulterer i en delt sessionsnøgle.
Resten af sessionen krypteres ved hjælp af en symmetrisk kryptering, i øjeblikket 128 bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 bit AES eller 256 bit AES. Klienten vælger krypteringsalgoritmen til at bruge fra dem, der tilbydes af serveren. Endvidere tilvejebringes sessionsintegritet gennem en krypteringsbesked-autentificeringskode (hmac-sha1 eller hmac-md5).
Protokolversion 2 indeholder en offentlig nøglebaseret bruger (PubkeyAuthentication) eller klientværts (HostbasedAuthentication) -autentificeringsmetode, konventionel adgangskodeautentificering og udfordringsresponsbaserede metoder.
Kommandoudførelse og data videresendelse
Hvis klienten bekræfter sig selv, indtastes en dialog til forberedelse af sessionen. På nuværende tidspunkt kan klienten anmode om ting som at tildele en pseudotype, videresende X11-forbindelser, videresende TCP / IP-forbindelser eller videresende godkendelsesagentforbindelsen over den sikre kanal.
Endelig anmoder klienten enten om en shell eller udførelse af en kommando. Siderne indtaster derefter sessionstilstand. I denne tilstand kan hver side sende data til enhver tid, og sådanne data videresendes til / fra shell eller kommando på serversiden og brugerterminalen på klientsiden.
Når brugerprogrammet afslutter og alle fremsendte X11 og andre forbindelser er lukket, sender serveren kommandoen udgangsstatus til klienten, og begge sider afslutter.
sshd kan konfigureres ved hjælp af kommandolinjevalg eller en konfigurationsfil. Kommandolinjemuligheder overstyrer værdier angivet i konfigurationsfilen.
sshd genlæser sin konfigurationsfil, når den modtager et hangup-signal,SIGHUP ved at udføre sig selv med navnet det blev startet som, dvs. / usr / sbin / sshd
Indstillingerne er som følger:
-b bits
Angiver antallet af bits i servernøglen Ephemeral Protocol version 1 (standard 768).
-d
Fejlretningstilstand. Serveren sender verbose fejlfejl output til systemloggen og sætter sig ikke i baggrunden. Serveren fungerer heller ikke og vil kun behandle en forbindelse. Denne indstilling er kun beregnet til debugging til serveren. Flere-d muligheder øger fejlretningsniveauet. Maksimum er 3.
-e
Når denne indstilling er angivet,sshd vil sende output til standardfejlen i stedet for systemloggen.
-f configuration_file
Angiver navnet på konfigurationsfilen. Standard er / etc / ssh / sshd_configsshdnægter at starte, hvis der ikke er nogen konfigurationsfil.
-g login_grace_time
Giver grace tid for klienter at autentificere sig selv (standard 120 sekunder). Hvis klienten ikke bekræfter brugeren inden for dette mange sekunder, afbrydes og afbrydes serveren.En værdi på nul angiver ingen grænse.
-h host_key_file
Angiver en fil, hvorfra en værtsnøgle læses. Denne mulighed skal gives, hvissshd Kør ikke som root (da de normale værtsnøglefiler normalt ikke kan læses af andre end root). Standard er / etc / ssh / ssh_host_key for protokol version 1 og / etc / ssh / ssh_host_rsa_key og / etc / ssh / ssh_host_dsa_key til protokolversion 2. Det er muligt at have flere værtsnøglefiler til de forskellige protokolversioner og værtsnøgle algoritmer.
-jeg
Angiver detsshd bliver kørt fra inetd.sshd Kør normalt ikke fra inetd, fordi det skal generere servernøglen, før det kan reagere på klienten, og det kan tage titusind sekunder. Kunderne skulle vente for længe, hvis nøglen blev regenereret hver gang. Imidlertid med små nøgleformater (fx 512) ved anvendelse afsshd fra inetd kan være muligt.
-k key_gen_time
Angiver, hvor ofte servernøglen for den ekememæssige protokolversion 1 regenereres (standard 3600 sekunder eller en time). Motiveringen til at regenerere nøglen ret ofte er, at nøglen ikke opbevares overalt, og efter ca. en time bliver det umuligt at genoprette nøglen til dekryptering af aflytede kommunikationer, selvom maskinen er revnet i eller fysisk beslaglagt. En værdi på nul indikerer, at nøglen aldrig vil blive regenereret.
-o mulighed
Kan bruges til at give valgmuligheder i det format, der bruges i konfigurationsfilen. Dette er nyttigt for at angive muligheder, for hvilke der ikke er et separat kommandolinjeflag.
-p Havn
Angiver den port, som serveren lytter til forbindelser (standard 22). Flere port muligheder er tilladt. Porte, der er angivet i konfigurationsfilen, ignoreres, når en kommandolinjeport er angivet.
-q
Stille tilstand. Intet sendes til systemloggen. Normalt logges begyndelsen, godkendelsen og opsigelsen af hver forbindelse.
-t
Test mode. Kontroller kun gyldigheden af konfigurationsfilen og fornuftigheden af tasterne. Dette er nyttigt til opdateringsshd pålideligt, da konfigurationsindstillingerne kan ændre sig.
-u len
Denne indstilling bruges til at angive størrelsen på feltet i feltetutmp struktur, der indeholder fjernværtsnavnet. Hvis det løste værtsnavn er længere end len den stiplede decimalværdi vil blive brugt i stedet. Dette gør det muligt for værter med meget lange værtsnavne, der overlader dette felt, for stadig at være unikt identificeret. Angivelse -u0 indikerer, at kun stiplede decimaler skal placeres i UTMP-filen. -u0 bruges også til at forhindresshd fra at foretage DNS-anmodninger, medmindre godkendelsesmekanismen eller konfigurationen kræver det. Autentificeringsmekanismer, der kan kræve DNS inkluderetRhostsAuthenticationRhostsRSAAuthentication HostbasedAuthentication og ved hjælp af afra = mønster-listemulighed i en nøglefil. Konfigurationsindstillinger, der kræver DNS, omfatter at bruge en USER @ HOSTpattern iAllowUsers ellerDenyUsers
-D
Når denne indstilling er angivetsshd vil ikke løsne og bliver ikke en dæmon. Dette giver nem overvågning afsshd
-4
Forcessshd at kun bruge IPv4-adresser.
-6
Forcessshd at kun bruge IPv6-adresser.
Konfigurationsfil
sshd læser konfigurationsdata fra / etc / ssh / sshd_config (eller filen specificeret med -f på kommandolinjen). Filformat og konfigurationsindstillinger er beskrevet i sshd_config5.
Login proces
Når en bruger logger ind med succes,sshd gør følgende:
- Hvis login er på en tty, og ingen kommando er angivet, udskriver sidste logintid og / etc / motd (medmindre det er forhindret i konfigurationsfilen eller ved $ HOME / .hushlogin se sektionen Sx FILES).
- Hvis login er på en tty, registreres login tid.
- Checks / etc / nologin, hvis den eksisterer, udskriver indhold og afslutter (medmindre root).
- Ændringer for at køre med normale brugerrettigheder.
- Sætter op grundlæggende miljø.
- Læs $ HOME / .ssh / miljø hvis det eksisterer og brugere får lov til at ændre deres omgivelser. SePermitUserEnvironment mulighed i sshd_config5.
- Ændringer i brugerens hjemmekatalog.
- Hvis $ HOME / .ssh / rc eksisterer, kører det; ellers hvis / etc / ssh / sshrc eksisterer, kører det; ellers kører xauth. `` Rc''filerne får X11-godkendelsesprotokollen og cookie i standardindgang.
- Kører brugerens shell eller kommando.
Authorized_Keys filformat
$ HOME / .ssh / authorized_keys er standardfilen, der viser de offentlige nøgler, der er tilladt for RSA-godkendelse i protokolversion 1 og til offentlig nøgleautentificering (PubkeyAuthentication) i protokolversion 2.AuthorizedKeysFile kan bruges til at angive en alternativ fil.
Hver linje i filen indeholder en tast (tomme linjer og linjer, der begynder med en `# ', ignoreres som kommentarer). Hver RSA-offentlig nøgle består af følgende felter, adskilt af mellemrum: indstillinger, bit, eksponent, modul, kommentar. Hver protokol version 2 offentlig nøgle består af: muligheder, keytype, base64 kodetast, kommentar. Valgfeltet er valgfrit; dets tilstedeværelse bestemmes af, om linjen starter med et tal eller ej (valgfeltet starter aldrig med et tal). Bit-, eksponent-, modul- og kommentarfelterne giver RSA-nøglen til protokolversion 1; Kommentarfeltet bruges ikke til noget (men det kan være praktisk for brugeren at identificere nøglen). For protokolversion 2 er keytypen `` ssh-dss '' eller `` ssh-rsa ''
Bemærk, at linjer i denne fil normalt er flere hundrede bytes lange (på grund af størrelsen af den offentlige nøglekode). Du vil ikke skrive dem ind; I stedet skal du kopiere identitets.pub id_dsa.pub eller id_rsa.pub-filen og redigere den.
sshd håndhæver en minimum RSA nøglemodul størrelse for protokol 1 og protokol 2 nøgler på 768 bits.
Indstillingerne (hvis de findes) består af kommaseparerede valgspecifikationer. Ingen mellemrum er tilladt, undtagen i dobbelt citater. Følgende valgspecifikationer understøttes (bemærk, at valgmulighederne er uagtige):
fra = mønster-liste
Angiver, at det kanoniske navn på den eksterne vært skal være til stede i den kommaseparerede liste med mønstre (`* 'og`?' Som jokertegn) ud over godkendelse af offentlig nøgle. Listen kan også indeholde mønstre negeret ved at prefixe dem med `! ' ; Hvis det kanoniske værtsnavn matcher et negeret mønster, accepteres nøglen ikke. Formålet med denne mulighed er at øge sikkerheden muligvis: Autentificering af autentiske nøgler er ikke i sig selv på netværket eller navneservere eller noget (men nøglen); Men hvis nogen på en eller anden måde stjæler nøglen, tillader nøglen en forbryder at logge ind fra hvor som helst i verden. Denne ekstra mulighed gør det vanskeligere at bruge en stjålet nøgle (navneservere og / eller routere skal kompromitteres ud over blot nøglen).
kommando = kommando
Angiver, at kommandoen udføres, når denne nøgle bruges til godkendelse. Kommandoen leveret af brugeren (hvis nogen) ignoreres. Kommandoen køres på en PTY, hvis klienten anmoder om en PTY; ellers køres det uden en tty. Hvis en 8-bit ren kanal er påkrævet, må man ikke anmode om et certifikat eller skal angiveno-pty Et citat kan medtages i kommandoen ved at citere det med en tilbageslag. Denne mulighed kan være nyttigt at begrænse visse offentlige nøgler til at udføre en bestemt operation. Et eksempel kan være en nøgle, der tillader fjernbackups, men intet andet. Bemærk, at klienten kan angive TCP / IP og / eller X11 videresendelse, medmindre de er udtrykkeligt forbudt. Bemærk, at denne mulighed gælder for udførelse af skal, kommando eller subsystem.
miljø = NAME = værdi
Angiver, at strengen skal tilføjes til miljøet, når du logger ind med denne nøgle. Miljøvariabler indstillet på denne måde tilsidesætter andre standardmiljøværdier. Flere muligheder af denne type er tilladt. Miljøbehandling er deaktiveret som standard og styres viaPermitUserEnvironment mulighed. Denne indstilling deaktiveres automatisk, hvisUseLogin er aktiveret.
no-port-forwarding
Forbyder TCP / IP videresendelse, når denne nøgle bruges til godkendelse. Eventuelle henvendelser fra porten til klienten returnerer en fejl. Dette kan bruges, fx i forbindelse medkommando mulighed.
no-X11-videresendelse
Forbud X11 videresendelse, når denne nøgle bruges til godkendelse. Eventuelle X11-fremsendelsesanmodninger fra klienten returnerer en fejl.
no-agent-videresendelse
Forbudsautentificering agent fremsendelse, når denne nøgle bruges til godkendelse.
no-pty
Forhindrer tty-tildeling (en anmodning om at tildele en PTY vil mislykkes).
permitopen = host: port
Begræns lokalt`` ssh -L '' port viderestilling, så den kun kan forbinde til den angivne vært og port. IPv6-adresser kan angives med en alternativ syntaks: host / port Mange permitopen valgmuligheder kan anvendes adskilt med kommaer. Ingen mønster matching udføres på de angivne værtsnavne, de skal være bogstavelige domæner eller adresser.
eksempler
1024 33 12121 … 312314325 [email protected]
fra = "*. niksula.hut.fi,! pc.niksula.hut.fi" 1024 35 23 … 2334 ylo @ niksula
command = "dump / home", no-pty, no-port-forwarding 1024 33 23 … 2323 backup.hut.fi
permitopen = "10.2.1.55:80", permitopen = "10.2.1.56:25" 1024 33 23 … 2323
Ssh_Known_Hosts Filformat
/ Etc / ssh / ssh_known_hosts og $ HOME / .ssh / known_hosts-filer indeholder værts offentlige nøgler til alle kendte værter. Den globale fil skal udarbejdes af administratoren (valgfri), og brugerfilen opretholdes automatisk: Når brugeren forbinder fra en ukendt vært, tilføjes nøglen til hver brugerfil.
Hver linje i disse filer indeholder følgende felter: værtsnavne, bits, eksponent, modul, kommentar. Feltene er adskilt af mellemrum.
Hostnavne er en kommasepareret liste over mønstre ('*' og '?' Fungerer som jokertegn); hvert mønster er igen tilpasset det kanoniske værtsnavn (ved godkendelse af en klient) eller mod det brugerleverede navn (når en server godkendes). Et mønster kan også foregå med `! ' for at angive negation: Hvis værtsnavnet matcher et negeret mønster, accepteres det ikke (ved den linje), selvom det matcher et andet mønster på linjen.
Bits, exponent og modul er taget direkte fra RSA værtsnøglen; de kan f.eks. fås fra /etc/ssh/ssh_host_key.pub Det valgfrie kommentarfelt fortsætter til slutningen af linjen og bruges ikke.
Linjer startende med `# 'og tomme linjer ignoreres som kommentarer.
Ved udførelse af værtsautentificering accepteres godkendelse, hvis en matchende linje har den rigtige nøgle. Det er således tilladt (men ikke anbefalet) at have flere linjer eller forskellige værtsnøgler til de samme navne. Dette vil uundgåeligt ske, når korte former for værtsnavne fra forskellige domæner sættes i filen. Det er muligt, at filerne indeholder modstridende oplysninger; Autentificering accepteres, hvis der findes gyldige oplysninger fra hver enkelt fil.
Bemærk, at linjerne i disse filer typisk er hundredvis af tegn lange, og du vil helt sikkert ikke indtaste værtsnøglerne manuelt. Fremstil dem snarere ved et script eller ved at tage /etc/ssh/ssh_host_key.pub og tilføje værtsnavne på forsiden.
eksempler
closenet, …, 130.233.208.41 1024 37 159 … 93 closenet.hut.fi cvs.openbsd.org, 199.185.137.3 ssh-rsa AAAA1234 ….. =
Se også
scp (1), sftp (1), ssh (1), ssh-add1, ssh-agent1, ssh-keygen1, login.conf5, moduli (5), sshd_config5, sftp-server8
T. Ylonen T. Kivinen M. Saarinen T. Rinne S. Lehtinen "SSH Protocol Architecture" udkast-ietf-secsh-arkitektur-12.txt januar 2002 arbejder i gang materiale
M. Friedl N. Provos W. A. Simpson "Diffie-Hellman Group Exchange for SSH Transport Layer Protocol" draft-ietf-secsh-dh-group-exchange-02.txt januar 2002 arbejder i gang materiale
Vigtig: Brug mand kommando ( % mand ) for at se, hvordan en kommando bruges på din computer.
