stdoutem um servidor CentOS precisa ser canalizado para stdinoutro servidor CentOS. Isso é possível?

Atualizar

ScottPack, MikeyB e jofel têm respostas válidas. Concordei com a resposta de Scott porque, embora minha pergunta não especificasse a segurança como um requisito, é sempre bom estar seguro. No entanto, as sugestões dos outros dois companheiros também funcionarão.

Este é um sim descarado.

Quando se utiliza sshum comando em um servidor remoto, ele executa algum tipo de redirecionamento interno de entrada / saída. Na verdade, acho que esse é um dos recursos sutilmente mais agradáveis ​​do OpenSSH. Especificamente, se você usar sshpara executar um comando arbitrário em um sistema remoto, o ssh será mapeado STDINe STDOUTpara o comando que está sendo executado.

Para fins de exemplo, vamos supor que você deseja criar um tarball de backup, mas não deseja armazená-lo localmente. Vamos dar uma olhada nessa sintaxe:

$ tar -cf - /path/to/backup/dir | ssh remotehost "cat - > backupfile.tar"

Estamos criando um tarball e escrevendo-o para STDOUTcoisas normais. Como estamos usando o ssh para executar um comando remoto, o STDIN é mapeado para o STDINde cat. Que então redirecionamos para um arquivo.

Uma maneira conveniente de canalizar dados entre hosts, quando você não precisa se preocupar com a segurança por cabo, está usando netcatnas duas extremidades da conexão.

Isso também permite que você os configure de forma assíncrona:

No "receptor" (realmente, você terá uma comunicação bidirecional, mas é mais fácil pensar assim), execute:

nc -l -p 5000 > /path/to/backupfile.tar

E no "remetente", execute:

tar cf - /path/to/dir | nc 1.2.3.4 5000

Uma ferramenta muito poderosa para criar conexões uni e bidirecionais é socat. Para uma breve olhada nas possibilidades, veja os exemplos em sua página de manual .

Ele substitui netcatcompletamente as ferramentas similares e oferece suporte para conexões criptografadas ssl. Para iniciantes, pode não ser simples o suficiente, mas é pelo menos bom saber que existe.

TL; DR

As coisas só ficam um pouco mais complicadas quando você tem um servidor bastião que deve ser usado.

1. Você pode passar sshcomo o comando da seguinte sshmaneira:

   • cat local_script.sh | ssh -A usera@bastion ssh -A userb@privateserver "cat > remote_copy_of_local_script.sh; bash remote_copy_of_local_script.sh"

2. Cuidado com pseudo-terminais

Observe que o ponto de maior importância aqui é que ssh, como a maioria das ferramentas, trata stdoute stdincorrige por padrão.

No entanto, quando você começa a ver a opção como Disable pseudo-terminal allocation.e Force pseudo-terminal allocation.pode ser necessário fazer uma pequena tentativa e erro. Mas, como regra geral, você não deseja alterar o ttycomportamento, a menos que esteja tentando corrigir lixo ilegível / binário em um emulador de terminal (o que um humano digita).

Por exemplo, eu costumo usar -Atpara que o agente ssh da minha estação de trabalho seja encaminhado e para que a execução remota do tmux não seja binária (assim ssh -At bastion.internal tmux -L bruno attach). E, para docker também (assim sudo docker exec -it jenkins bash).

No entanto, esses dois -tsinalizadores causam dificuldades para rastrear a corrupção de dados quando tento fazer algo assim:

# copy /etc/init from jenkins to /tmp/init in testjenkins running as a container
ssh -A bastion.internal \
ssh -A jenkins.internal \
sudo tar cf - -C /etc init | \
sudo docker exec -i testjenkins \
bash -c 'tar xvf - -C /tmp'

# note trailing slashes to make this oneliner more readable.

Tente colocar sua chave pública ssh em outro host apenas com um comando

ssh root@example.com 'cat >> .ssh/authorized_keys' < .ssh/id_rsa.pub

Acho que é o mais fácil, depois de configurar nenhum handshake de senha entre servidores para o usuário, você está executando o comando como:

Descomprimido

tar cf - . | ssh servername "cd /path-to-dir && tar xf -"

Compressão em tempo real

tar czf - . | ssh servername "cd /path-to-dir && tar xzf -"