Can I pipe stdout on one server to stdin on another server?

Question

stdout on one CentOS server needs to be piped to stdin on another CentOS server. Is this possible?

Update

ScottPack, MikeyB and jofel all have valid answers. I awarded the answer to Scott because, even though my question didn't specify security as a requirement, it's always nice to be safe. However, the other two fellows' suggestions will also work.

Answer 1

This is an unabashed yes. When one uses ssh to execute a command on a remote server it performs some kind of fancy internal input/output redirection. In fact, I find this to be one of the subtly nicer features of OpenSSH. Specifically, if you use ssh to execute an arbitrary command on a remote system, then ssh will map STDIN and sTDOUT to that of the command being executed.

For the purposes of an example, let's assume you want to create a backup tarball, but don't want to, or can't, store it locally. Let's have a gander at this syntax:

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

We're creating a tarball, and writing it to STDOUT, normal stuff. Since we're using ssh to execute a remote command, STDIN gets mapped to the STDIN of cat. Which we then redirect to a file.

Answer 2

A convenient way of piping data between hosts when you don't need to worry about security over the wire is using netcat on both ends on the connection.

This also lets you set them up asynchronously:

On the "receiver" (really, you'll have two-way communication, but it's easier to think of it like this), run:

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

And on the "sender", run:

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

Answer 3

A very powerful tool for creating uni- and bidirectional connections is socat. For a short look at the possibilities, look at the examples in its manpage.

It replaces netcat and similar tools completely and has support for ssl encrypted connections. For beginners, it might be not simple enough, but it is at least good to know that it exists.

Answer 4

TL;DR

1. You can pass ssh as the command to ssh like so cat local_script.sh | ssh -A usera@bastion ssh -A userb@privateserver "cat > remote_script.sh; bash remote_script.sh"
2. Beware of pseudo-terminals

---

Note that the point of key importance here is that ssh, like most tools, just treats stdout and stdin correct by default.

However, when you start to see option like Disable pseudo-terminal allocation. and Force pseudo-terminal allocation. you may need to do a little trial and error. But, as a general rule you don't want to alter tty behavior unless you are trying to fix garbled/binary junk in a terminal emulator (what a human types in).

For example, I tend to use -At so that my workstation's ssh-agent gets forwarded, and so that running tmux remotely doesn't barf binary (like so ssh -At bastion.internal tmux -L bruno attach). And, for docker too (like so sudo docker exec -it jenkins bash).

However, those two -t flags cause some hard to track down data corruption when I try to do something like this:

# 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.

Answer 5

I find this to be the easiest, after setting up no password handshaking between servers for the user you are running the command as:

Uncompressed

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

Compression on the fly

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

Answer 6

Try to put your ssh public key in another host just by one command

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