Come limitare un utente SSH per consentire solo il tunneling SSH?

Come posso limitare un utente sul server SSH per consentire loro solo i privilegi per TUNNELING SSH ? cioè Quindi non possono eseguire comandi anche se accedono tramite SSH.

I miei server Linux sono Ubuntu 11.04 e OpenWrt.

linux ssh account-restrictions

— LanceBaynes
fonte

Risposte:

Sul lato server, è possibile limitare ciò impostando la shell utente su /bin/true. Ciò consentirà loro di autenticarsi, ma in realtà non eseguiranno nulla poiché non ottengono una shell per eseguirlo. Ciò significa che saranno limitati a qualsiasi sottoinsieme di cose che SSH è in grado di offrire. Se offre il port forwarding, saranno comunque in grado di farlo.

Sul lato client, probabilmente vorrai connetterti con -N. Questo impedisce al client di CHIEDERE un comando remoto come una shell, si ferma solo dopo aver completato la parte di autenticazione. _{Grazie ai commentatori per averlo segnalato.}

— Caleb
fonte

Proverò questo qui: P thx!

— LanceBaynes,

Per aggiungere alla risposta di Caleb, potrebbe anche essere necessario dire al client di non eseguire una shell. Con la riga di comando openssh, questo viene fatto con il flag -N. C'è un'opzione simile in PuTTY, ma non ricordo il nome esatto.

— Bill B,

hmm, questa è fondamentalmente la sicurezza lato client, no? Sto cercando un'impostazione di sicurezza lato server, ma grazie!

— LanceBaynes,

Spiacente, non ero chiaro - intendevo in combinazione con l'impostazione del server. È stata la mia esperienza in passato che se si imposta la shell su qualcosa che non è una shell, non è possibile connettersi affatto perché tenta di aprire una shell ma non è possibile. Pertanto, la sicurezza viene applicata sul lato server (utilizzando il metodo di Caleb) ma se si verificano problemi di connessione, potrebbe essere necessario impostare l'interruttore sul lato client.

— Bill B,

Si crea tale utente con useradd sshtunnel -m -d /home/sshtunnel -s /bin/true.

— fracz,

Quanto segue presenta il vantaggio che non sono consentiti inoltri di socket dell'agente X11 e SSH, che potrebbero essere comunque consentiti in modo Calebs. Un altro vantaggio è che se l'utente è in grado di modificare la shell predefinita in qualsiasi altro modo, ciò limiterà l'accesso SSH ai soli inoltri TCP.

Inserisci quanto segue nel tuo /etc/ssh/sshd_config:

Match User that-restricted-guy
  AllowTcpForwarding yes
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

per consentire all'utente that-restricted-guydi inoltrare qualsiasi connessione TCP attraverso la macchina abilitata per SSH (connessione a questa macchina, anche localhoste persino connessione da questa macchina ad altre macchine).

Se lo vuoi ancora più restrittivo (che è una buona idea) puoi anche fare quanto segue:

Match User even-more-restricted-guy
  PermitOpen 127.0.0.1:12345
  X11Forwarding no
  AllowAgentForwarding no
  ForceCommand /bin/false

Ciò consentirà all'utente even-more-restricted-guydi inoltrare sempre e solo le connessioni alla porta TCP 127.0.0.1 12345 (poiché è visibile attraverso la macchina abilitata per SSH).

Quando l'utente si connette normalmente, ora verrà immediatamente disconnesso perché /bin/falseverrà attivato il comando che non fa altro che uscire istantaneamente con un codice di 1. Se si desidera evitare ciò e mantenere aperta la connessione di inoltro, aggiungere il -Nflag al sshcomando. Ciò non tenterà di eseguire alcun comando ma consentirà comunque di impostare gli inoltri TCP.

Un esempio di un comando forward che dovrebbe funzionare in quest'ultima configurazione:

ssh -L 12345:127.0.0.1:12345 -N even-more-restricted-guy@insert-your-machine

— AEF
fonte

Ho riformulato la risposta come una soluzione migliorata rispetto alla risposta di Calebs.

— aef

Sicuro. Anche io ho pulito. È bello vedere risolto il malinteso. Buona notte.

— Jakuje,

Puoi controllare cosa le persone possono fare in ssh abbinando i gruppi assumendo che la tua versione di ssh sia abbastanza nuova da supportarla (openssh 5.x +).

Fondamentalmente, li trattiamo come se fossero utenti sftp, ma consentiamo l'inoltro tcp e specificiamo facoltativamente le destinazioni a cui possono inoltrare. Se dai loro una home directory ma non crei alcuna directory sotto di essa, non possono trasferire alcun file perché non avranno il permesso di farlo.

Match Group                     nicepeople
    PubkeyAuthentication        yes
    PasswordAuthentication      yes
    PermitEmptyPasswords        no
    GatewayPorts                no
    ChrootDirectory             /opt/dummy_location/%u
    ForceCommand                internal-sftp
    AllowTcpForwarding          yes
        PermitOpen              192.168.0.8:22
        PermitOpen              192.168.0.5:8080
    # Or leave out the PermitOpen to allow forwarding to anywhere.
    HostbasedAuthentication     no
    RhostsRSAAuthentication     no
    AllowAgentForwarding        no
    Banner                      none

Puoi ripetere questi blocchi di gruppi di corrispondenza per ciascun gruppo che desideri fornire comportamenti o restrizioni diversi.

Puoi controllare ulteriormente dove questa persona può andare sulla rete usando iptables

/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -j REJECT
/sbin/iptables -I OUTPUT -m owner --gid-owner 500 -m tcp -p tcp -d 192.168.0.0/24 -j ACCEPT

Ciò presuppone che il GID del gruppo "simpatici" sia 500.

Alcune delle opzioni ssh sopra sono disponibili nelle versioni precedenti di openssh, ma non nella sezione Gruppo di corrispondenza. Match Group è molto limitato in OpenSSH 4.xe versioni precedenti.

— Aaron
fonte