Estoy almacenando varias contraseñas (por ejemplo, para servidores de correo electrónico remotos) en mi llavero. Desde la línea de comandos, cuando inicie sesión localmente, puedo recuperarlos a través de:
security unlock-keychain ~/Library/Keychains/login.keychain
<enter password>
security find-internet-password -s smtp.gmail.com -a foo@gmail.com
<dumps keychain attributes, not including password>
security find-internet-password -s smtp.gmail.com -a foo@gmail.com -g
<dumps keychain attributes, including password>Sin embargo, los resultados no se pueden lograr cuando se ejecuta de forma remota (enviando a la caja desde otro lugar):
security unlock-keychain ~/Library/Keychains/login.keychain
<enter password>
security find-internet-password -s smtp.gmail.com -a foo@gmail.com
<dumps keychain attributes, not including password>
security find-internet-password -s smtp.gmail.com -a foo@gmail.com -g
<nothing printed, to stdout or stderr>Además, el valor de retorno del comando final (usando -g) es 36.
Volqué el resultado de setun inicio de sesión local y lo comparé con uno remoto, y las variables de entorno que faltan son:
Apple_PubSub_Socket_Render
GPG_AGENT_INFO
SECURITYSESSIONID
TERM_PROGRAM
TERM_PROGRAM_VERSION
TERM_SESSION_ID
XPC_FLAGS
XPC_SERVICE_NAME¿Qué me estoy perdiendo? He SSH_AUTH_SOCKestablecido un valor válido (devuelto desde ssh-agent).
Respuestas:
Al reproducir esto para investigar, me doy cuenta de que tengo mi llavero configurado para "Confirmar antes de permitir el acceso". Entonces, cuando realizo el
find-internet-passwordlocal con la-gbandera, aparece un cuadro de diálogo que indica que la seguridad quiere usar su información confidencial almacenada en "smtp". gmail.com "en su llavero. Si hago clic en "Permitir", entonces funciona, si hago clic en "Denegar", falla de manera similar alsshcaso, con un código de retorno de51.Cuando pruebo el comando de forma remota a través de
ssh, el-gresultado inmediato es un error, con el estado del36que está informando.Sospecho que esto se debe a que, cuando entras
ssh, no hay forma de que el sistema muestre un cuadro de diálogo que te permita confirmar que deseas permitir que elsecuritycomando acceda a esta información.Pude hacer que el comando funcionara mientras estaba conectado al
sshhacer clic primero en la opción "Permitir siempre" al ejecutar el comando localmente. Esto actualiza los permisos en Keychain para que ya no necesite responder al diálogo (incluso localmente), lo que también permite que funcione de forma remota.Sin embargo, no sé si esto será completamente útil para usted, ya que creo que significa que deberá otorgarle
securityacceso preventivo al programa a cualquier elemento de llavero al que desee acceder de forma remota. ¿Es posible escribir un guión para hacer esto?Si está experimentando esto manualmente y luego desea revocar este acceso, puede ir al elemento afectado en Acceso a llaveros, elegir Obtener información y mirar la pestaña Control de acceso . Verá una entrada para
securityallí, que puede eliminar:fuente
security unlock-keychain ~/Library/Keychains/login.keychainen la sesión remota donde está tratando de usar el llavero. Esto le pedirá su contraseña, por lo que no puede hacerlo en un script. Puede haber formas de lograr esto sin una contraseña, pero eso está fuera del alcance de esta pregunta :)/Users/[user]/Library/Keychains/ruta predeterminada , puede omitir la ruta completa e ir con solologin.keychain.security -i unlock-keychainfunciona para mí en MacOS 10.13.4 High Sierra.
Después de investigar la solución de karthick, encontré esto. El -i hace que el comando sea interactivo y le solicita su contraseña en el terminal.
fuente
Mientras el llavero de seguridad esté en la ubicación predeterminada, puede ejecutar el siguiente comando para desbloquearlo. No solicita una contraseña. Funcionó de forma remota.
security unlock-keychain -p "enter password"fuente