For å beskytte serveren vår mot brute-force-passord kan du bruke verktøyene sshguard eller sshit.

Arbeidsprinsipper.

sshguard og sshit fungerer på samme måte. De analyserer systemmeldinger om feil autentisering, og hvis en viss verdi er nådd, legger de inn den angripende ip-en i blokkeringsbrannmurregelen. Etter en viss tid fjernes ip fra regelen.
Følgelig kreves det en konfigurert brannmur for drift.

SSHGuard

sshguard kan jobbe med

• AIX innebygd brannmur- for IBM AIX-operativsystemer
• netfilter / iptables- for Linux-baserte operativsystemer
• Pakkefilter (PF)- for BSD-operativsystemer (Open, Free, Net, DragonFly -BSD)
• IPFirewall (IPFW)- for FreeBSD og Mac OS X
• IP-filter (IPFILTER)- for FreeBSD, NetBSD og Solaris
• tcpd "s hosts_access (/etc/hosts.allow)- bærbar på tvers av UNIX
• null- Bærbar gjør-ingenting-backend for å bruke deteksjon, men ikke forebygging

Jeg bruker PF så i notatet er det eksempler i PF.

Installerer sshguard.

FreeBSD:

Installer fra porter

Cd / usr / ports / security / sshguard-pf / && gjør installasjonen ren

Hvis du av en eller annen grunn ikke bruker porter, last ned den nyeste versjonen fra sshguard-nettstedet og kompiler manuelt

./configure --with-firewall = pf && make && make install

Debian:

Setter opp OS for at sshguard skal fungere.

Lag en fil for lagring av logger

# touch / var / log / sshguard

Debian (wheezy):

Rediger følgende linje i // etc / default / sshguard

#mcedit / etc / default / sshguard #ARGS = "- a 40 -p 420 -s 1200" ARGS = "- a 5 -p 420 -s 2400 -b 5: / etc / sshguard / svarteliste"

og start sshguard på nytt
service sshguard omstart

FreeBSD:

Vi må legge til to linjer til PF-konfigurasjonen

Bord fortsette

vi erklærer en tabell der sshguard går inn i ip-roboter.

Blokk inn raskt på $ if0 proto tcp fra

Egentlig selve blokkeringsregelen, den skal være merket helt øverst i regelblokken i PF-konfigurasjonsfilen. $ if0 grensesnittet som tilkoblinger vil bli blokkert på, for å blokkere på alle grensesnitt, erstatt med noen.
Les konfigurasjonsfilen på nytt

Auth.info; authpriv.info | exec / usr / local / sbin / sshguard

og start syslog på nytt

# / etc / rc.d / syslogd omstart

Faktisk, etter disse manipulasjonene, vil sshguard blokkere angrep med standardparametere.
Når man angriper /var/log/auth.log vi vil se noe sånt som følgende

Jun1611: 01: 40 www sshd: Ugyldig brukertest fra 61.172.251.183Jun1612: 29: 48 www sshd: Ugyldig brukertest fra85.114.130.168Jun1612: 29: 49 www sshd:Jun161.91. www sshd: Ugyldig brukertest fra85.114.130.168Jun1612: 29: 50 www sshd: Ugyldig brukertest fra85.114.130.168Jun1612: 29: 50 www sshguard: Blocking85.114.120 sekunder over 6.120 sekunder: 4 sekunder over 2 sekunder.

Konfigurere sshguard-alternativer

sshguard har en rekke parametere som vi kan overstyre
-en antall mislykkede autentiseringsforsøk hvoretter ip-en vil bli blokkert. Standard er 4.
-s hvor mange sekunder ip-en vil låses opp. Standard er 420.
-s hvor mange sekunder sshguard husker ip. Standard er 1200. For å gjøre det klarere, hvis det er ett angrep fra ip på 30 minutter, vil det aldri bli bannlyst med standardinnstillingen.
-w hvit ip, nettverk eller bane til en fil med hvite adresser. Filformatet er én linje - én oppføring, # definerer kommentarer.
-b bestemmer etter hvor mange blokkerende ip som vil bli lagt til svartelisten og banen til den. Svartelisten lastes når sshguard starter og slettes ikke automatisk.

sshguard har ikke en konfigurasjonsfil, parameterne settes når sshguard starter. I vårt tilfelle starter sshguard syslog, så la oss redigere syslog.conf slik at sshguard blokkerer ip etter 3 mislykkede forsøk på autentisering i 30 minutter, og etter 5 låser svarteliste den.

Auth.info; authpriv.info | exec / usr / local / sbin / sshguard -a 3-p 1500-b 5: /usr/local/etc/sshguard.blacklist

første gang blokkeres i 420 sekunder og slettes etter 7 minutter
andre gang med 2 * 420 y fjernes etter 14 minutter
tredje gang for 2 * 2 * 420 og slettes etter 28 minutter og så videre ...
2 ^ (N-1) * 420 N. gang.

Dritt

Sshit er henholdsvis et perl-skript, det er nødvendig at systemet har perl, samt 2 moduler

• IPC :: Kan deles
• Proc :: PID :: Fil

Sshit kan bare fungere med pf og ipfw.

Installerer shit

Sshit konfig.

Sshit har en konfigurasjonsfil /usr/local/etc/sshit.conf der du kan overstyre standardinnstillingene.

FIREWALL_TYPE = "pf"; # Hvilken brannmur bruker vi MAX_COUNT = 3; # Antall mislykkede autentiseringsforsøk hvoretter ip er blokkert WITHIN_TIME = 60; # Innen hvor mange sekunder må det angitte antallet mislykkede autentiseringer skje RESET_IP = 300; # Etter hvor mange sekunder vil ip låses opp. PFCTL_CMD = "/ sbin / pfctl"; PF_TABLE = "badhosts" # navn på tabellen der dårlig ip er angitt

Konfigurerer OS for shit.

I analogi med innstillingen for sshguard, rediger PF-konfigurasjonsfilen

Bord persist blokkering i rask på $ if0 proto tcp fra til $ if0 port ssh etikett "ssh brute"

les konfigurasjonsfilen på nytt

#pfctl -f /etc/pf.conf

Redigering av syslog.conf

Auth.info; authpriv.info | exec / usr / local / sbin / sshit

og start syslog på nytt

SSH er en sikker protokoll for overføring av data (kommandoer, filer, video osv.) mellom datamaskiner.

Som standard er den aktivert på VPS og dedikerte servere til de fleste vertsleverandører, siden den kan brukes til enkelt og trygt å administrere en ekstern maskin. Du kan forresten leie en VPS-server rimelig på Well-Web-tjenesten. Siden SSH er oppe på alle VPS, for å unngå problemer ved bruk av Secure Shell, er riktig SSH-beskyttelse nødvendig.

Deaktiver root-tilgang

Først av alt anbefales det å deaktivere muligheten til å eksternt koble til maskinen under superbruker (root)-kontoen. For å gjøre dette, må du finne filen sshd_config, som vanligvis (men ikke alltid) ligger i katalogen / etc / ssh / og åpne den.

I den må du finne PermitRootLogin-elementet og erstatte verdien med "nei", det vil si at du skal få følgende post:

PermitRootLogin-nr

Dette vil naturligvis ikke forhindre hacking, men det vil gjøre det noe vanskeligere.

For å minimere muligheten for hacking, anbefales det å bruke autorisasjon ved hjelp av nøkler i stedet for autorisasjon med pålogging og passord. Dette kan gjøres på flere måter. Dette er forresten også en god SSH-beskyttelse mot brute force.

Endre standardporten

Siden serverhacking via SSH vanligvis skjer gjennom brute-force-angrep, ville det være rasjonelt å endre standard 22. port til en annen. Dette er veldig enkelt å gjøre. Først av alt må du åpne den allerede nevnte sshd_config-filen, og legge til en linje der:

Port portnummer

Oppføringen vil for eksempel se slik ut:

Dette vil redusere antallet personer som ønsker uautorisert tilgang til serveren betydelig. Før du endrer portnummeret, må du sørge for at det ikke skader driften av andre applikasjoner. Du må også velge en port som ennå ikke er i bruk, slik at programmer ikke kommer i konflikt på grunn av den.

Begrensning av tilgang via IP

En annen beskyttelsesmetode, som praktisk talt vil redusere sannsynligheten for en uautorisert tilkobling til null, er å sette begrensninger på autorisasjon. SSH kan konfigureres på en slik måte at bare eksterne maskiner med spesifikke IP-adresser kan logge på serveren. For å gjøre dette, i sshd_config-filen, på AllowUser-linjen, legg til @ IP_number i navnet på hver bruker. For eksempel kan en post se slik ut:

Tillat brukere [e-postbeskyttet], [e-postbeskyttet]

Før du bruker denne metoden, anbefales det å forsikre deg om at det ikke vil være noen situasjoner der du kanskje trenger å logge på serveren fra en maskin hvis IP-adresse ikke er gitt av konfigurasjonen.

Sikkert passord

Og selvfølgelig bør du bruke et brute-force passord. Lange og med så mange forskjellige symboler som mulig, gjerne med krakozyabras. Dette er et must.

Et av de vanlige angrepene på SSH-tjenesten er et brute-force-angrep, der en ekstern angriper uendelig prøver å logge på med forskjellige passord. Selvfølgelig er det argumenter mot passordautentisering for SSH, og det finnes alternative autentiseringsmekanismer, eksisterende alternativer som offentlig nøkkelautentisering eller tofaktorautentisering vil oppheve et brute-forcing angrep. Uten å gå inn i en diskusjon om fordeler og ulemper ved forskjellige autentiseringsmetoder, la oss vurdere en situasjon der passordautentisering er nødvendig. Hvordan beskytter du SSH-serveren din mot brute force-angrep?

fail2ban er et velkjent rammeverk for beskyttelse mot inntrenging med åpen kildekode for Linux, det overvåker ulike systemloggfiler (f.eks. /var/log/auth.log eller / var / log / secure) og håndhever automatisk ulike beskyttelsesmetoder mot oppdagede mistenkelige handlinger. Faktisk kan fail2ban være svært nyttig for å beskytte mot brute-force-angrep på en SSH-server.

I denne opplæringen vil jeg demonstrere hvordan du installerer og konfigurerer fail2ban for å beskytte SSH-serveren mot brute-forcing angrep fra eksterne IP-adresser.

Installerer Fail2ban på Linux

For å installere fail2ban på CentOS eller RHEL, installer først EPEL-depotet, og kjør deretter følgende kommando.

For å installere fail2ban på Fedora, kjør ganske enkelt:

For å installere fail2ban på Ubuntu, Debian eller Linux Mint:

Konfigurerer Fail2ban for SSH Server

Du er nå klar til å konfigurere fail2ban for å herde SSH-serveren din. Du må redigere konfigurasjonsfilen i /etc/fail2ban/jail.conf. Konfigurasjonsfilen inneholder en "DEFAULT"-seksjon der du definerer standardparametere for alle tjenester som overvåkes, og tjenestespesifikke seksjoner der du definerer eventuelle tjenestespesifikke fengsler (f.eks. SSH, Apache, etc.) for å overskrive parametere.

I fengselsseksjonen til visse tjenester (et sted etter fengselsseksjonen) må du definere en seksjon hvor du skal konfigurere spesifikke innstillinger for SSH-fengsler. Gjeldende forbud mot IP-adresser gjøres av iptables.

Følgende eksempel er i /etc/fail2ban/jail.conf, som inneholder fengselskonfigurasjonen "ssh-iptables". Selvfølgelig kan det være andre fengsler for forskjellige applikasjoner, avhengig av dine behov.

$ sudo vi /etc/fail2ban/jail.local # mellomromseparert liste over IP-adresser, CIDR-prefikser eller DNS-vertsnavn # for å omgå sikkerhet fail2ban ignoreip = 127.0.0.1 172.31.0.0/24 10.10.0.0/264 1902.02. # antall sekunder som klienten er blokkert bantime = 86400 # antall mislykkede forsøk hvoretter blokkeringen skjer maxretry = 5 # antall sekunder som mislykkede forsøk kumulativt registreres findtime = 600 mta = sendmail aktivert = sant filter = sshd action = iptables sendmail-whois # for Debian-baserte distribusjoner logpath = /var/log/auth.log # for Red Hat-baserte distribusjoner logpath = / var / log / secure # ssh-spesifikk maksimal prøveterskel maxretry = 3

I samsvar med den gitte konfigurasjonen, vil fail2ban automatisk forby alle eksterne IP-adresser som minst 3 mislykkede forsøk ble mottatt fra i løpet av de siste 10 minuttene. Når den er utestengt, vil den fornærmende IP-en forbli blokkert i 24 timer. Dette arrangementet vil bli varslet via mail.

Etter at konfigurasjonsfilen er klar, start fail2ban-tjenesten på nytt som vist nedenfor.

På Debian, Ubuntu eller CentOS / RHEL 6:

$ sudo tjeneste fail2ban omstart

På Fedora eller CentOS / RHEL 7:

$ sudo systemctl start fail2ban på nytt

For å sjekke om fail2ban startet vellykket, kjør kommandoen fail2ban-client med argumentet "ping". Hvis fail2ban kjører normalt, bør du se et "pong"-svar.

$ sudo fail2ban-client ping Server svarte: pong

Tester Fail2ban på SSH mot brute-force-angrep

For å sjekke om fail2ban fungerer, prøv å logge på SSH-serveren med feil passord for å simulere et brute force-angrep. I mellomtiden, sjekk /var/log/fail2ban.log, som registrerer alle de interessante hendelsene som skjer i fail2ban.

$ sudo tail -f /var/log/fail2ban.log

I følge loggen ovenfor, utestengt fail2ban IP-adressen 192.168.1.8, da den oppdaget flere feil i et forsøk på å logge på SSH fra denne IP-adressen.

Sjekk Fail2ban-status og opphev blokkering av blokkerte IP-adresser

"ssh-iptables"-fengselet i fail2ban bruker iptables for å blokkere IP-adressene til overtredere, du kan enkelt sjekke forbudet ved å se på gjeldende iptables-regler som vist nedenfor.

$ sudo iptables --list -n Chain INPUT (policy ACCEPT) target prot opt ​​source destinasjon fail2ban-SSH tcp - 0.0.0.0/0 0.0.0.0/0 tcp dpt: 22 Chain FORWARD (policy ACCEPT) target prot opt ​​​​kildedestinasjon Chain OUTPUT (policy ACCEPT) target prot opt​source destination Chain fail2ban-SSH (1 referanser) target prot opt​source destinasjon DROP all - 192.168.1.8 0.0.0.0/0 RETURN all - 0.0.0.0/0 0.0.0.0/0

Hvis du vil fjerne blokkeringen av IP-adresser fra fail2ban, kan du også kjøre kommandoen iptables:

$ sudo iptables -D fail2ban-SSH -s 192.168.1.8 -j DROP

Mens du manuelt kan sjekke og administrere listen over blokkerte IP-er i fail2ban ved å bruke iptables-kommandoer, er den riktige måten å bruke kommandolinjeverktøyet ail2ban-client. Dette verktøyet lar deg administrere ikke bare "ssh-iptables"-fengselet, men også enhver annen type fail2ban-fengsel i et enhetlig kommandolinjegrensesnitt.

For å sjekke fail2ban-statusen (som vil vise deg en liste over aktive fengsler):

$ sudo fail2ban-klientstatus

For å sjekke statusen til et spesifikt fengsel (f.eks. ssh-iptables):

$ sudo fail2ban-klient status ssh-iptables

Kommandoen ovenfor vil vise en liste over forbudte IP-adresser.

Slik fjerner du blokkeringen av en spesifikk IP-adresse:

$ sudo fail2ban-client set ssh-iptables unbanip 192.168.1.8

Merk, hvis du stopper fail2ban, vil alle blokkerte IP-adresser bli opphevet. Når du starter fail2ban på nytt, vil den finne listen over støtende IP-adresser fra / var / log / secure (eller /var/log/auth.log) og bannlyse disse IP-adressene på nytt hvis forbudstiden ikke er utløpt.

Sette Fail2ban til å laste og aktivere automatisk

Etter at du har testet fail2ban, er det siste trinnet for å aktivere fail2ban å starte automatisk når serveren slås på. På Debian-baserte distribusjoner er fail2ban autostart aktivert som standard. På Red Hat-baserte distribusjoner, aktiver autostart på følgende måte.

På CentOS / RHEL 6:

$ sudo chkconfig fail2ban på

På Fedora eller CentOS / RHEL 7:

$ sudo systemctl aktiver fail2ban

Utfall

I denne opplæringen demonstrerte jeg hvordan du installerer og konfigurerer fail2ban for å sikre en SSH-server. Selv om fail2ban kan dempe et brute-force-angrep, husk at det ikke kan beskytte SSH-servere mot komplekse (distribuerte) brute-force-kampanjer der angripere omgår fail2ban ved å bruke tusenvis av bot-kontrollerte IP-adresser.

OpenSSH lar deg eksternt koble til serveren, manipulere filer og administrere systemet. I dag ønsker vi å fortelle deg om de beste metodene som vil øke sikkerheten til et system basert på OpenSSH.

Konfigurasjonsfiler

• / etc / ssh / sshd_config- OpenSSH server konfigurasjonsfil;
• / etc / ssh / ssh_config- konfigurasjonsfilen til klientdelen av OpenSSH;
• ~ / .ssh /- katalog hvor brukerens SSH-innstillinger er lagret;
• ~ / .ssh / authorized_keys eller ~ / .ssh / authorized_keys- en liste over nøkler (RSA eller DSA) som brukes til å koble til brukerkontoer;
• / etc / nologin- hvis denne filen eksisterer i systemet, vil sshd hindre alle brukere bortsett fra root fra å koble til systemet;
• /etc/hosts.allow og /etc/hosts.deny- forbudssystem (del av sikkerheten). Fungerer analogt med ACL;
• SSH-port som standard - 22

Ikke nødvendig - slå den av

Hvis serveren din ikke krever en ekstern SSH-tilkobling, sørg for å deaktivere den. Systemer som CentOS / RHEL gjør det slik:

Chkconfig sshd off yum slett openssh-server

Bruk SSH versjon 2

SSH-protokollen til den første versjonen har sikkerhetsproblemer som er lukket i den andre versjonen. Bruk derfor den andre versjonen. Sørg for at Protocol 2-alternativet er spesifisert i filen / etc / ssh / sshd_config.

Begrens SSH-tilgang

Som standard kan alle systembrukere koble seg til systemet via SSH. Vi anbefaler at du begrenser SSH-tilgang av sikkerhetshensyn. Aktiver for eksempel SSH for root, merion og nettverk:

Tillat brukere root merion-nettverk

På den annen side kan du gi tilgang til alle brukere unntatt de spesifiserte:

DenyUsers root merion-nettverk

Inaktivitetstid

Det er viktig å angi tiden en inaktiv økt vil bli avsluttet (fullført). Dette kan gjøres med følgende alternativer:

ClientAliveInterval 300 ClientAliveCountMax 0

I denne innstillingen har vi spesifisert en inaktivitetstid på 300 sekunder (5 minutter).

Om .rhosts-filer

Faktum er at denne filen inneholder en liste over verter og brukere. Hvis denne filen inneholder en kombinasjon av vert og bruker, vil denne brukeren kunne koble seg til systemet via SSH uten å be om passord. Vi anbefaler å deaktivere denne "fantastiske" funksjonen:

IgnorerRhosts ja

Ingen vertsbasert autentisering!

Såkalt Vertsbasert autentisering lar en bruker fra en bestemt vert koble seg til serveren. Deaktiver:

Vertsbasert autentiseringsnr

Direkte rotforbindelse

PermitRootLogin-nr

Lag et banner

For hver tilkobling oppretter du et banner der du kan true inntrengere som prøver å få uautorisert tilgang. Banner-parameteren er ansvarlig for å sette opp et banner.

Port 22 kun fra innsiden!

Få tilgang til port 22 i systemet kun gjennom kjeden av brannmurregler. Best av alt, la tilgang bare være fra LAN. For eksempel i Iptables du kan gi tilgang til 192.168.11.0/24:

A RH-Firewall-1-INPUT -s 192.168.11.0/24 -m tilstand --state NYTT -p tcp --dport 22 -j GODKJENNER

Hvor å lytte

Som standard lytter SSH etter tilkoblinger på alle tilgjengelige grensesnitt. Vi anbefaler at du endrer standardporten og spesifiserer IP-adressen der du vil vente på en tilkobling. For eksempel vil vi spesifisere port 962 og IP-adresse 192.168.11.24

Port 962 ListenAddress 192.168.11.24

Krypto-sterke passord

Bruk sterke passord. Det er mange verktøy på nettverket som vil generere et kryptografisk passord online, gratis og uten SMS :)

Nekt tomme passord

Det er brukere uten passord. Deres SSH-tilgang må også nektes ved å bruke alternativet:

Port 962 PermitEmptyPasswords no

Analyser logger

Sett hendelseslogging til INFO- eller DEBUG-modus - dette vil tillate deg å ha utvidet kontroll over systemet:

LogLevel INFO

Var denne artikkelen nyttig for deg?

Fortell oss hvorfor?

Vi beklager at artikkelen ikke var nyttig for deg: (Vennligst, hvis den ikke gjør det vanskelig, angi hvorfor? Vi vil være veldig takknemlige for et detaljert svar. Takk for at du hjelper oss med å bli bedre!

I denne artikkelen vil vi se på en grunnleggende metode for å beskytte SSH mot masse bruteforce-angrep. I dette tilfellet betyr et masse bruteforce-angrep ikke et målrettet brute-force-angrep på SSH-passordet ditt, men et omfattende beslag av en rekke servere, for påfølgende identifisering av de ustabile til brute-force login-passord-paring.

Hovedtrekkene i det massive bruteforce SSH-angrepet er omfattende skanning av IP-områder på åpen port 22 og bruk av ofte brukte brukernavn og passord (for eksempel root: passwd123, admin: server123, etc.).

For å se statistikk fra loggfilene over mislykkede SSH-autorisasjonsforsøk på serveren din, skriv inn kommandoen:

Cat / var / log / secure * | grep "Mislykket passord" | grep sshd | awk "(skriv ut $ 1, $ 2)" | sortere -k 1,1M -k 2n | unik -c

Dette skjermbildet gir statistikk over antall mislykkede autorisasjoner per dag. Hvis du stjeler lignende data fra deg selv, bør du iverksette tiltak for å beskytte SSH-en din mot massiv bruteforce.

1. Hvis du ikke bruk for autorisasjon, vanlige brukernavn som root, admin, administrator, bruker, etc. og bruk et komplekst passord for autorisasjon, så kan du umiddelbart gå til det andre punktet. For å endre passordet til et mer komplekst, skriv inn kommandoen:

Passwd # your_login #

hvor # your_login #- Ditt brukernavn.
Når du skriver inn et nytt passord, vises ikke passordet, markøren vil være på ett sted.

La oss gå til serveren via SSH, opprette en ny bruker og angi et passord for ham, for dette skriver vi inn kommandoene:

Adduser # newuser # passwd # newuser #

hvor # ny bruker #- Ditt nye brukernavn, ikke bruk ofte brukte brukernavn, ikke et dårlig alternativ your_nickadmin(f.eks. foxadmin, useralex, rootidler).

2. Etter det, gå gjennom SSH med et nytt brukernavn og passord. Og åpne SSH-demonkonfigurasjonen (sshd_config) med kommandoen:

Vi / etc / ssh / sshd_config

Etter det bør du se noe slikt:

Linjer som begynner med # blir kommentert ut.

Til beskytte SSH mot massiv bruteforce, fjern kommentarer og endre eller legg til følgende parametere fil:
en) havn- havnen som SSHD aksepterer og tjenester tilkoblinger. Fjern kommentarer (fjern før begynnelsen av linjen # ) og endre standarden 22 , til alle andre fra 1024 til 65536, bortsett fra reserverte porter - en liste over reserverte porter, for eksempel:

Port 2022

Å slette # og endre verdien port 22, trykk først på tastaturet Jeg, etter å ha redigert ønsket linje, trykk på tasten ESC

b) Logg innGraceTime- ventetid for brukerregistrering i systemet. Hvis brukeren ikke har hatt tid til å logge på systemet innen tiden som er tildelt i dette direktivet, avsluttes økten. La oss redusere denne verdien:

Logg innGraceTime 1m

c) PermitRootLogin- tillat bruker rot pålogging via SSH-protokoll. Endre til Nei.

PermitRootLogin-nr

d) Tillat brukere- brukernavn tillatt for pålogging via SSH-protokoll, atskilt med et mellomrom. Her, i stedet for # your_login #, spesifiserer vi det nye opprettede brukernavnet.

Tillat brukere # your_login #

e) MaxAuthTries- antall forsøk på å logge på systemet i én økt. Når maksimalt tillatt antall forsøk er nådd, avsluttes økten.

MaxAuthTries 2

Som et resultat får vi:

Port 2022 LoginGraceTime 1m PermitRootLogin no AllowUsers # your_login # MaxAuthTries 2

I denne artikkelen vil vi fullføre oppsettet SSH for å beskytte mot masse Ren styrke... Etter redigering , trykk på tastaturet : , vises en linje under og skriv deretter inn i den wq og trykk på tasten Tast inn... I dette tilfellet vil alle endringer som er gjort, lagres.

Hvis du gjorde noe galt (for eksempel slettet du noe ved et uhell), for å avslutte uten å lagre bruk i stedet for hurtigtasten wq, nøkler q!

Etter å ha fullført SSH-konfigurasjonen, start daemonen på nytt med kommandoen:

Service sshd omstart

Nå når du kobler til via SSH-protokollen, bruk den nye porten 2022 (eller den du spesifiserte i innstillingene) i stedet for standard port 22.

I den neste artikkelen om å sette opp SSH, vil jeg fortelle deg, mens vi vil forby passordautorisasjon og tillate autorisasjon kun ved å bruke den private SSH-nøkkelen, og dermed beskytte oss selv så mye som mulig mot passordgjetting.

I kontakt med