Me actualicé de Mac OS X Snow Leopard a Lion . Utilicé varios scripts sshpass
pero después de actualizar a Lion aparece el siguiente error:
Permiso denegado, por favor, intente de nuevo. debug1: read_passphrase: no se puede abrir /dev/tty: dispositivo no configurado depuración1: permanentemente_drop_suid: 502 ssh_askpass: exec(/usr/libexec/ssh-askpass): No existe tal archivo o directorio
Solo puedo conectarme con sshpass
(o escribir la contraseña manualmente). No hay forma de clave pública/privada. He reinstalado MacPorts y sshpass.
¿Cómo puedo obtener ssh-askpass ? ¿Cómo puedo configurar /dev/tty ?
¡Saludos!
Primero debe presentar una queja ante la administración del servidor, observando que la autenticación de clave pública es mucho más segura que una simple contraseña, pero supondré que ya lo ha hecho y que sus administradores son simplemente idiotas.
Lamentablemente, Apple eliminó ssh-askpass cuando integraron su funcionalidad en ssh, scp y ssh-add. Sin embargo, existe un paquete SSHKeychain que proporciona un ssh-askpass con una solicitud de contraseña Cocoa similar a Apple para el paquete openssh de macports. Debería solucionar sus problemas de la manera que desee, tal vez incluso configurando la variable SSH_ASKPASS por usted.
Solo para tu información, por lo general recomendaría no instalar el paquete openssh macports en sí mismo porque rompe la solicitud de contraseña de Apple, pero una vez que hayas instalado SSHKeychain, macports generalmente ofrece un openssh más reciente que Apple.
En mi humilde opinión, no hay nada de malo en incrustar contraseñas en scripts cuando el servidor deshabilita la autenticación de clave pública, es decir, si se preocupan por la seguridad, deberían volver a habilitar las claves públicas. Incluso hay servidores que intencionalmente rompen sshpass. Puede acceder a dichas máquinas utilizando el siguiente script expect:
#!/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
Puede acelerar este script reduciendo los tiempos de espera y los retrasos de send_human.
También me encontré con un problema similar después de actualizar a Mac OS X Lion. Uso Unison para sincronizar un directorio en mi MacBook Pro con mi servidor Linux, pero después de la actualización ya no pude conectarme. El problema es que /usr/libexec/ssh-askpass no está en Lion. Para corregir esto, puede ir a http://westergaard.eu/2011/07/printing-on-wi-from-mac-os-x-lion/?utm_source=rss&utm_medium=rss&utm_campaign=printing-on-wi-from- mac-os-x-lion . Allí puede descargar el archivo Printer-hack.zip. Contiene el archivo ssh-askpass que luego puede mover a /usr/libexec/.
sshpass -p
. ¡Eso no tiene sentido!La forma correcta de solucionar esto es eliminar todas las cosas de sshpass que instaló y simplemente confiar en lo que Apple ya configuró para usted.
De forma predeterminada, ssh-agent ya se está ejecutando (en realidad, está listo para ejecutarse una vez que lo use, a través de launchd). Puede verificar esto desde la terminal con env|grep SSH
la que debería volver con algo como SSH_AUTH_SOCK=/tmp/launch-7D4wfP/Listeners
. Si no se ve así, entonces todavía está anulando el valor predeterminado en uno de sus scripts de inicio de shell.
Luego, almacene su frase de contraseña de clave SSH en su llavero con ssh-add -K
. Una vez hecho esto, cargará automáticamente su clave en su ssh-agent cuando sea necesario.
EDITAR: Vaya, me perdí el bit "no pubkey auth" y lo que hace ssh-pass. Bien, intente configurar la variable de entorno SSH_ASKPASS en un script que imprima su contraseña. Eso hará que ssh ejecute ese script en lugar de ssh_askpass.
Lo que podría estar pasando es que Lion puede ser más estricto con el TTY y no aceptará el entorno que proporciona ssh-pass como un TTY real. Si ese es el caso, será necesario corregir ssh-pass. Tal vez compilar su propio ssh también funcione.
Bien, también enfrenté este mismo problema con AIX. El escenario era errático, a veces el comando se ejecutaba y otras veces arrojaba el /dev/tty
error.
Lo solucioné haciendo lo siguiente: exporto SSH_ASKPASS
a un script de shell que haría eco de la contraseña. y luego ejecutar ./sshpass -p $password $user@$node hostname
. Al hacer esto, los casos de los que ssh se queja /dev/tty
se generan $SSH_ASKPASS
y obtienen la contraseña.
Espero que esto sea útil. Estoy tentado a pensar que esto es más un error de sshpass, pero por supuesto no he depurado más.
Saludos Suriyan
Gilles 'SO- deja de ser malvado'
/dev/tty
" significaría ejecutar el script desde una terminal. Para obtener el indicador de la GUI, necesitassh-askpass
(y no sé por qué ya no lo tiene).El zorro
usuario8411