Existe um caminho para o SSH / SCP para outro servidor como um usuário diferente, através de um script?

Question

Eu preciso automatizar uma maneira de distribuir arquivos para vários servidores. O problema é claro que eu preciso usar um protocolo seguro (SSH ou SCP) e o nome de usuário / senha em cada servidor é diferente.

O cenário é que temos um servidor master a, com o usuário a_prod e precisamos enviar scripts / configs atualizados, etc. para os servidores b, c, d, ... e nesses servidores os nomes de usuários são b_dev, c_test , d_prod, cada um com senhas exclusivas.

Os nomes de usuários precisam ser únicos entre os ambientes por alguns motivos, lidando com o DB2 e a segurança corporativa.

As chaves compartilhadas não funcionarão nesse cenário, por isso preciso passar os nomes de usuários e as senhas por meio de um script. É um ambiente AIX e não tenho a capacidade de instalar o expect.

Alguma idéia?

Chaves compartilhadas são mencionadas em várias respostas abaixo: Eu tentei algumas maneiras de fazer isso, eu acho que o principal problema é que os IDs de usuários remotos não existem em nenhum outro host, então eu não posso fazer um ssh-keygen para -los no host que eu quero ssh de fazer uma implementação de chave compartilhada com o usuário principal (a_prod) com várias identidades, dependendo do host de destino (b_dev, c_test_d_prod). A chave privada para esses usuários precisa ser gerada no host a para os usuários remotos e, em seguida, suas chaves públicas precisam ser copiadas para os hosts de destino.

    

Answer 1

OK - finalmente consegui que isso funcionasse da seguinte forma:

1. Faça o ssh-keygen em todos os servidores.
2. Configure o arquivo de autorização para cada usuário com sua chave pública.
3. Configure o arquivo de identificação para cada usuário com a chave privada
4. Copie as chaves privadas dos servidores de destino para o servidor do qual você deseja ssh como arquivos exclusivos (b_dev_id_dsa_2048_a, c_test_id_dsa_a, ...)
5. Chame o ssh da seguinte maneira no host a: ssh -i b_dev_id_dsa_2048_a b_dev@b

e viola, finalmente funciona.

Obrigado a todos pela ajuda e, finalmente, ao niXar pelo momento final de Homer Simpson DUH, fazer isso é exatamente o que você faz se o usuário for o mesmo em todos os hosts.

    

Answer 2

"S corporativo (tupidez)": -)

SSH / SCP geralmente vive com o reino da filosofia UNIX, eu acho. É muito raro que os criadores de aplicativos Unix intencionalmente o façam para que o administrador não possa facilmente fazer algo estúpido. Haverá geralmente um aviso como: "Você provavelmente não quer fazer isso porque ... mas, se você realmente quiser, tudo bem!".

No caso de passar uma senha para ssh em um script, eles intencionalmente dificultam isso, porque é apenas uma idéia ruim .

Neste ponto, eu nem me incomodaria com o SSH. Você realmente precisa conversar com o pessoal de segurança corporativa e encontrar uma solução real para o cenário. Se eles não quiserem usar chaves, pergunte a eles o que você deve fazer. Se isso não funcionar, diga aos seus gerentes que o que eles querem não pode ser feito devido a restrições de segurança corporativa. Se os gerentes insistirem que você faça isso, consiga por escrito, ou é o seu rabo na linha

    

Answer 3

Insert standard disclaimer about corporate policy and why it's bad to put user/pass in scripts here.

Mas todos nós trabalhamos no mundo real onde às vezes não faz sentido. Soo .. Existem muitas ferramentas que permitem fazer isso. A Shell não tem uma maneira interna de fazer isso funcionar. Minha arma de escolha para scripts muito rápidos e sujos dessa natureza é Expect. É incrivelmente fácil de correr.

#!/usr/bin/expect

set nodename "hostname"
set username "user"
set password "pass"
set prompt "your prompt on the remote system"

eval spawn ssh -x $user@$nodeaddy

set timeout 15

expect "password:" { send "$password\r" }
expect "$prompt" { send "script\r" }
exit 0

Obviamente, isso pode ou não funcionar para você, mas você pode ver na sintaxe o quão simples é trabalhar.

    

Answer 4

Primeiro, um aviso: tenha cuidado para não criar um problema de segurança em nome da conveniência. Kevin e Kyle trazem bons pontos. Armazenar um monte de combinações de nome de usuário / senha em um arquivo (mesmo um banco de dados criptografado) é provavelmente uma idéia muito ruim e pode violar a política corporativa.

A solução para o seu problema pode ser um certificado do lado do cliente. Veja os artigos abaixo para mais informações:

• Configurando chaves SSH para acesso sem uma senha
• Executar comandos remotos com SSH

Answer 5

Supondo que um par de chaves privadas públicas seja permitido pela política corporativa, isso não é tão difícil de alcançar. Para obter um nome de usuário diferente do usuário que está executando ssh (o script), use username@host . A parte mais difícil é obter as chaves privadas apropriadas funcionando. Supondo que por causa de algum tipo de falsa sensação de segurança cada host deve usar um par de chaves diferente (caso contrário é mais simples) você deve criar um arquivo de configuração que informe ao cliente qual par usar para qual host (você também pode especificar o nome de usuário no arquivo).

Para o openssh, o arquivo seria parecido com

host a_prod
    user usera
    IdentityFile ~/.ssh/keyfora_prod

host b_dev
    user userb
    IdentityFile ~/.ssh/keyforb_prod

etc.

Lembre-se de que essa configuração não é realmente mais segura. Se alguém puder obter acesso a este usuário neste computador, ele poderá ler todas as chaves privadas (que não podem ter uma senha se as coisas tiverem que ser seguras, ou você deve usar o ssh_agent), bem como senhas codificadas. Como não há razão para os arquivos de chave privada residirem em qualquer outro lugar, mas no diretório ssh deste usuário (quando perdido, pode-se facilmente criar uma nova chave) ter quatro arquivos não é diferente de ter um a partir da perspectiva de segurança. p>     

Answer 6

Sem chaves privadas ou Expect ou algo parecido, não vejo como você pode fazer isso de forma automática. Alguém Tem que Ceder.

Você tem algo para trabalhar, não é? Eu suponho que você não tem Perl por aí desde que você poderia usar o Expect.pm? Python? Qualquer coisa? Simplesmente velho e feio ksh? Conte-nos mais.

Se você não tiver permissão para usar uma linguagem de programação, precisará inserir a passagem manualmente. Nesse caso, você pode usar:

scp myfile b_dev@b_prod:/path/to/dest

Se lotes estiverem envolvidos, considere o uso de SFTP. Você poderia então usar o lftp, e não ter que digitar a senha, aqui diretamente da página do manual:

lftp [-d] [-e cmd] [-p port] [-u user[,pass]] [site]

Mas se você não pode esperar, duvido que você possa usar o lftp. Você pode?

/ Oh, eu odeio porcaria proprietária do Unix

    

Answer 7

Não é uma boa ideia, mas se você realmente precisa fazer isso, o sshpass pode ajudá-lo: link

    

Answer 8

Eu tive que fazer algo parecido, apenas para trás. Estamos tirando arquivos de um monte de servidores, e foi assim que fizemos.

awk '{FS="|"; printf("rsync %s:%s %s &\n", $1, $2, $3)}' config | sh

Crie um arquivo chamado config e nele coloque as linhas que deseja executar. (por favor note: você precisa inserir uma linha em branco para começar).

Do jeito que está configurado agora, você colocaria [email protected]|(folder on remote server)|(folder on local server) em config, e ele rsync os dois. Você vai querer trocar o comando rsync no comando awk para fazer o oposto.

Isso funcionaria bem com a autenticação ssh-key, que é o que usamos.

    

Answer 9

Eu também gostaria de sugerir a criação de chaves SSH para a autenticação e usar uma ferramenta como unison ou lsyncd (dependendo da sua necessidade) para manter os arquivos em sincronia.

Se a autenticação baseada em chave não for uma opção, você pode usar "esperar" ( link ) para criar um script isto. Espere verificações para um outup definido (digamos a pergunta para a senha) e relacionado a isso entre uma string definida (nesse exemplo a senha).

Mas, novamente, como sugerido, eu preferiria a solução de chave ssh.