ssh-under-cron smette di funzionare in OS X 10.7 Lion

12

Appena aggiornato da Snow Leopard a Lion, i miei lavori cron che usano ssh hanno smesso di funzionare. Sembra che ssh-agent non funzioni più come previsto.

Ecco una versione bowdlerized del mio script chiamato-da-cron che ha funzionato benissimo con Snow Leopard:

#!/bin/bash
whoami # just to verify I'm running as myself, not root
ssh-agent # just to see what it outputs    
eval 'ssh-agent'
ssh -vvv REMOTESERVER ls

Quando viene eseguito dal prompt dei comandi, questo script funziona come previsto.

Quando viene eseguito da cron, non funziona. L'output di ssh-agent sembra normale:

SSH_AUTH_SOCK=/tmp/ssh-QRxPUMRxbu/agent.17147; export SSH_AUTH_SOCK;
SSH_AGENT_PID=17148; export SSH_AGENT_PID;
echo Agent pid 17148;
Agent pid 17150

Ma l'output ssh -vvv mostra che fallisce proprio quando la chiave privata deve essere letta:

debug1: Server accepts key: pkalg ssh-dss blen 818
debug2: input_userauth_pk_ok: fp ...
debug3: sign_and_send_pubkey: DSA ...
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: read_passphrase: can't open /dev/tty: Device not configured
debug2: no passphrase given, try next key

In altre parole, mi aspetto che scriva la passphrase per ~/.ssh/id_dsa , che ovviamente non funziona nei lavori cron.

Tutto questo ha funzionato in Snow Leopard.

Notate che ho impostato il Keychain Access in modo che ssh , ssh-agent e ssh-add possano leggere la mia passphrase per il mio file .ssh/id_dsa - di conseguenza posso SSH da un prompt del terminale senza mai dover inserire la mia passphrase.

Questo problema è necessario per eseguire ssh-add ad un certo punto del mio processo di accesso? Eseguirlo da un prompt bash standard non aiuta il cron job (anche se, stranamente, mi chiede la mia passphrase ... che non penso sia necessaria b / c della configurazione di Accesso Portachiavi).

NOTA 1 - prima di reindirizzarmi - Sono consapevole che c'è una domanda simile qui ( Mac OS X Lion e sshpass ) ma riguarda specificamente un programma sshpass che non uso (anche se credo che a questa domanda si possa rispondere anche questa).

NOTA 2 - Mi rendo conto che le chiavi SSH passphrase-less risolverebbero il mio problema; tuttavia preferirei non seguire questa strada.

    
posta John Hart 26.07.2011 - 20:32
fonte

4 risposte

10

Per chi finisce in questa pagina, mi sono reso conto che avrei dovuto postare la risposta:

L'utilizzo di launchd anziché di cron risolve il problema dell'autorizzazione. I lavori di avvio dell'utente (che vengono eseguiti solo quando si è effettuato il login) utilizzano correttamente le informazioni sull'agente SSH sbloccate tramite il portachiavi come parte del login (come parte della gestione delle chiavi OS X standard, nessun altro software richiesto).

Per ridurre al minimo le mie interazioni con launchd, ho creato un singolo lavoro launchd che chiama uno script bash. In questo modo posso semplicemente modificare lo script senza occuparmi di launchd.

Ecco il file di avvio:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.mycron.hourly</string>

  <key>ProgramArguments</key>
  <array>
    <string>/Users/john/bin/cron.hourly</string>
  </array>

  <key>Nice</key>
  <integer>1</integer>

  <key>StartInterval</key>
  <integer>3600</integer> <!-- start every X seconds -->

  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

Ho salvato il file in ~/Library/LaunchAgents/com.mycron.hourly.plist , quindi lo ho caricato con:

launchctl load ~/Library/LaunchAgents/com.mycron.hourly.plist

Una volta caricato, verrà eseguito immediatamente e poi di nuovo ogni 60 minuti.

Se segui la stessa procedura, ti consigliamo di cambiare la stringa "ProgramArguments" con il percorso corretto per il tuo script.

    
risposta data 19.07.2012 - 18:36
fonte
7

L'aggiunta del seguente codice allo script della tua shell bash risolverà il problema:

declare -x SSH_AUTH_SOCK=$( find /tmp/launch-*/Listeners -user your_user -type s | head -1 )

Sostituisci your_user con il tuo nome utente.

Questo codice imposta il valore corretto per SSH_AUTH_SOCK che informa ssh o scp su come comunicare con ssh-agent quando lo script della shell è avviato da cron .

    
risposta data 07.02.2012 - 19:33
fonte
1

Mi aspetto una maggiore sicurezza come sandbox e le modifiche per spostare ulteriormente le cose a 64 bit causano un dolore inaspettato.

Non è una risposta, di per sé, ma launchd sta ricevendo tutto l'amore dalla mela in questi giorni.

Non risolve il problema con cron, ma è più stabile e più persone possono aiutarlo.

    
risposta data 26.07.2011 - 22:22
fonte
1

Per chiunque lo trovi ora, cercando di farlo funzionare in El Capitan, e ancora riluttante a trasformare il tuo cron job su una riga in uno script di avvio, la risposta di Werner Antweiler funziona ancora, ma il percorso è cambiato. Il sotto funzionava per me:

declare -x SSH_AUTH_SOCK=$(find /var/folders/*/*/*/*/agent.* -user your_user -type s | head -1)

NOTA : ricorda di sostituire your_user con il tuo nome utente!

Non mi permetterebbe di inviarlo come commento alla sua risposta in quanto mi manca la reputazione, ma non volevo lasciarla senza aggiornare questo dato che mi ha definitivamente aiutato a configurarlo.

Modifica: 30 marzo 2016

Dopo aver provato questo per un po ', ho bisogno di aggiungere che questo funziona solo dopo che l'agente è stato utilizzato almeno una volta durante il login. L'avvio di una connessione ssh o l'esecuzione manuale di ssh-agent è sufficiente per farlo. È inoltre possibile utilizzare uno script di avvio se si desidera eseguirlo automaticamente. Ho creato un startup.sh che esegue solo ssh-agent e quindi ha utilizzato Script Editor per salvare un file .app con quanto segue e ha aggiunto l'app risultante ai miei elementi di accesso:

do shell script "/path/to/startup.sh"
    
risposta data 22.03.2016 - 12:43
fonte

Leggi altre domande sui tag