Zezwalanie tylko określonym użytkownikom na logowanie się przez ssh na jednym porcie, a inni na logowanie przez inny port

Mam następujący przypadek użycia:

• Musisz umożliwić użytkownikom logowanie się z zabezpieczonej, zaufanej sieci
• a następnie zezwalanie dwóm (tylko dwóm) użytkownikom mobilnym na zdalne logowanie na komputerze z systemem Linux Centos.

Mogę uruchomić sshd na różnych portach, np .:

• od wewnątrz można go uruchomić na 22, ponieważ nie chcę, aby łączyły się one z innymi portami (bałagan w skrypcie).
• Dla zewnętrznych użytkowników mobilnych, uruchomię sshd na innym porcie, powiedzmy port X (zwiększone bezpieczeństwo - to konfiguracja w małym biurze).

Dla zwiększenia bezpieczeństwa miałem nadzieję skonfigurować sshd, aby umożliwić dostęp tylko określonym użytkownikom na porcie X (a następnie skonfigurować niektóre alerty, abyśmy mogli wiedzieć, kiedy użytkownicy logują się przez port X).

Nie mogę jednak znaleźć takiej konfiguracji w dokumentacji sshd. Jeśli nie ma takiego rozwiązania, czy możliwe jest przynajmniej uruchomienie skryptu powłoki, aby uruchomić się za każdym razem, gdy ktoś dokona sshd na porcie X? Patrzyłem na dokumentację iptables, aby zobaczyć, czy może wywołać alert, gdy loguje się sshd, ale nic nie mogę wymyślić.

Docenione wkłady

Uruchomienie SSHna alternatywnym porcie nie jest już traktowane jako bezpieczeństwo. Daje to tylko odrobinę niejasności i dodatkowy stopień złożoności dla użytkowników. Dodaje zero przeszkód dla osób chcących złamać sieć, które korzystają ze zautomatyzowanych skanerów portów i nie dbają o to, na jakim porcie działa.

Jeśli chcesz wzmocnić bezpieczeństwo w systemie, który zezwala na zdalny przychodzący SSH przez Internet, kontroluj swoich użytkowników sshd_configzgodnie ze wskazaniami @Anthon, a następnie wdrażaj zabezpieczenia bezpośrednio w PAM.

Utwórz dwie grupy lusersi rusers. Dodaj zdalnych użytkowników mobilnych do rusersgrupy. Użyj modułu PAM pam_succeed_if.so , aby zezwolić na dostęp tym użytkownikom. Dodaj linie do konfiguracji pam dla ssh:

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

Niektóre moduły pam_succeed_if.so mogą wymagać użycia nieco innej składni, np group = lusers.

Wówczas nie tylko sshdogranicza użytkowników, którzy mogą się połączyć, ale w przypadku błędu sshdnadal masz ochronę, którą oferują ograniczenia oparte na PAM.

Dodatkowym krokiem dla zdalnych użytkowników jest wymuszenie użycia ssh_keys z hasłami. Tak więc lokalni użytkownicy mogą logować się przy użyciu kluczy lub haseł, ale użytkownicy zdalni muszą mieć klucz, a jeśli utworzysz dla nich klucze, możesz upewnić się, że klucz ma skojarzone hasło. Ograniczając w ten sposób dostęp do lokalizacji, które faktycznie posiadają klucz SSH i hasło. I ograniczenie potencjalnych wektorów ataku, jeśli hasło użytkownika zostanie naruszone.

W sshd_config:

zmień 2 ustawienia:

ChallengeResponseAuthentication yes

i

PasswordAuthentication yes

do:

ChallengeResponseAuthentication no

i

PasswordAuthentication no

Tak więc domyślnie jest teraz dozwolone tylko uwierzytelnianie klucza. Następnie dla użytkowników lokalnych możesz użyć matchustawienia konfiguracji, aby zmienić ustawienie domyślne dla użytkowników lokalnych. Zakładając, że Twoja lokalna sieć prywatna to 192.168.1.0/24, dodaj do sshd_config:

Match Address 192.168.1.0/24
PasswordAuthentication yes

Teraz użytkownicy lokalni mogą łączyć się za pomocą haseł lub kluczy, a użytkownicy zdalni będą zmuszeni do korzystania z kluczy. To od Ciebie zależy, czy utworzysz klucze ze zdaniami.

Jako dodatkową korzyść, musisz zarządzać tylko jednym sshd_config, i musisz uruchomić ssh tylko na jednym porcie, co ułatwia twoje własne zarządzanie.

edycja 2017-01-21 - Ograniczenie użycia authorized_keysplików.

Jeśli chcesz się upewnić, że użytkownicy nie mogą po prostu samodzielnie wygenerować klucza ssh i użyć go z authorized_keysplikiem do logowania, możesz kontrolować, ustawiając określoną lokalizację dla sshd, aby szukał autoryzowanych kluczy.

W /etc/ssh/sshd_configzmień:

AuthorizedKeysFile  %h/ssh/authorized_keys

do czegoś takiego:

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

Wskazanie kontrolowanego katalogu, do którego użytkownicy nie mają uprawnień do zapisu, oznacza, że ​​nie mogą wygenerować własnego klucza i użyć go do obejścia wprowadzonych reguł.

Możesz dodać coś takiego do /etc/ssh/sshd_config:

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

Powyższe zakłada, że ​​dozwoleni użytkownicy zdalni są nazywani mobileuser1i mobileuser2, a twoja zaufana sieć ma 10.0.0.0 z maską podsieci 255.0.0.0.

Pozwala to dwóm użytkownikom mobilnym zalogować się z dowolnego miejsca, a wszyscy mogą zalogować się z zaufanej sieci. Każdemu użytkownikowi, który nie pasuje do żadnego z tych wzorców (np. fooLogując się zdalnie) zostanie odmówiony dostęp.

Możesz to zrobić, uruchamiając dwa demony ssh i dwa sshd_configpliki. Skopiuj istniejący (np. Z /etc/ssh/sshd_config /etc/ssh/sshd_alt_configalternatywnej konfiguracji konfiguracji (ze manstrony dla sshd_config:

Port

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.

Prawdopodobnie chcesz mieć alternatywny dziennik ssh do innego pliku, i np. Postępuj zgodnie z tym, co zapisano w tym pliku, aby zauważyć nieprawidłowe próby logowania.