7 ms·

Are there are any security precautions in using ssh (or telnet, netcat or curl for that matter) to connect to an unknown service like this?

lallysingh 5y ago
Your terminal probably has some stack overflows in its terminal emulation code.
pushcx 5y ago
A privacy precaution would be to `ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no jobs.hackclub.com`. By default ssh will send all its public keys to a server unless given an identify file to use as an arg or in ~/.ssh/config.
- thaumasiotes 5y ago
  In case you want to apply for a job without admitting who you are?
  - parksy 5y ago
    In case you want to connect to a random ssh server without giving it your public ssh keys.
    - thaumasiotes 5y ago
      Yes, but there's a reason those are called "public" keys. The reason is that you don't suffer any harm by giving them out. Except that they may be publicly identified with you. In that case, and only that case, giving them out would involve purporting to be the person who is publicly associated with the keys. (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) So this concern appears to be that you want to apply for a job without disclosing your identity. I think that's a strange thing to do.
      - geofft 5y ago
        > (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) I don't believe this is true, right? You do a private key operation demonstrating you possess the private key associated with the public key. Or, by contradiction: Since the key is public, any server can put the fingerprint of the key in an authorized_keys file. It can then challenge you to log in in a way that exactly matches what a real server you'd actually want to log into would do, because a real server doesn't have your private key either. If your client could also authenticate to the server in a way that didn't prove anything beyond possession of the public key, then it could do the same to some actual server, i.e., the SSH protocol would have no meaningful authentication at all. Because we know the SSH protocol is not completely and trivially broken, this cannot be true. (I think you also overestimate the value of technical deniability - certainly outside a court of law, nobody is obligated to think, "Well, it could be a complete coincidence, so I'm going to disregard this piece of information I just learned." And I wouldn't bet on it inside a court of law either.)
        thewakalix 5y ago
        As I understand it, your SSH client gives out all your public keys, but doesn’t authenticate with all of them. That might be the crux.
        thaumasiotes 5y ago
        > I think you also overestimate the value of technical deniability Huh? I presented the claim to identity that submitting a public key implicitly makes as being the only thing that our hypothetical applicant is seeking to avoid. I valued the technical deniability at zero. But I said above, and say again here, that most job applicants are not seeking to avoid disclosing their identity as they apply for a job. They are usually specifically trying to highlight it.
        deleted 5y ago
        [deleted]
        deleted 5y ago
        [deleted]
  - gorgoiler 5y ago
    The “public” in public key just means it doesn’t need to be secret, for cryptographic purposes. It’s different to your public identity as a person — I don’t think I’ve ever seen an ssh key used for that, in practice. I might have multiple ssh key pairs related to my different roles as: high school teacher, two different GitHub users, peer to peer pharmaceuticals distributor, and upstanding private citizen. I cannot see a scenario where prospective employers would want to connect these identities.
    - sterlind 5y ago
      Prospective employers probably would want to connect your street pharmacy side-gig with your identity, you just wouldn't want them to.
      - gorgoiler 5y ago
        Hah, good point. Also, if my upstream dealer knew I was a teacher they’d probably leverage that to blackmail me.
      - krageon 5y ago
        Any good prospective employer would not want to, unless it's directly relevant to their work field.
        seoaeu 5y ago
        Employers are greatly interested in how prospective employees feel about following the law. Learning about your "street pharmacy side-gig" gives a clear answer of that.
  - eyelidlessness 5y ago
    Huh? People routinely have public identification they don’t share with prospective employers. I personally use the same handle everywhere so any employer who doesn’t want me can go to hell without me telling them. A lot of people keep quite public things quite private from their employers. And why shouldn’t they? Their employers are not their owners.
toast0 5y ago
Make sure you're not doing agent forwarding or port forwarding.
deleted 5y ago
[deleted]
raggi 5y ago
Yes. Do not connect with agent forwarding, as doing so would allow the server operator to connect to other locations as you. Do not forward environment information, though the typical ssh default is not to. You will likely leak your username. If you connect from an internet reachable host, and you made the mistake of not doing the first item in this list, they could easily connect back to you, not requiring any zero days. Other probably lower ROI attacks might include forcing you down to using extremely poor protocol versions or crypto options, resulting in potential information exposure if you remained online long enough to push a relevant sample of traffic. I would pin the client to a very tight set of allowed protocols and cipher suites. Your terminal emulator program should ideally be sandboxed, iTerm, xterm, rxvt, etc have had bugs found and most aren't regularly fuzzed. Similarly, having been in the ssh code base plenty, I'm not really sure I would wholly trust the standard openssh(1) client post-auth against a malicious server. It's highly macro-conditioned C with subtle semantics and invariants spread all over the place, extremely large functions, in-line parsing and in-house crypto. It does some things well, like trying to clear keys from memory early, but it's not written in a safe language, nor is it written in a safe way. As far as I know, the client is not fuzzed (though I'd be happy to find out I'm wrong). It also, depending on configuration calls out to other libraries with unfortunate history, zlib in particular, which while there hasn't been a known recent issue, there have been serious issues in the past. Depending on how it was sourced, there may be other issues too. If you look in the OpenBSD repository for example, you'll find the libz it is linking is from zlib 1.2.3, so a good 10 years older than the last relatively serious zlib exploit, which is about 5 years old. The zlib changelog in OpenBSD does not seem to include the patch for CVE-2016-9841. This doesn't prove anything that significant, only points out the reality that this stuff doesn't get as many eyeballs as it really should. I just went diving for 10 minutes and this is what I found. In case you're wondering, the function in question is called from inflate, which is called from ssh_packet_read_poll2 (one of the aforementioned extremely long and macro-configured ssh functions), and is called in both the server and client dispatch code. Using a modern web browser is a much safer way to go about this, in the end.
- justinjlynn 5y ago
  Thanks for the excellent summary and explanation. I knew the answer was that it wasn't safe - but the detail here is remarkable. :)
inetknght 5y ago
If you use the same public key across services then there's a good chance that your user can be identified. Github, for example, publishes users' public keys [0]. So if I re-use the same public key then you know it's me. Re-using the same public key is bad for privacy. But if you combine it with other security nightmares. With agent forwarding the remote can enumerate all of your unlocked keys. The solution is 1) do not enable agent forwarding and 2) do not use key agents. With X11 forwarding the remote side has basically full access to your local session. The solution is don't enable X11 forwarding.
- philshem 5y ago
  I guess [0] is https://github.com/$USERNAME.keys e.g. https://github.com/nat.keys https://github.com/nat.keys
  - inetknght 5y ago
    Whoops yeah pretty much. I forgot to paste the link. I was distracted. Now it's too late to edit
grishka 5y ago
Not quite security-related, but ssh is very pushy about host key verification and insists on adding keys to known hosts. That isn't always a desired behavior, so I have this: alias sshn="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"
airhead969 5y ago
-akx https://www.man7.org/linux/man-pages/man1/ssh.1.html https://www.man7.org/linux/man-pages/man1/ssh.1.html
px43 5y ago
I remember back where there were some code execution bugs in putty, a friend would pose as a naive Linux noob on IRC, go into hacking channels, and ask if people could help him fix some problem, and he would get shells on anyone who tried to log in to his machine. https://www.exploit-db.com/exploits/1788 https://www.exploit-db.com/exploits/1788

lallysingh 5y ago

Your terminal probably has some stack overflows in its terminal emulation code.

pushcx 5y ago

A privacy precaution would be to `ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no jobs.hackclub.com`. By default ssh will send all its public keys to a server unless given an identify file to use as an arg or in ~/.ssh/config.

thaumasiotes 5y ago
In case you want to apply for a job without admitting who you are?
- parksy 5y ago
  In case you want to connect to a random ssh server without giving it your public ssh keys.
  - thaumasiotes 5y ago
    Yes, but there's a reason those are called "public" keys. The reason is that you don't suffer any harm by giving them out. Except that they may be publicly identified with you. In that case, and only that case, giving them out would involve purporting to be the person who is publicly associated with the keys. (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) So this concern appears to be that you want to apply for a job without disclosing your identity. I think that's a strange thing to do.
    - geofft 5y ago
      > (It wouldn't prove it, because, after all, those keys are public; anyone can know and distribute them.) I don't believe this is true, right? You do a private key operation demonstrating you possess the private key associated with the public key. Or, by contradiction: Since the key is public, any server can put the fingerprint of the key in an authorized_keys file. It can then challenge you to log in in a way that exactly matches what a real server you'd actually want to log into would do, because a real server doesn't have your private key either. If your client could also authenticate to the server in a way that didn't prove anything beyond possession of the public key, then it could do the same to some actual server, i.e., the SSH protocol would have no meaningful authentication at all. Because we know the SSH protocol is not completely and trivially broken, this cannot be true. (I think you also overestimate the value of technical deniability - certainly outside a court of law, nobody is obligated to think, "Well, it could be a complete coincidence, so I'm going to disregard this piece of information I just learned." And I wouldn't bet on it inside a court of law either.)
      - thewakalix 5y ago
        As I understand it, your SSH client gives out all your public keys, but doesn’t authenticate with all of them. That might be the crux.
      - thaumasiotes 5y ago
        > I think you also overestimate the value of technical deniability Huh? I presented the claim to identity that submitting a public key implicitly makes as being the only thing that our hypothetical applicant is seeking to avoid. I valued the technical deniability at zero. But I said above, and say again here, that most job applicants are not seeking to avoid disclosing their identity as they apply for a job. They are usually specifically trying to highlight it.
      - deleted 5y ago
        [deleted]
      - deleted 5y ago
        [deleted]
- gorgoiler 5y ago
  The “public” in public key just means it doesn’t need to be secret, for cryptographic purposes. It’s different to your public identity as a person — I don’t think I’ve ever seen an ssh key used for that, in practice. I might have multiple ssh key pairs related to my different roles as: high school teacher, two different GitHub users, peer to peer pharmaceuticals distributor, and upstanding private citizen. I cannot see a scenario where prospective employers would want to connect these identities.
  - sterlind 5y ago
    Prospective employers probably would want to connect your street pharmacy side-gig with your identity, you just wouldn't want them to.
    - gorgoiler 5y ago
      Hah, good point. Also, if my upstream dealer knew I was a teacher they’d probably leverage that to blackmail me.
    - krageon 5y ago
      Any good prospective employer would not want to, unless it's directly relevant to their work field.
      - seoaeu 5y ago
        Employers are greatly interested in how prospective employees feel about following the law. Learning about your "street pharmacy side-gig" gives a clear answer of that.
- eyelidlessness 5y ago
  Huh? People routinely have public identification they don’t share with prospective employers. I personally use the same handle everywhere so any employer who doesn’t want me can go to hell without me telling them. A lot of people keep quite public things quite private from their employers. And why shouldn’t they? Their employers are not their owners.

toast0 5y ago

Make sure you're not doing agent forwarding or port forwarding.

deleted 5y ago

[deleted]

raggi 5y ago

Yes. Do not connect with agent forwarding, as doing so would allow the server operator to connect to other locations as you. Do not forward environment information, though the typical ssh default is not to. You will likely leak your username. If you connect from an internet reachable host, and you made the mistake of not doing the first item in this list, they could easily connect back to you, not requiring any zero days. Other probably lower ROI attacks might include forcing you down to using extremely poor protocol versions or crypto options, resulting in potential information exposure if you remained online long enough to push a relevant sample of traffic. I would pin the client to a very tight set of allowed protocols and cipher suites. Your terminal emulator program should ideally be sandboxed, iTerm, xterm, rxvt, etc have had bugs found and most aren't regularly fuzzed. Similarly, having been in the ssh code base plenty, I'm not really sure I would wholly trust the standard openssh(1) client post-auth against a malicious server. It's highly macro-conditioned C with subtle semantics and invariants spread all over the place, extremely large functions, in-line parsing and in-house crypto. It does some things well, like trying to clear keys from memory early, but it's not written in a safe language, nor is it written in a safe way. As far as I know, the client is not fuzzed (though I'd be happy to find out I'm wrong). It also, depending on configuration calls out to other libraries with unfortunate history, zlib in particular, which while there hasn't been a known recent issue, there have been serious issues in the past. Depending on how it was sourced, there may be other issues too. If you look in the OpenBSD repository for example, you'll find the libz it is linking is from zlib 1.2.3, so a good 10 years older than the last relatively serious zlib exploit, which is about 5 years old. The zlib changelog in OpenBSD does not seem to include the patch for CVE-2016-9841. This doesn't prove anything that significant, only points out the reality that this stuff doesn't get as many eyeballs as it really should. I just went diving for 10 minutes and this is what I found. In case you're wondering, the function in question is called from inflate, which is called from ssh_packet_read_poll2 (one of the aforementioned extremely long and macro-configured ssh functions), and is called in both the server and client dispatch code. Using a modern web browser is a much safer way to go about this, in the end.

justinjlynn 5y ago
Thanks for the excellent summary and explanation. I knew the answer was that it wasn't safe - but the detail here is remarkable. :)

inetknght 5y ago

If you use the same public key across services then there's a good chance that your user can be identified. Github, for example, publishes users' public keys [0]. So if I re-use the same public key then you know it's me. Re-using the same public key is bad for privacy. But if you combine it with other security nightmares. With agent forwarding the remote can enumerate all of your unlocked keys. The solution is 1) do not enable agent forwarding and 2) do not use key agents. With X11 forwarding the remote side has basically full access to your local session. The solution is don't enable X11 forwarding.

philshem 5y ago
I guess [0] is https://github.com/$USERNAME.keys e.g. https://github.com/nat.keys https://github.com/nat.keys
- inetknght 5y ago
  Whoops yeah pretty much. I forgot to paste the link. I was distracted. Now it's too late to edit

grishka 5y ago

Not quite security-related, but ssh is very pushy about host key verification and insists on adding keys to known hosts. That isn't always a desired behavior, so I have this: alias sshn="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"

airhead969 5y ago

-akx https://www.man7.org/linux/man-pages/man1/ssh.1.html https://www.man7.org/linux/man-pages/man1/ssh.1.html

px43 5y ago

I remember back where there were some code execution bugs in putty, a friend would pose as a naive Linux noob on IRC, go into hacking channels, and ask if people could help him fix some problem, and he would get shells on anyone who tried to log in to his machine. https://www.exploit-db.com/exploits/1788 https://www.exploit-db.com/exploits/1788