ssh Autorizzazione negata solo nel processo cron

Avere un problema molto strano. Ho creato un piccolo script bash che esegue un comando su un host remoto tramite ssh (usando l'autenticazione con chiave pubblica).

Quando eseguo manualmente questo script dalla riga di comando, funziona bene, ma quando viene inserito in /etc/cron.hourly non riesce con Permission denied, please try again.errore.

• Ho impostato esplicitamente la chiave nello script utilizzando ssh -i /root/.ssh/id_rsa user@remote "command";
• lo script è in esecuzione come root (ho aggiunto un echo `id` > /tmp/whoami.logper ricontrollare); e
• la chiave ssh non è protetta da password ...

Il sistema è il server Ubuntu 12.04, non ho molto accesso sul lato remoto per la risoluzione dei problemi, ma come ho detto, eseguendo ssh manualmente o lo stesso script bash dalla riga di comando funziona.

Qualche idea sul perché questo accada o su come risolverlo ??

aggiornare

ho scoperto che mi sbagliavo, e la chiave ssh era protetta da password (con il portachiavi che caricava l'agente ssh), quindi perché non è riuscita da uno script ma non durante l'esecuzione dalla sessione bash. L'aggiunta . ~/.keychain/$HOSTNAME-shalla mia sceneggiatura ha risolto il problema (grazie a @grawity che mi ha indicato la giusta direzione e ha fornito una risposta completa).

I comandi interattivi e i lavori cron vengono eseguiti in ambienti diversi: in particolare, una sessione interattiva potrebbe avere un agente SSH in esecuzione o un TGT Kerberos archiviato. A causa del modo in cui vengono sshordinati i metodi di autenticazione, non puoi essere sicuro che la tua chiave venga utilizzata solo perché hai aggiunto l' -iopzione.

• Se è in esecuzione un agente SSH, il sshclient cerca sempre le chiavi dell'agente prima di utilizzare qualsiasi chiave specificata in modo esplicito.

• Se la rete utilizza Kerberos ed è presente un TGT Kerberos, OpenSSH lo utilizzerà prima di provare l'autenticazione con chiave pubblica.

Non so nulla del tuo ambiente, ma entrambe queste possibilità sono facili da verificare:

1. Aggiungi unset SSH_AUTH_SOCKe unset KRB5CCNAMEprima del sshcomando, quindi esegui manualmente lo script modificato.

   Ciò impedirà allo script di vedere l'agente o i ticket Kerberos e utilizzerà solo la chiave specificata in modo esplicito.

2. Aggiungere l' -vopzione per ssh. Questo mostrerà più dettagli su come avviene l'autenticazione.

Puoi anche aggiungere -oIdentitiesOnly=yesal sshcomando; questo lo costringerà ad usare la chiave specificata .

E se aggiungi suggerimenti sull'accesso all'agente da cron, ancora meglio

Questo non è generalmente raccomandato, poiché l'agente è generalmente strettamente legato alla sessione di accesso interattivo. In particolare, viene avviato solo quando si accede e viene eliminato quando si esegue la disconnessione - e ha bisogno della password per sbloccare effettivamente le chiavi SSH (supponendo che fossero protette da password).

Hai citato "Portachiavi" - è questo il programma OS X o lo script Linux? (Non so molto sull'architettura di Mac OS X, ma AFAIK rende molto più difficile accedere all'agente ssh dell'utente da un cronjob ...)

Un'altra soluzione a questo problema è impostare cron su ssh nella casella locale per eseguire a sua volta il comando ssh invece di eseguire il file o il comando dal relativo percorso assoluto locale. Questo memorizza nella cache KRB5CCNAME e funziona dove / percorso / comando no.

# Fails:
0 * * * * /home/user/sshscript.sh

# Works:
0 * * * * /usr/bin/ssh user@localhost /home/user/sshscript.sh

#!/bin/bash
# Works:
unset SSH_AUTH_SOCK
unset KRB5CCNAME
/usr/bin/ssh user@localhost /home/user/sshscript.sh

È possibile utilizzare ssh-cron per impostare connessioni SSH pianificate per proteggere i server senza esporre le chiavi SSH, ma utilizzando l'agente SSH.

puoi eseguire il tuo script o comando in crontab come:

0 * * * * bash -c -l "/home/user/sshscript.sh"

o

0 * * * * bash -c -l "ssh root @ yourhost 'echo $ HOSTNAME'"