4 ms·

The point is that we'd like to know that its not heavily degrading to the existing purpose. No one said anything about high performance.

• tremon 7y ago
  What part of the existing purpose is performance-critical?
  • castis 7y ago
    I dont understand the purpose of this question. The existing purpose is that it works at all?
    • ryanlol 7y ago
      I’m really not convinced that this is a realistic concern. And anyway, what you’re posing certainly isn’t a performance concern, but a “does the software work” concern.
      • castis 7y ago
        "I’m really not convinced". Ok great thanks, neither is anyone else, which is why we'd like numbers.
        • FDSGSG 7y ago
          Why do you think that this specific change would make ssh not "work at all" as opposed to the hundreds of other changes that happen? Do you even pay close attention to those changes? I for sure don't. Why are you concerned about this in the first place? Obviously there's always a general concern about any changes, but what makes this specific change a big deal to you?
          • deleted 7y ago
            [deleted]
          • deleted 7y ago
            [deleted]
          • deleted 7y ago
            [deleted]
          • archgoon 7y ago
            This particular change got a hacker news article. It seems to be inherently more noticeable than others. Seems reasonable to ask about the performance (and memory) implications of the change. If they're minimal, than this solution can be easily added to other situations where encryption is being used. If it's heavy, then different solutions would need to be developed on a case by case basis.
          • castis 7y ago
            edit: your annoyance is not worth anyones time
            • FDSGSG 7y ago
              >reading way too far into it Dunno, your earlier comments seem to imply otherwise: >we'd like to know that its not heavily degrading to the existing purpose... which is why we'd like numbers
  • namibj 7y ago
    Tanking DDoS? Like, the more connections you can handle normally, the less filtering you need to do on incoming connections?
    • ryanlol 7y ago
      OpenSSHd does not “tank DDoS”, it’ll simply consume all resources available to it if attacked. The only way to mitigate such an attack would be to drop it before it reaches the SSH daemon.
  • simias 7y ago
    I certainly wouldn't want scp to suddenly slow down compared to what I'm used to. I use scp and sftp rather heavily to transfer very large files and do backups, that might not be performance-critical but it's definitely performance-sensitive. I haven't had to mess with that in a while but there was a time where you'd get a significant boost with scp on underpowered hosts if you used the arcfour cipher for instance (I believe that it's now fully deprecated, and for good reasons).
    • chasil 7y ago
      If you were willing to sacrifice best practices for performance, one obvious option is to accept only hmac-md5, which is very fast and still somewhat secure. If the systems involved lack "AES-NI" native CPU opcodes, then you might revert to chacha20-poly1305, which is supposedly faster on CPUs that lack acceleration. This also overrides the hmac-md5 above, as it is an AEAD. If you needed to go faster still, then you could instead choose ARCFOUR (RC4) as you say, but this has been removed from the latest versions of OpenSSH because it is not safe. The worst of the above configurations are still not as bad as classic FTP.
    • LinuxBender 7y ago
      Using LFTP's mirror sub-system plus SFTP can be faster than all of the unencrypted protocols. It gives you the behavior of rsync, but can work with sftp+chroot logins and can spawn multiple threads per job or even per file. Working demo [1] I find it very useful when I want to give people the ability to transfer files quickly, but I don't want to give them a shell. [1] - https://tinyvpn.org/sftp/#lftp https://tinyvpn.org/sftp/#lftp