Zulassen, dass sich nur bestimmte Benutzer über ssh an einem Port und andere über einen anderen Port anmelden

Ich habe den folgenden Anwendungsfall:

• Benutzer müssen sich von einem gesicherten, vertrauenswürdigen Netzwerk aus anmelden können
• Anschließend können sich einige (nur zwei) mobile Benutzer remote auf einem Linux Centos-Computer anmelden.

Ich kann das sshd auf verschiedenen Ports laufen lassen, zB:

• Von innen ist es in Ordnung, es auf 22 laufen zu lassen, da ich nicht möchte, dass sie eine Verbindung zu anderen Ports herstellen (bringt das Skript durcheinander).
• Für externe mobile Benutzer werde ich den sshd auf einem anderen Port ausführen, z. B. Port X (erhöhte Sicherheit - dies ist eine Einrichtung für kleine Büros).

Aus Sicherheitsgründen wollte ich sshd so konfigurieren, dass nur bestimmte Benutzer auf Port X Zugriff haben (und dann einige Warnungen konfigurieren, damit wir wissen, wann sich Benutzer über Port X anmelden).

Es ist mir jedoch nicht möglich, eine solche Konfiguration in der sshd-Dokumentation zu finden. Wenn es keine solche Lösung gibt, ist es zumindest möglich, ein Shell-Skript auszulösen, das ausgeführt wird, wenn jemand die sshd-Anmeldung an Port X abschließt? Ich habe in der Dokumentation zu iptables nachgeschlagen, ob es eine Warnung auslösen kann, wenn sshd login vorhanden ist, aber keine Lösung gefunden hat.

Eingänge geschätzt

Das Ausführen SSHauf einem alternativen Port zählt nicht mehr als Sicherheit. Dies führt nur zu einer geringfügigen Verschleierung und zu einem zusätzlichen Komplexitätsschritt für Ihre Benutzer. Personen, die Ihr Netzwerk unterbrechen möchten, automatisierte Port-Scanner verwenden und sich nicht darum kümmern, auf welchem ​​Port sie ausgeführt werden, können dies problemlos tun.

Wenn Sie die Sicherheit auf einem System verbessern möchten, das remote internetbasiertes SSH für eingehende sshd_configNachrichten zulässt , steuern Sie Ihre Benutzer in @Anthon und implementieren Sie die Sicherheit direkt in PAM.

Erstellen Sie zwei Gruppen lusersund rusers. Fügen Sie die mobilen Remotebenutzer der rusersGruppe hinzu. Verwenden Sie das PAM-Modul pam_succeed_if.so , um den Zugriff auf diese Benutzer zuzulassen. Fügen Sie Ihrer Pam-Konfiguration Zeilen für ssh hinzu:

account     sufficient  pam_succeed_if.so user ingroup lusers
account     sufficient  pam_succeed_if.so user ingroup rusers

Bei einigen Modulen von pam_succeed_if.so müssen Sie möglicherweise eine leicht abweichende Syntax verwenden, z group = lusers.

Dies sshdschränkt nicht nur die Benutzer ein, die eine Verbindung herstellen können, sondern Sie haben auch im Fall eines Fehlers sshdweiterhin den Schutz, den die PAM-basierten Einschränkungen bieten.

Ein weiterer Schritt für die Remotebenutzer besteht darin, die Verwendung von ssh_keys mit Passphrasen zu erzwingen. Lokale Benutzer können sich also mit Schlüsseln oder Kennwörtern anmelden, Remote-Benutzer müssen jedoch über einen Schlüssel verfügen. Wenn Sie die Schlüssel für diese Benutzer erstellen, können Sie sicherstellen, dass dem Schlüssel eine Passphrase zugeordnet ist. Auf diese Weise wird der Zugriff auf Standorte beschränkt, die tatsächlich den SSH-Schlüssel und die Passphrase besitzen. Und die Begrenzung möglicher Angriffsmethoden, wenn das Kennwort eines Benutzers erstellt wird.

In sshd_config:

2 Einstellungen ändern:

ChallengeResponseAuthentication yes

und

PasswordAuthentication yes

zu:

ChallengeResponseAuthentication no

und

PasswordAuthentication no

Standardmäßig ist jetzt nur die Schlüsselauthentifizierung zulässig. Dann können Sie für lokale Benutzer die matchKonfigurationseinstellung verwenden, um die Standardeinstellung für lokale Benutzer zu ändern. Angenommen, Ihr lokales privates Netzwerk ist 192.168.1.0/24, fügen Sie Folgendes hinzu sshd_config:

Match Address 192.168.1.0/24
PasswordAuthentication yes

Jetzt können die lokalen Benutzer eine Verbindung mit Kennwörtern oder Schlüsseln herstellen, und entfernte Benutzer werden gezwungen, Schlüssel zu verwenden. Es liegt an Ihnen, die Schlüssel mit Passphrasen zu erstellen.

Als zusätzlichen Vorteil müssen Sie nur sshd_configeinen einzigen Port verwalten und ssh nur auf einem einzigen Port ausführen, was Ihre eigene Verwaltung vereinfacht.

edit 2017-01-21 - Beschränkung der Verwendung von authorized_keysDateien.

Wenn Sie sicherstellen möchten, dass Benutzer nicht einfach einen SSH-Schlüssel selbst generieren und ihn mit einer authorized_keysDatei zum Anmelden verwenden können, können Sie steuern, dass durch Festlegen eines bestimmten Speicherorts für SSHD nach autorisierten Schlüsseln gesucht wird.

In /etc/ssh/sshd_config, ändern:

AuthorizedKeysFile  %h/ssh/authorized_keys

zu etwas wie:

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

Wenn Benutzer auf ein kontrolliertes Verzeichnis verweisen, in das sie keine Schreibberechtigung haben, können sie keinen eigenen Schlüssel generieren und ihn verwenden, um die von Ihnen festgelegten Regeln zu umgehen.

Sie können Folgendes hinzufügen /etc/ssh/sshd_config:

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

Das oben Gesagte setzt voraus, dass die zulässigen Remotebenutzer benannt sind mobileuser1und mobileuser2und dass Ihr vertrauenswürdiges Netzwerk 10.0.0.0 mit Subnetzmaske 255.0.0.0 ist.

Auf diese Weise können sich die beiden mobilen Benutzer von überall aus anmelden und jeder kann sich über das vertrauenswürdige Netzwerk anmelden. Jedem Benutzer, der mit keinem dieser Muster übereinstimmt (z. B. Benutzer, der sich von einem fooRemotestandort aus anmeldet), wird der Zugriff verweigert.

Sie können dies tun, indem Sie zwei ssh-Daemons und zwei sshd_configDateien starten . Kopieren Sie Ihre vorhandene (z. B. aus /etc/ssh/sshd_config /etc/ssh/sshd_alt_configund in der alternativen Konfigurationseinrichtung) von der manSeite für sshd_config:

Hafen

Specifies the port number that sshd(8) listens on.  The default
is 22.  Multiple options of this type are permitted.  See also
ListenAddress

AllowUsers

This keyword can be followed by a list of user name patterns,
separated by spaces.  If specified, login is allowed only for
user names that match one of the patterns.  Only user names are
valid; a numerical user ID is not recognized.  By default, login
is allowed for all users.  If the pattern takes the form
USER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts.  The
allow/deny directives are processed in the following order:
DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

Möglicherweise möchten Sie das alternative ssh-Protokoll in einer anderen Datei speichern und z. B. die darin enthaltenen Informationen befolgen, um fehlerhafte Anmeldeversuche zu erkennen.