How to send data to local clipboard from a remote SSH session

Question

Borderline ServerFault question, but I\'m programming some shell scripts, so I\'m trying here first :)

Most *nixes have a command that will let you pipe/red

Answer 1

My favorite way is ssh [remote-machine] "cat log.txt" | xclip -selection c. This is most useful when you don't want to (or can't) ssh from remote to local.

Edit: on Cygwin ssh [remote-machine] "cat log.txt" > /dev/clipboard.

Edit: A helpful comment from nbren12:

It is almost always possible to setup a reverse ssh connection using SSH port forwarding. Just add RemoteForward 127.0.0.1:2222 127.0.0.1:22 to the server's entry in your local .ssh/config, and then execute ssh -p 2222 127.0.0.1 on the remote machine, which will then redirect the connection to the local machine. – nbren12

Answer 2

This answer develops both upon the chosen answer by adding more security.

That answer discussed the general form

<command that makes output> | \
    ssh <user A>@<host A> <command that maps stdin to clipboard>

Where security may be lacking is in the ssh permissions allowing <user B> on host B> to ssh into host A and execute any command.

Of course B to A access may already be gated by an ssh key, and it may even have a password. But another layer of security can restrict the scope of allowable commands that B can execute on A, e.g. so that rm -rf / cannot be called. (This is especially important when the ssh key doesn't have a password.)

Fortunately, ssh has a built-in feature called command restriction or forced command. See ssh.com, or this serverfault.com question.

The solution below shows the general form solution along with ssh command restriction enforced.

Example Solution with command restriction added

This security enhanced solution follows the general form - the call from the ssh session on host-B is simply:

cat <file> | ssh <user-A>@<host A> to_clipboard

The rest of this shows the setup to get that to work.

Setup of ssh command restriction

Suppose the user account on B is user-B, and B has an ssh key id-clip, that has been created in the usual way (ssh-keygen).

Then in user-A's ssh directory there is a file

/home/user-A/.ssh/authorized_keys

that recognizes the key id-clip and allows ssh connection.

Usually the contents of each line authorized_keys is exactly the public key being authorized, e.g., the contents of id-clip.pub.

However, to enforce command restriction that public key content is prepended (on the same line) by the command to be executed.
In our case:

command="/home/user-A/.ssh/allowed-commands.sh id-clip",no-agent-forwarding,no-port-forwarding,no-user-rc,no-x11-forwarding,no-pty <content of file id-clip.pub>

The designated command "/home/user-A/.ssh/allowed-commands.sh id-clip", and only that designated command, is executed whenever key id-clip is used initiate an ssh connection to host-A - no matter what command is written the ssh command line.

The command indicates a script file allowed-commands.sh, and the contents of that that script file is

#/bin/bash
#
# You can have only one forced command in ~/.ssh/authorized_keys. Use this
# wrapper to allow several commands.

Id=${1}

case "$SSH_ORIGINAL_COMMAND" in
    "to-clipboard")
          notify-send "ssh to-clipboard, from ${Id}"
        cat | xsel --display :0 -i -b
          ;;
    *)
        echo "Access denied"
        exit 1
        ;;
esac

The original call to ssh on machine B was

... | ssh <user-A>@<host A> to_clipboard

The string to-clipboard is passed to allowed-commands.sh by the environment variable SSH_ORIGINAL_COMMAND. Addition, we have passed the name of the key, id-clip, from the line in authorized_keyswhich is only accessed by id-clip.

The line

          notify-send "ssh to-clipboard, from ${Id}"

is just a popup messagebox to let you know the clipboard is being written - that's probably a good security feature too. (notify-send works on Ubuntu 18.04, maybe not others).

In the line

cat | xsel --display :0 -i -b

the parameter --display :0 is necessary because the process doesn't have it's own X display with a clipboard, so it must be specificied explicitly. This value :0 happens to work on Ubuntu 18.04 with Wayland window server. On other setups it might not work. For a standard X server this answer might help.

host-A /etc/ssh/sshd_config parameters

Finally a few parameters in /etc/ssh/sshd_config on host A that should be set to ensure permission to connect, and permission to use ssh-key only without password:

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
AllowUsers user-A

To make the sshd server re-read the config

sudo systemctl restart sshd.service

or

sudo service sshd.service restart

conclusion

It's some effort to set it up, but other functions besides to-clipboard can be constructed in parallel the same framework.

Answer 3

I'm resurrecting this thread because I've been looking for the same kind of solution, and I've found one that works for me. It's a minor modification to a suggestion from OSX Daily.

In my case, I use Terminal on my local OSX machine to connect to a linux server via SSH. Like the OP, I wanted to be able to transfer small bits of text from terminal to my local clipboard, using only the keyboard.

The essence of the solution:

commandThatMakesOutput | ssh desktop pbcopy

When run in an ssh session to a remote computer, this command takes the output of commandThatMakesOutput (e.g. ls, pwd) and pipes the output to the clipboard of the local computer (the name or IP of "desktop"). In other words, it uses nested ssh: you're connected to the remote computer via one ssh session, you execute the command there, and the remote computer connects to your desktop via a different ssh session and puts the text to your clipboard.

It requires your desktop to be configured as an ssh server (which I leave to you and google). It's much easier if you've set up ssh keys to facilitate fast ssh usage, preferably using a per-session passphrase, or whatever your security needs require.

Other examples:

ls  | ssh desktopIpAddress pbcopy
pwd |  ssh desktopIpAddress pbcopy

For convenience, I've created a bash file to shorten the text required after the pipe:

#!/bin/bash
ssh desktop pbcopy

In my case, i'm using a specially named key

I saved it with the file name cb (my mnemonic (ClipBoard). Put the script somewhere in your path, make it executable and voila:

ls | cb

Answer 4

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 supports Linux, *BSD and OS X; I made a special putty build to utilize this functionality from windows also.

Answer 5

This is my solution based on SSH reverse tunnel, netcat and xclip.

First create script (eg. clipboard-daemon.sh) on your workstation:

#!/bin/bash
HOST=127.0.0.1
PORT=3333

NUM=`netstat -tlpn 2>/dev/null | grep -c " ${HOST}:${PORT} "`
if [ $NUM -gt 0 ]; then
    exit
fi

while [ true ]; do
    nc -l ${HOST} ${PORT} | xclip -selection clipboard
done

and start it in background.

./clipboard-daemon.sh&

It will start nc piping output to xclip and respawning process after receiving portion of data

Then start ssh connection to remote host:

ssh user@host -R127.0.0.1:3333:127.0.0.1:3333

While logged in on remote box, try this:

echo "this is test" >/dev/tcp/127.0.0.1/3333

then try paste on your workstation

You can of course write wrapper script that starts clipboard-daemon.sh first and then ssh session. This is how it works for me. Enjoy.

Answer 6

@rhileighalmgren solution is good, but pbcopy will annoyingly copy last "\n" character, I use "head" to strip out last character to prevent this:

#!/bin/bash
head -c -1 |  ssh desktop pbcopy

My full solution is here : http://taylor.woodstitch.com/linux/copy-local-clipboard-remote-ssh-server/