Abilita l'accesso alla shell SSH ma disabilita l'accesso SFTP

21

Ho cercato una risposta praticabile a questa domanda e la maggior parte delle risposte include consigli sul perché non farlo. Tuttavia, ecco lo scenario e ciò che lo rende necessario:

Ho un'app console e nel file .prof di ogni utente, c'è un comando di avvio per l'app, e subito dopo il comando che lo avvia, c'è un comando "exit", che li disconnette dal sistema. Voglio solo che siano in grado di accedere a questa app console attraverso l'interfaccia fornita da essa. All'avvio, l'app presenta all'utente un elenco di client a cui è possibile accedere tramite l'app, con ogni client con la propria directory di dati. Agli utenti viene concesso l'accesso solo ai client a cui dovranno accedere.

Ora ecco il problema: se concedo agli utenti l'accesso SSH, potranno anche accedere utilizzando un client SFTP, che fornirà loro l'accesso diretto alle directory dei dati per l'app, che è MOLTO indesiderabile, dal momento che anche accedono alle directory dei dati a cui non dovrebbero avere accesso.

Questa è stata una cosa così semplice da fare quando si utilizza una combinazione telnet / FTP, ma ora che voglio dare agli utenti l'accesso da qualsiasi parte di Internet, non sono stato in grado di trovare un modo per escluderli da SFTP, mentre permettendo comunque loro di accedere alla shell dove possono eseguire l'app.

— sosaisapunk
fonte

8

Ho dimenticato i dettagli, ma penso che SSH ti permetta di limitare gli utenti all'esecuzione di un singolo comando quando effettuano l'accesso. Non ottengono l'accesso completo alla shell se lo configuri. Potrebbe essere utile per il tuo caso d'uso. (Dopotutto è possibile emulare l'accesso SFTP utilizzando SSHFS. La semplice disabilitazione di SFTP non impedirà a un utente moderatamente determinato di accedere a qualsiasi file a cui ha accesso il proprio account utente.)

— David Z

3

Inoltre, potresti voler considerare il "chrooting" dei tuoi utenti. e per l'accesso ai dati di riserva, sembra un problema di progettazione

— Dennis Nolte,

2

Usarlo .profilesembra la soluzione sbagliata. Credo che configurare l'utente con una shell alternativa avrebbe molto più senso.

— Kasperd,

3

Non provare a usare il .profiletrucco per limitare l'accesso, poiché è banale bypassarlo. (vedi la mia risposta per i dettagli)

— Aleksi Torhamo,

22

Modificare:

Nel caso in cui non sia ovvio, la seguente risposta non è intesa come un metodo sicuro per impedire a SFTP di essere utilizzato da chiunque abbia accesso alla shell al server. È solo una risposta che spiega come disabilitarlo dalla visibilità esterna. Per una discussione sulla sicurezza a livello di utente, vedi le risposte di @cpast e @Aleksi Torhamo. Se la sicurezza è il tuo obiettivo, questa risposta non è quella giusta. Se il semplice servizio visibile è il tuo focus, allora questa è la tua risposta.

Ora continuiamo con la risposta originale:

Commenta il supporto sftp in sshd_config (e ovviamente riavvia sshd):

#Subsystem sftp /usr/lib/openssh/sftp-server

— Wesley
fonte

1

A volte la linea può essereSubsystem sftp internal-sftp

— Kondybas il

1

Ho Subsystem sftp /usr/libexec/sftp-server Ma quello ha funzionato. Grazie mille

— sosaisapunk il

16

Questo non sembra plausibile. Se è possibile eseguire comandi arbitrari sul server, è possibile eseguire il programma lato server sftp. Anche se non è installato, è possibile implementarlo nuovamente come comando long shell e fare in modo che il client sftp invii questo comando invece di sftp. Questo metodo potrebbe rendere meno comodo l'uso di sftp ma non c'è modo di impedire a un utente che può eseguire comandi arbitrari di usare quei comandi per effettuare trasferimenti di file.

— R ..

1

@sosaisapunk Questo non è vero. Gli utenti possono eseguire qualsiasi comando desiderino utilizzando ssh user@host command, poiché .profilenon verranno eseguiti affatto se lo fai e quindi la tua app non si avvierà affatto. Possono ottenere l'accesso completo alla shell semplicemente dicendo ssh -t user@host bash. Provalo e vedrai. Il sottosistema è solo un alias di comando; se prima potevano usare sftp, possono comunque usarlo - e qualsiasi altro comando che vogliono. Leggi la mia risposta qui sotto.

— Aleksi Torhamo,

1

@sosaisapunk: No, il punto è che puoi farlo con ssh, ma non con il fatto .profileche non è pensato per la sicurezza ed è facilmente aggirabile. Nella mia risposta, ho elencato tre diversi metodi per farlo con ssh. In breve, basta spostare l'invocazione della tua app da .profileuno script di shell e 1) impostare lo script di shell come shell dell'utente 2) impostare lo script di shell come (correttamente abbinato) ForceCommandin sshd_config3) passare all'autenticazione a chiave pubblica e impostare il shell script come commandin .ssh/authorized_keys. (Inoltre, dovresti usare @name in modo che le persone vengano informate dei commenti)

— Aleksi Torhamo

28

Come altri hanno già detto, la disabilitazione sftpnon è per nulla sufficiente: un utente con sshaccesso illimitato può visualizzare qualsiasi file che il proprio account ha le autorizzazioni per visualizzare, può modificare tutto ciò che ha l'autorizzazione a modificare e può facilmente scaricare tutto ciò che può leggere da solo macchina. L'unico modo per impedire loro di farlo è effettivamente limitare il loro accesso. Inoltre, non è l'ideale fare affidamento .profileper limitare gli utenti, in quanto non è quello per cui (Modifica: come Aleksi menziona nella sua risposta, è in effetti banale aggirare .profile; il fatto .profileè che è per comodità, non per sicurezza, quindi non è inteso a limitare l'utente. Utilizzare le cose progettate per la sicurezza, come le cose seguenti, per fornire sicurezza).

Esistono due modi di base per farlo: è possibile limitarli tramite autorizzazioni per i file o forzarli a eseguire solo l'app della console. Il secondo modo è migliore: assegnare gli utenti che dovrebbero essere limitati all'app della console a un gruppo (ad es. customers); quindi, in sshd_config, aggiungi le seguenti righe:

Match Group customers
ForceCommand /path/to/app

Quello che fa è farlo in modo che tutte le connessioni dagli utenti di quel gruppo aprano l'app console; non possono avviare nient'altro, incluso lo sftpstrumento server. Questo impedisce loro di fare qualsiasi altra cosa con il sistema e, diversamente .profile, lo fa usando il server SSH stesso ( .profileli limita alla shell, ForceCommandimpedisce anche di fare altre cose che non comportano l'avvio di una shell). Inoltre .profile, diversamente , questo è concepito come una cosa di sicurezza; è fatto appositamente per resistere a un utente malintenzionato che lo elude.

L'alternativa (probabilmente inferiore) implicherebbe la creazione di un nuovo utente per eseguire l'app console. Dovresti quindi limitare le directory dei dati a quell'utente, impostare l'app console di proprietà dell'utente e impostare u+ssul programma. Questo è il setuidbit; significa che qualcuno che esegue il programma della console lo fa con le autorizzazioni del proprietario del programma. In questo modo, l'utente stesso non ha accesso alle directory, ma solo attraverso il programma. Tuttavia, probabilmente dovresti semplicemente usare ForceCommand, poiché ciò limita tutti gli accessi a "esegui questo programma".

— cpast
fonte

4

Vorrei aggiungere che ForceCommandnon impedisce il port forwarding SSH.

— nyuszika7h,

1

In realtà, fare affidamento .profileè più che "non ideale"; è facilmente aggirabile (vedi la mia risposta per i dettagli) e quindi non fornisce alcuna protezione, solo un falso senso di sicurezza.

— Aleksi Torhamo,

@AleksiTorhamo Ah. Sospettavo che tu potessi bypassarlo, ma non ero sicuro di come (generalmente sospetto che le cose non destinate alla sicurezza siano aggirabili). Grazie per i dettagli su come!

— Pas

15

Non tentare di farlo .profileperché non fornisce alcuna sicurezza e non limita esattamente nulla!

Non importa ciò che si mette in .profile, dal momento che si può escludere che, semplicemente dando un comando da eseguire sulla riga di comando ssh, in questo modo: ssh user@host command. Puoi comunque ottenere un normale accesso alla shell ssh -t user@host bash.

Disabilitare il sottosistema sftp, come menzionato in un'altra risposta, non aiuta affatto. I sottosistemi sono essenzialmente solo alias di comandi, e puoi sempre usare sftp normalmente sftp -s /path/to/sftp-executable user@host.

Come cpast e alcuni commentatori hanno detto, è necessario utilizzare i meccanismi adeguati per limitare l'accesso. Questo è,

Utilizzare ForceCommandinsshd_config
Usa il login senza password e command="..."dentro.ssh/authorized_keys
Cambia la shell dell'utente in qualcosa che limiti ciò che l'utente può fare

Gli appunti:

command="..." si applica solo per una chiave, quindi non limita l'accesso ssh per l'utente utilizzando una password o un'altra chiave
Potresti anche voler limitare il port forwarding ecc. (Port forwarding, x11 forwarding, agent forwarding e pty allocation sono quelli di cui ho sentito parlare)
- AllowTcpForwarding ecc. in sshd_config
- no-port-forwarding ecc. in .ssh/authorized_keys
Se hai altri demoni (come FTP) in esecuzione, dovresti verificare che non facciano entrare l'utente (Alcuni demoni prendono questa decisione in base alla shell dell'utente, quindi se lo cambi, potresti voler ricontrollare)
Puoi cambiare la shell dell'utente in uno script che fa quello che vuoi; o viene eseguito senza argomenti o similiscript -c 'command-the-user-wanted-to-run'
Entrambi ForceCommanded command="..."eseguono il comando attraverso la shell dell'utente, quindi non funzionano se la shell dell'utente è impostata su es. /bin/falseo/sbin/nologin

Disclaimer: non sono un esperto della questione in alcun modo, quindi mentre posso dire che la .profilecosa non è sicura, non posso promettere che non ci sia "gotcha" con altri metodi che non conosco di. Sono al sicuro per quanto ne so, ma non sarei la prima persona a sbagliare su Internet.

— Aleksi Torhamo
fonte

1

Sembra che almeno per ForceCommande accesso forzato senza password con command=in authorized_keys, mentre è stato bypassato in precedenza, ciò è dovuto a un bug nel server: è destinato a essere protetto da un utente malintenzionato e un utente che lo ignora viene considerato una grave vulnerabilità nel server SSH (ed è quindi una correzione prioritaria). Come fai notare, .profileè aggirabile dal punto di vista del design: poiché non è considerato una funzionalità di sicurezza, un utente che lo ignora è perfettamente OK dal punto di vista dello sviluppatore della shell.

— Pas

1

@cpast: Sì, stavo pensando all'esistenza di più funzionalità come il port forwarding. Voglio dire, se non sapevi che ssh consente il port forwarding e solo usato ForceCommandper limitare l'accesso, e aveva un demone che ascolta solo le connessioni localmente e non esegue l'autenticazione, l'utente ssh potrebbe comunque accedere al demone. Le caratteristiche che ho elencato sono quelle es. Le soluzioni di hosting git di solito si disattivano e non ho ancora visto altre "dall'aspetto malvagio" nelle manpage, ma non ho ancora trovato alcun documento ufficiale "questo è il modo in cui usi in ForceCommandmodo sicuro".

— Aleksi Torhamo,

Certamente ~/.profileè modificabile dall'utente e non è utile per la sicurezza, ma potresti rendere significativa la tecnica di cpast inserendola /etc/profile? È possibile controllare l'UID per limitarlo agli utenti giusti.

— pulcini,

1

@chicks: No, ha lo stesso identico problema. Il problema non è che il file è modificabile dall'utente; Il problema è che entrambi i file possono essere completamente esclusi. I file sono usati solo per le shell di login, che si ottengono se si dice semplicemente ssh user@host, ma se si dice a ssh di eseguire un comando, ad es. ssh user@host command- non si ottiene più una shell di accesso e i file non vengono toccati affatto. Quindi puoi semplicemente escludere qualsiasi restrizione che qualcuno abbia provato a creare con i file semplicemente dando un argomento in più a ssh.

— Aleksi Torhamo,

2

@chicks: Inoltre, ho appena capito che ti riferivi a cpast; il metodo nella risposta di cpast non usa .profile, usa sshd_confige dovrebbe essere sicuro. Indica solo .profileun metodo che non dovresti usare per farlo.

— Aleksi Torhamo,

1

È possibile abilitare SSH e disabilitare SFTP sia a livello globale che per utente / gruppo.

Personalmente ne ho bisogno perché voglio dare accesso ad alcuni repository git su SSH e mi piace disabilitare i sistemi che non sono necessari. In tal caso, SFTP non è necessario.

A livello globale

È possibile disabilitare SFTP per tutti gli utenti in un paio di modi.

Il sottosistema mancante

Il demone SFTP utilizzato da SSH può essere configurato tramite la Subsystemparola chiave. Dal sshd_config(5)manuale:

Subsystem
        Configures an external subsystem (e.g. file transfer daemon).
        Arguments should be a subsystem name and a command (with optional
        arguments) to execute upon subsystem request.

        The command sftp-server(8) implements the “sftp” file transfer
        subsystem.

        Alternately the name “internal-sftp” implements an in-process
        “sftp” server.  This may simplify configurations using
        ChrootDirectory to force a different filesystem root on clients.

        By default no subsystems are defined.

L'ultima riga suggerisce che dovrebbe essere sufficiente non definire alcun sottosistema per "sftp".

Una falsa bugia

Puoi anche disabilitare SFTP impostando il demone SFTP usato da SSH su qualcosa di inutilizzabile. Ad esempio, configurare il sottosistema "sftp" su /bin/false:

Subsystem sftp /bin/false

Quando qualcosa tenta di accedere tramite SFTP, il demone SSH prova a generare il "demone sftp" /bin/false. Il /bin/falseprogramma fa solo una cosa, ovvero restituire un codice di errore. Il tentativo di connessione SFTP viene effettivamente negato.

Per utente / gruppo

È anche possibile disabilitare SFTP per utente, gruppo o un paio di altri criteri.

Questo non funziona se si desidera che l'utente riceva un normale prompt della shell. Né ha senso, dato che potresti aggirare la maggior parte delle cose se hai accesso alla shell. Funzionerà solo se si desidera dare accesso a un programma specifico.

accoppiamento

Per abbinare un set di utenti, è possibile configurare SSH con la Matchparola chiave. Dal sshd_config(5)manuale:

Match
        ...

        The arguments to Match are one or more criteria-pattern pairs or the
        single token All which matches all criteria.  The available criteria
        are User, Group, Host, LocalAddress, LocalPort, and Address.  The
        match patterns may consist of single entries or comma-separated
        lists and may use the wildcard and negation operators described in
        the PATTERNS section of ssh_config(5).

        ...

Un paio di esempi:

Match User eva corrisponde all'utente "eva"
Match User stephen,maria corrisponde agli utenti "stephen" e "maria"
Match Group wheel,adams,simpsons corrisponde ai gruppi "ruota", "adams", "simpsons"

Se vuoi maggiori informazioni, ci sono molti carichi nel sshd_config(5)manuale.

Comando forzato

Normalmente si ottiene la shell di accesso dell'utente quando ci si connette tramite SSH, ma SSH può essere configurato per forzare un determinato comando. Il comando è forzato per qualsiasi connessione SSH, incluso SFTP, e quindi potresti avere la possibilità di forzare il comando che desideri.

Il comando per forzare può essere configurato con la ForceCommandparola chiave. Dal sshd_config(5)manuale:

ForceCommand
        Forces the execution of the command specified by ForceCommand,
        ignoring any command supplied by the client and ~/.ssh/rc if
        present.  The command is invoked by using the user's login shell
        with the -c option.  This applies to shell, command, or subsystem
        execution.  It is most useful inside a Match block.  The command
        originally supplied by the client is available in the
        SSH_ORIGINAL_COMMAND environment variable.  Specifying a command of
        “internal-sftp” will force the use of an in-process sftp server that
        requires no support files when used with ChrootDirectory.  The
        default is “none”.

Quindi puoi forzare il comando vincolato che desideri utilizzare ForceCommand <your command>. Per esempio:

Match User kim
        ForceCommand echo 'successful login man, congrats'

Esempio

Nel mio caso in cui voglio dare accesso a Git, ho solo bisogno che l'utente abbia accesso git-shell. Questa è la sezione che disabilita SFTP per i miei utenti git, insieme ad alcune opzioni di sicurezza:

Match Group git

        # have to do this instead of setting the login shell to `git-shell`,
        # to disable SFTP
        ForceCommand /usr/bin/git-shell -c "$SSH_ORIGINAL_COMMAND"

        # disable stuff we don't need
        AllowAgentForwarding no
        AllowTcpForwarding no
        AllowStreamLocalForwarding no
        PermitOpen none
        PermitTunnel no
        PermitTTY no
        X11Forwarding no

— aude
fonte

Nel mio caso, volevo consentire l'accesso a MySQL (impedendo sia l'accesso SFTP sia le finestre del terminale SSH) per una particolare chiave autorizzata (cioè, nessuna modifica al file sshd_config). Sono riuscito a farlo con le seguenti opzioni ~ / .ssh / authorized_keys per la chiave particolare: command = "/ usr / bin / echo 'È consentito solo l'accesso a MySQL.'", No-pty, no-X11-forwarding, allowopen = "127.0.0.1:3306"

— Martin_ATS il