Quanto è sicuro per proteggere una chiave ssh senza passphrase utilizzando l'opzione "command" nel file authorized_keys?

Ci sono momentjs in cui utilizzare chiavi ssh con passphrase vuota è altamente auspicabile (backup, …). Il problema noto è che tali chiavi sono sicure solo al punto in cui vengono trattenute da mani non affidate.

Tuttavia, nel caso in cui sarebbero compromessi, tali chiavi potrebbero essere ulteriormente protette dal fare danni troppo danneggiando alcune opzioni nel file authorized_keys del server, ad esempio:

 command="/usr/bin/foo",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAA..... 

Teoricamente, questa chiave potrebbe essere utilizzata solo per eseguire command /usr/bin/foo sul server. Un nuovo problema si presenta poiché uno avrebbe bisogno di uno speciale tasto dedicato per each command.

Per questa ragione, una variante più elaborata può essere trovata su Internet (ad esempio su questo stesso sito: sshd_config rispetto al parametro di command autorizzato_keys ) che consiste nell'installazione di una chiave generica limitata a uno script creato localmente che avrebbe utilizzato la variabile di ambiente SSH_ORIGINAL_COMMAND impostato da ssh.

La chiusura della chiave (limitata) in chiave authorized_keys sarebbe quindi simile a:

 command="/usr/local/bin/myssh",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAA..... 

e lo script myssh sarebbe simile:

 #!/bin/sh msg="Command not allowed with this key" case "$SSH_ORIGINAL_COMMAND" in *\&*) echo $msg ;; *\(*) echo $msg ;; *\{*) echo $msg ;; *\;*) echo $msg ;; *\<*) echo $msg ;; *\`*) echo $msg ;; *\|*) echo $msg ;; rsync\ --server*) # optionnally check for extra arguments # .... # then $SSH_ORIGINAL_COMMAND ;; some-local-script*) # optionnally check for extra arguments # .... # then $SSH_ORIGINAL_COMMAND ;; *) echo $msg ;; esac 

La mia unica domanda è: si può essere certi che una chiave protetta non possa uscire dalla sua gabbia ?

Grazie in anticipo !

3 Solutions collect form web for “Quanto è sicuro per proteggere una chiave ssh senza passphrase utilizzando l'opzione "command" nel file authorized_keys?”

In realtà, il gitolite utilizza lo stesso metodo per autenticare l'utente (identificare la base utente sulla chiave SSH utilizzata) e limitare ciò che l'utente può eseguire (solo il command che inizia il gitolite).

gitolite è usato da kernel.org per il controllo dell'accesso il loro repo git, quindi penso che questo metodo dovrebbe essere abbastanza affidabile. 1

Dipende dalla sicurezza dello script wrapper e dai comandi consentiti.

Lo script wrapper deve proteggere dai tentativi di eseguire più comandi (ad esempio allowed-command blah; other-command ) o abuso delle differenze PATH . Probabilmente scriverò lo script per call i comandi consentiti con il loro path completo e utilizzare exec per impedire un'ulteriore interpretazione del command fornito dal client:

 set -- $SSH_ORIGINAL_COMMAND case "$SSH_ORIGINAL_COMMAND" in rsync\ --server*) shift 2; exec /usr/bin/rsync --server "$@" ;; 

È inoltre necessario assicurarsi che i comandi consentiti non dispongano di un meccanismo per eseguire altri comandi. Ad esempio, rsync -e "other-command" renderebbe rsync eseguire un command diverso. ( --server dovrebbe impedire questo nello script precedente).

Io non sono un esperto di ssh o di sicurezza, ma bloccando un qualche tipo di bug in ssh o il tuo script 'myssh' non riesco a vedere problemi di sicurezza con quello. Ma tu sai quel vecchio adagio, meglio che scusarmi. Forse è anche ansible configurare il filtraggio basato su IP, se applicabile.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.