Das SSH Secure Shell-Handbuch

Tutorial über dieses großartige Protokoll, das seine Reise 1997 begann und eine Vielzahl von Tools anbietet, die sich durch ihre Sicherheit auszeichnen. Da es sehr umfangreich ist, werde ich es in mehrere Einträge aufteilen, um das Wichtigste sowohl auf Client- als auch auf Serverebene abzudecken.

Wir können sehen, dass seine große Anziehungskraft die mehr als ausreichende Eigenschaft ist, das alte TELNET- Protokoll zu verschieben, das keine Informationsverschlüsselung aufweist und die Daten, sogar die Zugangsdaten, gefährdet.

Der SSH-Server bietet standardmäßig den TCP-Port 22. Ein SSH-Client wird im Allgemeinen zum Herstellen von Verbindungen zu einem SSHD-Server verwendet, der Remoteverbindungen akzeptiert. Beide sind in den modernsten Betriebssystemen verbreitet, einschließlich Mac, Linux, Solaris und OpenVMS.

Die Windows-Unterstützung für die Serverversion wird voraussichtlich in diesem Jahr offiziell veröffentlicht. Auf Client-Ebene bietet sie eine Vielzahl von Optionen, mit denen PuTTY gegenüber anderen hervorgehoben wird.

1. Installieren Sie Secure Shell SSH

In fast allen Distributionen ist Ihre Client-Version vorinstalliert, während die Serverversion im Repository verfügbar ist. Die Installation sollte sehr einfach sein.

 sudo apt-get installiere openssh-server 

 sudo yum installiere openssh-server 

 Pacman -Syu openssh 

Wir überprüfen, ob Sie mit Folgendem arbeiten:

 Lokaler Curl-Host: 22 

Bei richtigem Laufen solltest du werfen:

[color = # 696969] [/ color]

Mit dem Client können wir eine Verbindung zum Server herstellen, der remote sein kann, auch wenn die beiden Versionen intern über localhost verbunden sind.

Der einfachste Weg, uns zu verbinden, wäre:

 ssh user @ hostname 

Im Falle einer internen Verbindung wäre dies:

 ssh user @ localhost 

Wir haben eine Vielzahl von Optionen für die Verbindung. Ich werde einige sehr nützliche erläutern. Sie können alle Ihre Optionen auflisten mit:

 Mann ssh 

Hier zeigen wir ihnen:

con el usuario jcarrillo utilizando una llave privada diferente ubicada en nuestro folder /home/jcarrillo/llaves-aws usando el puerto 8022 de nuestro instancia en AWS. Wir verbinden uns mit dem Benutzer jcarrillo auf dem Server prueba.solvetic.com über einen anderen privaten Schlüssel in unserem Ordner / home / jcarrillo / llaves-aws über den Port 8022 unserer Instanz in AWS.

 Beispiel → ssh -C -i "~ / keys-aws /" -p 8022 -l jcarrillo prueba.solvetic.com 

Wie wir sehen, handelt es sich um ein umfangreiches, aber sehr umfassendes Tool, das mehr Einträge verdient, um die notwendigen Funktionen für jeden Sysadmin mit mittlerem oder professionellem Level abdecken zu können.

Nun gehen wir zu seiner Konfiguration auf Client-Server-Ebene, generieren öffentliche und private Schlüssel, verwenden Port-Forwarding in realen Situationen, leiten den X-Server über X11-Forwarding um, verwenden unter anderem scp, sftp, ssh-agent.

2. Sichern des SSH-Servers

Wir fahren mit OpenSSH fort und konzentrieren uns auf die Sicherung unseres SSH-Servers , um alle Arten von Angriffen zu vermeiden, die unseren Server gefährden könnten. el cual podemos modificar con cualquier editor de texto en mi caso usar vim: Alle diese Konfigurationen werden in der Datei sshd_config in / etc / ssh / vorgenommen, die wir in meinem Fall mit einem beliebigen Texteditor ändern können. Verwenden Sie dazu vim:

 sudo vim / etc / ssh / sshd_config 

Jetzt sehen wir, wie wir es ändern können.

Im Inneren sehen wir eine typische Konfigurationsdatei basierend auf “Optionswert”. Wenn eine der Optionen nicht standardmäßig gefunden wird, müssen wir die Zeile vollständig platzieren. In anderen Fällen ändert sich die Zeile nur von 0 zu 1 von Nein zu Ja oder es wird ein Kommentar entfernt.

Es ist wichtig, den Standardport in einen zufälligen zu ändern. Viele Skripte sind so konfiguriert, dass sie diesen Port angreifen. Es ist ratsam, ihn im Bereich von 1000 bis 23000 zu ändern, um zu versuchen, den Port nicht von einem anderen Dienst zu verwenden.

Wir sollten auch keine Ports wie 2222, 8022 oder 1022 verwenden, die so häufig sind wie die 22, und viele Skripte sind so konfiguriert, dass sie diese angreifen.

Port 2345

Wenn SELINUX aktiviert ist, müssen wir einen zusätzlichen Befehl verwenden, um den Zugriff von außen auf den neuen Port zu ermöglichen.

semanage port -a -t ssh_port_t -p tcp 2345 #Port 22 für Sicherheit ändern

Wir müssen sicherstellen, dass alle unsere Verbindungen unter Protokoll 2 hergestellt werden, das 1 hat viele Schwachstellen.

Protokoll 2

Suchen Sie im Abschnitt “Authentifizierung” . Ihre ersten beiden Optionen sind ebenfalls wichtig. Die erste ist die Anzahl der Sekunden, die der Remote-Benutzer sich bei Ihrem Computer anmelden muss. Geben Sie diesen Wert ein paar Sekunden ein, wir brauchen nicht lange, um uns anzumelden, wenn wir den Account und das Passwort kennen.

Auf diese Weise vermeiden wir bestimmte Skripte, die diese Zeit nutzen. Der typische Wert in Bezug auf die Sicherheit beträgt 30, obwohl er möglicherweise noch geringer ist.

LoginGraceTime 30

Dies ist die wichtigste Option, um Opfer eines Angriffs zu werden. Sie benötigen drei Dinge:

• Benutzer
• Hafen
• Passwort

Wenn wir den root deaktivieren, haben sie bereits einen root, wenn ein Benutzer in allen Systemen gleich ist. Darüber hinaus kann dieser Benutzer Probleme verursachen, wenn alle Berechtigungen aktiviert sind .

PermitRootLogin nicht

Wir können steuern, welcher Benutzer sich über SSH anmelden kann, und sogar eine Klausel einfügen, um nur von einer bestimmten IP-Adresse aus eine Verbindung herzustellen. Dies ähnelt dem, was AWS anbietet, um uns mit Ihren Instanzen zu verbinden.

AllowUsers [email protected]

Es ist wichtig, den Zugriff nur für Benutzer zuzulassen, die Remotezugriff benötigen, und diese nach Möglichkeit auf eine bekannte IP-Adresse zu beschränken.

Wenn wir das Passwort falsch eingeben, gibt der Server uns mehrere Versuche, es erneut einzugeben. Dies muss begrenzt sein, oder Sie können Opfer eines Brute-Force-Skripts werden. Wir können es zwei- oder dreimal platzieren.

MaxAuthTries 2

Dies kann abhängig von der Verwendung, die Sie dem Server geben, variieren. Idealerweise ist es jedoch, die Steuerung zu übernehmen. Fügen Sie einfach die Gesamtzahl der von SSH zugelassenen Benutzer hinzu.

MaxStartups X

Nachdem wir alle Änderungen in unserer Datei vorgenommen haben, müssen wir unseren sshd-Dienst neu starten . Dieser kann je nach Dienstmanager variieren.

 systemctl starte sshd neu 

 Dienst neu starten sshd 

All diese Änderungen erhöhen die Sicherheit zusätzlich, aber wir müssen Folgendes berücksichtigen:

• Verwenden Sie alphanumerische Kennwörter
• Verwenden Sie nach Möglichkeit die Authentifizierung über öffentliche / private Schlüssel .
• Ergänzen Sie die Sicherheit mit SELINUX und Firewalls.
• Steuern Sie den Zugriff, auf den sich Benutzer remote anmelden müssen.

Authentifizieren Sie öffentliche / private SSH-Schlüssel

Derzeit ist die Verwendung von SSH-Schlüsseln eine wesentliche Voraussetzung. Diese Authentifizierung wird häufig von Administratoren verwendet, um Aufgaben zwischen mehreren Servern zu automatisieren, und wird sogar von Entwicklern verwendet, um auf SCM wie GIT , GITHUB , GITLAB und andere zuzugreifen .

Es bietet eine große Sicherheit und die Möglichkeit , automatisierte Aufgaben auf der Grundlage von Skripten wie einem Backup oder dem Replizieren von Änderungen auf mehrere Knoten gleichzeitig zu erstellen .

Mithilfe eines SSH- Schlüssels (öffentlich und privat) können Sie problemlos eine Verbindung zu einem oder mehreren Servern herstellen, ohne jedes Mal ein Kennwort eingeben zu müssen. Es ist möglich, Ihre Schlüssel ohne eine Passphrase zu konfigurieren. Dies wäre jedoch unklug. Wenn jemand Ihr Passwort erhält, können Sie es verwenden. Wir werden darüber sprechen, wie man Schlüssel generiert, verteilt und ssh-agent verwendet, um mehr Sicherheit zu erhalten.

Stellen Sie zunächst sicher, dass Sie OpenSSH installiert haben, es ist nicht erforderlich, den Server nur den Client.

Wir beginnen mit der Generierung eines Schlüssels vom Typ DSA mit einer Sicherheit von mehr als 1024 Bit, obwohl Sie noch weiter gehen und einen Schlüssel vom Typ RSA mit einer Obergrenze von 4096 generieren können.

 ssh-keygen -b 1024 -t dsa 

Es wird nach dem Speicherort gefragt, an dem die Standardschlüssel ~ / .ssh gespeichert werden

 Geben Sie die Datei ein, in der der Schlüssel gespeichert werden soll (/home/test/.ssh/id_dsa). 

Dann wird er nach einer Phrase fragen, wir werden keine benutzen und wir werden es leer lassen und er wird uns sagen, dass der Schlüssel erstellt wurde und uns widerspiegelt.

Das Bild wird immer anders generiert, wenn wir dann in den .ssh Ordner gehen, müssen wir 2 Dateien haben

id_dsa —–> Privater Schlüssel (Teilen Sie ihn mit niemandem, er ist wie Ihr TDC).
id_dsa.pub —-> Diesen teilen wir, um eine Verbindung herzustellen.

Für den Fall, dass Sie den öffentlichen Schlüssel in SCM oder Chef, Puppet, teilen möchten, visualisieren Jenkins die öffentliche Schlüsseldatei und kopieren sie und fügen sie gegebenenfalls ein.

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

Falls Sie es freigeben möchten, um auf einen Server zuzugreifen, empfehle ich immer, ssh-copy-id zu verwenden, das in OpenSSH enthalten und sehr einfach zu verwenden ist:

 ssh-copy-id Benutzer @ Remote-Server-IP -i gibt den Speicherort des zu verwendenden Schlüssels an. 

Es gibt andere Möglichkeiten wie:

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

 scp ~ / .ssh / id_dsa.pub Benutzer @ Remote-Server-IP 

Ab sofort sind die Tasten verbunden und müssen nur noch den Host eingeben.

 SSH-L Benutzer Remote-Server-IP 

Dieses Mal werden Sie nicht nach einem Passwort gefragt und wir können Skripte ohne Interaktion verwenden.

Die Sicherheit der SSH-Schlüssel basiert auf unserem privaten Schlüssel, der als Zugangskarte fungiert. Falls jedoch jemand unseren Schlüssel stiehlt, können Sie auf alle Stellen zugreifen, auf die wir Zugriff haben. Bei der Erstellung einer Passphrase können wir jedoch eine zusätzliche Ebene festlegen, die nicht nur für die Eingabe der Passphrase, sondern auch für deren Eingabe erforderlich ist.

Dieses Mal erstellen wir einen RSA-Schlüssel mit größerer Sicherheit, indem wir eine Phrase konfigurieren.

 ssh-keygen -b 4096 -t rsa -C "Schlüssel mit Passphrase" # -C Kommentar hinzufügen. 

Als Phrase können wir Leerzeichen, Punkte und Sonderzeichen verwenden

 Beispiel ---> Est @ ist mein neuer @ Schlüssel mit Fr @ S3. 

Wir teilen den neuen Schlüssel:

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

Diesmal brauchen wir den Schlüssel und die Passphrase, aber die Eingabe ist mehrere Male langwierig, aber wir können sie mit ssh-agent ergänzen, wir müssen sie starten.

 SSH-Agent 

Wir fügen unseren Schlüssel hinzu

 ssh-add Geben Sie die Passphrase für /home/user/.ssh/id_rsa ein: #Wir stellen die von uns konfigurierte Phrase vor. 

Jetzt können wir uns mit jedem Server verbinden, der unseren Schlüssel verwendet, ohne unsere Passphrase eingeben zu müssen.

Ich empfehle diese Methode, wenn Sie nicht im Intranet, auf dem Client und auf dem Server sind und sich an verschiedenen Stellen im Internet befinden und wir keine automatisierten Aufgaben ausführen, sondern eine Verbindung zum Server zu Zwecken der Remoteverwaltung herstellen. Geben Sie am besten ein Kennwort oder ein Sehr lange Passphrase (15 oder mehr Zeichen, Großbuchstaben, Kleinbuchstaben, Zahlen und Symbole) zum öffentlichen Schlüssel.

Auf diese Weise wird es praktisch unmöglich sein, von dieser Methode gehackt zu werden, da nicht nur der Hacker das Kennwort kennen muss, sondern auch ein gültiges öffentliches Zertifikat auf dem Server haben muss, damit es authentifiziert werden kann. (Natürlich unter der Annahme, dass der Server nie kompromittiert wurde und vollständig aktualisiert wurde und die bestmögliche Sicherheit bietet) .