<<TableOfContents: execution failed “] (se også loggen)>>
OpenSSH (eller Secure SHell) er blevet en de facto-standard for fjernadgang, der erstatter telnet-protokollen. SSH har gjort protokoller som telnet overflødige, hvilket for størstedelens vedkommende skyldes, at forbindelsen er krypteret, og at adgangskoder ikke længere sendes i klartekst, så alle kan se dem.
En standardinstallation af ssh er imidlertid ikke perfekt, og når man kører en ssh-server, er der et par enkle trin, der kan hærde en installation dramatisk.
En af de første ting, du vil bemærke, hvis du har ssh kørende og eksponeret for omverdenen, er, at du sandsynligvis vil logge forsøg fra hackere på at gætte dit brugernavn/adgangskode. Typisk vil en hacker scanne efter port 22 (standardporten, som ssh lytter på) for at finde maskiner med ssh kørende, og derefter forsøge et brute-force-angreb mod den. Med stærke adgangskoder på plads vil ethvert angreb forhåbentlig blive logget og bemærket, før det kan lykkes.
Håber du allerede bruger stærke adgangskoder, men hvis du ikke gør det, så prøv at vælge adgangskoder, der indeholder:
- Minimum 8 tegn
- Mix af store og små bogstaver
- Mix af bogstaver og tal
- Ingen alfanumeriske tegn (f.eks. specialtegn som ! ” £ $ % ^ osv.)
Fordelene ved stærke adgangskoder er ikke specifikke for ssh, men har en indvirkning på alle aspekter af systemsikkerheden. Yderligere oplysninger om adgangskoder kan findes i CentOS-dokumentationen:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Hvis du absolut ikke kan forhindre dine brugere i at vælge svage adgangskoder, så overvej at bruge tilfældigt genererede eller svært gættelige brugernavne til dine brugerkonti. Hvis skurkene ikke kan gætte brugernavnet, kan de heller ikke bruge brute force-passwordet. Dette er dog stadig sikkerhed gennem uklarhed, og vær opmærksom på informationslækage af brugernavne fra ting som f.eks. e-mail, der sendes fra brugerkonti.
Disable Root Logins
SSH-serverindstillingerne er gemt i filen /etc/ssh/sshd_config. Hvis du vil deaktivere root-logins, skal du sikre dig, at du har følgende post:
# Prevent root logins:PermitRootLogin no
og genstart sshd-tjenesten:
service sshd restart
Hvis du har brug for root-adgang, skal du logge ind som en normal bruger og bruge kommandoen su.
Begræns brugerlogins
SSH-logins kan begrænses til kun at omfatte visse brugere, der har brug for fjernadgang. Hvis du har mange brugerkonti på systemet, giver det mening at begrænse fjernadgang til kun dem, der virkelig har brug for det, hvilket begrænser virkningen af, at en tilfældig bruger har en svag adgangskode. Tilføj en AllowUsers-linje efterfulgt af en liste af brugernavne adskilt af mellemrum til /etc/ssh/sshd_config For eksempel:
AllowUsers alice bob
og genstart sshd-tjenesten.
Disable Protocol 1
SSH har to protokoller, den kan bruge, nemlig protokol 1 og protokol 2. Den ældre protokol 1 er mindre sikker og bør deaktiveres, medmindre du ved, at du specifikt har brug for den. Kig efter følgende linje i filen /etc/ssh/sshd_config, udkommenter den og ændr den som vist:
# Protocol 2,1Protocol 2
og genstart sshd-tjenesten.
Brug en ikke-standardiseret port
Som standard lytter ssh efter indgående forbindelser på port 22. For at en hacker kan konstatere, at ssh kører på din maskine, vil han højst sandsynligt scanne port 22 for at konstatere dette. En effektiv metode er at køre ssh på en ikke-standardiseret port. Enhver ubrugt port kan bruges, selv om en port over 1024 er at foretrække. Mange mennesker vælger 2222 som en alternativ port (da den er nem at huske), ligesom 8080 ofte er kendt som den alternative HTTP-port. Netop af denne grund er det sandsynligvis ikke det bedste valg, da enhver hacker, der scanner port 22, sandsynligvis også vil scanne port 2222 for en god ordens skyld. Det er bedre at vælge en tilfældig høj port, som ikke bruges til nogen kendte tjenester. For at foretage ændringen skal du tilføje en linje som denne til din /etc/ssh/sshd_config-fil:
# Run ssh on a non-standard port:Port 2345 #Change me
og genstart sshd-tjenesten. Glem ikke derefter at foretage eventuelle nødvendige ændringer af port forwarding i din router og eventuelle gældende firewallregler. På CentOS 7 (og højere) kan du f.eks. på CentOS 7 (og højere) ændre firewalld’s ssh-tjeneste ved at lave en kopi af dens tjenestefil i /etc/firewalld/ og ændre dens portlinje:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Ændrer derefter portlinjen i /etc/firewalld/services/ssh-custom.xml, så porten er den samme som i ssh-konfigurationsfilen:
<port protocol="tcp" port="2345"/>
Sidst skal du fjerne ssh-tjenesten, tilføje ssh-custom-tjenesten og genindlæse firewalld, for at ændringen kan træde i kraft:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Og på CentOS 6 skal du tilføje en iptable-regel for at åbne den nye ssh-port:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Glem ikke at lukke den gamle port også.
På CentOS 6 og derover bør du også opdatere selinux, der mærker den valgte port korrekt, ellers vil sshd blive forhindret i at få adgang til den. F.eks:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Da ssh ikke længere lytter efter forbindelser på standardporten, skal du fortælle din klient, hvilken port den skal forbinde på. Hvis vi bruger ssh-klienten fra kommandolinjen, kan vi angive porten ved hjælp af -p-switchen:
$ ssh -p 2345 myserver
eller hvis du bruger fish-protokollen i konqueror, f.eks:
fish://myserver:2345/remote/dir
Hvis du tænker, at dette lyder som en plage at skulle angive porten hver gang du opretter forbindelse, skal du blot tilføje en post, der angiver porten i din lokale ~/.ssh/config-fil:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
Og filen: ~/.ssh/config skal have følgende tilladelser:
$ chmod 600 ~/.ssh/config
Filtrer SSH ved firewallen
Hvis du kun har brug for fjernadgang fra én IP-adresse (f.eks. fra arbejdet til din hjemmeserver), skal du overveje at filtrere forbindelser ved din firewall ved enten at tilføje en firewallregel på din router eller i iptables for at begrænse adgangen til port 22 til kun at omfatte den specifikke IP-adresse. I iptables kan dette f.eks. opnås med følgende type regel for iptables (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
eller ved hjælp af firwalld (CentOS 7) kan du bruge rich-rules til kun at tillade ssh på en bestemt port. Kildeadressen kan være en enkelt adresse eller en basisadresse med en bitmaske:
SSH understøtter også indbygget TCP-wrappere, og adgangen til ssh-tjenesten kan styres på samme måde ved hjælp af hosts.allow og hosts.deny.
Hvis du ikke er i stand til at begrænse kilde-IP-adresser og skal åbne ssh-porten globalt, kan iptables stadig hjælpe med at forhindre brute-force-angreb ved at logge og blokere gentagne forsøg på at logge ind fra den samme IP-adresse. For eksempel med iptables
Den første regel registrerer IP-adressen for hvert nyt forsøg på at få adgang til port 22 ved hjælp af det seneste modul. Den anden regel kontrollerer, om den pågældende IP-adresse har forsøgt at oprette forbindelse 4 eller flere gange inden for de sidste 60 sekunder, og hvis ikke, accepteres pakken. Bemærk, at denne regel vil kræve en standardpolitik på DROP på inputkæden.
Glem ikke at ændre porten efter behov, hvis du kører ssh på en ikke-standardiseret port. Hvor det er muligt, er filtrering ved firewallen en yderst effektiv metode til sikring af adgangen til en ssh-server.
For systemer, der bruger FirewallD-tjenesten (CentOS 7 eller højere), skal du bruge firewall-cmd:
Den første kommando fjerner den mere lempelige serviceregle, den anden indsætter en regel, der kun accepterer 4 forbindelser i et minut og logger alle forbindelser.
Brug offentlige/private nøgler til autentificering
Brug af krypterede nøgler til autentificering giver to hovedfordele. For det første er det praktisk, da du ikke længere behøver at indtaste en adgangskode (medmindre du krypterer dine nøgler med adgangskodebeskyttelse), hvis du bruger offentlige/private nøgler. For det andet kan du, når der er oprettet offentlig/privat nøglepar-godkendelse på serveren, helt deaktivere adgangskode-godkendelse, hvilket betyder, at du uden en autoriseret nøgle ikke kan få adgang – så ikke flere forsøg på at knække adgangskoder.
Det er en forholdsvis enkel proces at oprette et offentligt/privat nøglepar og installere dem til brug på din ssh-server.
Først skal du oprette et offentligt/privat nøglepar på den klient, som du vil bruge til at oprette forbindelse til serveren (du skal gøre dette fra hver klientmaskine, hvorfra du opretter forbindelse):
$ ssh-keygen -t rsa
Hvis du ikke ønsker at blive bedt om en passphrase (som grundlæggende er en adgangskode til at låse en given offentlig nøgle op), hver gang du opretter forbindelse, skal du blot trykke på enter, når du bliver bedt om en passphrase, når du opretter nøgleparret. Det er op til dig at beslutte, om du skal tilføje passphrase-beskyttelseskrypteringen til din nøgle, når du opretter den. Hvis du ikke beskytter din nøgle med en passphrase, vil enhver, der får adgang til din lokale maskine, automatisk få ssh-adgang til fjernserveren. Desuden har root på den lokale maskine adgang til dine nøgler, selv om man antager, at hvis du ikke kan stole på root (eller root er kompromitteret), så er du virkelig i problemer. Kryptering af nøglen tilføjer yderligere sikkerhed på bekostning af at fjerne behovet for at indtaste en adgangskode til ssh-serveren, som kun skal erstattes af indtastning af en passphrase for brug af nøglen. Dette kan yderligere forenkles ved at bruge programmet ssh_agent
Sæt nu tilladelser på din private nøgle:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Kopier den offentlige nøgle (id_rsa.pub) til serveren, og installer den på listen authorized_keys:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Bemærk: Når du har importeret den offentlige nøgle, kan du slette den fra serveren.
og endelig indstiller du filtilladelser på serveren:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
De ovennævnte tilladelser er påkrævet, hvis StrictModes er indstillet til yes i /etc/ssh/sshd_config (standard).
Sørg for, at de korrekte SELinux-kontekster er indstillet:
$ restorecon -Rv ~/.ssh
Nu, når du logger ind på serveren, vil du ikke blive bedt om en adgangskode (medmindre du indtastede en passphrase, da du oprettede dit nøglepar). Som standard vil ssh først forsøge at autentificere ved hjælp af nøgler. Hvis der ikke findes nogen nøgler, eller hvis godkendelsen mislykkes, vil ssh falde tilbage til konventionel adgangskodegodkendelse.
Når du har kontrolleret, at du kan logge ind på serveren med succes ved hjælp af dit offentlige/private nøglepar, kan du deaktivere adgangskodeautentifikation helt ved at tilføje følgende indstilling til din /etc/ssh/sshd_config-fil:
# Disable password authentication forcing use of keysPasswordAuthentication no
Frequently Asked Question (FAQ)
Q: CentOS bruger version X af OpenSSH, og den seneste version er version Y. Version X indeholdt en alvorlig sikkerhedsbrist, skal jeg opgradere?
A: Nej. Upstream-leverandøren har en politik om backporting af sikkerhedspatches fra de seneste udgivelser til den aktuelle distributionsversion. Så længe du har de seneste opdateringer anvendt til din CentOS-distribution, er du fuldt ud patchet. Se her for yderligere oplysninger om backporting af sikkerhedspatches:
http://www.redhat.com/advice/speaks_backport.html
Q: Hvordan får jeg ssh til at tillade adgangskodefri nøglebaseret autentificering mellem maskiner, der deler brugernes hjemmekataloger via NFS?
SA: SElinux blokerer root-adgang til NFS-delte mapper og filer, der som standard ikke kan læses af hele verden, og derfor kan sshd ikke læse brugernes nøglefiler i ~/.ssh. Hvis du vil aktivere adgangen, skal du ændre indstillingen for use_nfs_home_dirs ved at køre følgende kommando som superbruger:
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