1. 23
  1. 3

    can we start complaining again about them not merging HPN-SSH? it is becoming a bother now that distros are dropping rsh.

    1. 5

      which bit of the HPN patch do you want?

      Merging support for the none cipher is never going to happen, but we have been tweaking the channel buffer sizes for high BDP links.

      1. 1

        the none cipher

        seems like the simplest and most useful addition with the lowest maintenance burden

        why is it never going to happen?

        1. 4

          Sounds like it’d be a great way to introduce invisible insecure states unless OpenSSH screamed when a channel isn’t encrypted.

          1. 2

            it occurs to me you may not have been aware that HPN-SSH’s none cipher requires the option to be specified on the command line. it also screams “WARNING: NONE CIPHER ENABLED” when in use.

            1. 1

              are you envisioning a particular scenario?

              1. 2

                yeah, ssh should never silently downgrade to an unencrypted channel. like, there should never be any possibility for that to happen at all. and having a none cipher means that there is some possibility that can happen.

                1. 1

                  what’s the attack scenario? need something concrete to say whether there is truly no possibility now, or if adding the none cipher significantly increases the possibility.

                  note the precautions detailed here:

                  Q: I have ‘-oNoneSwitch=yes’ on the command line. Why doesn’t it work?

                  A: You must use both ’-oNoneSwitch=yes and ‘-oNoneEnabled=yes’ on the client command line. Only using one or the other will not work. Additionally, the None cipher must be enabled on the server with NoneEnabled=yes in the sshd_config file or on the command line. Anytime the None cipher is used a warning will be printed to screen saying “WARNING: NONE CIPHER ENABLED”. If you do not see that warning then the NONE cipher is not in use.

      2. 3

        ssh-agent restriction is something I am looking forward to, but it can’t be immediately usable unless remote hosts are also upgraded to OpenSSH 8.9+

        1. 4

          A near-future release of OpenSSH will switch scp(1) from using the legacy scp/rcp protocol to using SFTP by default.

          This is also nice and will take effect almost immediately.

          1. 2

            IIRC SFTP is nothing like FTP and more like NFS. Which makes it quite latency sensitive. While SCP is just piping over SSH. So, while SFTP is nicer to use, it can be quite a bit slower on low-latency but high bandwidth links.

            1. 2

              Can you explain this more? (about being slower on low-latency/high-bandwidth links) It would help future protocol design.

              1. 8

                SFTP is basically the Unix open/read/write/stat/close API presented over a network. The protocol does support streaming of concurrent requests, but unless the client is carefully written to take advantage of this then each operation can incur a RTT delay.

                OpenSSH’s sftp and (now) scp do implement pipelining when uploading and downloading, so individual transfers should go fast. However, there is no pipelining between transfers, so if you are copying a bunch of tiny files then SFTP could be slower.

                There’s no technical blocker to improving this, just that it’s fiddly to write.

                1. 4

                  Thanks, that’s exactly what I was curious about. Many years ago, I added pipelining to paramiko, and it seemed to help a lot… but I didn’t add cross-file pipelining, so I guess I contributed to the problem. :)

                  I guess for a modern implementation of this use-case, you’d want an rsync-successor on each side of the link, to sync up file trees and blocks, and not bother with sending one file at a time.

                2. 3

                  Presumably SFTP involves more back and forth chatter, and scp would do something akin to ssh remote tar -czf - <thefiles> and stream the result back, allowing the packet size to reach and maintain its maximum.

            2. 2

              That is mostly true - restriction of forwarded keys does require the extension to be present on the server. However, you can still use it to restrict whether a key is presented for forwarding at all without the server needing the extension.

              Put differently, the restrictions work for the first hop even if the server lacks the extension, but multi-hop definitely needs it.

              1. 1

                Agent forwarding should just not be used. SSH has had -J for ages

                1. 1

                  -J is slow on high latency networks, esp. when your bastion host is >200ms away, and then host you wish to connect to is also ~200ms. With agent forwarding your computer is only connected to remote host ~200ms away, so perception is much better.

              Stories with similar links:

              1. OpenSSH 9.0 Release Notes via fs111 4 months ago | 40 points | 1 comment
              2. OpenSSH 8.2/8.2p1 (2020-02-14) via inactive-user 2 years ago | -3 points | 1 comment
              3. OpenSSH 7.8/7.8p1 via inactive-user 3 years ago | 4 points | no comments