4 ms·

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 bac

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.

disintegrator 2y ago
Brilliant tip! I’m going to give it a shot tomorrow and update the post (with attribution).
hamandcheese 2y ago
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.
- nneonneo 2y ago
  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.
fulafel 2y ago
Having that kind of ssh access from guest to host negates the security barrier benefits that using a dev VM might have.
- nneonneo 2y ago
  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.
bartvk 2y ago
iOS devices share a clipboard with macOS. It would be cool if that could be implemented on Linux.
- sangnoir 2y ago
  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 .
divbzero 2y ago
> 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.
- nneonneo 2y ago
  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.
qazxcvbnm 2y ago
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.

disintegrator 2y ago

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

hamandcheese 2y ago

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.

nneonneo 2y ago
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.

fulafel 2y ago

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

nneonneo 2y ago
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.

bartvk 2y ago

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

sangnoir 2y ago
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 .

divbzero 2y ago

> 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.

nneonneo 2y ago
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.

qazxcvbnm 2y ago

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.