Não é possível fazer o ssh na máquina remota usando o shell script no Crontab

11

Abaixo está o script que estou tentando executar, que é executado sem nenhum 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

Mas uma vez que eu o adiciono ao crontab, ele não me dá o usuário.

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

Por favor, dê seus pensamentos ...

pode ser que o cron demon esteja em execução, então precisamos incluir alguns binários ...?

Gilles 'SO- parar de ser mau'
fonte
1
Permissão negada (chave pública, gssapi-keyex, gssapi-with-mic, senha). Permissão negada (chave pública, gssapi-keyex, gssapi-with-mic, senha). Permissão negada (chave pública, gssapi-keyex, gssapi-with-mic, senha).
Quais são suas intenções com isso? O que você está tentando alcançar. Só para você saber que não podemos ajudar em nenhuma atividade maliciosa, se essa é a sua intenção
Timothy Frew

Respostas:

14

Você pode fazer conexões ssh dentro de uma sessão cron. O que você precisa é configurar uma autenticação de chave pública para ter acesso sem senha. Para que isso funcione, você precisa ter PubkeyAuthentication yesem cada servidor remoto sshd_config.

Você pode criar um par de chaves públicas / privadas com ou sem uma senha. Se você usar uma senha (recomentada), também precisará iniciar o ssh-agent. Sem uma senha, você só precisa adicionar o parâmetro -i your_identity_fileà sshlinha de comando. sshusará $HOME/.ssh/id_rsacomo padrão.

Eu repliquei seu exemplo usando um par de chaves com uma senha. Aqui está como eu fiz isso.

1) Criou o par de chaves com a senha. Salva a chave privada como ~/.ssh/id_rsa_test, que deve ter as permissões corretas por padrão. Podemos inserir uma senha vazia por não usar uma.

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) Enviou a chave pública para os servidores, fez o mesmo para todos eles. Lembre-se de que eles precisam ter PubkeyAuthenticationativado.

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) Execute o ssh-agent como serviço com -s. Isso não o matará se você sair. Sua saída é um script de shell válido, configurando o ambiente para que o cliente ssh saiba como se conectar a ele. Salvamos isso em um arquivo (apenas a primeira linha é realmente necessária).

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) Carregou o acima em nosso ambiente atual para que possamos ssh-addadicionar nossa chave privada ssh-agent. a senha de cima.

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) Verificado, é adicionado.

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) O script que usei, ligeiramente modificado que o seu. Observe que eu não coloquei o comando ssh entre parênteses e não usei backticks $(), o que é uma alternativa melhor para a substituição de comandos (isso é bashcompatível, você não mencionou qual shell está usando). Eu usei exatamente o mesmo comando ssh que o seu.

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) Meu crontab (observe que meu shé realmente bash)

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

8) A saída

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

O único problema com o uso de uma senha é que você precisa digitá-la manualmente pelo menos uma vez. Portanto, o acima não funcionará automaticamente após uma reinicialização.

forcefsck
fonte
Maravilhoso - obrigado. Eu posso viver com a reinicialização automática após a reinicialização, por enquanto, pelo menos.
Peter Mounce
Use ssh-cron para configurar conexões SSH agendadas para proteger servidores sem expor suas chaves SSH, mas usando o agente SSH. unix.stackexchange.com/questions/8903/…
Luchostein
4

Quem digita a senha? O trabalho cron não pode chegar ao seu ssh-agent, portanto a chave pública não funcionará.

Você precisa fornecer sshum arquivo de chave explicitamente (consulte a -iopção), pois ele não pode consultar um agente; e essa chave deve ter uma senha vazia.

geekosaur
fonte
Tentei passar também o nome de usuário e a senha - ssh -t -t -o ConnectTimeout = 60 usuário @ machine $ 1 finger | cauda -1 | awk '{print $ 1}' </ home / user / passwd ---- i diretório home média está em NFS, para que ele monta a everymachine
Se o ssh tiver algum sentido, ele está usando /dev/ttypara ler a senha em vez de stdin; isso não vai funcionar do cron.
Geekosaur
Tentei dar -i opção, mas sem sorte! ---- ssh -o ConnectTimeout = 60 -i /home/subrahmanyam/.ssh/known_hosts machine $ 1 finger | cauda -1 | awk '{print $ 1}' ------ AVISO: ARQUIVO CHAVE PRIVADA NÃO PROTEGIDA! As permissões 0640 para '/home/user/.ssh/known_hosts' estão muito abertas. É recomendável que seus arquivos de chave privada NÃO sejam acessíveis por outras pessoas. Essa chave privada será ignorada. permissões ruins: ignore key:
Por que está reclamando known_hosts? Mas sim, você precisa ficar atento às permissões - o arquivo da chave privada deve estar no modo 0600 ou 0400, de sua propriedade. Se você precisar de algum outro usuário para poder usá-lo também, examinará as ACLs POSIX ou similares.
Geekosaur
Pensando bem, eu vi o GSSAPI sendo oferecido lá, então outra possibilidade é obter um keytab e usá-lo kinitdentro do cron job. Dito isto, os keytabs também exigem o mesmo cuidado nas permissões; mas sshpelo menos não vai reclamar deles.
Geekosaur #
1

Em vez de armazenar um arquivo temporário como o forcefsck, prefiro usar findpara procurar no agente ativo.

No tópico de um script que precisa de ssh-agent, eu uso:

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

Ele procura pelo ssh-agentsoquete e retorna o primeiro. Ele é restrito apenas ao usuário atual; portanto, você não tentará acidentalmente usar outros usuários e obterá um erro de permissão negada. Você também precisa estar logado com um ativo ssh-agent. (O Ubuntu inicia um agente quando a GUI inicia).

Se você colocar isso em outro script, precisará chamá-lo com sourceou .porque ele precisa definir a SSH_AUTH_SOCKvariável.

reaver277
fonte
0

Use ssh-cron para configurar conexões SSH agendadas para proteger servidores sem expor suas chaves SSH, mas usando o agente SSH.

Luchostein
fonte
0

Você pode executar seu script ou comando no crontab como:

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

ou

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