Se fornisci un comando remoto da eseguire, SSH non alloca un tty, quindi il comando remoto non è in grado di disabilitare echo. Puoi forzare SSH a fornire un tty usando -t
opzione:
ssh -t [email protected] 'mysql -u user -p'
L'opzione equivalente (per -o
o per il file di configurazione) è RequestTTY
. Metterei in guardia dall'usarlo in config perché può avere effetti indesiderati per i comandi non interattivi.
Memorizzazione della password in un file di opzioni protetto
Se puoi fidarti della sicurezza del computer remoto, puoi memorizzare la password in un file di opzioni opportunamente protetto, come suggerito nelle Linee guida per l'utente finale per la sicurezza delle password capitolo del manuale, senza la necessità di comunicare tramite ssh
o per digitare ogni volta.
Nello specifico puoi aggiungere una riga nella sezione [client] del file .my.cnf
nella tua 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 come
ssh [email protected] 'mysql -u user110971 --defaults-file=/home/user110971/mysql-opts'
dove user110971
è il nome utente del tuo account.
Forzare ssh ad allocare uno pseudo tty (ssh -t
)
Questo problema si verifica ogni volta che invii un comando tramite ssh
e devi inserire l'input perché, per impostazione predefinita, ssh
non allocherà uno pseudo-tty.
Puoi forzare l'allocazione tty con l'opzione -t
, (anche più di uno se necessario):
-t
Forza allocazione pseudo-tty. Questo può essere utilizzato per eseguire programmi basati su schermo arbitrari su una macchina remota, che può essere molto utile, ad es. durante l'implementazione dei servizi di menu. Più
-t
opzioni forzano l'allocazione tty, anche se ssh non ha tty locale.
Come puoi leggere in questo post Debian (Jul_11_2008) su sudo
, è un vecchio problema che ama ripresentarsi:
ssh [email protected] "sudo ls" password: password
E la password ti viene mostrata
La soluzione è forzare ssh ad allocare una pseudo-tty, con il flag -t:
ssh -t [email protected] sudo ls
Nota:
Se puoi fare affidamento sul lasciare la password in un file accessibile solo da te e root sul funzionamento cliente.
Se è possibile riavviare il computer remoto cambiando sistema operativo o rimuovere l'HDD, il computer non può essere considerato completamente sicuro... ma in tal caso il database stesso non sarà sicuro.
Anche l'opzione di montaggio "hidepid" per proc fs è preziosa. Rende le tue righe di comando invisibili nell'elenco dei processi per altri utenti.fstab example:
proc /proc proc hidepid=1 0 0