ssh-agent e crontab — existe uma boa maneira de encontrar?
Pergunta
Eu escrevi um script simples que e-mails para fora do svn logs de atividade noturna para nossos desenvolvedores.Até agora, eu tenho que correr na mesma máquina como o repositório svn, assim não terá de se preocupar com a autenticação, eu poderia simplesmente usar o svn do file:/// estilo de endereço.
Agora eu estou executando o script em um computador de casa, acessando um repositório remoto, então eu tive que mudar para o svn+ssh:// caminhos.Com o ssh-chave bem configurada, eu já não precisa de inserir senhas para acessar o repositório do svn em circunstâncias normais.
No entanto, crontab não tem acesso para minhas chaves ssh / ssh-agent.Eu li sobre esse problema alguns lugares na web, e é também mencionada aqui, sem resolução de:
Por ssh falha a partir do crontab, mas succedes quando executado a partir de uma linha de comando?
A minha solução foi adicionar no topo do script:
### TOTAL HACK TO MAKE SSH-KEYS WORK ###
eval `ssh-agent -s`
Isso parece funcionar em MacOSX 10.6.
A minha pergunta é: quão terrível é este, e há um caminho melhor?
Solução
Quando você executa o SSH -Agent -s, ele lança um processo de fundo que você precisará matar mais tarde. Então, o mínimo é mudar seu hack para algo como:
eval `ssh-agent -s`
svn stuff
kill $SSH_AGENT_PID
No entanto, não entendo como esse hack está funcionando. Simplesmente executar um agente sem também executar o SSH-ADD não carregará nenhuma chave. Talvez o ssh-agent de MacOS esteja se comportando de maneira diferente do seu página manual diz que sim.
Outras dicas
Além disso...
Se a chave tem um passhphrase, chaveiro vai pedir-lhe uma vez (válido até que você reinicie a máquina ou matar o ssh-agent).
keychain é o que você precisa!Simplesmente instale-o e adicione o código a seguir no seu .bash_profile:
keychain ~/.ssh/id_dsa
Então use o código abaixo no seu script para carregar o ssh-agent variáveis de ambiente:
. ~/.keychain/$HOSTNAME-sh
Nota:chaveiro também gera código para csh de peixe e conchas.
Copiado resposta https://serverfault.com/questions/92683/execute-rsync-command-over-ssh-with-an-ssh-agent-via-crontab
Eu tive um problema parecido. Meu script (que se baseava nas teclas SSH) funcionou quando eu o executei manualmente, mas falhou quando correu com Crontab.
Definindo manualmente a chave apropriada com
ssh -i /path/to/key
não funcionou.
Mas, eventualmente, descobri que o ssh_auth_sock estava vazio quando o Crontab estava executando o SSH. Eu não tinha exatamente certeza do porquê, mas eu apenas
env | grep SSH
Copiou o valor retornado e adicionou essa definição à cabeça do meu Crontab.
SSH_AUTH_SOCK="/tmp/value-you-get-from-above-command"
Estou sem profundidade sobre o que está acontecendo aqui, mas resolveu meu problema. O Crontab corre bem agora.
Uma maneira de recuperar o PID e o soquete da execução do SSH-Agent seria.
SSH_AGENT_PID=`pgrep -U $USER ssh-agent`
for PID in $SSH_AGENT_PID; do
let "FPID = $PID - 1"
FILE=`find /tmp -path "*ssh*" -type s -iname "agent.$FPID"`
export SSH_AGENT_PID="$PID"
export SSH_AUTH_SOCK="$FILE"
done
É claro que isso presume que você possui o PGREP instalado no sistema e existe apenas uma corrida SSH-Agent ou, no caso de múltiplas
Minha solução - com base no PRA's - melhorou um processo para matar, mesmo na falha do script:
eval `ssh-agent`
function cleanup {
/bin/kill $SSH_AGENT_PID
}
trap cleanup EXIT
ssh-add
svn-stuff
Observe que devo ligar para o ssh-add na minha máquina (Scientific Linux 6).
Supondo que você já configurou as configurações SSH e que o script funcione bem do terminal, usando o chaveiro É definitivamente a maneira mais fácil de garantir que o script funcione bem em Crontab também.
Como o chaveiro não está incluído na maioria das derivações do UNIX/Linux, aqui está o procedimento passo a passo.
1. Faça o download do pacote RPM apropriado, dependendo da sua versão do sistema operacional de http://pkgs.repofororge.org/keychain/. Exemplo para o CentOS 6:
wget http://pkgs.repoforge.org/keychain/keychain-2.7.0-1.el6.rf.noarch.rpm
2. Instale o pacote:
sudo rpm -Uvh keychain-2.7.0-1.el6.rf.noarch.rpm
3. Gere arquivos de chaveiro para sua chave SSH, eles estarão localizados no diretório ~/.KeyChain. Exemplo para id_rsa:
keychain ~/.ssh/id_rsa
4. Adicione a seguinte linha ao seu script em qualquer lugar antes do primeiro comando que está usando a autenticação SSH:
source ~/.keychain/$HOSTNAME-sh
Pessoalmente, tentei evitar usar programas adicionais para isso, mas tudo o que eu tentei não funcionou. E isso funcionou muito bem.
Para configurar processos automatizados sem hacks automatizados de senha/senha, eu uso um arquivo de identidade separado que não possui a senha e restringe as entradas Autorizadas de Máquinas de destino prefixadas com from="automated.machine.com" ...
etc ..
Criei um teclado público-privado para a máquina de envio sem uma senha:
ssh-keygen -f .ssh/id_localAuto
(Hit Return quando solicitado a uma senha)
Eu configurei uma entrada de host remoteauto em .ssh/config
:
Host remoteAuto
HostName remote.machine.edu
IdentityFile ~/.ssh/id_localAuto
e o remote.machine.edu:.ssh/authorized_keys com:
...
from="192.168.1.777" ssh-rsa ABCDEFGabcdefg....
...
Então o SSH não precisa da autorização autenticada externamente fornecida pela SSH-Agent ou Keychain, para que você possa usar comandos como:
scp -p remoteAuto:watchdog ./watchdog_remote
rsync -Ca remoteAuto/stuff/* remote_mirror
svn svn+ssh://remoteAuto/path
svn update
...
Inspirado por algumas das outras respostas aqui (principalmente VPK), criei a seguinte entrada Crontab, que não requer um script externo:
PATH=/usr/bin:/bin:/usr/sbin:/sbin
* * * * * SSH_AUTH_SOCK=$(lsof -a -p $(pgrep ssh-agent) -U -F n | sed -n 's/^n//p') ssh hostname remote-command-here
Aqui está uma solução que funcionará se você não puder usar o chaveiro e se você não puder iniciar um agente SSH do seu script (por exemplo, porque sua chave é protegida pela senha).
Execute isso uma vez:
nohup ssh-agent > .ssh-agent-file &
. ssh-agent-file
ssh-add # you'd enter your passphrase here
No script que você está fugindo de Cron:
# start of script
. ${HOME}/.ssh-agent-file
# now your key is available
É claro que isso permite que qualquer pessoa que possa ler '~/.ssh-agent-file' e o soquete correspondente use suas credenciais SSH; portanto, use com cuidado em qualquer ambiente multi-usuário.