Come creare un utente SSH limitato per il port forwarding?

90

ændrük ha suggerito una connessione inversa per ottenere una semplice connessione SSH con qualcun altro (per l'aiuto remoto). Affinché funzioni, è necessario un utente aggiuntivo per accettare la connessione. Questo utente deve essere in grado di inoltrare la propria porta attraverso il server (il server funge da proxy).

Come faccio a creare un utente con restrizioni che non può fare nient'altro di quanto descritto sopra?

Il nuovo utente deve non essere in grado di:

  • esegue i comandi della shell
  • accedi ai file o carica file sul server
  • usa il server come proxy (ad es. webproxy)
  • accedere a servizi locali che altrimenti non erano accessibili pubblicamente a causa di un firewall
  • uccide il server

Riassunto, come faccio a creare un utente SSH limitato che è in grado di connettersi al server SSH senza privilegi, quindi posso connettermi tramite quella connessione con il suo computer?

    
posta Lekensteyn 10.06.2011 - 22:04

2 risposte

142

TL; DR - vai in fondo alla risposta, "Applicare le restrizioni"

L'aggiunta di un utente con restrizioni è composta da due parti: 1. Creazione dell'utente 2. Configurazione del daemon SSH (sshd)

Configurazione sshd

Il posto migliore per conoscere le possibilità di SSH è leggere le relative pagine di manuale:

  • ssh (1)
  • ssh_config (5)
  • sshd (8)
  • sshd_config (5)

Dove può il client SSH eseguire azioni?

Prima di poter limitare qualcosa, è necessario conoscere le funzionalità di SSH. Sputare attraverso le pagine di manuale produce:

  • Esecuzione comandi
  • Caricamento file tramite sftp
  • Port forwarding
    • Il client inoltra una porta (non) utilizzata al server
    • Il server inoltra la sua porta al client
    • Il server inoltra una porta di un altro host al client (proxy-ish)
  • inoltro X11 (inoltro display)
  • Agente di autenticazione che inoltra
  • Inoltro di un dispositivo tunnel

Dalla sezione Autenticazione della pagina di manuale di sshd (8) :

  

Se il client si autentica correttamente, una finestra di dialogo per la preparazione   la sessione è stata inserita. In questo momento il cliente può richiedere cose come    allocare una pseudo-tty, inoltrando le connessioni X11, inoltrando TCP   connessioni o inoltro della connessione dell'agent di autenticazione su   canale sicuro.

     

Dopo questo, il client richiede una shell o l'esecuzione di un comando .   I lati quindi entrano in modalità sessione. In questa modalità, entrambi i lati potrebbero inviare   dati in qualsiasi momento e tali dati vengono inoltrati a / dalla shell o dal comando   sul lato server, e il terminale utente sul lato client.

Opzioni per limitare le funzionalità SSH

I file e le loro opzioni che alterano il comportamento sono:

  • ~/.ssh/authorized_keys : contiene le chiavi a cui è consentito connettersi e che possono essere fornite con le opzioni:
    • command="command" - Il comando fornito dall'utente (se presente) viene ignorato. Tieni presente che il client può specificare l'inoltro TCP e / o X11 a meno che non siano esplicitamente vietati . Nota che questa opzione si applica all'esecuzione di shell, comando o sottosistema.
    • no-agent-forwarding - Proibisce l'inoltro dell'agente di autenticazione quando questa chiave viene utilizzata per l'autenticazione.
    • no-port-forwarding - Proibisce l'inoltro TCP quando questa chiave viene utilizzata per l'autenticazione
    • no-X11-forwarding - "Proibisce l'inoltro X11 quando questa chiave viene utilizzata per l'autenticazione."
    • permitopen="host:port" - Limita l'inoltro della porta locale 'ssh -L' in modo tale che possa connettersi solo all'host e alla porta specificati.
  • ~/.ssh/environment - Questo file viene letto nell'ambiente all'accesso (se esiste). L'elaborazione dell'ambiente è disabilitata per impostazione predefinita ed è controllata tramite l'opzione PermitUserEnvironment
  • ~/.ssh/rc - Contiene le routine di inizializzazione da eseguire prima che la directory home dell'utente sia accessibile.
  • /etc/ssh/sshd_config : il file di configurazione del sistema
    • AllowAgentForwarding - Specifica se l'inoltro ssh-agent (1) è consentito.
    • AllowTcpForwarding
    • ForceCommand - "Forza l'esecuzione del comando specificato da ForceCommand, ignorando qualsiasi comando fornito dal client e ~ / .ssh / rc se presente.Il comando viene richiamato utilizzando la shell di login dell'utente con l'opzione -c."
    • GatewayPorts - "Specifica se gli host remoti possono connettersi alle porte inoltrate per il client, per impostazione predefinita sshd (8) associa i port forwarding remoti all'indirizzo loopback, impedendo così ad altri host remoti di connettersi alle porte inoltrate. usato per specificare che sshd dovrebbe permettere ai port forwarding remoti di collegarsi ad indirizzi non di loopback, permettendo così ad altri host di connettersi. "
    • %codice%:
        

      Specifica le destinazioni a cui è in esecuzione il port forwarding TCP   consentito. La specifica di inoltro deve essere una delle   seguenti moduli:

      PermitOpen host:port
      PermitOpen IPv4_addr:port
      PermitOpen [IPv6_addr]:port
      
           

      È possibile specificare più in avanti separandoli con   spazi bianchi. Un argomento di 'any' può essere usato per rimuovere tutto   restrizioni e consentire eventuali richieste di inoltro. Di default tutto   richieste di port forwarding sono permesse.

    •   
    • PermitOpen - Specifica se è consentito il tun (4) inoltro del dispositivo. L'impostazione predefinita è 'no'
    •   
    • PermitTunnel - Specifica se è consentito l'inoltro X11.L'impostazione predefinita è 'no'
    •   
  •   

Applicazione delle restrizioni

La modifica del file di configurazione a livello di sistema X11Forwarding consente di applicare la configurazione anche se viene applicata l'autenticazione basata su password o se le restrizioni in /etc/ssh/sshd_config vengono rimosse accidentalmente. Se hai modificato i valori predefiniti globali, dovresti decommentare le opzioni di conseguenza.

Match User limited-user
   #AllowTcpForwarding yes
   #X11Forwarding no
   #PermitTunnel no
   #GatewayPorts no
   AllowAgentForwarding no
   PermitOpen localhost:62222
   ForceCommand echo 'This account can only be used for [reason]'

Ora aggiungi un utente:

sudo useradd -m limited-user

L'opzione ~/.ssh/authorized_keys può essere omessa se la shell è impostata su una non shell come ForceCommand (o /bin/false ) come /bin/true non farà nulla.

Ora il client può connettersi solo alla porta 62222 sull'indirizzo di loopback del server su SSH (non ascolterà sull'indirizzo IP pubblico)

Disabilitare /bin/false -c [command] disabilita anche l'uso di AllowTcpForwarding , vanificando così l'uso di un account così limitato per l'inoltro di una singola porta. -R presuppone che la porta 62222 sul server non sia mai in uso perché il client può connettersi felicemente ad essa e ascoltarla anche su di essa.

Se l'inoltro TCP è consentito nella configurazione a livello di sistema e l'autenticazione basata su password disabilitata, è possibile utilizzare anche le impostazioni per-key. Modifica PermitOpen localhost:62222 e aggiungi le opzioni successive prima di ~/.ssh/authorized_keys (con uno spazio tra le opzioni e ssh- ):

command="echo 'This account can only be used for [reason]'",no-agent-forwarding,no-X11-forwarding,permitopen="localhost:62222"

Verifica

Per essere sicuri che funzioni come previsto, è necessario eseguire alcuni test case. Nei seguenti comandi, ssh- deve essere sostituito dal login effettivo se non è impostato in host . Dietro il comando, viene mostrato un comando che deve essere eseguito sul client o sul server (come specificato).

# connection closed:
ssh host
# connection closed (/bin/date is not executed):
ssh host /bin/date
# administratively prohibited (2x):
ssh host -N -D 62222 # client: curl -I --socks5 localhost:62222 example.com
ssh host -N -L 8080:example.com:80 # client: curl -I localhost:8080
sftp host
# should be possible because the client should forward his SSH server
ssh host -N -R 8080:example.com:80 # server: curl -I localhost:8080
# This works, it forwards the client SSH to the server
ssh host -N -R 62222:localhost:22
# unfortunately, the client can listen on that port too. Not a big issue
ssh host -N -L 1234:localhost:62222

Conclusione

Lista di controllo: l'utente SSH non dovrebbe essere in grado di:

  • esegui i comandi della shell - done
  • accedi ai file o carica file sul server - fatto
  • usa il server come proxy (ad es. webproxy) - fatto
  • accedere a servizi locali che altrimenti non erano accessibili pubblicamente a causa di un firewall - parzialmente , il client non può accedere ad altre porte oltre il 62222, ma può ascoltare e connettersi alla porta 62222 sul server
  • uccide il server - completato (nota che questi controlli sono limitati al server SSH. Se hai un altro servizio vulnerabile sulla macchina, potrebbe consentire a un eventuale utente malintenzionato di eseguire comandi, uccidere il server, ecc.)
risposta data Lekensteyn 22.06.2011 - 11:11
2

Sono sicuro che ci sono molte soluzioni a questo e molte più robuste di quelle che sto proponendo. Tuttavia, questo potrebbe essere sufficiente per le tue esigenze. Per fare ciò, suppongo che l'utente sia in grado di eseguire l'autenticazione basata su chiave ssh (il mastice o qualsiasi sys unix dovrebbe supportare questo).

  • Aggiungi un utente come faresti normalmente ('adduser' o qualsiasi altro strumento)

  • Crea gli utenti .ssh dir e .ssh / authorized_keys

your_user $ sudo -Hu ssh_forwarder /bin/bash

ssh_forwarder $ cd ~
ssh_forwarder $ mkdir .ssh
ssh_forwarder $ ( umask 066 && cat > .ssh/authorized_keys ) <<EOF
no-agent-forwarding,no-X11-forwarding,command="read a; exit" ssh-rsa AAAB3NzaC1y....2cD/VN3NtHw== [email protected]
EOF
  • Disattiva l'accesso tramite password a questo account.
your_user $ sudo usermod --lock ssh_forwarder

Ora, l'unico modo in cui l'utente può entrare nel tuo sistema è tramite l'accesso alla chiave ssh corretta, e ssh eseguirà "/ bin / bash -c" leggendo a "" per loro, indipendentemente da cosa tentano di eseguire . 'read a' leggerà semplicemente fino a una nuova riga, e quindi la shell uscirà, quindi l'utente deve solo premere 'invio' per terminare la connessione.

Ci sono molte altre cose che potresti fare in 'command ='. Vedi man authorized_keys e cerca 'comando' per maggiori informazioni.

Se non ti piace il fatto che premendo enter entri la connessione, puoi usare qualcosa come la seguente per la voce 'command =':

command="f=./.fifo.$$ && mkfifo $f && trap \"rm -f $f\" EXIT && read a <$f && echo $a; exit;"

Questo crea solo un fifo temporaneo nella home directory degli utenti, quindi prova a leggerlo. Niente scriverà su quel file, quindi questo si bloccherà all'infinito. Inoltre, se vuoi terminare forzatamente quella connessione, puoi fare qualcosa di simile a:

 your_user$ echo GOODBYE | sudo tee ~ssh_forwarder/.fifo.*

Questo dovrebbe usare pochissime risorse e nulla dovrebbe essere in grado di andare storto in quello script che non finirebbe con la chiusura della shell.

sleep 1h; echo You have been here too long. Good bye.

Non ho visto fuori mano come si potrebbe consentire all'utente di inoltrare in remoto ( ssh -R ) ma limitare ( ssh -L ). Forse si potrebbe usare "permitopen". Googling non è stato molto utile. Sembrerebbe che qualcosa come "no-port-forwarding, permitremoteopen = 10001" sia utile per consentire ssh -R 6901:localhost:6901 .

Questa è una a soluzione. Può essere sicuramente migliorato e qualsiasi apertura di porte remote dovrebbe essere esaminata attentamente. Se il mio obiettivo era quello di consentire a mia nonna di connettersi alla mia LAN in modo da poter usare vnc per vedere il suo schermo, e l'accesso a quelle chiavi era limitato a lei, personalmente mi sentivo ragionevolmente al sicuro. Se questo fosse per un'impresa, sarebbero necessarie indagini più approfondite. Una cosa da tenere presente è che ssh -N non richiede alcuna shell, quindi il codice 'command =' non viene eseguito.

Altri meccanismi, possibilmente più sicuri, possono includere la creazione di una shell personalizzata per l'utente e persino il blocco con apparmour.

    
risposta data smoser 21.06.2011 - 15:09

Leggi altre domande sui tag