[carodgers]

Terminal emulators have taken a very odd attitude toward OSC52. Many (or all?) of them selectively disable either copy, or paste, or both, depending on how cautious the maintainer is.

Yes, it's true that an application that can read system clipboard content may scrape a password, but literally any application running in the terminal can read private keys out of your .ssh folder.

With some heavy reading and a bit of experimentation, you can usually get this working, though.

[CGamesPlay]

But with OSC 52, any system I ssh into can scrape those passwords. Bigger attack surface, to be sure. And unfortunately there’s no particularly good way of telling if the received escape code originated from the local machine.

[em-bee]

only passwords that you type after logging in. but if you can't trust the remote system then i don't think OSC 52 is the only way to do that.

[CGamesPlay]

You are misunderstanding OSC 52. A malicious/compromised SSH host can simply repeatedly print the OSC 52 paste command, causing the compliant terminal to repeatedly send any copied text to the remote system.

Everything in your comment is true regardless of OSC 52 support, though. OSC 52 just increases the attack surface for the sake of convenience.

[em-bee]

oh, i didn't know about paste. mainly because i am confused why that is even needed. i get the application running inside the terminal needing to have a way to send a selection to the the terminal, but pasting into an application already worked without OSC 52, so why did they add a function to pull from the paste buffer?

[procaryote]

There are lots of ways to secure your private keys though, including passphrases, having a ssh agent that requires interaction to use a key, having them on hardware security keys etc.

Having osc52 paste default off seems very reasonable