Posso disabilitare l'accesso interattivo alla shell mentre eseguo il tunneling del traffico Web tramite SSH?


12

Sto cercando di implementare il tunneling SSH come soluzione VPN economica per consentire agli utenti esterni di accedere ad applicazioni Web solo per Intranet.

Attualmente sto usando Ubuntu Server 10.04.1 a 64 bit con OpenSSH installato.

Sto usando Putty su scatole di Windows per creare un tunnel su una porta locale al mio server SSH.

start putty -D 9999 mysshserver.com -N

Quindi uso a dire a Firefox di usare un proxy SOCKS su localhost: 9999.

Il flag -N disabiliterà la shell interattiva dal lato client. C'è un modo per farlo sul lato server?

Oltre a disabilitare l'accesso root, usare l'autenticazione con chiave rsa e cambiare la porta predefinita; ci sono altre ovvie pratiche di sicurezza che dovrei seguire a questo scopo? Il mio obiettivo è semplicemente essere in grado di tunnelizzare il traffico web.

Risposte:


15

Dopo quattro anni questa risposta meritava un aggiornamento. Mentre originariamente mi sono usato authorized_keyse probabilmente lo userei ancora in alcuni casi selezionati, puoi anche usare il sshd_configfile di configurazione del server centrale .

sshd_config

Puoi designare (per il tuo particolare caso d'uso) un gruppo, come proxy-onlyo Matchsingoli utenti. In sshd_config. Questo viene fatto dopo le impostazioni globali e revoca, ripete o perfeziona alcune delle impostazioni fornite nelle impostazioni globali.

Nota: alcune delle sintassi / direttive utilizzate sshd_config(5)sono documentate nella manpagina per ssh_config(5). In particolare, assicurati di leggere la sezione PATTERN di ssh_config(5).

Per un gruppo questo significa che il tuo Matchblocco inizierà così:

Match group proxy-only

È possibile Matchi seguenti criteri: User, Group, Host, LocalAddress, LocalPorte Address. Per abbinare diversi criteri basta separare in virgola le coppie modello-criterio ( group proxy-onlysopra).

All'interno di tale blocco, che è tradizionalmente rientrato di conseguenza per brevità (ma non è necessario), è quindi possibile dichiarare le impostazioni che si desidera applicare per il gruppo utenti senza dover modificare ogni singolo authorized_keysfile per i membri di quel gruppo.

L' no-ptyimpostazione da authorized_keysverrebbe rispecchiata da PermitTTY noun'impostazione e command="/sbin/nologin"diventerebbe ForceCommand /sbin/nologin.

Inoltre, puoi anche configurare più impostazioni per soddisfare la paranoia di un amministratore, come ad esempio chrootinserire l'utente nella sua cartella home e finire con qualcosa del genere:

Match group proxy-only
    PermitTTY no
    ForceCommand /sbin/nologin
    ChrootDirectory %h
    # Optionally enable these by un-commenting the needed line
    # AllowTcpForwarding no
    # GatewayPorts yes
    # KbdInteractiveAuthentication no
    # PasswordAuthentication no
    # PubkeyAuthentication yes
    # PermitRootLogin no

(controlla se hai bisogno o vuoi le righe commentate e il commento come necessario)

Il %hè un token che viene sostituito da directory home dell'utente ( %udarebbe il nome utente e %%un segno di percentuale). Ho trovato ChrootDirectoryparticolarmente utile limitare i miei sftp-onlyutenti:

Match group sftp-only
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory %h
    ForceCommand internal-sftp
    PasswordAuthentication no

Tieni presente che solo alcune direttive possono essere utilizzate in un Matchblocco. Consultare la manpagina sshd_config(5)per i dettagli (cercare Match).

authorized_keys

NB: la parte sotto questa osservazione è stata la mia risposta originale. Nel frattempo, ma dipende anche dalle funzionalità della sshdversione esatta, nella maggior parte dei casi sceglierei il metodo sopra descritto.

Sì, è possibile, per quanto possibile assegnare le chiavi pubbliche. Oltre a nologin come raccomandato da ajdecon, suggerirei di impostare quanto segue davanti alla voce chiave in authorized_keys:

no-pty ssh-rsa ...

No pty indica al lato server che non è necessario allocare alcun pseudo-terminale per quella chiave.

Puoi anche forzare l'esecuzione di qualcosa come nologin per una chiave particolare anteponendo questo:

command="/sbin/nologin",no-pty ssh-rsa ...

Si noti che no-ptyda soli non impedirà all'utente della chiave di eseguire comandi. Vedi superuser.com/q/1230979/195460 .
Tad Lispy,

3

Per qualsiasi utente solo tunneling, cambia la shell di login in / sbin / nologin. In questo modo il tuo utente non sarà in grado di accedere a una shell sul server, ma sarà comunque in grado di eseguire l'impostazione dei tunnel ssh dal proprio client.


0

So che questa potrebbe non essere la risposta che stai cercando, ma hai preso in considerazione l'utilizzo di OpenVPN come alternativa?


0

Nel caso in cui si sia pronti a rinunciare all'autenticazione utente / pass e utilizzare le chiavi per l'accesso, è possibile specificare i parametri per ciascuna chiave pubblica.

I parametri notevoli sono:

command = "comando"

Specifica che il comando viene eseguito ogni volta che questa chiave viene utilizzata per l'autenticazione. Il comando fornito dall'utente (se presente) viene ignorato.

e

limitare

Abilitare tutte le restrizioni, ovvero disabilitare port, agent e X11 forwarding, nonché disabilitare l'allocazione PTY e l'esecuzione di ~ / .ssh / rc.

e infine

port forwarding Abilita il port forwarding precedentemente disabilitato dall'opzione di limitazione.

Con questi puoi praticamente limitare l'utente di quella particolare coppia di chiavi che cosa può fare con la sessione SSH.

Sarebbe così:

restrict,port-forwarding,command="/sbin/nologin" ssh-rsa <base64-encoded key>

Vedo che la mia risposta è in qualche modo ridondante su serverfault.com/a/242411/13364 , ma l'ho lasciata a causa dei parametri "restringi" e "port forwarding", che a mio avviso meglio di "no-pty".
asdmin,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.