SSH rende visibili tutte le password digitate quando il comando viene fornito come argomento al comando SSH

Se eseguo questo:

ssh user@server 'mysql -u user -p'

Quando mi chiede la password MySQL e inizio a digitare, la password è visibile sullo schermo. Come posso impedirlo? Se eseguo l'accesso sshe quindi eseguo il comando MySQL, tutto funziona correttamente.

— user110971
fonte

non pensi che il titolo sia piuttosto poco chiaro .. Potresti dire che rende tutto il testo comprese le password visibili. E come si intende ssh per sapere che cosa si sta digitando è una password rispetto ad altri comandi o dati?

— barlop

@barlop Sono aperto ai suggerimenti.

— user110971,

@barlop funziona bene quando si esegue il comando una volta che si è inviato al server. Sto cercando un modo per rendere lo stesso comportamento ssh quando i comandi sono forniti come argomento.

— user110971,

probabilmente non è così necessario, ma è possibile includere dalla console una copia completa / esempio incollato, ad esempio mostrando non solo il comando ssh ma la risposta e il prompt mysql che segue. Puoi cambiare la password in swisscheese in modo da non metterla sul sito al momento non posso provarla

— barlop

@barlop Sono esattamente gli stessi messaggi che ti aspetteresti, ad esempio password ssh seguita da istruzioni password MySQL

— user110971

Risposte:

100

Se si fornisce un comando remoto da eseguire, SSH non alloca un tty, quindi il comando remoto non è in grado di disabilitare l'eco. Puoi forzare SSH a fornire un tty usando l' -topzione:

ssh -t user@server 'mysql -u user -p'

L'opzione equivalente (per -oo per il file di configurazione) è RequestTTY. Ti starei attento a non usarlo in config perché può avere effetti indesiderati per comandi non interattivi .

— Toby Speight
fonte

Oppure puoi modificare ~ / .ssh / config per configurare quell'host specifico per richiedere sempre un TTY. Vedi RequestTTYin man 5 ssh_config.

— un CVn

@ MichaelKjörling (e Toby): forse aggiungere un po 'di avvertimento che l'aggiunta di "-t" dovrebbe essere riservata solo all'uso interattivo, poiché ha effetti collaterali. Per una buona visione di alcuni di questi effetti collaterali: unix.stackexchange.com/a/122624/27616 (da StephaneChazelas)

— Olivier Dulac,

D'accordo - Stavo per suggerire che è un peccato non poter aggiungere impostazioni (come questa) in base al comando remoto (piuttosto che da parte di Host).

— Toby Speight,

Memorizzazione della password in un file di opzioni protetto

Se puoi fidarti ^[*] della sicurezza del computer remoto, puoi archiviare la password in un file di opzioni adeguatamente protetto, come suggerito nel capitolo Linee guida per l'utente finale per la sicurezza della password del manuale, senza la necessità di comunicare ssho digitare ogni tempo.

In particolare è possibile aggiungere una riga nella sezione [client] del file .my.cnfnella home directory:

[client]
password=your_pass

Ovviamente devi impedire che quel file sia accessibile a chiunque tranne te stesso, impostando la modalità di accesso al file su 400 o 600 con, ad es.

chmod 600 ~/.my.cnf

Quindi puoi usare qualcosa di simile

ssh user@server 'mysql -u user110971 --defaults-file=/home/user110971/mysql-opts'

dov'è user110971il nome utente del tuo account.

Costringere ssh ad allocare una pseudo tty ( `ssh -t`)

Questo problema si verifica ogni volta che si invia un comando sshe è necessario inserire l'input perché, per impostazione predefinita, sshnon alloca una pseudo-tty.

È possibile forzare l'allocazione tty con l'opzione -t, (anche più di una se necessario):

-t

Forza l'allocazione pseudo-tty. Questo può essere usato per eseguire programmi arbitrari basati su schermo su una macchina remota, il che può essere molto utile, ad esempio quando si implementano servizi di menu. Le -topzioni multiple impongono l'allocazione di tty, anche se ssh non ha tty locale.

Come potete leggere in questo post Debian (Jul_11_2008) su sudo, è una vecchia questione che ama ripetersi:

ssh user@server "sudo ls"  
password: password  
E ti viene mostrata la password
La soluzione è forzare ssh ad allocare una pseudo-tty, con il flag -t:
ssh -t user@server sudo ls

Nota:

^[*] Se puoi affidarti a lasciare la password in un file accessibile solo da te e root sulclient di lavoro .
Se è possibile riavviare il computer remoto cambiando il sistema operativo o rimuovere l'HDD, il computer non può essere considerato completamente sicuro ... ma in tal caso il database stesso non sarà sicuro.

— Hastur
fonte

forse aggiungere un po 'di avvertimento che l'aggiunta di "-t" dovrebbe essere riservata solo all'uso interattivo, poiché ha effetti collaterali. Per una buona visione di alcuni di questi effetti collaterali: unix.stackexchange.com/a/122624/27616 (da StephaneChazelas)

— Olivier Dulac,

Anche l'opzione mount "hidepid" per proc fs è preziosa. Rende invisibili le tue linee di comando nell'elenco dei processi per altri utenti. Esempio di fstab:

proc /proc proc hidepid=1 0 0

— Bandie
fonte

SSH rende visibili tutte le password digitate quando il comando viene fornito come argomento al comando SSH

Memorizzazione della password in un file di opzioni protetto

Costringere ssh ad allocare una pseudo tty ( ssh -t)

-t

Nota:

Costringere ssh ad allocare una pseudo tty ( `ssh -t`)

`-t`