it-swarm.com.de

Ist es möglich, 2 Ports auf SSH mit 2 verschiedenen Authentifizierungsschemata zu öffnen?

Ich versuche derzeit, einen SSH-Server so einzurichten, dass der Zugriff von außerhalb des Netzwerks NUR mit einem SSH-Schlüssel zulässig ist und kein Zugriff auf root oder eine andere Kombination aus Benutzername und Kennwort möglich ist.

Gleichzeitig müssen interne Benutzer im Netzwerk weiterhin eine Verbindung zum selben System herstellen können, müssen sich jedoch im herkömmlichen Sinne mit einem Benutzernamen und einem Kennwort anmelden.

Sowohl externe als auch interne Benutzer greifen mit PuttySSH von Windows aus auf das System zu, und der externe Zugriff erfolgt über eine Portweiterleitungs-Firewall, die den Quellport nach außen an einem willkürlich ausgewählten Port mit hoher Nummer wie 55000 (oder) öffnet was auch immer die Admins entscheiden)

Das folgende Diagramm versucht, die Verkehrsströme besser darzustellen.

(SSH Setup

Ich weiß, wie man die eigentliche Anmeldung so einrichtet, dass nur Schlüssel verwendet werden, und ich weiß, wie man root verweigert. Ich weiß nicht, wie man die beiden Anmeldetypen trennt.

Ich hatte überlegt, zwei Kopien von SSHD auszuführen, die an verschiedenen Ports mit derselben IP-Adresse lauschen und für jeden Port zwei verschiedene Konfigurationen haben.

Ich habe auch überlegt, eine "Übereinstimmungs" -Regel einzurichten, bin mir aber nicht sicher, ob ich mit diesen Optionen serverweite Konfigurationen trennen kann.

Schließlich ist die externe Person, die sich anmeldet, immer derselbe Benutzer, den wir für die Zwecke dieser Frage "Frank" nennen. "Frank" darf sich also immer nur von der externen IP-Adresse aus anmelden und darf nie wirklich vorne sitzen von jedem System, das eine interne Verbindung herstellt, wobei jeder andere Benutzer des Systems immer nur eine interne Verbindung herstellt und niemals eine Verbindung von einer externen IP herstellt.

Die Franks-IP, von der aus er eine Verbindung herstellt, ist dynamisch zugewiesen, aber die öffentliche IP, die er ebenfalls verbindet, ist statisch und ändert sich nie. Die interne IP des Portweiterleiters ändert sich ebenfalls nie und auch die interne IP-Adresse des SSH-Servers ändert sich nie .

Interne Clients stellen immer eine Verbindung von einer IP im privaten Netzwerkbereich her, zu der die IP des internen SSH-Servers gehört, und sind eine 16-Bit-Maske EG: 192.168.0.0/16

Ist diese Einrichtung mit einer Konfigurationsdatei und einer SSH-Serverinstanz möglich? Wenn ja, wie mache ich das?

oder

Bin ich viel besser mit 2 laufenden Servern mit unterschiedlicher Konfiguration?

Zur Referenz läuft der SSH-Server unter Ubuntu 18.04.

16
shawty

Es stellte sich also heraus, dass die Antwort tatsächlich viel einfacher war, als ich gedacht hatte.

Ich muss mich jedoch bei '@jeff schaller' für seine Kommentare bedanken. Wenn er nicht gewesen wäre, hätte ich nicht angefangen zu untersuchen, wie die SSH-Konfiguration 'Match' funktioniert.

Wie auch immer

Der Trick besteht darin, die Datei/etc/ssh/sshd_config als Standardkonfiguration für den Zugriff über die externe Internetverbindung einzurichten.

In meinem Fall bedeutete dies, Folgendes einzustellen

PermitRootLogin no
PasswordAuthentication no
UsePAM no

Auf diese Weise erzwinge ich ALLE Anmeldungen, unabhängig davon, woher sie kommen, um schlüsselbasierte Anmeldungen mit einem SSH-Schlüssel zu sein.

Ich habe dann auf den Windows-Computern 'PuttyGen' verwendet, um ein öffentliches/privates Schlüsselpaar zu generieren, das ich auf der Festplatte gespeichert habe, und einen entsprechenden SSH-Eintrag für meine Datei "autorisierte_Hosts" im Home-Verzeichnis des externen Benutzers.

Ich habe diesen SSH-Schlüssel an der richtigen Stelle im Home-Ordner meines Benutzers eingefügt und PuTTY so eingerichtet, dass die von PuttyGen generierte private (ppk) Datei für die Anmeldung verwendet und das Profil gespeichert wird.

Ich habe dann das Profil gespeichert und diese und die ppk-Schlüsseldatei mit einer sicheren Methode an den externen Benutzer gesendet (verschlüsselte E-Mail mit einer passwortgeschützten Zip-Datei im Anhang).

Sobald der Benutzer das ppk und das Profil in seiner Kopie von PuTTY hatte und sich anmelden konnte, fügte ich als letzte 2 Zeilen meiner sshd_config-Datei Folgendes hinzu

Match Host server1,server1.internalnet.local,1.2.3.4
    PasswordAuthentication yes

In der Zeile "Match" habe ich die Servernamen geändert, um die Namen meiner eigenen Server zu schützen.

Beachten Sie, dass jede Serverdomäne durch ein Komma und NO SPACES getrennt ist. Dies ist wichtig. Wenn Sie Leerzeichen einfügen, führt dies dazu, dass SSHD die Konfiguration nicht lädt und einen Fehler meldet. Die drei Übereinstimmungen, die ich dort habe, bewirken Folgendes:

server1 - stimmt mit jedem überein, der nur 'server1' ohne Domain zum Verbinden von EG verwendet: 'fred @ server1'

server1.internalnet.local - stimmt mit jedem überein, der den vollständig qualifizierten internen Domainnamen EG verwendet: EG: '[email protected]' (HINWEIS: Sie werden benötigen ein internes DNS, damit dies korrekt funktioniert)

1.2.3.4 - Übereinstimmungen mit dem spezifischen I.P. Dem SSH-Server zugewiesene Adresse EG: '[email protected]' Dies kann Platzhalter oder noch besser das Netz-/Masken-CIDR-Format EG: 1.2. * oder 192.168.1.0/8 verwenden. Wenn Sie jedoch Platzhalter verwenden, lesen Sie bitte Die Antwort von fchurca unten für einige wichtige Hinweise.

Wenn eines der bereitgestellten Muster mit dem Host übereinstimmt, auf den zugegriffen wird, besteht die einzige Änderung, die an der laufenden Konfiguration vorgenommen werden muss, darin, die Möglichkeit einer interaktiven Kennwortanmeldung wieder zu aktivieren.

Sie können hier auch andere Konfigurationsanweisungen einfügen. Diese Anweisungen werden auch für interne Hosts, die in der Übereinstimmungsliste aufgeführt sind, wieder aktiviert.

lesen Sie jedoch Folgendes:

https://man.openbsd.org/OpenBSD-current/man5/ssh_config.5

da nicht jede Konfigurationsoption innerhalb eines Übereinstimmungsblocks verwendet werden darf, habe ich dies herausgefunden, als ich versuchte, "UsePAM yes" zu verwenden, um die PAM-Authentifizierung wieder einzuschalten, nur um genau zu erfahren, dass dies nicht zulässig war.

Wenn Sie Ihre Änderungen vorgenommen haben, geben Sie ein

sshd -T

anschließend kehren Sie zurück, um sie zu testen, bevor Sie versuchen, den Server neu zu starten. Es werden alle Fehler gemeldet, die Sie haben.

Zusätzlich zu allem oben habe ich auch über die folgenden zwei Links viel Hilfe bekommen:

https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Match_keyword.html

https://www.cyberciti.biz/faq/match-address-sshd_config-allow-root-loginfrom-one_ip_address-on-linux-unix/

29
shawty

1.2. * - Stimmt mit jedem im lokalen Netz überein, wobei eine beliebige Adresse verwendet wird, die dem SSH-Server zugewiesen ist, der in der 16-Bit-Netzmaske für den Server enthalten ist. EG: '[email protected]'

Vorsichtig! Der Mustervergleich in .ssh/config basiert auf String-Globbing, nicht unbedingt auf IP-Adressen. Laut derselben Manpage lesen Sie:

MUSTER

Ein Muster besteht aus null oder mehr Nicht-Leerzeichen, "*" (ein Platzhalter, der null oder mehr Zeichen entspricht) oder "?" (Ein Platzhalter, der genau einem Zeichen entspricht). Um beispielsweise eine Reihe von Deklarationen für einen beliebigen Host in der Gruppe ".co.uk" anzugeben, kann das folgende Muster verwendet werden:

Host *.co.uk

Das folgende Muster würde mit jedem Host im Netzwerkbereich 192.168.0 [0-9] übereinstimmen:

Host 192.168.0.?

Wenn jemand versucht, sich von einer IP-Adresse aus anzumelden, die öffentlich in 1.2.badguy.com Aufgelöst wird, entspricht dies Ihrer 1.2.* - Regel.

https://man.openbsd.org/OpenBSD-current/man5/ssh_config.5#PATTERNS

[Der Vollständigkeit halber aktualisiert]

Wie an anderer Stelle erwähnt, können Sie Match Address 1.2.0.0/16 Anstelle von Match Host 1.2.* Verwenden.

[/Aktualisieren]

8
fchurca

Ich denke, Sie sollten sich darum kümmern, Ihre SSH-Konfigurationen aufzuteilen. Zum Beispiel; Richten Sie Ihre Datei/etc/ssh/ssh_config so ein, dass sie standardmäßig die globalen Variablen enthält, die Sie für alle Benutzer benötigen (SSH-Schlüsselauthentifizierung, Portweiterleitung usw.).

Wenn Ihr Benutzer (nennen wir ihn Bob) ein lokales (oder von nfs gemountetes) Home-Verzeichnis hat, geben Sie eine Konfiguration nur für ihn in /home/bob/.ssh/ ein. Diese Konfiguration enthält Ihre Übereinstimmungsanweisung sowie die Frage, ob er sich mit einem Kennwort und nicht mit einem Zertifikat verbinden muss, sowie seine eigenen Keep-Alive-Werte usw.

Ich habe dies in der Vergangenheit getan und derzeit, um bestimmte lokale Konten so zu sperren, dass sie nur von einer IP-Adresse eingehen und nur eine zertifikatbasierte Authentifizierung zulassen, während andere Benutzerkonten möglicherweise stattdessen die PAM-Authentifizierung verwenden und über eine kennwortbasierte Authentifizierung verfügen.

Kurz gesagt, das Erstellen und Verwalten separater Benutzerkonfigurationsdateien basierend auf den Benutzeranforderungen ist einfacher zu verwalten als der Versuch, alles unter der Standardkonfigurationsdatei für ssh zu halten.

1
jmatzke