9 ms·

OpenSSH 9.0

247 points by rurban 5y ago

pengaru 5y ago
Every time I pay enough attention to an OpenSSH release that I trick myself into reading some of the code, I'm left smh in disbelief that I actually rely on this software still.
- jabiko 5y ago
  Can you tell why that is? Did you find the OpenSSH source code especially bad? I am under the belief that OpenSSH is a really high quality, security focused software project.
  - traceroute66 5y ago
    > Can you tell why that is? Yeah, I too find it a really bizarre comment to make, especially as it is not substantiated with any detail whatsoever. OpenSSH comes from the house of OpenBSD and LibreSSL. I am no security guru, but as I understand it, all three have a well deserved security reputation, and the core maintainers run a tight ship. We've already covered in recent weeks on HN how OpenSSH has maintained its robustness in the face of an increasingly hostile cyber world.[1] So, if you are going to imply that OpenSSH code is shit, back it up with hard facts. [1] https://news.ycombinator.com/item?id=30830749 https://news.ycombinator.com/item?id=30830749
    - pengaru 5y ago
      If you think this [0] is quality workmanship, I never want to work on your team. I haven't even exhaustively looked through this code, only took a quick glance at clientloop.c [1] and was curious about how the channels were integrated into the poll loop. This is a mess, and I'm pretty sure I already see a bug. [0] https://github.com/openssh/openssh-portable/blob/master/channels.c#L2636-L2743 https://github.com/openssh/openssh-portable/blob/master/chan... [1] https://github.com/openssh/openssh-portable/blob/master/clientloop.c#L1306-L1388 https://github.com/openssh/openssh-portable/blob/master/clie... Edit: I'm not looking at a future CVE, but I've definitely found a bug. For those of you tossing up low-effort straw men, actually go grok the code. The way they've integrated the poll loop into all the actual handling of the returned events is a sprawling mess, and the bug I've found is a direct result of that.
      - paskozdilar 5y ago
        I don't see anything so obviously wrong with [0]. I guess I'll never make it into your team ¯\_(ツ)_/¯
      - artogahr 5y ago
        Out of curiosity, can you explain what's wrong with that code? I dabbled in C a few years back but I'm nowhere near competent enough to find anything wrong with it.
        faho 5y ago
        I'm also no C guru, but this seems to dereference a pointer before checking if it's in-bounds: struct pollfd *pfd = &pfds[p]; if (fd == -1) return; if (p == -1 || (u_int)p >= npfd) fatal_f("channel %d: bad pfd %d (max %u)", c->self, p, npfd); dump_channel_poll(__func__, what, c, p, pfd); If p is < 0 or >= npfd (the number of elements in pfds), this should read out of bounds of the pfds array, and the check happens too late. This is similar to a famous Linux kernel bug from ages ago, where a !NULL check was optimized away in such a situation, leading to an exploit: https://lwn.net/Articles/342330/ https://lwn.net/Articles/342330/ In this case I'm not aware if something like that happens, or if it happens to be harmless.
        aaronmdjones 5y ago
        This: struct pollfd *pfd = &pfds[p]; ... does not dereference pfds. It looks that way, but you need to account for the address-of operator before it. What it's actually doing is: struct pollfd *pfd = pfds + p; ... and thus it works even if pfds is NULL or if p is out of bounds. The following check before using pfd is correct.
        faho 5y ago
        Ah, okay. Personally I'd still want to do the check before, because someone could still be adding something in-between the assignment and the check, but if that's the order it's resolved in it seems to be working now. (I'm guessing they declare and assign the variable first because of C version constraints - wasn't that something that changed in C99?)
    - adastra22 5y ago
      > I am no security guru, but as I understand it, all three have a well deserved security reputation, and the core maintainers run a tight ship. Among us security gurus, OpenSSL has a really bad reputation. It's a giant pile of spaghetti code with a huge history of critical system vulnerabilities stemming from trying to be everything to everybody. Bitcoin is in the process of writing replacement functionality in order to remove OpenSSL entirely from its dependency tree because they got burned by major bugs multiple times in the past. A lot of modern alternatives like libsodium list "not OpenSSL" as a selling point. The situation is so bad that multiple organizations have forked OpenSSL to create stripped down alternatives (BoringSSL, LibreSSL) that are more likely to be secure. I know less about the OpenSSH code base specifically, except that it came out of the same culture and the same developers. I wouldn't use it in new projects unless I had no other choice.
      - zokier 5y ago
        > I know less about the OpenSSH code base specifically, except that it came out of the same culture and the same developers ummm what? Afaik openssh and openssl have no major common history? openssh comes from openbsd, openssl has always been independent project.
      - brynet 5y ago
        OpenSSH and LibreSSL are OpenBSD projects. OpenSSL has nothing to do with OpenBSD.
        adastra22 5y ago
        Thank you for the correction!
- daneel_w 5y ago
  It's one of the most deployed pieces of software on the planet, and for that reason has a million eyes on it, yet there doesn't seem to be any alarming concern about the source quality. Maybe it's all right after all...
  - tialaramex 5y ago
    Maybe. You've expressed the same sentiment as you'd have seen for OpenSSL just a few months before everybody decided OpenSSL was unacceptable and they'd fork it (producing BoringSSL, LibreSSL and so on). OpenBSD has some very peculiar preferences, some of which are in step with modern thinking (e.g. they like sandboxes, privilege dropping and defence in depth very much) but some very much are not (they like C despite its lack of Type Safety, Memory Safety, and generally just Safety) SecSH (the SSH v2 standard) is a fairly clean modern encrypted protocol design. You do a key exchange, you bring up an encrypted link and then everything else happens inside this, alleviating many of your security concerns, the same way TLS 1.3 works (but TLS 1.3 is much more recent). But the OpenSSH codebase dates back to even before SSHv2, it's basically the original SSH codebase, from back when encrypted remote shells was an entirely new idea, the mid-1990s, the SSH codebase went proprietary and OpenSSH is the fork. That's some crufty old code, and in C that's not an insignificant problem because problems in code you never read has potentially drastic consequences for unrelated code in the same binary.
    - jamespo 5y ago
      The reason they use C is as you said it's a fork. Being able to compile to almost anything is another factor I'd expect.
      - tialaramex 5y ago
        That would be an obvious reason why their SSH implementation is in C. But for example their ACME implementation (to get certificates from e.g. Let's Encrypt) is also in C, even though various more famous ACME clients that were started earlier and have better features are in more modern languages like Python. That C ACME client complies with OpenBSD's other preferences, it is privilege separated resulting in a bunch of separate programs running to handle different privileges for example, but it is written in C and lacks some obvious security features that aren't platform specific. Thus on OpenBSD a separate program handles your private key data from the one talking to the network. But, if you used a more capable ACME implementation for other platforms written in say, bash, a completely separate piece of software even on another machine can be talking to the network since that's just how the certificate process works. OpenBSD does not support this (last time I looked).
- deleted 5y ago
  [deleted]
- aborsy 5y ago
  OpenSSH is very well regarded in security community, has seen no major vulnerability for a long time.
sigil 5y ago
We are making [NTRU Prime + x25519 key exchange the default] now (i.e. ahead of cryptographically-relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available.
- unixhero 5y ago
  Very future proof! So it is quantum brute force crack proof?
  - zaarn 5y ago
    It isn't, you can always brute force the symmetric key used for traffic if you wanted. The handshake itself can also in theory be brute forced if you know all input parameters except the input key.
    - dandanua 5y ago
      It's true in theory, but not in practice, since the time needed is on a cosmic scale. Quantum computers are practical devices, also they use dedicated algorithms, not brute force.
      - bigcat123 5y ago
- chasil 5y ago
  This situation is actually more complex than the summary implies. NIST is conducting a competition for post-quantum key exchange and signature algorithms. NTRU Prime did not make the cut as a key exchange finalist. It appears that NTRU Prime is going ahead in OpenSSH, without any formal endorsement from NIST. In the notes listing NTRU Prime as an alternate (and rejection as a finalist), Daniel J. Bernstein filed a complaint with his experience at NIST: https://csrc.nist.gov/Projects/post-quantum-cryptography/round-3-submissions https://csrc.nist.gov/Projects/post-quantum-cryptography/rou... "Formal complaint regarding 8 June 2021 incident - 2021.06.15, Daniel J. Bernstein..." "Executive summary. A week ago Dr. Daniel Apon from NIST publicly accused me of professional misconduct. Specifically, he accused me of initiating private contact with NIST so as to provide false information to NIST regarding the timing of an upcoming announcement relevant to NIST’s ongoing decisions..." It is unfortunate that this disfunction has a practical impact upon OpenSSH.
ggm 5y ago
I like how they do new side effect of improvement with downsides. We can get used to this, and then they can deprecate scp/rcp in a future release.
- raspyberr 5y ago
  What's actually a convenient way of transferring files across a network if scp is being removed? Update: Thanks for the replies. I should've done a bit of extra research about scp first. Guess this is an example of Cunningham's Law.
  - ggm 5y ago
    The protocol is being deprecated not the scp command. It's been reimplemented over sftp. They have had to handle wildcard/glob expansion, and how scp tried to deal with it. TL;DR it's just the same command, mostly, for now.
  - exitb 5y ago
    They plan to deprecate scp the protocol, not scp the tool, which will use SFTP under the hood.
    - perbu 5y ago
      I'm pretty sure scp isn't a protocol. It is just a tool that relies on doing a request for execution over the regular ssh2 protocol. I've written a few custom ssh servers and you don't really need to do anything to them to support scp. sftp uses the sftp subsystem. scp just uses regular ssh requests and transports data over the ssh channels.
      - deleted 5y ago
        [deleted]
      - yakubin 5y ago
        See <https://en.wikipedia.org/wiki/Secure_copy_protocol https://en.wikipedia.org/wiki/Secure_copy_protocol> SFTP also transports data over SSH channels.
traceroute66 5y ago
Before this thread gets too long, there is already a lengthly discussion in play.[1] Hint for the future : There's a search box on the bottom of HN. ;-) [1]https://news.ycombinator.com/item?id=30954800 https://news.ycombinator.com/item?id=30954800
- aspenmayer 5y ago
  Ironically, that post is marked as dupe atm.
  - JimmaDaRustla 5y ago
    Because it was posted after this post.
    - robertlagrant 5y ago
      Ironically what we needed was a hint for the past, not for the future.
  - deleted 5y ago
    [deleted]
  - nivanson 5y ago
    Well, the dupe marked post is hours younger than this post.
- klocksib 5y ago
  You should post your hint to the other thread as it's the dupe.
- JimmaDaRustla 5y ago
  That was posted after this post...
- rurban 5y ago
  indeed. he should have used that. I was first, because when I updated my openssh mirror this morning, I was pleasently surprised by this.
ArcMex 5y ago
>sftp(1): add a "cp" command to allow the sftp client to perform server-side file copies. Well, goes to show how little I know. Been using this for years but apparently not!
- adolph 5y ago
  Maybe you have been using scp instead of sftp? Maybe you have been using a different sftp client than the OpenSSH one? https://superuser.com/questions/686394/scp-between-two-remote-hosts-from-my-third-pc https://superuser.com/questions/686394/scp-between-two-remot... https://unix.stackexchange.com/questions/8707/whats-the-difference-between-sftp-scp-and-fish-protocols https://unix.stackexchange.com/questions/8707/whats-the-diff...
- axiolite 5y ago
  > Been using this for years but apparently not! I don't know what you're trying to say here. Perhaps you misunderstood what's been added? Example: $ sftp HOST Connected to HOST. sftp> cp filea fileb Invalid command.
floor_ 5y ago
I would love an stb single header style version of this. I had to build this recently and it was a fucking nightmare.
exfascist 5y ago
One nice thing about recent versions of SSH is that they include support for signing arbitrary messages with your ssh key. I know you're not supposed to re-use keys but there have been situations where I needed to prove my identity to people who only had my ssh public key. This would have been super useful in the past.
- tialaramex 5y ago
  The OpenSSH arbitrary signing comes with a rationale for why this is actually safe. Basically they know these keys are intended for SSH, for which they will sign messages with a particular structure, and so they can choose the structure signed for the "arbitrary data signing" feature so that the two are necessarily disjoint - so no possible "arbitrary data" signature can be confused for a "I'm signing in to this SSH server" signature, and you're at no risk. Thus, even if you allow some adversary to literally pick the arbitrary data, when you'll sign that data and so on, your signing it cannot possibly allow them to impersonate you to a SSH server. This is easier to pull off than the rationale for key re-use in encryption because signing opaque blobs is a neutral action your SSH client already does, if adversaries could learn your keys or whatever from seeing you sign such a blob, then SSH authentication itself would be unsafe already. In contrast decrypting data an adversary sent to you might reveal something, especially if you can be persuaded (as happened for HTTPS with older TLS versions and most popular implementations) to tell the adversary what happened when you tried so this will usually be dangerous and a rationale for why it's safe must be thorough if we want non-experts to do it.
  - catlifeonmars 5y ago
    > In contrast decrypting data an adversary sent to you might reveal something, especially if you can be persuaded (as happened for HTTPS with older TLS versions and most popular implementations) to tell the adversary what happened when you tried so this will usually be dangerous and a rationale for why it's safe must be thorough if we want non-experts to do it. What exactly happened for HTTPS with older TLS versions? Sounds like you’re alluding to some sort of oracle attack.
deleted 5y ago
[deleted]

247 points by rurban 5y ago

Every time I pay enough attention to an OpenSSH release that I trick myself into reading some of the code, I'm left smh in disbelief that I actually rely on this software still.

jabiko 5y ago
Can you tell why that is? Did you find the OpenSSH source code especially bad? I am under the belief that OpenSSH is a really high quality, security focused software project.
- traceroute66 5y ago
  > Can you tell why that is? Yeah, I too find it a really bizarre comment to make, especially as it is not substantiated with any detail whatsoever. OpenSSH comes from the house of OpenBSD and LibreSSL. I am no security guru, but as I understand it, all three have a well deserved security reputation, and the core maintainers run a tight ship. We've already covered in recent weeks on HN how OpenSSH has maintained its robustness in the face of an increasingly hostile cyber world.[1] So, if you are going to imply that OpenSSH code is shit, back it up with hard facts. [1] https://news.ycombinator.com/item?id=30830749 https://news.ycombinator.com/item?id=30830749
  - pengaru 5y ago
    If you think this [0] is quality workmanship, I never want to work on your team. I haven't even exhaustively looked through this code, only took a quick glance at clientloop.c [1] and was curious about how the channels were integrated into the poll loop. This is a mess, and I'm pretty sure I already see a bug. [0] https://github.com/openssh/openssh-portable/blob/master/channels.c#L2636-L2743 https://github.com/openssh/openssh-portable/blob/master/chan... [1] https://github.com/openssh/openssh-portable/blob/master/clientloop.c#L1306-L1388 https://github.com/openssh/openssh-portable/blob/master/clie... Edit: I'm not looking at a future CVE, but I've definitely found a bug. For those of you tossing up low-effort straw men, actually go grok the code. The way they've integrated the poll loop into all the actual handling of the returned events is a sprawling mess, and the bug I've found is a direct result of that.
    - paskozdilar 5y ago
      I don't see anything so obviously wrong with [0]. I guess I'll never make it into your team ¯\_(ツ)_/¯
    - artogahr 5y ago
      Out of curiosity, can you explain what's wrong with that code? I dabbled in C a few years back but I'm nowhere near competent enough to find anything wrong with it.
      - faho 5y ago
        I'm also no C guru, but this seems to dereference a pointer before checking if it's in-bounds: struct pollfd *pfd = &pfds[p]; if (fd == -1) return; if (p == -1 || (u_int)p >= npfd) fatal_f("channel %d: bad pfd %d (max %u)", c->self, p, npfd); dump_channel_poll(__func__, what, c, p, pfd); If p is < 0 or >= npfd (the number of elements in pfds), this should read out of bounds of the pfds array, and the check happens too late. This is similar to a famous Linux kernel bug from ages ago, where a !NULL check was optimized away in such a situation, leading to an exploit: https://lwn.net/Articles/342330/ https://lwn.net/Articles/342330/ In this case I'm not aware if something like that happens, or if it happens to be harmless.
        aaronmdjones 5y ago
        This: struct pollfd *pfd = &pfds[p]; ... does not dereference pfds. It looks that way, but you need to account for the address-of operator before it. What it's actually doing is: struct pollfd *pfd = pfds + p; ... and thus it works even if pfds is NULL or if p is out of bounds. The following check before using pfd is correct.
        faho 5y ago
        Ah, okay. Personally I'd still want to do the check before, because someone could still be adding something in-between the assignment and the check, but if that's the order it's resolved in it seems to be working now. (I'm guessing they declare and assign the variable first because of C version constraints - wasn't that something that changed in C99?)
  - adastra22 5y ago
    > I am no security guru, but as I understand it, all three have a well deserved security reputation, and the core maintainers run a tight ship. Among us security gurus, OpenSSL has a really bad reputation. It's a giant pile of spaghetti code with a huge history of critical system vulnerabilities stemming from trying to be everything to everybody. Bitcoin is in the process of writing replacement functionality in order to remove OpenSSL entirely from its dependency tree because they got burned by major bugs multiple times in the past. A lot of modern alternatives like libsodium list "not OpenSSL" as a selling point. The situation is so bad that multiple organizations have forked OpenSSL to create stripped down alternatives (BoringSSL, LibreSSL) that are more likely to be secure. I know less about the OpenSSH code base specifically, except that it came out of the same culture and the same developers. I wouldn't use it in new projects unless I had no other choice.
    - zokier 5y ago
      > I know less about the OpenSSH code base specifically, except that it came out of the same culture and the same developers ummm what? Afaik openssh and openssl have no major common history? openssh comes from openbsd, openssl has always been independent project.
    - brynet 5y ago
      OpenSSH and LibreSSL are OpenBSD projects. OpenSSL has nothing to do with OpenBSD.
      - adastra22 5y ago
        Thank you for the correction!
daneel_w 5y ago
It's one of the most deployed pieces of software on the planet, and for that reason has a million eyes on it, yet there doesn't seem to be any alarming concern about the source quality. Maybe it's all right after all...
- tialaramex 5y ago
  Maybe. You've expressed the same sentiment as you'd have seen for OpenSSL just a few months before everybody decided OpenSSL was unacceptable and they'd fork it (producing BoringSSL, LibreSSL and so on). OpenBSD has some very peculiar preferences, some of which are in step with modern thinking (e.g. they like sandboxes, privilege dropping and defence in depth very much) but some very much are not (they like C despite its lack of Type Safety, Memory Safety, and generally just Safety) SecSH (the SSH v2 standard) is a fairly clean modern encrypted protocol design. You do a key exchange, you bring up an encrypted link and then everything else happens inside this, alleviating many of your security concerns, the same way TLS 1.3 works (but TLS 1.3 is much more recent). But the OpenSSH codebase dates back to even before SSHv2, it's basically the original SSH codebase, from back when encrypted remote shells was an entirely new idea, the mid-1990s, the SSH codebase went proprietary and OpenSSH is the fork. That's some crufty old code, and in C that's not an insignificant problem because problems in code you never read has potentially drastic consequences for unrelated code in the same binary.
  - jamespo 5y ago
    The reason they use C is as you said it's a fork. Being able to compile to almost anything is another factor I'd expect.
    - tialaramex 5y ago
      That would be an obvious reason why their SSH implementation is in C. But for example their ACME implementation (to get certificates from e.g. Let's Encrypt) is also in C, even though various more famous ACME clients that were started earlier and have better features are in more modern languages like Python. That C ACME client complies with OpenBSD's other preferences, it is privilege separated resulting in a bunch of separate programs running to handle different privileges for example, but it is written in C and lacks some obvious security features that aren't platform specific. Thus on OpenBSD a separate program handles your private key data from the one talking to the network. But, if you used a more capable ACME implementation for other platforms written in say, bash, a completely separate piece of software even on another machine can be talking to the network since that's just how the certificate process works. OpenBSD does not support this (last time I looked).
deleted 5y ago
[deleted]
aborsy 5y ago
OpenSSH is very well regarded in security community, has seen no major vulnerability for a long time.

sigil 5y ago

We are making [NTRU Prime + x25519 key exchange the default] now (i.e. ahead of cryptographically-relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available.

unixhero 5y ago
Very future proof! So it is quantum brute force crack proof?
- zaarn 5y ago
  It isn't, you can always brute force the symmetric key used for traffic if you wanted. The handshake itself can also in theory be brute forced if you know all input parameters except the input key.
  - dandanua 5y ago
    It's true in theory, but not in practice, since the time needed is on a cosmic scale. Quantum computers are practical devices, also they use dedicated algorithms, not brute force.
    - bigcat123 5y ago
chasil 5y ago
This situation is actually more complex than the summary implies. NIST is conducting a competition for post-quantum key exchange and signature algorithms. NTRU Prime did not make the cut as a key exchange finalist. It appears that NTRU Prime is going ahead in OpenSSH, without any formal endorsement from NIST. In the notes listing NTRU Prime as an alternate (and rejection as a finalist), Daniel J. Bernstein filed a complaint with his experience at NIST: https://csrc.nist.gov/Projects/post-quantum-cryptography/round-3-submissions https://csrc.nist.gov/Projects/post-quantum-cryptography/rou... "Formal complaint regarding 8 June 2021 incident - 2021.06.15, Daniel J. Bernstein..." "Executive summary. A week ago Dr. Daniel Apon from NIST publicly accused me of professional misconduct. Specifically, he accused me of initiating private contact with NIST so as to provide false information to NIST regarding the timing of an upcoming announcement relevant to NIST’s ongoing decisions..." It is unfortunate that this disfunction has a practical impact upon OpenSSH.

ggm 5y ago

I like how they do new side effect of improvement with downsides. We can get used to this, and then they can deprecate scp/rcp in a future release.

raspyberr 5y ago
What's actually a convenient way of transferring files across a network if scp is being removed? Update: Thanks for the replies. I should've done a bit of extra research about scp first. Guess this is an example of Cunningham's Law.
- ggm 5y ago
  The protocol is being deprecated not the scp command. It's been reimplemented over sftp. They have had to handle wildcard/glob expansion, and how scp tried to deal with it. TL;DR it's just the same command, mostly, for now.
- exitb 5y ago
  They plan to deprecate scp the protocol, not scp the tool, which will use SFTP under the hood.
  - perbu 5y ago
    I'm pretty sure scp isn't a protocol. It is just a tool that relies on doing a request for execution over the regular ssh2 protocol. I've written a few custom ssh servers and you don't really need to do anything to them to support scp. sftp uses the sftp subsystem. scp just uses regular ssh requests and transports data over the ssh channels.
    - deleted 5y ago
      [deleted]
    - yakubin 5y ago
      See <https://en.wikipedia.org/wiki/Secure_copy_protocol https://en.wikipedia.org/wiki/Secure_copy_protocol> SFTP also transports data over SSH channels.

traceroute66 5y ago

Before this thread gets too long, there is already a lengthly discussion in play.[1] Hint for the future : There's a search box on the bottom of HN. ;-) [1]https://news.ycombinator.com/item?id=30954800 https://news.ycombinator.com/item?id=30954800

aspenmayer 5y ago
Ironically, that post is marked as dupe atm.
- JimmaDaRustla 5y ago
  Because it was posted after this post.
  - robertlagrant 5y ago
    Ironically what we needed was a hint for the past, not for the future.
- deleted 5y ago
  [deleted]
- nivanson 5y ago
  Well, the dupe marked post is hours younger than this post.
klocksib 5y ago
You should post your hint to the other thread as it's the dupe.
JimmaDaRustla 5y ago
That was posted after this post...
rurban 5y ago
indeed. he should have used that. I was first, because when I updated my openssh mirror this morning, I was pleasently surprised by this.

ArcMex 5y ago

>sftp(1): add a "cp" command to allow the sftp client to perform server-side file copies. Well, goes to show how little I know. Been using this for years but apparently not!

adolph 5y ago
Maybe you have been using scp instead of sftp? Maybe you have been using a different sftp client than the OpenSSH one? https://superuser.com/questions/686394/scp-between-two-remote-hosts-from-my-third-pc https://superuser.com/questions/686394/scp-between-two-remot... https://unix.stackexchange.com/questions/8707/whats-the-difference-between-sftp-scp-and-fish-protocols https://unix.stackexchange.com/questions/8707/whats-the-diff...
axiolite 5y ago
> Been using this for years but apparently not! I don't know what you're trying to say here. Perhaps you misunderstood what's been added? Example: $ sftp HOST Connected to HOST. sftp> cp filea fileb Invalid command.

floor_ 5y ago

I would love an stb single header style version of this. I had to build this recently and it was a fucking nightmare.

exfascist 5y ago

One nice thing about recent versions of SSH is that they include support for signing arbitrary messages with your ssh key. I know you're not supposed to re-use keys but there have been situations where I needed to prove my identity to people who only had my ssh public key. This would have been super useful in the past.

tialaramex 5y ago
The OpenSSH arbitrary signing comes with a rationale for why this is actually safe. Basically they know these keys are intended for SSH, for which they will sign messages with a particular structure, and so they can choose the structure signed for the "arbitrary data signing" feature so that the two are necessarily disjoint - so no possible "arbitrary data" signature can be confused for a "I'm signing in to this SSH server" signature, and you're at no risk. Thus, even if you allow some adversary to literally pick the arbitrary data, when you'll sign that data and so on, your signing it cannot possibly allow them to impersonate you to a SSH server. This is easier to pull off than the rationale for key re-use in encryption because signing opaque blobs is a neutral action your SSH client already does, if adversaries could learn your keys or whatever from seeing you sign such a blob, then SSH authentication itself would be unsafe already. In contrast decrypting data an adversary sent to you might reveal something, especially if you can be persuaded (as happened for HTTPS with older TLS versions and most popular implementations) to tell the adversary what happened when you tried so this will usually be dangerous and a rationale for why it's safe must be thorough if we want non-experts to do it.
- catlifeonmars 5y ago
  > In contrast decrypting data an adversary sent to you might reveal something, especially if you can be persuaded (as happened for HTTPS with older TLS versions and most popular implementations) to tell the adversary what happened when you tried so this will usually be dangerous and a rationale for why it's safe must be thorough if we want non-experts to do it. What exactly happened for HTTPS with older TLS versions? Sounds like you’re alluding to some sort of oracle attack.

deleted 5y ago

[deleted]