God praksis med OpenSSH

OpenSSH (Åpne Secure Shell) er et sett med applikasjoner som tillater kryptert kommunikasjon over et nettverk, ved hjelp av protokollen SSH. Det ble opprettet som et gratis og åpent alternativ til programmet Secure Shell, som er proprietær programvare. « Wikipedia.

Noen brukere kan tro at god praksis bare skal brukes på servere, og dette er ikke tilfelle. Mange GNU / Linux-distribusjoner inkluderer OpenSSH som standard, og det er noen få ting å huske på.

Sikkerhet

Dette er de 6 viktigste punktene du må huske på når du konfigurerer SSH:

  1. Bruk et sterkt passord.
  2. Endre standardporten til SSH.
  3. Bruk alltid versjon 2 av SSH-protokollen.
  4. Deaktiver rottilgang.
  5. Begrens brukertilgang.
  6. Bruk nøkkelautentisering.
  7. Andre alternativer

Et sterkt passord

Et godt passord er et som inneholder alfanumeriske eller spesialtegn, mellomrom, store og små bokstaver... osv. Her inne DesdeLinux Vi har vist flere metoder for å generere gode passord. Kan besøke denne artikkelen y denne andre.

Endre standardporten

Standardporten for SSH er 22. For å endre den, alt vi trenger å gjøre er å redigere filen / Etc / ssh / sshd_config. Vi ser etter linjen som sier:

#Port 22

vi kommenterer det og endrer 22 for et annet nummer .. for eksempel:

Port 7022

For å kjenne portene vi ikke bruker på datamaskinen / serveren vår, kan vi utføre i terminalen:

$ netstat -ntap

Nå for å få tilgang til datamaskinen eller serveren, må vi gjøre det med alternativet -p som følger:

$ ssh -p 7022 usuario@servidor

Bruk protokoll 2

For å være sikker på at vi bruker versjon 2 av SSH-protokollen, må vi redigere filen / Etc / ssh / sshd_config og se etter linjen som sier:

# Protokoll 2

Vi kommenterer det og starter SSH-tjenesten på nytt.

Ikke tillat tilgang som root

For å forhindre at rotbrukeren får tilgang til eksternt via SSH, ser vi i filen/ Etc / ssh / sshd_config køen:

#PermitRootLogin no

og vi kommenterer det. Jeg synes det er verdt å avklare at før vi gjør dette, må vi sørge for at brukeren vår har de nødvendige tillatelsene til å utføre administrative oppgaver.

Begrens brukernes tilgang

Det gjør heller ikke vondt å tillate tilgang via SSH bare til visse pålitelige brukere, så vi går tilbake til filen / Etc / ssh / sshd_config og vi legger til linjen:

TillatBrukere elav usemoslinux kzkggaara

Der det åpenbart er brukerne elav, usemoslinux og kzkggaara de som vil kunne få tilgang.

Bruk nøkkelautentisering

Selv om denne metoden er den mest anbefalte, må vi være spesielt forsiktige fordi vi får tilgang til serveren uten å skrive inn passordet. Dette betyr at hvis en bruker klarer å gå inn i økten vår eller datamaskinen vår blir stjålet, kan vi være i trøbbel. La oss imidlertid se hvordan du gjør det.

Det første er å lage et par nøkler (offentlig og privat):

ssh-keygen -t rsa -b 4096

Deretter sender vi nøkkelen til datamaskinen / serveren:

ssh-copy-id -i ~/.ssh/id_rsa.pub elav@200.8.200.7

Endelig må vi ha ikke kommentert, i filen / Etc / ssh / sshd_config køen:

AuthorizedKeysFile .ssh/authorized_keys

Andre alternativer

Yukiterus bidrag

Vi kan redusere ventetiden der en bruker kan logge seg på systemet til 30 sekunder

LoginGraceTime 30

For å unngå ssh-angrep gjennom TCP Spoofing, og la krypteringen være i live på ssh-siden i maksimalt 3 minutter, kan vi aktivere disse 3 alternativene.

TCPKeepAlive no ClientAliveInterval 60 ClientAliveCountMax 3

Deaktiver bruken av rhosts eller shosts-filer, som av sikkerhetsmessige årsaker oppfordres til ikke å brukes.

IgnorerRosts ja IgnorererBrukerKjentHosts yes RhostsAuthentication no RhostsRSAAuthentication no

Kontroller de effektive tillatelsene til brukeren under pålogging.

StrictModes yes

Aktiver separasjon av privilegier.

UsePrivilegeSeparation yes

konklusjoner:

Ved å gjøre disse trinnene kan vi legge til ekstra sikkerhet på datamaskiner og servere, men vi må aldri glemme at det er en viktig faktor: hva er mellom stolen og tastaturet. Derfor anbefaler jeg å lese denne artikkelen.

Fuente: HowToForge


Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.

  1.   yukiteru sa

    Utmerket innlegg @elav og jeg legger til noen interessante ting:

    Logg innGraceTime 30

    Dette lar oss redusere ventetiden der en bruker kan logge seg på systemet til 30 sekunder

    TCPKeepLive nr
    ClientAlive Interval 60
    ClientAliveCountMax 3

    Disse tre alternativene er ganske nyttige for å unngå ssh-angrep ved hjelp av TCP Spoofing, slik at den krypterte er i live på ssh-siden aktiv i maksimalt 3 minutter.

    IgnorerReiser ja
    IgnoreUserKnownHosts ja
    RhostsGodkjenning nr
    RhostsRSA Godkjenningsnr

    Det deaktiverer bruken av rhosts eller shosts-filer, som av sikkerhetsmessige årsaker oppfordres til ikke å bli brukt.

    StrictModes ja

    Dette alternativet brukes til å kontrollere de effektive tillatelsene til brukeren under pålogging.

    UsePrivilegeSeparation ja

    Aktiver separasjon av privilegier.

    1.    livlig sa

      Vel, om en stund redigerer jeg innlegget og legger det til innlegget 😀

  2.   Eugenio sa

    Det er overflødig å ikke kommentere for å ikke endre linjen. De kommenterte linjene viser standardverdien for hvert alternativ (les avklaringen i begynnelsen av selve filen). Rottilgang er deaktivert som standard osv. Derfor har det ingen effekt å fjerne merking av det.

    1.    livlig sa

      # Strategien som brukes for alternativer i standard sshd_config leveres med
      # OpenSSH er å spesifisere alternativer med standardverdien der
      # mulig, men la dem kommenteres. Ukommenterte alternativer overstyrer
      # standardverdi.

      Ja, men for eksempel, hvordan vet vi at vi bare bruker versjon 2 av protokollen? Fordi vi godt kunne bruke 1 og 2 samtidig. Som den siste linjen sier, overskriver du for eksempel dette alternativet hvis du ikke kommenterer dette alternativet. Hvis vi bruker versjon 2 som standard, fin, hvis ikke, bruker vi den JA eller JA 😀

      Takk for kommentaren

  3.   Sli sa

    Veldig god artikkel, jeg visste flere ting, men en ting som aldri er klart for meg er bruk av nøkler, egentlig hva er de og hvilke fordeler har den, hvis jeg bruker nøkler, kan jeg bruke passord ?? Hvis ja, hvorfor øker det sikkerheten, og hvis ikke, hvordan får jeg tilgang til den fra en annen PC?

  4.   Ha det sa

    Hilsen, jeg har installert debian 8.1 og jeg kan ikke koble fra Windows-PCen min til Debian med WINSCP. Må jeg bruke protokoll 1? noe hjelp .. takk
    Ha det

  5.   franksanabria sa

    Du kan være interessert i denne videoen om openssh https://m.youtube.com/watch?v=uyMb8uq6L54

  6.   flis sa

    Jeg vil prøve noen ting her, flere har jeg allerede prøvd takket være Arch Wiki, andre på grunn av latskap eller manglende kunnskap. Jeg lagrer det når jeg starter RPi