Live data from Hacker News

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

jobs.hackclub.com

81–90 of 119 posts

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

#81
post #9

Earlier quoted context omitted.

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.

In case you want to apply for a job without admitting who you are?

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.

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

#83

Earlier quoted context omitted.

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

Plausible deniability.

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

#84
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?

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…

I guess [0] is

    https://github.com/$USERNAME.keys
e.g. https://github.com/nat.keys

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

#85

Earlier quoted context omitted.

Just added SSL. Live at https://jobs.hackclub.com .

You should use a 301 (permanent) redirect, not a 302 (temporary) redirect as you currently are. Just speaking generally, I found the use of an http: link on this very curious, given that it’s about SSH (and thus encryption in no little part), so I’m guessing you’re not a “Web Developer”. So here’s my advice on the matter: everything on the web should be HTTPS now; nothing should be plain-text HTTP, with zero exceptio…

Unless you want to allow browsers that can't do HTTPS, such as old Amiga browsers.

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

#86
post #85

Earlier quoted context omitted.

You should use a 301 (permanent) redirect, not a 302 (temporary) redirect as you currently are. Just speaking generally, I found the use of an http: link on this very curious, given that it’s about SSH (and thus encryption in no little part), so I’m guessing you’re not a “Web Developer”. So here’s my advice on the matter: everything on the web should be HTTPS now; nothing should be plain-text HTTP, with zero exceptio…

Unless you want to allow browsers that can't do HTTPS, such as old Amiga browsers.

I’m going to be callous and say that Amiga browsers aren’t on the web. It’s a dead platform, if you’re actually targeting something for it you’re kind of not targeting the web proper, but rather a historical artefact that kinda lives in the same space. :-)

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

#88

Earlier quoted context omitted.

Why exactly? Other than a lot of "potential problems" security theater? People still send postcards, where they don't care if people read what's written on it..

Because it’s the expected behavior. If you showed up to an interview for an attorney position and your interviewer was shirtless you’d think they’d lost their mind.

Was it normal to go to job interviews shirtless 10-15 years ago? Please come up with a better analogy ;-)

Grandparent said "unforgivable".. sheesh, over the top much?

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

#89
post #50
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

This requires an explicit argument, right?

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

#90
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…

Note that they could only log back into your machine if you use the same credentials to between machines. This is one of the arguments for generating a unique SSH key on each machine you use. It makes it far harder to break in if you mess up somewhere along the way.

Not necessarily. If you have multiple keys active in local your SSH Agent, then connect to a malicious host with Agent Forwarding enabled, the malicious host could try to connect to to a third host and I believe it will try to use all active keys from the local agent.
Post reply on HN