namn
sshd - OpenSSH SSH-demonen
Synopsis
sshd -deiqtD46 -b bitar -f config_file -g login_grace_time -h host_key_file -k key_gen_time -o alternativ -p hamn -u len
Beskrivning
sshd (SSH Daemon) är daemonprogrammet för ssh (1). Tillsammans ersätter dessa program rlogin och rsh, och tillhandahålla säker krypterad kommunikation mellan två osäkra värdar över ett osäkert nätverk. Programmen är avsedda att vara lika lätta att installera och använda som möjligt.
sshd är demonen som lyssnar på anslutningar från kunder. Det startas normalt vid start från / etc / rc. Det forklar en ny demon för varje inkommande anslutning. De forked-demonerna hanterar nyckelutbyte, kryptering, autentisering, kommandotillförsel och datautbyte. Denna genomförande avsshd stöder både SSH protokoll version 1 och 2 samtidigt.
SSH-protokollversion 1
Varje värd har en värdspecifik RSA-nyckel (normalt 1024 bitar) som används för att identifiera värden. Dessutom, när demonen startar, genererar den en serverns RSA-nyckel (normalt 768 bitar). Denna nyckel regenereras normalt varje timme om den har använts och lagras aldrig på disken.
När en klient ansluter svarar demonen med sina offentliga värd- och servernycklar. Klienten jämför RSA-värdnyckeln mot sin egen databas för att verifiera att den inte har ändrats. Klienten genererar sedan ett 256-bitars slumptal. Den krypterar detta slumptal med både värdnyckeln och servernyckeln och skickar det krypterade numret till servern. Båda sidorna använder sedan detta slumptal som en sessionstangent som används för att kryptera all ytterligare kommunikation i sessionen. Resten av sessionen krypteras med en konventionell kryptering, för närvarande Blowfish eller 3DES, med 3DES som standard. Klienten väljer krypteringsalgoritmen för att använda från de som serveren erbjuder.
Därefter anger servern och klienten en autentiseringsdialog. Klienten försöker autentisera sig med hjälp av .hosts-autentisering, .hosts-autentisering kombinerad med RSA-värdautentisering, RSA-utmaningsreaktionsautentisering eller lösenordsbaserad autentisering.
Rhosts-autentisering är normalt inaktiverad eftersom den är grundläggande osäker, men kan aktiveras i serverkonfigurationsfilen om så önskas. Systemets säkerhet förbättras inte om intershdrlogind och rexecd är inaktiverade (sålunda inaktiverar helt rlogin och rsh i maskinen).
SSH-protokollversion 2
Version 2 fungerar på samma sätt: Varje värd har en värdspecifik nyckel (RSA eller DSA) som används för att identifiera värden. Men när demonen startar genererar den inte en servernyckel. Framåt säkerhet ges genom ett Diffie-Hellman nyckelavtal. Detta nyckelavtal resulterar i en gemensam sessionsnyckel.
Resten av sessionen krypteras med en symmetrisk chiffer, för närvarande 128 bitars AES, Blowfish, 3DES, CAST128, Arcfour, 192 bitars AES eller 256 bitars AES. Klienten väljer krypteringsalgoritmen för att använda från de som serveren erbjuder. Dessutom tillhandahålls sessionens integritet genom en krypteringsmeddelandeautentiseringskod (hmac-sha1 eller hmac-md5).
Protokollversion 2 tillhandahåller en public key-based user (PubkeyAuthentication) eller klient värd (HostbasedAuthentication) autentiseringsmetod, konventionell lösenordsverifiering och utmaningssvarbaserade metoder.
Kommandotillverkning och vidarebefordran av data
Om klienten godkänner sig själv, skrivs en dialogruta för att förbereda sessionen. Vid denna tidpunkt kan klienten begära saker som att tilldela en pseudo-tty, vidarebefordra X11-anslutningar, vidarebefordra TCP / IP-anslutningar eller vidarebefordra autentiseringsagentens anslutning via den säkra kanalen.
Slutligen begär kunden antingen ett skal eller ett exekvering av ett kommando. Sidorna anger sedan sessionsläge. I det här läget kan vardera sidan skicka data när som helst och sådan data vidarebefordras till / från skalet eller kommandot på serverns sida och användarterminalen på klientsidan.
När användarprogrammet avslutas och alla vidarebefordrade X11 och andra anslutningar har stängts skickar servern kommandostatus till klienten och båda sidorna går ut.
sshd kan konfigureras med kommandoradsalternativ eller en konfigurationsfil. Kommandoradsalternativ överväger värden som anges i konfigurationsfilen.
sshd läser om sin konfigurationsfil när den tar emot en uppkopplingssignal,SIGHUP genom att exekvera sig med namnet det startades som, dvs / usr / sbin / sshd
Alternativen är som följer:
-b bitar
Anger antalet bitar i servernivån Ephemeral Protocol Version 1 (standard 768).
-d
Debugläge. Servern skickar verbose felsökningsutdata till systemloggen och lägger inte sig i bakgrunden. Servern fungerar inte och kommer bara att bearbeta en anslutning. Det här alternativet är endast avsett för debugging för servern. Multiple -d alternativ ökar felsökningsnivån. Maximalt är 3.
-e
När det här alternativet är angivet,sshd kommer att skicka utmatningen till standardfelet istället för systemloggen.
-f konfigurationsfil
Anger namnet på konfigurationsfilen. Standardvärdet är / etc / ssh / sshd_configsshdvägrar att starta om det inte finns någon konfigurationsfil.
-g login_grace_time
Ger nådtid för klienter att autentisera sig (standard 120 sekunder). Om klienten inte godkänner användaren inom dessa många sekunder, kopplas servern bort och avslutas.Ett värde på noll anger ingen gräns.
-h host_key_file
Anger en fil från vilken en värdnyckel läses. Detta alternativ måste anges omsshd körs inte som root (eftersom de normala värdnyckelfilerna normalt inte kan läsas av någon annan än root). Standardvärdet är / etc / ssh / ssh_host_key för protokollversion 1 och / etc / ssh / ssh_host_rsa_key och / etc / ssh / ssh_host_dsa_key för protokollversion 2. Det är möjligt att ha flera värdnyckelfiler för olika protokollversioner och värdnyckel algoritmer.
-jag
Anger detsshd körs från inetd.sshd körs normalt inte från inetd eftersom det måste generera serverns nyckel innan det kan svara på klienten, och det kan ta tiotals sekunder. Kunderna måste vänta för länge om nyckeln regenererades varje gång. Emellertid med små nyckelstorlekar (t ex 512) med användning avsshd från inetd kan vara genomförbart.
-k key_gen_time
Anger hur ofta servernyckeln för ephemeral protocol version 1 regenereras (standard 3600 sekunder eller en timme). Motiven för att regenerera nyckeln ganska ofta är att nyckeln inte lagras någonstans, och efter ungefär en timme blir det omöjligt att återställa nyckeln för dekryptering av avlyssnade kommunikationer, även om maskinen är knäckt eller fysiskt beslagtagen. Ett värde på noll indikerar att nyckeln aldrig kommer att regenereras.
-o alternativ
Kan användas för att ge alternativ i det format som används i konfigurationsfilen. Detta är användbart för att ange alternativ för vilka det inte finns någon separat kommandorad flagga.
-p hamn
Anger den port som servern lyssnar på för anslutningar (standard 22). Flera portalternativ är tillåtna. Portar som anges i konfigurationsfilen ignoreras när en kommandoradsport anges.
-q
Tyst läge. Inget skickas till systemloggen. Normalt loggas början, autentisering och uppsägning av varje anslutning.
-t
Övningsläge. Kontrollera endast giltigheten för konfigurationsfilen och saniteten hos nycklarna. Detta är användbart för uppdateringsshd på ett tillförlitligt sätt eftersom konfigurationsalternativen kan förändras.
-u len
Det här alternativet används för att ange storleken på fältet iutmp struktur som rymmer fjärrvärdnamnet. Om det upplösta värdnamnet är längre än len Det prickade decimalvärdet kommer att användas istället. Detta tillåter värdar med mycket långa värdnamn som överfyller detta fält för att fortfarande vara unikt identifierade. Specificera -u0 indikerar att endast prickade decimaler ska läggas i UTMP-filen. -u0 används också för att förhindrasshd från att göra DNS-förfrågningar om inte verifieringsmekanismen eller konfigurationen kräver det. Godkännandemekanismer som kan kräva DNS inkluderarRhostsAuthenticationRhostsRSAAuthentication HostbasedAuthentication och använder afrån = mönster-listaalternativ i en nyckelfil. Konfigurationsalternativ som kräver DNS inkluderar att använda en USER @ HOSTpattern iAllowUsers ellerDenyUsers
-D
När detta alternativ är angivetsshd kommer inte att lossna och blir inte en demon. Detta möjliggör enkel övervakning avsshd
-4
kraftersshd att bara använda IPv4-adresser.
-6
kraftersshd att bara använda IPv6-adresser.
Konfigurationsfil
sshd läser konfigurationsdata från / etc / ssh / sshd_config (eller filen som anges med -f på kommandoraden). Filformatet och konfigurationsalternativen beskrivs i sshd_config5.
Inloggningsprocess
När en användare loggar in med framgång,sshd gör följande:
- Om inloggningen är på en tty, och inget kommando har angivits, skriver du senaste inloggningstid och / etc / motd (om inte förhindras i konfigurationsfilen eller genom $ HOME / .hushlogin se avsnittet Sx FILES).
- Om inloggningen är på en tty registrerar du inloggningstid.
- Kontrollerar / etc / nologin om den existerar, skriver ut innehåll och avslutar (såvida inte root).
- Ändringar att köra med normala användarbehörigheter.
- Ställer in grundläggande miljö.
- Läs $ HOME / .ssh / miljö om det finns och användare får ändra sin miljö. SePermitUserEnvironment alternativet i sshd_config5.
- Ändringar i användarens hemkatalog.
- Om $ HOME / .ssh / rc existerar, kör det; annars om / etc / ssh / sshrc existerar kör det; annars kör xauth. `` Rc '' -filerna får X11-autentiseringsprotokollet och cookien i standardinmatningen.
- Kör användarens skal eller kommando.
Authorized_Keys filformat
$ HOME / .ssh / authorized_keys är standardfilen som listar de offentliga nycklarna som är tillåtna för RSA-autentisering i protokollversion 1 och för public key authentication (PubkeyAuthentication) i protokollversion 2.AuthorizedKeysFile kan användas för att ange en alternativ fil.
Varje rad i filen innehåller en nyckel (tomma linjer och rader som börjar med en `# 'ignoreras som kommentarer). Varje RSA-offentlig nyckel består av följande fält, åtskilda av mellanslag: alternativ, bitar, exponent, modul, kommentar. Varje protokollversion 2 public key består av: alternativ, keytype, bas64 kodad nyckel, kommentar. Alternativfältet är valfritt; dess närvaro bestäms av huruvida linjen börjar med ett tal eller inte (alternativfältet börjar aldrig med ett nummer). Bitarna, exponent-, modul- och kommentarfälten ger RSA-nyckeln för protokollversion 1; Kommentarfältet används inte för något (men kan vara bekvämt för användaren att identifiera nyckeln). För protokollversion 2 är keytypen `` ssh-dss '' eller `` ssh-rsa ''
Observera att rader i den här filen vanligtvis är flera hundra bytes långa (på grund av storleken på kodningen för den allmänna nyckeln). Du vill inte skriva in dem istället kopiera identitets.pub id_dsa.pub eller id_rsa.pub-filen och redigera den.
sshd verkställer en minsta RSA-nyckelmodulstorlek för protokoll 1 och protokoll 2 nycklar på 768 bitar.
Alternativen (om de finns) består av kommaseparerade alternativspecifikationer. Inga mellanslag är tillåtna, utom i dubbla citat. Följande alternativspecifikationer stöds (observera att alternativ nyckelord är okänsliga):
från = mönster-lista
Anger att det kanoniska namnet på fjärrvärdena förutom den allmänna nyckelgodkännelsen måste finnas i den kommaseparerade listan över mönster (`* 'och`?' Som jokertecken). Listan kan också innehålla mönster negativt genom att prefixa dem med `! ' ; Om det kanoniska värdnamnet matchar ett negerat mönster accepteras nyckeln inte. Syftet med det här alternativet är att eventuellt öka säkerheten: Autentisk autentisering av sig själv litar inte på nätverket eller namnservrar eller något (men nyckeln); Men om någon på något sätt stjäl nyckeln, tillåter nyckeln en inkräktare att logga in från var som helst i världen. Det här alternativet gör det svårare att använda en stulen nyckel (namnservrar och / eller routrar måste kompromissa utöver bara nyckeln).
kommando = kommando
Anger att kommandot exekveras när denna nyckel används för autentisering. Kommandot som tillhandahålls av användaren (om någon) ignoreras. Kommandot körs på ett PTY om klienten begär ett PTY; annars körs det utan en tty. Om en 8-bitars ren kanal krävs, måste man inte begära ett material eller ska angeno-pty Ett citat kan inkluderas i kommandot genom att citera det med en backslash. Det här alternativet kan vara användbart för att begränsa vissa offentliga nycklar för att utföra en viss operation. Ett exempel kan vara en nyckel som tillåter fjärrbackup men inget annat. Observera att klienten kan ange TCP / IP och / eller X11 vidarebefordran om inte de är uttryckligen förbjudna. Observera att det här alternativet gäller utförande av skal, kommando eller delsystem.
miljö = NAME = värde
Anger att strängen ska läggas till miljön när du loggar in med den här nyckeln. Miljövariablerna ställs in på ett sätt som överväger andra standardmiljövärden. Flera alternativ av denna typ är tillåtna. Miljöbehandling är som standard inaktiverad och styrs viaPermitUserEnvironment alternativ. Det här alternativet inaktiveras automatiskt omUseLogin är aktiverad.
no-port-forwarding
Förbjuder TCP / IP vidarebefordran när den här tangenten används för autentisering. Eventuella portförfrågningar från klienten kommer att returnera ett fel. Detta kan användas, t ex i samband medkommando alternativ.
no-X11-forwarding
Förbjuder X11 vidarebefordran när den här tangenten används för autentisering. Eventuella X11-förfrågningar från kunden kommer att returnera ett fel.
no-agent-forwarding
Förbudsautentiseringsmedel vidarebefordras när denna nyckel används för autentisering.
no-pty
Förhindrar tty-fördelning (en begäran om att ange ett värde kommer att misslyckas).
permitopen = värd: port
Begränsa lokalt`` ssh -L '' port vidarebefordran så att den bara kan ansluta till den angivna värden och porten. IPv6-adresser kan anges med en alternativ syntax: värd / port Flera olika permitopen Alternativ kan appliceras separerade med kommatecken. Ingen mönster matchning utförs på de angivna värdnamnen, de måste vara bokstavliga domäner eller adresser.
exempel
1024 33 12121 … 312314325 [email protected]
från = "*. 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 och $ HOME / .ssh / known_hosts-filer innehåller värdens offentliga nycklar för alla kända värdar. Den globala filen ska utarbetas av administratören (tillval) och användarfilen bibehålls automatiskt: När användaren ansluter från en okänd värd läggs nyckeln till användarfilen.
Varje rad i dessa filer innehåller följande fält: värdnamn, bitar, exponent, modul, kommentar. Fälten är åtskilda av mellanslag.
Värdnamn är en kommaseparerad lista över mönster ('*' och '?' Fungerar som jokertecken); varje mönster matchas i sin tur mot det kanoniska värdnamnet (vid autentisering av en klient) eller mot det användarlevererade namnet (vid autentisering av en server). Ett mönster kan också föregås av `! ' för att indikera negation: om värdnamnet matchar ett negerat mönster accepteras det inte (av den raden) även om det matchade ett annat mönster på linjen.
Bit, exponent och modul tas direkt från RSA-värdnyckeln; de kan erhållas t.ex. från /etc/ssh/ssh_host_key.pub Det frivilliga kommentarfältet fortsätter till slutet av raden och används inte.
Linjer som börjar med `# 'och tomma linjer ignoreras som kommentarer.
När du utför värdautentisering accepteras autentisering om någon matchande rad har rätt nyckel. Det är således tillåtet (men inte rekommenderat) att ha flera rader eller olika värdnycklar för samma namn. Detta kommer oundvikligen att hända när korta former av värdnamn från olika domäner läggs in i filen. Det är möjligt att filerna innehåller motstridiga uppgifter. autentisering accepteras om giltig information kan hittas från endera filen.
Observera att raderna i dessa filer normalt är hundratals tecken långa och du vill definitivt inte skriva in värdnycklarna för hand. Snarare, skapa dem med ett skript eller genom att ta /etc/ssh/ssh_host_key.pub och lägga till värdnamnen på framsidan.
exempel
closenet, …, 130.233.208.41 1024 37 159 … 93 closenet.hut.fi cvs.openbsd.org, 199.185.137.3 ssh-rsa AAAA1234 ….. =
Se även
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-protokollarkitektur" utkast-ietf-secsh-arkitektur-12.txt januari 2002 arbeta pågår material
M. Friedl N. Provos W. A. Simpson "Diffie-Hellman Group Exchange för SSH Transport Layer Protocol" draft-ietf-secsh-dh-group-exchange-02.txt Januari 2002 arbetar pågår material
Viktig: Använd man kommando ( % man ) för att se hur ett kommando används på din dator.
