Secure Shell SSH Manual

Handledning om detta magnifika protokoll som började sina äventyr 1997, och som erbjuder ett brett utbud av verktyg som sticker ut för deras säkerhet, eftersom det är mycket omfattande kommer jag att dela upp det i flera poster som försöker täcka det viktigaste både på klient- och servernivå.

Vad är Secure Shell -protokollet?Secure Shell eller SSH är ett nätverksprotokoll som tillåter utbyte av data över en säker kanal mellan två datorer. SSH använder krypteringstekniker som gör att informationen som färdas genom kommunikationsmediet blir oläslig och ingen tredje person kan upptäcka användarnamn och lösenord för anslutningen eller vad som skrivs under hela sessionen. SSH använder kryptering med offentlig nyckel för att autentisera fjärrdatorn och tillåta den att autentisera användaren vid behov.

SSH används vanligtvis för att starta en session på en fjärransluten maskin, där du kan utföra kommandon, men det tillåter också tunnling, godtycklig vidarebefordran av TCP -portar och X11 -anslutningar; Filöverföringar kan också utföras med tillhörande SFTP- eller SCP -protokoll.

Vi kan se att dess stora attraktion är dess egenskap mer än tillräckligt för att förskjuta det gamla TELNET -protokollet, som saknar informationskryptering, komprometterar data, inklusive åtkomstuppgif.webpter.

De SSH -server, erbjuder TCP -port 22 som standard. En SSH -klient används vanligtvis för att upprätta anslutningar till en sshd -server som accepterar fjärranslutningar. Båda finns vanligtvis på de flesta moderna operativsystem, inklusive Mac, Linux, Solaris och OpenVMS.

Windows -support för dess serverversion förväntas släppas officiellt i år medan det på kundnivå erbjuder ett brett utbud av alternativ som markerar PuTTY framför de andra.

Lär dig att använda kitt

OpenSSHOpenSSH (Open Secure Shell) är en uppsättning applikationer som tillåter krypterad kommunikation över ett nätverk, med SSH -protokollet. Det skapades som ett gratis och öppet alternativ till SSH -protokollet, det är det mest använda under Linux och det kommer att vara det som vi kommer att använda i alla poster.

1. Installera Secure Shell SSH

I nästan alla distributioner är dess klientversion förinstallerad medan serverversionen är tillgänglig av förvaret, installationen bör vara mycket enkel.

Debian, Ubuntu, Linux Mint och derivat

 sudo apt-get install openssh-server

Centos, Rhel, Fedora

 sudo yum installera openssh-server

Arch-Linux

 pacman -Syu openssh

Vi verifierar att det körs med:

 curl lokal värd: 22

Om den körs korrekt ska den returnera:

[color = # 696969] [/Färg]

Ansluter till servern
Med klienten kan vi ansluta till servern som kan vara fjärrkontroll även om vi har båda versionerna att ansluta internt med localhost.

Det mest grundläggande sättet att ansluta skulle vara:

 ssh -användare @ hostaddress

Vid anslutning internt skulle det vara:

 ssh -användare @ localhost

Vi har en mängd olika alternativ när du ansluter, jag kommer att förklara några mycket användbara, du kan lista alla dina alternativ med:

 man ssh

Här visar vi dem:

Man SSH -alternativ
-CBegär datakomprimering som sparar bandbredd eller data om du befinner dig i ett mobilnät.

-lAnge användaren som vi kommer att ansluta till.

-OCHSkapa en loggfil där standardfelet avviks.

-FVi väljer en annan konfigurationsfil som är användbar för servrar med ovanliga alternativ.

-gKrävs för hamntunnel.

-iVi väljer den mapp som vi ska använda för en alternativ privat nyckel.

-KAktivera när du använder GSSAPI -referenser.

-nGenom att använda den i samband med X11 på detta sätt omdirigeras all log som genereras av programmet till / dev / null.

-ellerKrävs för att använda mer avancerade alternativ som ServerAliveInterval 30.

-sVälj en annan port än 22 för att ansluta till värden.

-vDen visar alla steg som krävs för att upprätta anslutningen. Du kan få ännu mer information med -vv -vvv.

-XNödvändigt om vi vill använda X11 Forwarding.

-YAktiverar säker X11 -vidarebefordran.

Vi kommer att ansluta till test.solvetic.com-servern med jcarrillo-användaren med en annan privat nyckel i vår / home / jcarrillo / keys-aws-mapp med port 8022 i vår instans på AWS.

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

Som vi kan se är det ett omfattande men mycket komplett verktyg som förtjänar fler poster för att kunna täcka sina nödvändiga funktioner för alla Sysadmin på mellanliggande eller professionell nivå.

Nu går vi vidare till dess konfiguration på klient-servernivå, genererar offentliga och privata nycklar, användning av portvidarebefordran i verkliga situationer, omdirigering av X-servern genom X11-vidarebefordran, användning av bland annat scp, sftp, ssh-agent .

2. Säkra SSH -servern

Vi fortsätter med OpenSSH fokuserar på säkra vår SSH -server, för att undvika alla typer av attacker som kan äventyra vår server. Alla dessa konfigurationer kommer att göras i filen sshd_config som finns i / etc / ssh / som vi kan ändra med valfri textredigerare i mitt fall vim:

 sudo vim / etc / ssh / sshd_config

Nu ser vi hur man ändrar det.

Ändra sshd_config
Inuti ser vi en typisk konfigurationsfil baserad på "Värde alternativ" Om något av alternativen inte hittas som standard måste vi placera raden helt, i andra fall blir det bara att ändra från 0 till 1 från Nej till Ja eller avmarkera en rad.

Ändra port 22
Är viktigt ändra standardporten till en slumpmässig port många skript är konfigurerade för att attackera den här porten, det rekommenderas att ändra den i från 1000 till 23000 se till att porten inte används av en annan tjänst.

Vi ska inte heller använda portar som 2222, 8022 eller 1022, de är lika vanliga som 22 och många skript är konfigurerade för att attackera dem.

port 2345

Om vi ​​har SELINUX aktiverat måste vi använda ett ytterligare kommando för att tillåta åtkomst utifrån till den nya porten.

Semanage port -a -t ssh_port_t -p tcp 2345 #Ändra port 22 för säkerhet

Använd standardprotokoll 2
Vi måste se till att alla våra anslutningar görs enligt protokoll 2 eftersom 1 har många sårbarheter.

Protokoll 2

Dags att ange referenser
Sök avsnitt "Autentisering". Dina två första alternativ är också viktiga. Den första är antalet sekunder som fjärranvändaren måste logga in på din maskin. Ställ in det värdet på några sekunder, det tar inte lång tid att logga in om vi känner till kontot och lösenordet.

På så sätt undviker vi vissa skript som utnyttjar den tiden. Det typiska värdet när det gäller säkerhet är 30, även om det kan vara ännu mindre.

Logga in GraceTime 30

Inaktivera rotåtkomst
Detta Det är det viktigaste alternativet att bli offer för en attack, de behöver 3 saker:

• Användare
• hamn
• Lösenord

Om vi ​​inaktiverar root har de redan en eftersom root är en vanlig användare på alla system. Utöver detta kan den här användaren skapa förödelse genom att ha alla behörigheter aktiverade.

PermitRootLogin nr

Aktivera kontrollerad åtkomst
Vi kan styra vilken användare som kan logga in via SSH och till och med placera en klausul för att ansluta endast från en viss IP. Detta liknar det AWS erbjuder för att ansluta oss till dina instanser.

AllowUsers [email protected]

Det är viktigt att endast tillåta användare som behöver fjärråtkomst och om möjligt begränsa dem till en känd IP -adress.

Konfigurera antalet misslyckade försök
Om vi ​​anger lösenordet fel ger servern oss flera försök att ange det igen, detta måste begränsas eller så kan du bli offer för ett brute force-skript, vi kan placera det 2 eller 3 gånger.

MaxAuthTries 2

Antal anslutningar tillåtna samtidigt
Detta kan variera beroende på hur du använder servern, men idealet är att ha den kontrollerad, lägg bara till det totala antalet användare som SSH tillåter.

MaxStartups X

Efter att ha gjort alla ändringar i vår fil måste vi starta om vår sshd -tjänst, Det kan variera beroende på servicechef.

SystemD

 systemctl starta om sshd

Uppstart / Sysinit

 service restart sshd

Alla dessa ändringar lägger till a extra säkerhetsnivå men vi måste komma ihåg:

• Använd alfanumeriska lösenord.
• Använda sig av Autentisering med offentliga / privata nycklar när det är möjligt.
• Kompletterande säkerhet med SELINUX och brandväggar.
• Kontrollera åtkomst till vilken användare måste logga in på distans.

Verifiera SSH offentliga / privata nycklar

Använd för närvarande SSH -nycklar Det är ett oumbärligt krav, denna autentisering används i stor utsträckning av administratörer för att automatisera uppgif.webpter mellan olika servrar och används till och med av utvecklare för att komma åt SCM som GIT, GITHUB, GITLAB bland andra.

Det erbjuder stor säkerhet och möjlighet till skapa automatiserade uppgif.webpter manusbaserad som en Tillbaka eller Replikera ändringar till flera noder samtidigt.

När du använder en nyckel SSH (offentligt och privat), de kan enkelt ansluta till en server, eller flera servrar, utan att behöva ange ett lösenord varje gång. Det är möjligt att konfigurera dina nycklar utan en lösenfras, men det skulle vara hänsynslöst, om någon fick din nyckel kunde de använda den. Vi kommer att prata om hur man genererar nycklar, distribuerar dem och använder ssh-agent för att få större säkerhet.

Generera nycklar utan lösenfras
Först och främst, se till att du har OpenSSH installerat, det är inte nödvändigt, servern bara klienten.

Vi börjar med att generera en nyckel av DSA -typ med 1024 bitars säkerhet, mer än tillräckligt även om du kan gå längre och generera en nyckel av RSA -typ med en gräns på 4096.

 ssh -keygen -b 1024 -t dsa

Det kommer att be oss om platsen där det kommer att spara standardnycklarna ~ / .ssh

 Ange filen där nyckeln ska sparas (/home/test/.ssh/id_dsa)

Då kommer den att be om en fras för nu kommer vi inte att använda någon och vi kommer att lämna den tom och den kommer att berätta att nyckeln har skapats och speglar oss.

Bilden kommer alltid att vara annorlunda, den genereras slumpmässigt, så om vi går till .ssh -mappen måste vi ha 2 filer

id_dsa -----> Privat nyckel (Dela den inte med någon, det är som din TDC).
id_dsa.pub ----> Det är den vi delar för att ansluta.

Dela offentlig nyckel
Om vi ​​vill dela den offentliga nyckeln i SCM eller Chef, Puppet, Jenkins, visualiserar vi den offentliga nyckelfilen, kopierar den och klistrar in den där den motsvarar.

 mer 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 

Om du vill dela den för att komma åt en server rekommenderar jag alltid att du använder ssh-copy-id som ingår i OpenSSH och är mycket lätt att använda:

 ssh-copy-id user @ remote-server-ip -i anger platsen för nyckeln som ska användas.

Det finns andra sätt som:

 ssh-användare @ fjärrserver-ip \ 'cat >> .ssh / Author_keys2' <.ssh / id_dsa.pub

 scp ~ / .ssh / id_dsa.pub användare @ fjärrserver-ip

Från och med nu är nycklarna anslutna och du behöver bara ange värden.

 ssh -l användare fjärrserver-ip

Den här gången kommer det inte att begära något lösenord och vi kan använda skript utan interaktion.

Skapa lösenfras och associera med ssh-agent
De SSH -nyckelsäkerhet Den är baserad på vår privata nyckel som fungerar som ett passerkort, men om någon stjäl vår nyckel kommer de att kunna komma åt alla platser där vi har åtkomst. Men när vi skapar en lösenfras kan vi ha en extra nivå, inte bara är nyckeln nödvändig, utan vi behöver inte introducera vår fras.

Den här gången skapar vi en rsa -nyckel med större säkerhet genom att konfigurera en fras.

 ssh -keygen -b 4096 -t rsa -C "Nyckel med lösenfras" # -C Lägg till en kommentar. 

Som en fras kan vi använda mellanslag, prickar och specialtecken

 exempel ---> Detta är min nya nyckel med Fr @ S3.

Vi delar den nya nyckeln:

 scp ~ / .ssh / id_rsa.pub användare @ fjärrserver-ip

Den här gången behöver vi nyckeln och lösenfrasen men att skriva in den flera gånger är tråkigt men vi kan komplettera den med ssh-agent vi måste starta den.

 ssh-agent

Vi lägger till vår nyckel

 ssh-add Ange lösenfras för /home/user/.ssh/id_rsa: # Vi anger frasen som vi har konfigurerat. 

Nu kan vi ansluta till vilken server som helst som använder vår nyckel utan att behöva ange vår lösenfras.

Jag rekommenderar den här metoden om du befinner dig utanför intranätet, klienten och servern på olika platser på Internet, och vi kommer inte att använda automatiska uppgif.webpter, utan snarare ansluta till servern för fjärradministration, det är bäst att ange ett lösenord eller mycket lång lösenfras (15 eller fler tecken, versaler, gemener, siffror och symboler) till den offentliga nyckeln.

Den här vägen det blir praktiskt taget omöjligt att bli hackad med denna metod, eftersom inte bara hackaren måste känna till lösenordet utan han måste ha ett giltigt offentligt certifikat på servern så att han kan autentiseras. (Naturligtvis förutsatt att servern aldrig har äventyrats och är helt uppdaterad och med bästa möjliga säkerhet).

Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng