Non riesco ad accedere a una macchina remota usando lo script della shell in Crontab


11

Di seguito è riportato lo script che sto cercando di eseguire, che viene eseguito senza alcun problema

for i in `seq 200 2100`
do
  usr=(`ssh -t -t -o ConnectTimeout=60 machine$1 finger | tail -1 | awk '{print$1}'`) 
  echo $usr
done

Ma una volta aggiunto a crontab, non mi dà l'utente.

22  12  *  *  *  sh /home/subrahmanyam/Scripts/who.sh

Per favore, dai i tuoi pensieri .....

potrebbe essere cron demon in esecuzione, quindi dobbiamo includere alcuni binari ...?


1
Autorizzazione negata (publickey, gssapi-keyex, gssapi-with-mic, password). Autorizzazione negata (publickey, gssapi-keyex, gssapi-with-mic, password). Autorizzazione negata (publickey, gssapi-keyex, gssapi-with-mic, password).

Quali sono le tue intenzioni con questo? Cosa stai cercando di ottenere. Solo perché sai che non possiamo aiutarti in nessuna attività dannosa se questa è la tua intenzione
Timothy Frew

Risposte:


14

È possibile effettuare connessioni ssh all'interno di una sessione cron. Ciò di cui hai bisogno è configurare un'autenticazione con chiave pubblica per avere accesso senza password. Affinché ciò funzioni, è necessario disporre PubkeyAuthentication yesdi ciascun server remoto sshd_config.

È possibile creare una coppia di chiavi privata / pubblica con o senza passphrase. Se usi una passphrase (raccomandata) devi anche avviare ssh-agent. Senza una passphrase, è sufficiente aggiungere il parametro -i your_identity_filealla sshriga di comando. sshuserà $HOME/.ssh/id_rsacome predefinito.

Ho replicato il tuo esempio usando una coppia di chiavi con una passphrase. Ecco come l'ho fatto.

1) Creata la coppia di chiavi con passphrase. Salvata la chiave privata come ~/.ssh/id_rsa_test, che dovrebbe avere le autorizzazioni corrette per impostazione predefinita. Possiamo inserire una passphrase vuota per non usarne una.

john@coffee:~$ ssh-keygen -N "somephrase" -f .ssh/id_rsa_test
Generating public/private rsa key pair.
Your identification has been saved in .ssh/id_rsa_test.
Your public key has been saved in .ssh/id_rsa_test.pub.
[snip]

2) Ha inviato la chiave pubblica ai server, ha fatto lo stesso per tutti. Ricorda che devono essere PubkeyAuthenticationabilitati.

john@coffee:~$ ssh-copy-id -i .ssh/id_rsa_test server1
The authenticity of host 'server1 (11.22.33.1)' can't be established.
RSA key fingerprint is 79:e8:0d:f5:a3:33:1c:ae:f5:24:55:86:82:31:b2:76.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,11.22.33.1' (RSA) to the list of known hosts.
john@server1's password: 
Now try logging into the machine, with "ssh 'server1'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

3) Eseguire ssh-agent come servizio con -s. Questo non lo ucciderà se ti disconnetti. Il suo output è uno script shell valido, che imposta l'ambiente in modo che il client ssh sappia come connettersi ad esso. Lo salviamo in un file (è davvero necessaria solo la prima riga).

john@coffee:~$ ssh-agent -s | head -n 1 > ssh-agent.cf 
john@coffee:~$ cat ssh-agent.cf 
SSH_AUTH_SOCK=/tmp/ssh-VhyKL22691/agent.22691; export SSH_AUTH_SOCK;

4) Ho caricato quanto sopra nel nostro ambiente attuale in modo che possiamo usare ssh-addper aggiungere la nostra chiave privata a ssh-agent. la passphrase dall'alto.

john@coffee:~$ source ssh-agent.cf 
john@coffee:~$ ssh-add  .ssh/id_rsa_test
Enter passphrase for .ssh/id_rsa_test: 
Identity added: .ssh/id_rsa_test (.ssh/id_rsa_test)

5) Verificato che è stato aggiunto.

john@coffee:~$ ssh-add -l
2048 96:58:94:67:da:67:c0:5f:b9:0c:40:9b:52:62:55:6a .ssh/id_rsa_test (RSA)

6) Lo script che ho usato, leggermente modificato rispetto al tuo. Nota che non ho racchiuso il comando ssh tra parentesi e non ho usato piuttosto i backtick $(), che è un'alternativa migliore per la sostituzione dei comandi (questo è bashcompatibile, non hai menzionato quale shell stai usando). Ho usato esattamente lo stesso comando ssh del tuo.

john@coffee:~$ cat foo.sh 
#!/bin/bash

source /home/john/ssh-agent.cf
for server in server1 server2; do
    usr=$(ssh -t -t -o ConnectTimeout=60 $server finger | tail -1 | awk '{print $1}')
    date=$(ssh -o ConnectTimeout=60 $server date)
    echo "$server - $date - $usr" >> /home/john/foo.log
done

7) Il mio crontab (nota che il mio shè in realtà bash)

john@coffee:~$ crontab -l
# m h  dom mon dow   command
*/1  *  *  *  *  sh /home/john/foo.sh

8) L'uscita

john@coffee:~$ tail -n 4 foo.log
server1 - Wed Mar 23 14:12:03 EET 2011 - john
server2 - Wed Mar 23 14:12:04 EET 2011 - john
server1 - Wed Mar 23 14:13:03 EET 2011 - john
server2 - Wed Mar 23 14:13:04 EET 2011 - john

L'unico problema con l'utilizzo di una passphrase è che è necessario immetterlo manualmente almeno una volta. Quindi, quanto sopra non funzionerà automaticamente dopo un riavvio.


Magnifico - grazie. Posso vivere senza il riavvio automatico dopo il riavvio per ora, almeno.
Peter Mounce,

Utilizzare ssh-cron per impostare connessioni SSH pianificate per proteggere i server senza esporre le chiavi SSH, ma utilizzando l'agente SSH. unix.stackexchange.com/questions/8903/…
Luchostein

4

Chi digita la password? Il cron job non può essere ricevuto dal tuo ssh-agent, quindi la chiave pubblica non funzionerà.

Devi fornire sshesplicitamente un file chiave (vedi l' -iopzione), dal momento che non può interrogare un agente; e quella chiave deve avere una passphrase vuota.


Provato passando anche il nome utente e la password - ssh -t -t -o ConnectTimeout = 60 user @ machine $ 1 finger | coda -1 | awk '{print $ 1}' </ home / user / passwd ---- intendo home directory è su NFS, quindi monta su

Se ssh ha qualche senso, sta usando /dev/ttyper leggere la password invece di stdin; che non funzionerà da cron.
Geekosaur,

Ho provato a dare l'opzione -i ma senza fortuna! ---- ssh -o ConnectTimeout = 60 -i /home/subrahmanyam/.ssh/known_hosts machine $ 1 dito | coda -1 | awk '{print $ 1}' ------ ATTENZIONE: FILE CHIAVE PRIVATO NON PROTETTO! Le autorizzazioni 0640 per '/home/user/.ssh/known_hosts' sono troppo aperte. Si consiglia che i file delle chiavi private NON siano accessibili ad altri. Questa chiave privata verrà ignorata. permessi errati: ignora chiave:

Perché si lamenta known_hosts? Sì, è necessario fare attenzione alle autorizzazioni: il file della chiave privata dovrebbe essere la modalità 0600 o anche 0400, di proprietà dell'utente. Se hai bisogno di un altro utente per poterlo usare anche tu, dovresti esaminare gli ACL POSIX o simili.
Geekosaur,

Vieni a pensarci bene, ho visto GSSAPI offerto in là, quindi un'altra possibilità è quella di ottenere un keytab e usarlo kinitall'interno del lavoro cron. Detto questo, i keytab richiedono anche la stessa attenzione nelle autorizzazioni; ma sshalmeno non si lamentano di loro.
Geekosaur,

1

Piuttosto che archiviare un file temporaneo come ha fatto forcefsck, preferisco usare findper cercare l'agente attivo.

Nell'argomento di uno script che ha bisogno di ssh-agent, io uso:

export SSH_AUTH_SOCK=$(find /run/user/$(id -u)/ -mindepth 2 -maxdepth 2 -path '*keyring-*' -name 'ssh' -print -quit 2>/dev/null)

Cerca il ssh-agentsocket e restituisce il primo. È limitato solo all'utente corrente, pertanto non proverai per sbaglio a utilizzare altri utenti e riceverai un errore di autorizzazione negata. Dovresti anche aver già effettuato l'accesso con un attivo ssh-agent. (Ubuntu avvia un agente all'avvio della GUI).

Se lo metti in un altro script, dovrai chiamarlo con sourceo .perché deve impostare la SSH_AUTH_SOCKvariabile.


0

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


0

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'"
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.