Consentire solo a utenti specifici di accedere tramite ssh su una porta e altri utenti di accedere tramite un'altra porta

Ho il seguente caso d'uso:

• È necessario consentire agli utenti di accedere da una rete sicura e affidabile
• e quindi consentire a un paio (solo due) utenti mobili di accedere in remoto su una macchina Linux Centos.

Posso far funzionare sshd su porte diverse, ad esempio:

• dall'interno va bene farlo funzionare su 22 poiché non voglio farli connettere su altre porte (rovina lo script).
• Per gli utenti mobili esterni, eseguirò l'sshd su una porta diversa, diciamo la porta X (maggiore sicurezza - questo è un tipo di installazione per piccoli uffici).

Per maggiore sicurezza, speravo di configurare sshd per consentire l'accesso solo a determinati utenti sulla porta X (e quindi configurare alcuni avvisi in modo che possiamo sapere quando gli utenti accedono tramite la porta X).

Tuttavia, non riesco a trovare alcuna configurazione come questa nella documentazione sshd. Se non esiste una soluzione come questa, è almeno possibile attivare l'esecuzione di uno script shell ogni volta che qualcuno completa l'accesso sshd sulla porta X? Stavo guardando la documentazione di iptables per vedere se poteva innescare un avviso quando il login sshd è lì ma non è riuscito a trovare nulla.

Ingressi apprezzati

L'esecuzione SSHsu una porta alternativa non conta più come sicurezza. Aggiunge solo un po 'di oscurità e un ulteriore livello di complessità per i tuoi utenti. Aggiunge zero ostacoli alle persone che desiderano interrompere la rete, che utilizzano scanner di porte automatizzati e non si preoccupano della porta su cui è in esecuzione.

Se vuoi rafforzare la sicurezza su un sistema che consente SSH in ingresso basato su Internet remoto, controlla i tuoi utenti sshd_configcome indicato da @Anthon, quindi implementa la sicurezza direttamente in PAM.

Creare due gruppi luserse rusers. Aggiungi gli utenti mobili remoti al rusersgruppo. Utilizzare il modulo PAM pam_succeed_if.so per consentire l'accesso a tali utenti. Aggiungi righe al tuo pam config per ssh:

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

Alcuni moduli pam_succeed_if.so potrebbero richiedere l'uso di una sintassi leggermente diversa, come group = lusers.

Quindi, non solo sta sshdlimitando gli utenti che possono connettersi, ma in caso di errore sshd, hai ancora la protezione offerta dalle restrizioni basate su PAM.

Un ulteriore passaggio per gli utenti remoti è forzare l'uso di ssh_keys con passphrase. Pertanto, gli utenti locali possono accedere con chiavi o password, ma gli utenti remoti devono disporre di una chiave e, se si creano le chiavi per loro, è possibile assicurarsi che la chiave abbia un passphrase associato. Limitando così l'accesso a posizioni che possiedono effettivamente la chiave SSH e la passphrase. E limitare i potenziali vettori di attacco se la password di un utente è compromessa.

In sshd_config:

cambia 2 impostazioni:

ChallengeResponseAuthentication yes

e

PasswordAuthentication yes

per:

ChallengeResponseAuthentication no

e

PasswordAuthentication no

Quindi, l'impostazione predefinita è ora consentire solo l'autenticazione con chiave. Quindi, per gli utenti locali è possibile utilizzare l' matchimpostazione di configurazione per modificare l'impostazione predefinita per gli utenti locali. Supponendo che la tua rete privata locale sia 192.168.1.0/24, aggiungi a sshd_config:

Match Address 192.168.1.0/24
PasswordAuthentication yes

Ora, gli utenti locali possono connettersi con password o chiavi e gli utenti remoti saranno costretti a utilizzare le chiavi. Sta a te creare le chiavi con passphrase.

Come ulteriore vantaggio, devi solo gestire un singolo sshd_confige devi solo eseguire ssh su una singola porta, il che semplifica la tua gestione.

modifica 21-01-2017 - Limitare l'uso dei authorized_keysfile.

Se vuoi assicurarti che gli utenti non possano semplicemente auto-generare una chiave ssh e usarla con un authorized_keysfile per accedere, puoi controllare che impostando una posizione specifica per sshd cercherà le chiavi autorizzate.

In /etc/ssh/sshd_config, cambia:

AuthorizedKeysFile  %h/ssh/authorized_keys

a qualcosa come:

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

Indicare una directory controllata su cui gli utenti non dispongono delle autorizzazioni per scrivere significa che non possono generare la propria chiave e usarla per aggirare le regole che hai messo in atto.

Puoi aggiungere qualcosa del genere al tuo /etc/ssh/sshd_config:

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

Quanto sopra presuppone che il permesso gli utenti remoti sono chiamati mobileuser1e mobileuser2, e che la rete di fiducia è 10.0.0.0 con la subnet mask 255.0.0.0.

Ciò consente ai due utenti mobili di accedere da qualsiasi luogo e tutti possono accedere dalla rete attendibile. A qualsiasi utente che non corrisponde a nessuno di questi pattern (come l' fooaccesso da remoto da parte dell'utente ) verrà negato l'accesso.

Puoi farlo avviando due demoni ssh e due sshd_configfile. Copia quello esistente (ad es. Da /etc/ssh/sshd_config /etc/ssh/sshd_alt_confige nella configurazione di configurazione alternativa (dalla manpagina per sshd_config:

Porta

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.

Probabilmente si desidera avere il registro ssh alternativo in un file diverso, ad esempio seguire ciò che è scritto in quel file per notare tentativi di accesso aberranti.