<<TableOfContents: execution failed ”] (se även loggen)>>
OpenSSH (eller Secure SHell) har blivit en de facto-standard för fjärråtkomst som ersätter telnetprotokollet. SSH har gjort protokoll som telnet överflödiga, till största delen på grund av att anslutningen är krypterad och att lösenord inte längre skickas i klartext så att alla kan se dem.
En standardinstallation av ssh är dock inte perfekt, och när man kör en ssh-server finns det några enkla steg som dramatiskt kan försvåra en installation.
Använd starka lösenord/användarnamn
En av de första sakerna du kommer att märka om du har ssh igång och är exponerad för omvärlden är att du förmodligen kommer att logga försök från hackare att gissa ditt användarnamn/lösenord. Vanligtvis kommer en hackare att söka efter port 22 (standardporten som ssh lyssnar på) för att hitta maskiner med ssh igång och sedan försöka göra en brute-force-attack mot den. Med starka lösenord på plats kommer förhoppningsvis alla attacker att loggas och uppmärksammas innan de lyckas.
Förhoppningsvis använder du redan starka lösenord, men om du inte gör det så försök att välja lösenord som innehåller:
- Minimalt 8 tecken
- Mix av stora och små bokstäver
- Mix av bokstäver och siffror
- Inte alfanumeriska tecken (t.ex. specialtecken som ! ” £ $ % ^ etc.)
Fördelarna med starka lösenord är inte specifika för ssh, utan har en inverkan på alla aspekter av systemsäkerhet. Ytterligare information om lösenord finns i CentOS-dokumentationen:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Om du absolut inte kan förhindra att dina användare väljer svaga lösenord, kan du överväga att använda slumpmässigt genererade eller svårgissade användarnamn för dina användarkonton. Om skurkarna inte kan gissa användarnamnet kan de inte heller använda brute force för lösenordet. Detta är dock fortfarande säkerhet genom oklarhet och var medveten om informationsläckage av användarnamn från saker som t.ex. e-post som skickas från användarkonton.
Disable Root Logins
SSH-serverinställningar lagras i filen /etc/ssh/sshd_config. Om du vill inaktivera rotinloggningar ska du se till att du har följande post:
# Prevent root logins:PermitRootLogin no
och starta om tjänsten sshd:
service sshd restart
Om du behöver root-åtkomst loggar du in som en vanlig användare och använder kommandot su.
Limit User Logins
SSH- inloggningar kan begränsas till endast vissa användare som behöver fjärråtkomst. Om du har många användarkonton på systemet är det vettigt att begränsa fjärråtkomst till endast de som verkligen behöver det och på så sätt begränsa effekten av att en tillfällig användare har ett svagt lösenord. Lägg till en AllowUsers-linje följt av en mellanslagsseparerad lista med användarnamn i /etc/ssh/sshd_config Till exempel:
AllowUsers alice bob
och starta om sshd-tjänsten.
Disable Protocol 1
SSH har två protokoll som den kan använda, protokoll 1 och protokoll 2. Det äldre protokoll 1 är mindre säkert och bör inaktiveras om du inte vet att du specifikt behöver det. Leta efter följande rad i filen /etc/ssh/sshd_config, kommentera upp den och ändra den enligt nedan:
# Protocol 2,1Protocol 2
och starta om sshd-tjänsten.
Använd en icke-standardiserad port
Shsh lyssnar som standard på inkommande anslutningar på port 22. För att en hackare ska kunna avgöra om ssh körs på din maskin kommer han troligen att skanna port 22 för att avgöra detta. En effektiv metod är att köra ssh på en icke-standardiserad port. Vilken oanvänd port som helst duger, även om en port över 1024 är att föredra. Många väljer 2222 som en alternativ port (eftersom den är lätt att komma ihåg), precis som 8080 ofta är känd som den alternativa HTTP-porten. Av just denna anledning är det förmodligen inte det bästa valet, eftersom alla hackare som skannar port 22 sannolikt också skannar port 2222 för säkerhets skull. Det är bättre att välja någon slumpmässig hög port som inte används för några kända tjänster. För att göra ändringen lägger du till en rad som denna i filen /etc/ssh/sshd_config:
# Run ssh on a non-standard port:Port 2345 #Change me
och starta om sshd-tjänsten. Glöm inte att sedan göra nödvändiga ändringar av portvidarebefordran i din router och eventuella tillämpliga brandväggsregler. På CentOS 7 (och högre) kan du till exempel ändra firewallds ssh-tjänst genom att göra en kopia av dess tjänstfil i /etc/firewalld/ och ändra dess portrad:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Ändra sedan portraden i /etc/firewalld/services/ssh-custom.xml så att porten är densamma som i ssh-konfigurationsfilen:
<port protocol="tcp" port="2345"/>
Slutligt tar du bort tjänsten ssh, lägger till tjänsten ssh-custom och laddar om firewalld för att ändringen ska träda i kraft:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Och på CentOS 6 lägger du till en iptable-regel för att öppna den nya ssh-porten:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Genom att stänga den gamla porten också.
På CentOS 6 och senare bör du också uppdatera selinux och märka den valda porten korrekt, annars kommer sshd att hindras från att komma åt den. Till exempel:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Då ssh inte längre lyssnar på anslutningar på standardporten måste du tala om för din klient vilken port den ska ansluta på. Om vi använder ssh-klienten från kommandoraden kan vi ange porten med hjälp av växeln -p:
$ ssh -p 2345 myserver
eller om du använder fish-protokollet i konqueror, till exempel:
fish://myserver:2345/remote/dir
Om du tycker att det låter jobbigt att behöva ange porten varje gång du ansluter, kan du helt enkelt lägga till en post som anger porten i din lokala ~/.ssh/config-fil:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
Och filen: ~/.ssh/config måste ha följande behörigheter:
$ chmod 600 ~/.ssh/config
Filtrera SSH vid brandväggen
Om du bara behöver fjärråtkomst från en IP-adress (t.ex. från jobbet till hemservern) kan du överväga att filtrera anslutningar vid brandväggen genom att antingen lägga till en brandväggsregel i routern eller i iptables för att begränsa åtkomsten till port 22 till endast den specifika IP-adressen. I iptables kan detta till exempel åstadkommas med följande typ av regel för iptables (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
eller med firwalld (CentOS 7) kan du använda rich-rules för att tillåta ssh på endast en specifik port. Källadressen kan vara en enskild adress eller en basadress med en bitmask:
SSH har också naturligt stöd för TCP-wrappers och tillgången till ssh-tjänsten kan kontrolleras på samma sätt med hjälp av hosts.allow och hosts.deny.
Om du inte kan begränsa källans IP-adresser och måste öppna ssh-porten globalt kan iptables fortfarande hjälpa till att förhindra brute-force-attacker genom att logga och blockera upprepade försök att logga in från samma IP-adress. Till exempel med iptables
Den första regeln registrerar IP-adressen för varje nytt försök att komma åt port 22 med hjälp av den senaste modulen. Den andra regeln kontrollerar om den IP-adressen har försökt ansluta fyra eller fler gånger under de senaste 60 sekunderna, och om så inte är fallet accepteras paketet. Observera att den här regeln skulle kräva en standardpolicy på DROP för inmatningskedjan.
Glöm inte att ändra porten på lämpligt sätt om du kör ssh på en icke-standardiserad port. Där det är möjligt är filtrering vid brandväggen en mycket effektiv metod för att säkra åtkomsten till en ssh-server.
För system som använder tjänsten FirewallD (CentOS 7 eller högre), använd firewall-cmd:
Det första kommandot tar bort den mer tillåtande tjänsteregeln, det andra installerar en regel som endast accepterar fyra anslutningar per minut och loggar alla anslutningar.
Använd offentliga/privata nycklar för autentisering
Användning av krypterade nycklar för autentisering ger två huvudsakliga fördelar. För det första är det bekvämt eftersom du inte längre behöver ange ett lösenord (om du inte krypterar dina nycklar med lösenordsskydd) om du använder offentliga/privata nycklar. För det andra kan du, när autentisering med offentliga/privata nyckelpar har ställts in på servern, inaktivera lösenordsautentisering helt och hållet, vilket innebär att du utan en auktoriserad nyckel inte kan få tillgång – så inga fler försök att knäcka lösenord.
Det är en relativt enkel process att skapa ett offentligt/privat nyckelpar och installera dem för användning på din ssh-server.
Skapa först ett offentligt/privat nyckelpar på den klient som du ska använda för att ansluta till servern (du måste göra detta från varje klientmaskin som du ansluter från):
$ ssh-keygen -t rsa
Om du inte vill bli ombedd om en lösenfras (som i princip är ett lösenord för att låsa upp en viss offentlig nyckel) varje gång du ansluter, tryck bara på enter när du blir ombedd om en lösenfras när du skapar nyckelparet. Det är upp till dig att bestämma om du ska lägga till lösenfrasens skyddskryptering till din nyckel när du skapar den. Om du inte skyddar din nyckel med lösenfrasskydd kommer alla som får tillgång till din lokala maskin automatiskt att ha ssh-åtkomst till fjärrservern. Dessutom har root på den lokala maskinen tillgång till dina nycklar även om man antar att om du inte kan lita på root (eller root är komprometterad) så har du riktiga problem. Att kryptera nyckeln ger ytterligare säkerhet på bekostnad av att man slipper ange ett lösenord för ssh-servern för att sedan ersättas med att ange en lösenfras för användning av nyckeln. Detta kan förenklas ytterligare genom att använda programmet ssh_agent
Sätt nu behörigheter för din privata nyckel:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Kopiera den offentliga nyckeln (id_rsa.pub) till servern och installera den i listan authorized_keys:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Notera: När du har importerat den offentliga nyckeln kan du ta bort den från servern.
och slutligen ställa in filbehörigheter på servern:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
Ovanstående behörigheter krävs om StrictModes är satt till yes i /etc/ssh/sshd_config (standard).
Säkerställ att rätt SELinux-kontexter är inställda:
$ restorecon -Rv ~/.ssh
Nu när du loggar in på servern kommer du inte att uppmanas att ange ett lösenord (om du inte angett en lösenfras när du skapade ditt nyckelpar). Som standard försöker ssh först autentisera sig med hjälp av nycklar. Om inga nycklar hittas eller om autentiseringen misslyckas kommer ssh att falla tillbaka till konventionell lösenordsautentisering.
När du har kontrollerat att du framgångsrikt kan logga in på servern med hjälp av ditt offentliga/privata nyckelpar kan du inaktivera lösenordsautentisering helt och hållet genom att lägga till följande inställning i filen /etc/ssh/sshd_config:
# Disable password authentication forcing use of keysPasswordAuthentication no
Frequently Asked Question (FAQ)
Q: CentOS använder version X av OpenSSH och den senaste versionen är version Y. Version X innehöll en allvarlig säkerhetsbrist, ska jag uppgradera?
A: Nej. Uppströmsleverantören har som policy att bakåtportera säkerhetskorrigeringar från de senaste utgåvorna till den aktuella distributionsversionen. Så länge du har de senaste uppdateringarna tillämpade för din CentOS-distribution är du helt skyddad. Se här för mer information om backporting av säkerhetspatchar:
http://www.redhat.com/advice/speaks_backport.html
Q: Hur får jag ssh att tillåta nyckelbaserad autentisering utan lösenord mellan maskiner som delar användarnas hemkataloger via NFS?
A: SElinux blockerar rotåtkomst till NFS-delade kataloger och filer som inte är läsbara för hela världen som standard och därför kan sshd inte läsa användarnas nyckelfiler i ~/.ssh. För att möjliggöra åtkomst ändrar du inställningen för use_nfs_home_dirs genom att köra följande kommando som superanvändare:
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Links
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html