Secure Shell SSH Manual

Vejledning om denne storslåede protokol, der begyndte sine eventyr i 1997, og som tilbyder en lang række værktøjer, der skiller sig ud for deres sikkerhed, da den er meget omfattende, vil jeg opdele den i flere poster, der forsøger at dække det vigtigste både på klient- og serverniveau.

Hvad er Secure Shell -protokollen?Secure Shell eller SSH er en netværksprotokol, der tillader udveksling af data over en sikker kanal mellem to computere. SSH bruger krypteringsteknikker, der får de oplysninger, der rejser gennem kommunikationsmediet til at blive ulæselige, og ingen tredjemand kan opdage brugernavn og adgangskode til forbindelsen eller det, der er skrevet under hele sessionen. SSH anvender offentlig nøglekryptografi til at godkende fjerncomputeren og tillade den at godkende brugeren, hvis det er nødvendigt.

SSH bruges normalt til at starte en session på en fjernmaskine, hvor du kan udføre kommandoer, men det tillader også tunneling, vilkårlig videresendelse af TCP -porte og X11 -forbindelser; Filoverførsler kan også udføres ved hjælp af tilhørende SFTP- eller SCP -protokoller.

Vi kan se, at dens store attraktion er dens karakteristik mere end nok til at fortrænge den gamle TELNET -protokol, som mangler informationskryptering, kompromitterende data, herunder adgangsoplysninger.

Det SSH server, tilbyder som standard TCP -port 22. En SSH -klient bruges generelt til at etablere forbindelser til en sshd -server, der accepterer fjernforbindelser. Begge findes normalt på de fleste moderne operativsystemer, herunder Mac, Linux, Solaris og OpenVMS.

Windows -support til dens serverversion forventes at blive officielt frigivet i år, mens den på kundeniveau tilbyder en lang række muligheder, der fremhæver PuTTY frem for de andre.

Lær at bruge Kitt

OpenSSHOpenSSH (Open Secure Shell) er et sæt applikationer, der tillader krypteret kommunikation over et netværk ved hjælp af SSH -protokollen. Det blev oprettet som et gratis og åbent alternativ til SSH -protokollen, det er det mest anvendte under Linux, og det vil være det, vi vil bruge i hele posterne.

1. Installer Secure Shell SSH

I næsten alle distributioner er klientversionen forudinstalleret, mens serverversionen er tilgængelig i depotet, installationen skal være meget enkel.

Debian, Ubuntu, Linux Mint og derivater

 sudo apt-get install openssh-server

Centos, Rhel, Fedora

 sudo yum installerer openssh-server

Arch-Linux

 pacman -Syu openssh

Vi bekræfter, at det kører med:

 curl localhost: 22

Hvis den kører korrekt, skal den vende tilbage:

[farve = # 696969] [/Farve]

Opretter forbindelse til serveren
Ved hjælp af klienten kan vi oprette forbindelse til den server, der kan være ekstern, selvom vi har begge versioner til at oprette forbindelse internt ved hjælp af localhost.

Den mest grundlæggende måde at oprette forbindelse på er:

 ssh bruger @ hostaddress

I tilfælde af forbindelse internt ville det være:

 ssh bruger @ localhost

Vi har en lang række muligheder, når du opretter forbindelse, jeg vil forklare nogle meget nyttige, du kan liste alle dine muligheder med:

 mand ssh

Her viser vi dem:

Man SSH muligheder
-CAnmod om datakomprimering, der sparer båndbredde eller data i tilfælde af at være på et mobilnetværk.

-lAngiv den bruger, som vi vil forbinde med.

-OGOpret en logfil, hvor standardfejlen afviges.

-FVi vælger en anden konfigurationsfil, der er nyttig til servere med usædvanlige muligheder.

-gPåkrævet til havntunnel.

-jegVi vælger den mappe, vi vil bruge til en alternativ privat nøgle.

-KAktiver ved brug af GSSAPI -legitimationsoplysninger.

-nVed at bruge det i forbindelse med X11 på denne måde omdirigeres al loggen, der genereres af applikationen, til / dev / null.

-ellerPåkrævet for at bruge mere avancerede muligheder, f.eks. ServerAliveInterval 30.

-sVælg en anden port end 22 for at oprette forbindelse til værten.

-vDet viser alle de trin, der er nødvendige for at etablere forbindelsen. Du kan få endnu flere oplysninger med -vv -vvv.

-XNødvendigt, hvis vi vil bruge X11 -videresendelse.

-YAktiverer sikker X11 -videresendelse.

Vi opretter forbindelse til test.solvetic.com-serveren med jcarrillo-brugeren ved hjælp af en anden privat nøgle i mappen / home / jcarrillo / keys-aws ved hjælp af port 8022 i vores instans på AWS.

 Eksempel → ssh -C -i “~ / keys -aws /” -p 8022 -l jcarrillo test.solvetic.com

Som vi kan se, er det et omfattende, men meget komplet værktøj, der fortjener flere poster for at kunne dække de nødvendige funktioner for ethvert Sysadmin på mellemliggende eller professionelt niveau.

Nu går vi videre til dens konfiguration på klient-server-niveau, genererer offentlige og private nøgler, brug af port videresendelse i virkelige situationer, omdirigering af X Server gennem X11 Forwarding, brug af scp, sftp, ssh-agent blandt andre .

2. Sikre SSH -server

Vi fortsætter med OpenSSH med fokus på sikring af vores SSH -server, for at undgå alle typer angreb, der kan kompromittere vores server. Alle disse konfigurationer udføres i sshd_config -filen i / etc / ssh /, som vi kan ændre med enhver teksteditor i mit tilfælde vim:

 sudo vim / etc / ssh / sshd_config

Nu ser vi, hvordan vi ændrer det.

Rediger sshd_config
Inde vil vi se en typisk konfigurationsfil baseret på "Valgmulighed" Hvis nogen af ​​mulighederne ikke findes som standard, skal vi placere linjen helt, i andre tilfælde vil det kun være at ændre fra 0 til 1 fra Nej til Ja eller fjerne en kommentar fra en linje.

Rediger port 22
Er vigtigt ændre standardporten til en tilfældig port mange scripts er konfigureret til at angribe denne port, anbefales det at ændre det i spænder fra 1000 til 23000 sikre, at porten ikke bruges af en anden tjeneste.

Vi bør heller ikke bruge porte som 2222, 8022 eller 1022, de er lige så almindelige som 22, og mange scripts er konfigureret til at angribe dem.

havn 2345

Hvis vi har SELINUX aktiveret, skal vi bruge en ekstra kommando for at give adgang udefra til den nye port.

Semanage port -a -t ssh_port_t -p tcp 2345 #Ændring af port 22 for sikkerhed

Brug standardprotokol 2
Vi skal sikre os, at alle vores forbindelser foretages i henhold til protokol 2, da 1 har mange sårbarheder.

Protokol 2

Tid til at indtaste legitimationsoplysninger
Søg sektion "Godkendelse". Dine to første muligheder er også vigtige. Den første er antallet af sekunder, som fjernbrugeren skal logge ind på din maskine. Indstil denne værdi til et par sekunder, det tager ikke lang tid at logge ind, hvis vi kender kontoen og adgangskoden.

På denne måde undgår vi visse scripts, der udnytter den tid. Den typiske værdi med hensyn til sikkerhed er 30, selvom den kan være endnu mindre.

LoginGraceTime 30

Deaktiver rodadgang
Dette Det er den vigtigste mulighed for at være offer for et angreb, de har brug for 3 ting:

• Bruger
• Havn
• Adgangskode

Hvis vi deaktiverer root, har de allerede en, da root er en almindelig bruger på alle systemer. Ud over dette kan denne bruger skabe ravage ved at have alle tilladelser aktiveret.

PermitRootLogin nr

Aktiver kontrolleret adgang
Vi kan kontrollere, hvilken bruger der kan logge ind via SSH og endda placere en klausul for kun at oprette forbindelse fra en bestemt IP. Dette svarer til, hvad AWS tilbyder for at forbinde os med dine instanser.

Tillad brugere [email protected]

Det er vigtigt kun at give adgang til brugere, der har brug for fjernadgang og om muligt begrænse dem til en kendt IP.

Konfigurer antallet af mislykkede forsøg
Hvis vi sætter kodeordet forkert, giver serveren os flere forsøg på at indtaste det igen, dette skal begrænses, eller du kan være offer for et brute force script, vi kan placere det 2 eller 3 gange.

MaxAuthTries 2

Antal forbindelser tilladt samtidigt
Dette kan variere afhængigt af, hvordan du bruger serveren, men det ideelle er at få det kontrolleret, bare tilføj det samlede antal brugere, der er tilladt af SSH.

MaxStartups X

Efter at have foretaget alle ændringer i vores fil skal vi genstart vores sshd -service, Det kan variere afhængigt af servicechefen.

SystemD

 systemctl genstart sshd

Opstart / Sysinit

 service genstart sshd

Alle disse ændringer tilføjer a ekstra sikkerhedsniveau men vi skal huske på:

• Brug alfanumeriske adgangskoder.
• Brug Godkendelse med offentlige / private nøgler når det er muligt.
• Supplerende sikkerhed med SELINUX og firewalls.
• Kontroller adgang, som brugerne skal logge på eksternt.

Godkend SSH offentlige / private nøgler

Bruges i øjeblikket SSH nøgler Det er et uundværligt krav, denne godkendelse bruges i vid udstrækning af administratorer til at automatisere opgaver mellem forskellige servere og bruges endda af udviklere til at få adgang til SCM som GIT, GITHUB, GITLAB blandt andre.

Det giver stor sikkerhed og mulighed for oprette automatiserede opgaver script-baseret som en Tilbage eller Gentag ændringer til flere noder på samme tid.

Når du bruger en nøgle SSH (offentlig og privat), de kan nemt oprette forbindelse til en server eller flere servere uden at skulle indtaste et kodeord hver gang. Det er muligt at konfigurere dine nøgler uden en adgangssætning, men det ville være hensynsløst, hvis nogen fik din nøgle, kunne de bruge den. Vi vil tale om, hvordan man genererer nøgler, distribuerer dem og bruger ssh-agent til at opnå større sikkerhed.

Generering af nøgler uden adgangskode
Først og fremmest skal du sørge for at have OpenSSH installeret, det er ikke nødvendigt, serveren er kun klienten.

Vi starter med at generere en DSA -nøgle med 1024 bits sikkerhed, mere end nok, selvom du kan gå videre og generere en RSA -nøgle med en grænse på 4096.

 ssh -keygen -b 1024 -t dsa

Det vil bede os om det sted, hvor det vil gemme standardnøgler ~ / .ssh

 Indtast filen, hvor nøglen skal gemmes (/home/test/.ssh/id_dsa)

Så vil den bede om en sætning, for nu vil vi ikke bruge nogen, og vi vil efterlade den tom, og den vil fortælle os, at nøglen er blevet oprettet og afspejler os.

Billedet vil altid være anderledes, det genereres tilfældigt, så hvis vi går til .ssh mappen skal vi have 2 filer

id_dsa -----> Privat nøgle (Del den ikke med nogen, den ligner din TDC).
id_dsa.pub ----> Det er den, vi deler for at oprette forbindelse.

Del offentlig nøgle
Hvis vi vil dele den offentlige nøgle i SCM eller Chef, Puppet, Jenkins, visualiserer vi den offentlige nøglefil, kopierer den og indsætter den, hvor den svarer.

 mere id_dsa.pub ssh- DSS AAAAB3NzaC1kc3MAAACBAN6SEI4Qqzb23pJYRXIAtPmGJHln5hFdthFq43ef + ifR29v2IknXCFwefKK8jorSDiUEY / 1F / yp0xao mjhFQu1jNXOgF0PAZTfivRVFn6Q9FRsyXU9s + FX + + L22sV7GkCHPxAAAAFQCyF1Gdh3 xQiW3mf3y4IX654O82SLGl7Vhh5UsvG8r8d8pV6R Cap4xr / J44xDDn 0gFArHmFwAxfQAAAIEAmVYjPYAdQ9DCNWP + + + 03anWgyoZqSPPs23djyVQ756U4VitM0GiIQQ89HCdvTFFpSagnfdVpWh4 Hxo4Y5skKihnPMtB bFNbP / 2SmGdPz1AOmb7tvRrTkj5VLtXeDeB3ulowUKarwiBVVvAvxtxmozoZHOADWqrEPizxIAAACAU2DF1ZGTiJMP OhVB7mlsVhhkq53OxKKJbZqsl9hkOiSxaLUfQBNu6Ae441ekIObqolWNCBIvCO3uQYOozyzNGBhqHE7FVq 1oXguj + + + 2GAQ UGNkee96D2by S7daieIKNmFer2hO / SBxzepMrWAiIUnUsP5irmYspkjGlQxP + hxb = test @ solvetic 

Hvis du vil dele den for at få adgang til en server, anbefaler jeg altid at bruge ssh-copy-id er inkluderet i OpenSSH og er meget let at bruge:

 ssh-copy-id user @ remote-server-ip -i angiver placeringen af ​​nøglen, der skal bruges.

Der er andre måder som:

 ssh user @ remote-server-ip \ 'cat >> .ssh / autorized_keys2' <.ssh / id_dsa.pub

 scp ~ / .ssh / id_dsa.pub bruger @ remote-server-ip

Fra nu af er tasterne forbundet, og du behøver kun at indtaste værten.

 ssh -l bruger remote-server-ip

Denne gang vil det ikke bede om nogen adgangskode, og vi kan bruge scripts uden interaktion.

Generer adgangskode og tilknyt ssh-agent
Det SSH nøglesikkerhed Det er baseret på vores private nøgle, der fungerer som et adgangskort, men hvis nogen stjæler vores nøgle, vil de have adgang til alle de steder, hvor vi har adgang. Men når vi genererer en adgangssætning, kan vi have et ekstra niveau, ikke kun er nøglen nødvendig, men vi behøver ikke at introducere vores sætning.

Denne gang opretter vi en rsa -nøgle med større sikkerhed ved at konfigurere en sætning.

 ssh -keygen -b 4096 -t rsa -C "Nøgle med adgangssætning" # -C Tilføj en kommentar. 

Som en sætning kan vi bruge mellemrum, prikker og specialtegn

 eksempel ---> Dette er min nye nøgle med Fr @ S3.

Vi deler den nye nøgle:

 scp ~ / .ssh / id_rsa.pub bruger @ remote-server-ip

Denne gang har vi brug for nøglen og adgangskoden, men at indtaste den flere gange er kedeligt, men vi kan supplere den med ssh-agent, vi skal starte den.

 ssh-agent

Vi tilføjer vores nøgle

 ssh-add Indtast adgangskode for /home/user/.ssh/id_rsa: # Vi indtaster den sætning, vi har konfigureret. 

Nu kan vi oprette forbindelse til enhver server, der bruger vores nøgle uden at skulle indtaste vores adgangssætning.

Jeg anbefaler denne metode, hvis du er uden for intranet, klient og server på forskellige punkter på Internettet, og vi vil ikke bruge automatiserede opgaver, men hellere oprette forbindelse til serveren til fjernadministrationsformål, det er bedst at angive en adgangskode eller meget lang adgangssætning (15 eller flere tegn, store, små, tal og symboler) til den offentlige nøgle.

Denne måde det vil praktisk talt være umuligt at blive hacket ved denne metode, da ikke kun hackeren skal kende adgangskoden, men han skal have et gyldigt offentligt certifikat på serveren, så han kan godkendes. (Selvfølgelig under forudsætning af at serveren aldrig er blevet kompromitteret og er helt opdateret og med den bedst mulige sikkerhed).

Kan du lide og hjælpe denne vejledning?Du kan belønne forfatteren ved at trykke på denne knap for at give ham et positivt punkt