Mac OS X Lion e sshpass

6

Ho effettuato l'upgrade da Mac OS X Snow Leopard a Lion . Ho usato diversi script con sshpass , ma dopo l'aggiornamento a Lion viene visualizzato il seguente errore:

Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: Device not configured
debug1: permanently_drop_suid: 502
ssh_askpass: exec(/usr/libexec/ssh-askpass): No such file or directory

Posso connettermi solo con sshpass (o digitare manualmente la password). Nessuna chiave pubblica / privata. Ho reinstallato MacPorts e sshpass.

Come posso ottenere ssh-askpass ? Come posso configurare / dev / tty ?

saluta!

    
posta TheFox 22.07.2011 - 15:07
fonte

4 risposte

2

Dovresti prima presentare un reclamo all'amministrazione del server, osservando che l'autenticazione della chiave pubblica è molto più sicura della semplice password, ma suppongo che tu l'abbia già fatto, e che i tuoi amministratori siano semplicemente idioti.

Apple ha rimosso tristemente ssh-askpass quando ha integrato la sua funzionalità in ssh, scp e ssh-add. Esiste comunque un pacchetto SSHKeychain che fornisce un ssh-askpass con una richiesta di password Cocoa simile a Apple per il pacchetto openssh di Macports. Dovrebbe risolvere i tuoi problemi nel modo desiderato, forse anche impostando la variabile SSH_ASKPASS per te.

Solo fyi, di solito mi raccomando di non installare il pacchetto openssh macports perché interrompe il prompt della password di Apple, ma una volta installato SSHKeychain macports di solito offre un openssh più recente di Apple.

Non c'è nulla di sbagliato imho con l'incorporamento delle password negli script quando il server disabilita l'autenticazione della chiave pubblica, ad esempio se si preoccupano della sicurezza, dovrebbero riattivare le chiavi pubbliche. Esistono persino server che interrompono intenzionalmente sshpass. È possibile accedere a tali macchine utilizzando il seguente script previsto:

#!/usr/bin/expect -f
set timeout -1
set send_human {.05 0.1 1 .07 1.5}
eval spawn $argv
match_max 100000
expect {
   -re "USERNAME@(\[0-9A-Za-z_\-\.\]+)'s password: "
     { sleep 0.1 ; send -- "PASSWORD\r" ; sleep 0.3 }
}
interact

Puoi velocizzare questo script riducendo i tempi di sonno e i ritardi send_human.

    
risposta data 11.11.2011 - 16:26
fonte
0

Ho anche avuto un problema simile dopo l'aggiornamento a Mac OS X Lion. Uso Unison per sincronizzare una directory sul mio MacBook Pro con il mio server Linux, ma dopo l'aggiornamento non sono riuscito a connettermi più. Il problema è che / usr / libexec / ssh-askpass è assente in Lion. Per correggere ciò puoi andare su link . Lì puoi scaricare il file Printer-hack.zip. Contiene il file ssh-askpass che puoi quindi spostare in / usr / libexec /.

    
risposta data 27.07.2011 - 01:20
fonte
0

Il modo corretto per risolvere questo problema è rimuovere tutte le informazioni sshpass installate e fare affidamento solo su ciò che Apple ha già configurato per te.

Per impostazione predefinita, ssh-agent è già in esecuzione (in realtà pronto per l'esecuzione una volta che lo si utilizza, tramite launchd). Puoi verificarlo dal terminale con env|grep SSH che dovrebbe tornare con qualcosa come SSH_AUTH_SOCK=/tmp/launch-7D4wfP/Listeners . Se non sembra così, stai comunque sovrascrivendo il valore predefinito in uno degli script di avvio della shell.

Quindi, archivia la passphrase della chiave SSH nel portachiavi con ssh-add -K . Una volta fatto, caricherà automaticamente la chiave nel tuo ssh-agent quando necessario.

EDIT: Oops Ho perso il bit "no pubkey auth" e cosa fa ssh-pass. Ok, prova a impostare la variabile di ambiente SSH_ASKPASS su uno script che stampa la tua password. Questo farà ssh eseguire tale script invece di ssh_askpass.

Ciò che potrebbe accadere è che Lion potrebbe essere più severo riguardo al TTY e non accetterà l'ambiente che ssh-pass fornisce come un vero TTY. Se questo è il caso, allora ssh-pass dovrà essere corretto. Forse anche la compilazione del tuo ssh potrebbe funzionare.

    
risposta data 24.08.2011 - 12:29
fonte
0

OK, ho affrontato lo stesso problema anche con AIX. Lo scenario era irregolare, a volte il comando veniva eseguito e talvolta veniva generato l'errore /dev/tty .

Ci ho lavorato attorno facendo quanto segue: Esportare SSH_ASKPASS in uno script di shell che farebbe eco alla password. e quindi esegui ./sshpass -p $password $user@$node hostname . In questo modo, i casi in cui ssh si lamenta di /dev/tty , genera $SSH_ASKPASS e ottiene la password.

Spero che questo sia utile. Sono tentato di pensare che si tratti più di un bug sshpass, ma ovviamente non ho eseguito il debug di più.

Saluti Suriyan

    
risposta data 13.09.2011 - 18:19
fonte

Leggi altre domande sui tag