Note that mosh is far closer to tmux than ssh. To do what it does, it has a full terminal emulator built in, and the protocol it uses is about patching updates to the state of the display, not about moving data.
Assuming you mean scp the protocol as opposed to scp the utility (because you could obviously rewrite the scp utility to target any protocol you cared to…), sort of?
scp was originally just the rcp protocol over ssh. Here’s a decent description:
Modern versions of openssh have reimplemented scp-the-command in terms of sftp-the-protocol. sftp-the-protocol was originially defined by Ylonen in version 2.0 of ssh. It was well-described in an IETF indvidual draft that never got adopted into a standards track RFC, but you can see it here:
It’s very much tied to ssh, particularly for authentication.
ssh as a protocol doesn’t seem terribly bound to TCP, though I may be missing something there. But someone has written a proxy that, if running on both the client and server, can send ssh traffic over QUIC instead of TCP:
With a sufficiently recent version of openssh on both sides, then, you could certainly use the openssh scp command with that proxy to run scp over QUIC. Assuming the proxy does what it says on the tin. As deep as I’ve needed to dive into the internals of ssh in my working life, I’ve never had a need to do that.
QUIC is actually almost perfect for SSH, in that QUIC was made to enabling multiplexing of HTTP requests and SSH has a very similar behaviour, in that multiple channels can run over a single TCP connection. The issue with trying to shoehorn SSH into QUIC via a proxy is those SSH channels aren’t then native QUIC channels, which nearly defeats the point of QUIC, as now the channels are still in a single stream, like with TCP and you get head-of-line blocking and all the things QUIC was designed to avoid!
There are two main reasons QUIC is of interest for SSH:
For file copying as qcp is doing it’s the supposed performance benefits, but those may not be as big as you expect (e.g. https://dl.acm.org/doi/10.1145/3589334.3645323); particularly if you control the endpoints and can use BBR as the TCP congestion control algorithm.
Endpoint mobility: Something like mosh but without the terminal prediction pieces would be very nice (think laptop moving between networks, etc.)
For file copying there is plenty to optimise at the SSH protocol and implementation level. There is some work in progress at https://github.com/djmdjm/openssh-portable-wip/pull/4 (including some comments from me) which adds an SSH extension to negotiate larger window sizes, this is actually the main limiting factor on SSH performance (at least if using something like rsync over it, SFTP and therefore modern scp has some additional buffering which may make it slower).
There is also some work on another option, changing SSH into a more HTTP based protocol and then running that over QUIC: https://github.com/francoismichel/ssh3 (I kind of feeling calling that “ssh” is a bit of misnomer).
Ross, the author of qcp, says he created it for connections of a few hundred Mbit/s and a few hundred milliseconds, ie, much less than the point where Zhang’s paper observed problems. I expect QUIC’s packet processing overhead will improve as hardware offload and multi-message transfer APIs improve to match TLS/TCP.
That OpenSSH pull request surprises me a little: I thought that it had learned about window scaling many years ago from the hpn-ssh project. A lot of the benefit of qcp is that it avoids the ssh framing and multiplexing layers, and it wants connection sizing hints so it doesn’t have to work out scaling parameters from scratch.
Yeah, ssh over native QUIC would be neat, a better match than layering ssh on http on quic. But I expect it would be a huge pain to change from ssh public key host auth to PKIX certificate auth, because lots of boxes running ssh are too isolated to be able to ACME.
Yeah, ssh over native QUIC would be neat, a better match than layering ssh on http on quic. But I expect it would be a huge pain to change from ssh public key host auth to PKIX certificate auth, because lots of boxes running ssh are too isolated to be able to ACME.
Can you elaborate on that? A self-signed PKIX certificate is logically equivalent to ssh key auth. Is there something I’m missing that would make it harder for an SSH client running over QUIC to present a self-signed certificate to a server running QUIC than it is to use bare keys?
You would have to extend all the existing ssh infrastructure to support a new kind of host key authentication. You would have to make sure the QUIC/TLS libraries have the necessary hooks for authenticating self-signed server certificates in the style of ssh host key authentication. You would have to invent some way for ssh clients to choose between QUIC and TCP port 22 based on which host keys have been learned.
It’s doable but it still sounds like a huge pain. But maybe worth it in the long run?
This reminds me of Mosh, which also uses a UDP protocol as a complement to SSH: https://mosh.org/
Note that mosh is far closer to tmux than ssh. To do what it does, it has a full terminal emulator built in, and the protocol it uses is about patching updates to the state of the display, not about moving data.
Is
scpbound to TCP in some capacity that means it can’t run over QUIC?Assuming you mean
scpthe protocol as opposed toscpthe utility (because you could obviously rewrite thescputility to target any protocol you cared to…), sort of?scpwas originally just thercpprotocol over ssh. Here’s a decent description:https://web.archive.org/web/20170215184048/https://blogs.oracle.com/janp/entry/how_the_scp_protocol_works
scp-the-protocol is generally considered deprecated:
https://lwn.net/Articles/835962/
Modern versions of openssh have reimplemented scp-the-command in terms of sftp-the-protocol. sftp-the-protocol was originially defined by Ylonen in version 2.0 of ssh. It was well-described in an IETF indvidual draft that never got adopted into a standards track RFC, but you can see it here:
https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13
It’s very much tied to ssh, particularly for authentication.
ssh as a protocol doesn’t seem terribly bound to TCP, though I may be missing something there. But someone has written a proxy that, if running on both the client and server, can send ssh traffic over QUIC instead of TCP:
https://github.com/moul/quicssh
With a sufficiently recent version of openssh on both sides, then, you could certainly use the openssh
scpcommand with that proxy to runscpover QUIC. Assuming the proxy does what it says on the tin. As deep as I’ve needed to dive into the internals of ssh in my working life, I’ve never had a need to do that.QUIC is actually almost perfect for SSH, in that QUIC was made to enabling multiplexing of HTTP requests and SSH has a very similar behaviour, in that multiple channels can run over a single TCP connection. The issue with trying to shoehorn SSH into QUIC via a proxy is those SSH channels aren’t then native QUIC channels, which nearly defeats the point of QUIC, as now the channels are still in a single stream, like with TCP and you get head-of-line blocking and all the things QUIC was designed to avoid!
There are two main reasons QUIC is of interest for SSH:
For file copying there is plenty to optimise at the SSH protocol and implementation level. There is some work in progress at https://github.com/djmdjm/openssh-portable-wip/pull/4 (including some comments from me) which adds an SSH extension to negotiate larger window sizes, this is actually the main limiting factor on SSH performance (at least if using something like rsync over it, SFTP and therefore modern scp has some additional buffering which may make it slower).
There is also some work on another option, changing SSH into a more HTTP based protocol and then running that over QUIC: https://github.com/francoismichel/ssh3 (I kind of feeling calling that “ssh” is a bit of misnomer).
Ross, the author of qcp, says he created it for connections of a few hundred Mbit/s and a few hundred milliseconds, ie, much less than the point where Zhang’s paper observed problems. I expect QUIC’s packet processing overhead will improve as hardware offload and multi-message transfer APIs improve to match TLS/TCP.
That OpenSSH pull request surprises me a little: I thought that it had learned about window scaling many years ago from the hpn-ssh project. A lot of the benefit of qcp is that it avoids the ssh framing and multiplexing layers, and it wants connection sizing hints so it doesn’t have to work out scaling parameters from scratch.
Yeah, ssh over native QUIC would be neat, a better match than layering ssh on http on quic. But I expect it would be a huge pain to change from ssh public key host auth to PKIX certificate auth, because lots of boxes running ssh are too isolated to be able to ACME.
Can you elaborate on that? A self-signed PKIX certificate is logically equivalent to ssh key auth. Is there something I’m missing that would make it harder for an SSH client running over QUIC to present a self-signed certificate to a server running QUIC than it is to use bare keys?
You would have to extend all the existing ssh infrastructure to support a new kind of host key authentication. You would have to make sure the QUIC/TLS libraries have the necessary hooks for authenticating self-signed server certificates in the style of ssh host key authentication. You would have to invent some way for ssh clients to choose between QUIC and TCP port 22 based on which host keys have been learned.
It’s doable but it still sounds like a huge pain. But maybe worth it in the long run?
In which situations will qcp beat scp, and by how much?