Question or issue on macOS:
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/redirect output to the local clipboard/pasteboard, and retrieve from same. On OS X these commands are
pbcopy, pbpaste
Is there anyway to replicate this functionality while SSHed into another server? That is,
And yes, I know I could just (shudder) use my mouse to select the text from the command, but I’ve gotten so used to the workflow of pipping output directly to the clipboard that I want the same for my remote sessions.
Code is useful, but general approaches are appreciated as well.
How to solve this problem?
Solution no. 1:
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
Solution no. 2:
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
Solution no. 3:
Found a great solution that doesn’t require a reverse ssh connection!
You can use xclip on the remote host, along with ssh X11 forwarding & XQuartz on the OSX system.
To set this up:
- Install XQuartz (I did this with soloist + pivotal_workstation::xquartz recipe, but you don’t have to)
- Run XQuartz.app
- Open XQuartz Preferences (
+
,
) - Make sure “Enable Syncing” and “Update Pasteboard when CLIPBOARD changes” are checked
ssh -X remote-host "echo 'hello from remote-host' | xclip -selection clipboard"
Solution no. 4:
Reverse tunnel port on ssh server
All the existing solutions either need:
- X11 on the client (if you have it,
xclip
on the server works great) or - the client and server to be in the same network (which is not the case if you’re at work trying to access your home computer).
Here’s another way to do it, though you’ll need to modify how you ssh into your computer.
I’ve started using this and it’s nowhere near as intimidating as it looks so give it a try.
Client (ssh session startup)
ssh [email protected] -R 2000:localhost:2000
(hint: make this a keybinding so you don’t have to type it)
Client (another tab)
nc -l 2000 | pbcopy
Note: if you don’t have pbcopy
then just tee
it to a file.
Server (inside SSH session)
cat some_useful_content.txt | nc localhost 2000
Other notes
Actually even if you’re in the middle of an ssh session there’s a way to start a tunnel but i donโt want to scare people away from what really isnโt as bad as it looks. But I’ll add the details later if I see any interest
Solution no. 5:
There are various tools to access X11 selections, including xclip and XSel. Note that X11 traditionally has multiple selections, and most programs have some understanding of both the clipboard and primary selection (which are not the same). Emacs can work with the secondary selection too, but that’s rare, and nobody really knows what to do with cut buffers…
$ xclip -help Usage: xclip [OPTION] [FILE]... Access an X server selection for reading or writing. -i, -in read text into X selection from standard input or files (default) -o, -out prints the selection to standard out (generally for piping to a file or program) -l, -loops number of selection requests to wait for before exiting -d, -display X display to connect to (eg localhost:0") -h, -help usage information -selection selection to access ("primary", "secondary", "clipboard" or "buffer-cut") -noutf8 don't treat text as utf-8, use old unicode -version version information -silent errors only, run in background (default) -quiet run in foreground, show what's happening -verbose running commentary Report bugs to
$ xsel -help Usage: xsel [options] Manipulate the X selection. By default the current selection is output and not modified if both standard input and standard output are terminals (ttys). Otherwise, the current selection is output if standard output is not a terminal (tty), and the selection is set from standard input if standard input is not a terminal (tty). If any input or output options are given then the program behaves only in the requested mode. If both input and output is required then the previous selection is output before being replaced by the contents of standard input. Input options -a, --append Append standard input to the selection -f, --follow Append to selection as standard input grows -i, --input Read standard input into the selection Output options -o, --output Write the selection to standard output Action options -c, --clear Clear the selection -d, --delete Request that the selection be cleared and that the application owning it delete its contents Selection options -p, --primary Operate on the PRIMARY selection (default) -s, --secondary Operate on the SECONDARY selection -b, --clipboard Operate on the CLIPBOARD selection -k, --keep Do not modify the selections, but make the PRIMARY and SECONDARY selections persist even after the programs they were selected in exit. -x, --exchange Exchange the PRIMARY and SECONDARY selections X options --display displayname Specify the connection to the X server -t ms, --selectionTimeout ms Specify the timeout in milliseconds within which the selection must be retrieved. A value of 0 (zero) specifies no timeout (default) Miscellaneous options -l, --logfile Specify file to log errors to when detached. -n, --nodetach Do not detach from the controlling terminal. Without this option, xsel will fork to become a background process in input, exchange and keep modes. -h, --help Display this help and exit -v, --verbose Print informative messages --version Output version information and exit Please report bugs to .
In short, you should try xclip -i
/xclip -o
or xclip -i -sel clip
/xclip -o -sel clip
or xsel -i
/xsel -o
or xsel -i -b
/xsel -o -b
, depending on what you want.
Solution no. 6:
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 [email protected] -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.
Solution no. 7:
Not a one-liner, but requires no extra ssh.
- install
netcat
if necessary - use termbin:
cat ~/some_file.txt | nc termbin.com 9999
. This will copy the output to thetermbin
website and prints the URL to your output. - visit that url from your computer, you get your output
Of course, do not use it for sensitive content.
Solution no. 8:
The simplest solution of all, if you’re on OS X using Terminal and you’ve been ssh’ing around in a remote server and wish to grab the results of a text file or a log or a csv, simply:
1) Cmd-K
to clear the output of the terminal
2) cat <filename>
to display the contents of the file
3) Cmd-S
to save the Terminal Output
You’ll have the manually remove the first line and last line of the file, but this method is a bit simpler than relying on other packages to be installed, “reverse tunnels” and trying to have a static IP, etc.
Solution no. 9:
This answer develops both upon the chosen answer by adding more security.
That answer discussed the general form
| \ ssh @
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 | ssh @ 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
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 @ 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_keys
which 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.
Solution no. 10:
@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/