Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

jobs.hackclub.com

Post reply on HN
Print view View original

71–80 of 119 posts

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#71

Post by shakna »

raggi wrote: post #50
reasons wrote: post #5

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?

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…

> As far as I know, the client is not fuzzed (though I'd be happy to find out I'm wrong).

Just touching on this one part, the rest still applies, openssh does use fuzzing. [0][1] Both client and daemon are fuzzed using AFL, though it does seem to be on an ad-hoc basis rather than automated, but it generally happens before a new release.

Unfortunately, to run AFL on openssh, they do have to patch it a bit, so what gets fuzzed and what is released isn't 1-to-1. This is because the privilege separations tend to defeat methods of detecting most of those sorts of bugs on their own.

[0] https://github.com/djmdjm/openssh-fuzz-cases

[1] For example: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ke...

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#72

Post by raggi »

shakna wrote: post #71
raggi wrote: post #50

Earlier quoted context omitted.

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…

> As far as I know, the client is not fuzzed (though I'd be happy to find out I'm wrong). Just touching on this one part, the rest still applies, openssh does use fuzzing. [0][1] Both client and daemon are fuzzed using AFL, though it does seem to be on an ad-hoc basis rather than automated, but it generally happens before a new release. Unfortunately, to run AFL on openssh, they do have to patch it a bit, so what get…

This is pleasing to hear :)

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#73

Post by [deleted] »

geofft wrote: post #30
thaumasiotes wrote: post #28

Earlier quoted context omitted.

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 th…

> (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 e…

[deleted]

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#74

Post by [deleted] »

geofft wrote: post #30
thaumasiotes wrote: post #28

Earlier quoted context omitted.

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 th…

> (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 e…

[deleted]

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#75

Post by dumpsterdiver »

geofft wrote: post #30
thaumasiotes wrote: post #28

Earlier quoted context omitted.

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 th…

> (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 e…

If I had two servers allowing ssh, and you logged into one of them by providing a public key which I added to the authorized_keys file, it would be a good guess that it was still you if you logged into my second server the same way.

Is that what you’re trying to say?

Granted it still wouldn’t prove it, because we are not our ssh keys. We’re all potentially one malware infection away from having our private keys compromised. Also, if someone wanted to "shed" the identity associated with a public key they could always just "accidentally" leak the private key in a public git commit.

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#76

Post by theteapot »

raggi wrote: post #50
reasons wrote: post #5

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?

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…

> Do not connect with agent forwarding, as doing so would allow the server operator to connect to other locations as you.

Just having enabled is enough?! Pretty sure you'd need to forward one or more identities too.

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#77

Post by thaumasiotes »

dumpsterdiver wrote: post #75
geofft wrote: post #30

Earlier quoted context omitted.

> (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 e…

If I had two servers allowing ssh, and you logged into one of them by providing a public key which I added to the authorized_keys file, it would be a good guess that it was still you if you logged into my second server the same way. Is that what you’re trying to say? Granted it still wouldn’t prove it, because we are not our ssh keys. We’re all potentially one malware infection away from having our private keys compr…

> Also, if someone wanted to "shed" the identity associated with a public key they could always just "accidentally" leak the private key in a public git commit.

That would allow anyone to prove that they owned the public key, which prevents the original owner from using it. But it seems like, if you want to stop using the key, it's simpler to just stop using it. What does leaking the private key accomplish that deleting the private key doesn't also accomplish?

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#78

Post by tomcooks »

HatchedLake721 wrote: post #7
1cvmask wrote: post #2

Says the subdomain link that lacks SSL. A wildcard certificate would have sufficed.

Kinda unforgivable to be on front page of HN in 2021 without https

Yes beware of the friendly dragon stealing your credit card info

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#79

Post by hutrdvnj »

raggi wrote: post #50
reasons wrote: post #5

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?

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…

Would it increase security if I ssh from a docker container?

Re: Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com

#80

Post by hutrdvnj »

ipaddr wrote: post #64
alexander-litty wrote: post #23

Earlier quoted context omitted.

People also expect their postcards to arrive untampered. ISPs, Comcast in particular, inject ad-loading javascript into HTTP pages. https://arstechnica.com/tech-policy/2014/09/why-comcasts-jav... https://www.reddit.com/r/technology/comments/9b5ikd/

In fairness isn't that a result of your relationship with your isp? If you remain because of price or no other services available why wouldn't you use a vpn knowing your isp is a hostile actor and probably trying to deeply inspect packets, etc?

Because if you use HTTP over VPN, then you really have to trust your VPN provider. Why should you do that?
Post reply on HN