Hacker News Reader

Comment by nneonneo | Hacker News Reader

You can use pbcopy/pbpaste in a Linux VM on Mac by making a shell script wrapper in the VM that calls “ssh mac-host pb{copy|paste}” - that is, basically ssh back from the guest to the host to use its clipboard. It’s seamless and fast since it’s basically a local network connection.

My specific setup is that I use an authorized_keys entry on the host that restricts the guest to running a specific command, which limits what a compromised guest can do to the host. The command is set to a script that has a list of specific permitted actions. This is a good option if you’re looking for a bit of additional isolation between host and guest.

View on HN

> I use an authorized_keys entry on the host that restricts the guest to running a specific command, which limits what a compromised guest can do to the host. The command is set to a script that has a list of specific permitted actions.

That’s a neat trick, thanks for mentioning this.

  command="command" ssh-ed25519 ...

would be the authorized_keys entry and I’m guessing the script would read the SSH_ORIGINAL_COMMAND environment variable to determine which action was intended.

Yes, that's exactly it.

My authorized_keys line looks like this:

  command="${HOME}/bin/fromvm vmname",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-ed25519 ...

I give each of my VMs a different name and key, which lets me identify them for the purpose of e.g. constructing ssh:// links for remote editing.

The actual script uses $SSH_ORIGINAL_COMMAND, exactly as you've described, which means that while the guest thinks its executing e.g. "pbcopy", the host "fromvm" script is actually receiving "pbcopy" in the $SSH_ORIGINAL_COMMAND and can apply the appropriate access control or restrictions.

In the past, I set up something similar, except I would reverse forward my local ssh port to my remote servers (so that I could easily ssh back regardless of network topology). Ultimately I didn't keep it out of security concerns -- I had done nothing to limit the commands.

On the topic of limiting the possible commands - for my use case I only needed pbcopy. Maybe think twice before letting an insecure VM or remote host read your clipboard contents with pbpaste.

Yep - good point. Another option would be to set a confirmation in front of every paste attempt - for example, putting Touch ID in front of any pbpaste call from the guest (which you can enforce with the authorized_keys command). That should be low-friction enough that it isn’t a major delay to your development process, while still being reasonably secure and providing the convenience of pasteboard access.

Having that kind of ssh access from guest to host negates the security barrier benefits that using a dev VM might have.

Please read the second part - I use a command restriction in authorized_keys so that the guest can only call certain commands.

Yes, the guest has “unlimited” access to the pasteboard, which does introduce some risks. For example, the guest could set a malicious command line that you paste into the terminal - which is generally mitigated with paste bracketing in zsh, vim, etc. It definitely weakens the isolation to a certain extent, but I don’t think it completely negates the security barrier as you claim.

Brilliant tip! I’m going to give it a shot tomorrow and update the post (with attribution).

I do something similar, and one more tip is to remember to provide your pbcopy and pbpaste with `LANG=en_US.UTF-8`, or else non-ASCII will be garbled.

iOS devices share a clipboard with macOS. It would be cool if that could be implemented on Linux.

Linux had this for more than 10 years with KDE Connect phone app. KDE connect has a bunch of other neat tricks, like letting you phone act as a touchpad for your computer .

Reply on news.ycombinator.com