Here's my usage case:

  • I'm often connected to other computers over SSH for work and I often need to copy and paste documents/text from the server to locally running editors for writing examples and sharing text.
  • Often, if the text is small enough, I'll simply copy the output from my terminal program (gnome-terminal at the moment) and paste it.
  • However, when it comes to entire documents, my options are quite limited. I can either copy the document chunk-by-chunk, or scp it to the local machine.

Is there a way to use a program such as xclip which will allow me to copy remote stdin to the local X server's clipboard? Something to the effect of:

cat myconffile.conf | sed {...} | copy-over-ssh-to-local-clipboard

would be awesome. Does something exist to make this possible?

10 Answers 10


If you run ssh with X forwarding, this is transparent: remote commands (including xclip) have access to your X server (including its keyboard). Make sure you have ForwardX11 yes in your ~/.ssh/config and X11Forwarding yes in the server sshd_config (depending on your distributions, these options may be on or off by default).

<myconffile.conf sed {...} | xclip -i

There are other ways of working on remote files that may be more convenient, for example mounting remote directories on your local machine with SSHfs, or opening remote files in Emacs with Tramp. If you have ssh and FUSE set up and SSHfs installed, SSHfs is as easy as mkdir ~/net/myserver; sshfs myserver:/ ~/net/myserver. If you have ssh set up and Emacs installed, Tramp is as easy as opening /myserver:/path/to/file.


You don't need anything special; since xclip works over stdin, just

ssh remotehost xclip < myconf.conf

Why would it need to be modified with sed? ssh is transparent to data when not used as a terminal, and is commonly used in pipelines such as

tar cfz - somedir | ssh remotehost 'cd destdir; tar xfz -'`
  • Is there a way to do it from within an existing SSH session? I'd really prefer not to have to open up another terminal window if I already have one open to the machine in question. – Naftuli Kay Jul 14 '11 at 23:56
  • And sed` is just there as an example, if I'd like to perform any processing on the stdin before copying it to the clipboard, I'd like that option. – Naftuli Kay Jul 14 '11 at 23:57
  • No, there's no way to inject data into an existing ssh session (it wouldn't be very secure if you could). You can set up the ssh ControlMaster stuff to multiplex additional connections over an existing one, but it's not really something for beginners and you still do it the same way afterward, by switching to another local terminal and running the command above (which does not open a new terminal window). – geekosaur Jul 15 '11 at 0:03
  • @NaftuliKay For a solution that works inside your normal SSH session, see my answer. – tanius Feb 2 '19 at 11:16

Here's how you would do it on OSX from your local machine

ssh remotehost.com "<some/file.txt" | pbcopy

if your local machine is running windows(7+) you can just use this from the CommandLine:

ssh user@server cat /home/user/file | clip


    ForwardX11 yes


X11Forwarding yes


$ xclip -o | ssh REMOTEHOST 'DISPLAY=:0 xclip -i'

Very similar to @d-raev's and @william-casarin solutions, however, it is different so I'm sharing what worked for me.

The command

ssh user@host "cat <myconffile.conf" | xclip -sel clip


This is using ssh to create a secure tunnel, login to user @ host or ip, then execute cat to print the contents of <myconffile.conf to stdout then piping that to the command xclip -sel clip on your local machine, which places the contents of <myconffile.conf into the clipboard on your local machine.

Real-world example usage

I use this command structure for tasks such as pasting ssh keys into github (allowing a simple ctrl-V or paste selection after I run the command) on with Bash on Ubuntu 16.04 and 18.04. Check out man ssh, man cat, and man xclip for behavior and option details.

  • 1
    This even works to copy from headless servers, where xclip won't run as there is no X. – tanius Feb 2 '19 at 10:09

I have similar issue with LUbuntu's lxterminal (tested various terminals) pasting clipboard to an ssh session. If clipboard has more than about 100 bytes the session timeouts and fails.

If I connect via ssh to almost any CentOS 5.x server and then connect to the target server, clipboard paste works without any issue for any reasonable data size.


Copying from a headless server to local clipboard, from inside your usual SSH session:

  1. Install ncat on your local and remote machine. (On your remote machine you can also do with nc or plain telnet, but on the local machine we need the options to execute commands (-c / -e) which are not available in nc in usual distributions like Debian and Ubuntu.)

    apt install nmap
  2. On your local machine, set up a server listening on the local interface that will copy content coming in on port 10009 to your X clipboard:

    ncat --keep-open --listen --sh-exec "xclip -selection clipboard" localhost 10009

    Or use the equivalent shorthand version:

    ncat -klc "xclip -sel c" localhost 10009
  3. SSH into the remote machine in such a way that a reverse tunnel is established from port 10008 of the remote machine to port 10009 on your local machine (where your server is listening). You can use that SSH session for your normal work.

    ssh -R 10008:localhost:10009 user@example.com
  4. When you want to copy a file's content from remote machine to local clipboard, execute in the SSH shell:

    ncat --send-only localhost 10008 < file.txt

    And of course, that's nicer when packaged as a shell shortcut or script. We could call it rclip for "[copy to] remote clipboard" in analogy to the well-known xclip.


  • No need to open another SSH session to the remote machine.

  • No need for xclip on the remote machine, so it works if you can't install it or can't use it because it's a headless server without X.


We do ncat -l localhost 10009 for the server, which means it listens only on the network interface with the localhost IP address. This local loop interface only allows connections from your own machine (including, in this case, those reverse tunneled in via SSH). So even if you are not behind a firewall, your port 10009 is not exposed to anyone on the Internet.


Adapted from the gist dergachev/ssh-forward-clipboard.md to work for Linux. That gist also contains instructions for how to make the SSH reverse tunnel a default.


Far Manager Linux port supports synchronizing clipboard between local and remote host. You just open local far2l, do "ssh somehost" inside, run remote far2l in that ssh session and get remote far2l working with your local clipboard.

It supportes Linux, *BSD and OS X; I made a special putty build to utilize this functionality from windows also.



You can convert your clipboard data with Base64 to ASCII text. Then you can push that through inside an already existing SSH connection.

  • Why convert to anything? It's already text in this case and even if it was binary there would be no reason you couldn't send it across a pipeline like this. – Caleb Aug 2 '11 at 10:41
  • clipboard could contain binary data, e.g.: a compiled application – LanceBaynes Aug 2 '11 at 14:34
  • Yes it could, but why would that be a problem? Binary data can be transferred through a pipe and ssh tunnel. – Caleb Aug 2 '11 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.