Show HN: Pbproxy – Send your clipboard anywhere you can ssh
github.compbproxy is a small wrapper to give you a consistent and remotely accessible interface to your system clipboard on linux and mac. Week of clipboard on HN! There’s never a situation where I want to copy/paste to any clipboard other than my local clipboard, so I solved this by simply aliasing pbcopy/papaste to always SSH back to my mac and run pbcopy/pbpaste there. But "where" is your mac? I.e., `cat clipboard | ssh ??? pbcopy`. I travel, so I don't always have the same IP address, and it's still too common to end up in a NAT'd hellscape with no usable IP. (Every office I've ever worked in, with one exception, has have v4-only NAT'd networks. Usually on a -PSK Wifi. Corp network infra is typically a joke.) One could perhaps set something up to forward a connection to a local daemon and then use that forwarded connection to push data backwards, but the complexity is going up, and fast. Use a reverse port forward via ssh. Just for other people arriving from Google who might think this is too much work, it seems to be enough for my use case to just type This is what I was hinting at with: > One could perhaps set something up to forward a connection to a local daemon […] [but complexity] Reverse port forwarding is exactly what I do. You can make it automatic for certain hosts using ssh_config. Tailscale/Wireguard helps give consistent IPs Wireguard is the same problem, just with a layer of indirection. (I've tried WG exactly to try to simplify the networking!) Now instead of SSH connecting, it's Wireguard. You can make some headway with this, but it's a bit painful. You need some fixed presence on the Internet, somewhere, like a server. That can be done, but now you're setting up routing, etc. Or paying Tailscale. It rubs me a bit of the wrong way, since the ISPs job was to provide end-to-end connectivity, and ISPs as a whole are falling down on that … I shouldn't need to build a shadow network in the IPv6 private space … (And again, we breach the "it isn't worth it" complexity barrier for a cross machine clipboard transfer…) Tailscale has “MagicDNS” that fixes the host name problem (for free) - https://tailscale.com/kb/1081/magicdns/ Would it be possible to use hostnames rather than IP addresses then you'd not have to worry as the resolution would be done for you? That only adds a layer of indirection to the same problem. You can refer to your laptop by hostname, but something have to update the hostname's record when the laptop moves about. That could be a daemon on the laptop [yada yada] but now you've added a ton of complexity. (And there's still the problem of NAT: your laptop might not be on the Internet.) Great idea! I'm not too skilled at SSH, can you share the alias? I saw your comment the other day where you talked about maybe putting this on GitHub. Very nice to see that you went ahead and did so :D With tmux, shell aliases for tmux send-buffer and tmux paste can manually do this without dependencies. how do you access another machine's clipboard with tmux? ssh -t that-machine tmux -s your-session show-buffer And | ssh -t tmux … set-buffer - I created a similar tool to help me synchronize my clipboard between my desktop and my laptop: https://github.com/b0o/clipshare
Of course you could instead add it to your ssh config along with agent forwarding. ssh -R 127.0.0.1:2210:127.0.0.1:22 user@somemachine
from my Mac terminal. ssh user@host "cat foo.txt" | pbcopy