Sul lato server, puoi limitare questo impostando la loro shell utente su /bin/true . Ciò consentirà loro di autenticarsi, ma in realtà non eseguire nulla poiché non hanno una shell per eseguirlo. Ciò significa che saranno limitati a qualsiasi sottoinsieme di cose che SSH è in grado di offrire loro. Se offre il port forwarding, saranno comunque in grado di farlo.
Sul lato client, probabilmente vorrai connetterti con il -N . Ciò impedisce al client di CHIEDERE un comando remoto come una shell, si interrompe solo dopo che la parte di autenticazione è stata eseguita. Grazie ai commentatori per averlo segnalato.
Quanto segue ha il vantaggio che anche gli inoltri di socket dell'agente X11 e SSH non sono consentiti, che potrebbero essere ancora consentiti in modo Calebs. Un altro vantaggio è che se l'utente è in grado di modificare la sua shell predefinita in qualsiasi altro modo, ciò limiterà comunque il suo 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-guy per inoltrare qualsiasi connessione TCP attraverso la tua macchina abilitata SSH (connessione a questa macchina, anche a localhost e persino la 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-guy per inoltrare sempre e solo le connessioni alla porta 127.0.0.1 TCP 12345 (poiché è visibile attraverso la tua macchina abilitata SSH).
Quando l'utente si connette normalmente, verrà immediatamente disconnesso a causa del /bin/false verrà attivato il comando che non fa altro che uscire istantaneamente con un codice 1. Se vuoi evitare questo e mantenere aperta la tua connessione di inoltro, aggiungi -N flag all'ssh comando. Questo non tenterà di eseguire alcun comando ma consentirà comunque di impostare gli inoltri TCP.
Un esempio di comando forward che dovrebbe funzionare in quest'ultima configurazione:
ssh -L 12345:127.0.0.1:12345 -N [email protected]
Puoi controllare cosa possono fare le persone in ssh abbinando i gruppi, supponendo 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 facoltativamente specificare le destinazioni a cui possono inoltrare. Se dai loro una home directory ma non crei alcuna directory al suo interno, non potranno 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 gruppi di corrispondenza blocchi per ogni gruppo a cui 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 "nicepeople" sia 500.
Alcune delle opzioni ssh di cui sopra sono disponibili nelle versioni precedenti di openssh, ma non nella sezione Match Group. Match Group è molto limitato in OpenSSH 4.xe versioni precedenti.