1. 16
  1. 8

    The way x/crypto/ssh is implemented now does not expose the username at the time of applying the server configuration for an incoming connection… Figuring this out requires deep-dive into the OpenSSH code as well as x/crypto/ssh.

    It really takes about 3 seconds of research to see how to do this. You can just store it in the Permissions.Extensions map in crypto/ssh.

    1. 6

      Interesting, but feels a bit odd to start out mentioning studies and thenfocus on the one piece that probably is pretty secure C

      Anyways, I really like seeing that there’s quite a few ssh related projects in Go.

      1. 5

        This article really fails to paint a picture for why. Why? OpenSSH is one of the most solid things we have

        1. 3

          I feel the same, BUT by the same token I also feel like competition in any ecosystem makes both parties stronger, so hey, if someone wants to implement a bespoke ssh in Golang, rock on with your bad selves I say and we all benefit, right?

          1. 1

            There are other ssh servers that are widely used like dropbear, why not another one? https://en.wikipedia.org/wiki/Comparison_of_SSH_servers

            1. 1

              Oh sure, if the answer is just “why not”. But the tone made it seem like there might be a why.

            2. 1

              The entire first paragraph talks about how memory-unsafe languages are a common problem for internet infrastructure. Seems like a reasonable statement for “why”.

              1. 2

                Yes, but this is OpenSSH. No matter what language it’s in, you would usually want to point to a history of that actually being a problem. But OpenSSH has no such history.