Show HN: Apply for a job through SSH, $ ssh jobs.hackclub.com
jobs.hackclub.com
jobs.hackclub.com
Imagine making a job board work over ssh and then using slack to communicate.
Especially when things like this exist and are much more in the spirit: https://github.com/shazow/ssh-chat
It’s built by a 15 year old Hack Clubber and streams to / from a channel on the Hack Club Slack.
Open source at https://github.com/quackduck/devzat
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.
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.)
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.
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.
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?
Anyone can download your public SSH keys from GitHub (github.com/<username>.keys). The Ubuntu Server installed uses this to make setting up a mostly headless server easier.
Application-wise: The statement "In case you want to apply for a job without admitting who you are" is begging the question that the service is actually for job applications, something we have no trust in or knowledge of other than the title of a post on a public forum.
Identity-wise: You're also making the assumption that key = person. Keys can be set up to authenticate client applications and remote services with each other. People can have dozens of keys for various things they have installed via wizards or copy-pasting tutorials which they may not even be aware of. Key pairs are also shared by email and internal docs far more often than they should be with limited control over who they are distributed to.
Harm-wise: If I were an evildoer, I would have spent my career obtaining and organising databases full of all sorts of information; email addresses, hashed passwords, usernames / aliases, phone numbers, etc. I'd definitely have a special database set aside for key-pairs I've scraped from various plaintext sources that I haven't found a use for. The opportunity to target a subset of industry professionals (with presumably more privileged access to information than the average joe) to correlate even a small fraction of known public keys with specific IPs, email addresses, even hackernews aliases would be a huge value add to my "services". You could just slurp the data in, then even if you get no hits, maybe a year or two down the line it becomes relevant.
For anyone dealing with this kind of threat vector on the daily the stakes are pretty high and can include bankruptcy and professional ruin. Yeah we all visit random websites, but it's not every day people connect to an SSH server outside of their trust network. Do you really wanna be that guy whose key was used to leak a database full of medical data or something?
The audience of this website include people who work with PII and may not be familiar with the intricacies of the SSH command line utility, and the state of affairs in information security is pretty bleak in IT-backed organisations as we see every single day, so in this context I don't think it's cool to bash people being privacy conscious.
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.
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.
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.
Of course there's a list of common services that you could probably try and they could gain access there like say push/pull on github/gitlab however as long as those common services have another layer of protection (i.e. mandatory commit signing) it should limit the effective attack area pretty effectively.
I also generally find that ssh connections will be one way (i.e. you typically only set up SSH authentication to flow in a specific direction). As long as your SSH authentication graph is directed and acyclic (i.e. no loops and connections only go in one direction), there is little ability for a malicious server to access other nodes in the SSH auth graph provided you connect from a leaf or near leaf node.
I don't use agent forwarding because of the issues with it but there are definitely ways to reduce the attack area that it provides.
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...
Just having enabled is enough?! Pretty sure you'd need to forward one or more identities too.
Not only are they not provably secure (very few things are), they are explicitly not intended for use as a security boundary. Their whole gimmick is lightweight containers you can use instead of VMs if you trust everyone who's going to run code under them.
The conflation of what amounts to fancy Linux cgroups trickery with hypervisors is a depressing misunderstanding of isolation.
This requires an explicit argument, right?
Recent example: https://www.openwall.com/lists/oss-security/2021/05/17/1
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.
https://github.com/$USERNAME.keys
alias sshn="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"Oh well.
Try it: `ssh sshtron.zachlatta.com`
I built SSHTron a few years ago at a hackathon. It served as the inspiration for jobs.hackclub.com.
The code for both is open source, at https://github.com/zachlatta/sshtron and https://github.com/hackclub/jobs respectively.
When was the last time you ssh'd to a server you didn't already have some level of trust with? (AWS, GCP, work server farms, etc.)
I'd still suggest that sharing your keys by default is ... a bad idea. Sure, fingerprints help, but there's the chance of accidentally or maliciously being redirected to a rogue server.
Also if you or another script once added * to your .ssh/config long ago it may still be lurking there among other lines without you realizing.
I agree checking fingerprints helps, but that can turned off pretty easily too.
http://weblog.raganwald.com/2007/01/dont-overthink-fizzbuzz....
People still send postcards, where they don't care if people read what's written on it..
ISPs, Comcast in particular, inject ad-loading javascript into HTTP pages.
https://arstechnica.com/tech-policy/2014/09/why-comcasts-jav...
Your isp knows you visited a certain domain with https. That's a concern.
You just shift the trust around. Now I have to trust the hoster, e.g. OVH instead of my local ISP. Really the best thing you can do is end-to-end encryption, don't send plaintext over the internet.
> Your isp knows you visited a certain domain with https. That's a concern.
How about DNS over HTTPS?
Any ISP is allowed to sniff and manipulate packets, so this isn't just about my ISP -- it's the server's ISP as well as any entities in-between.
Even if I did (assuming that I reasonably could!) change my ISP, that's changing only one of the potentially many hostile actors.
>why wouldn't you use a vpn
That would require me to trust the connection between the VPN and the server.
Plus, then I would need to buy a VPN subscription :) Just serve HTTPS!
A vpn moves any legal situation into a country with different laws.
Grandparent said "unforgivable".. sheesh, over the top much?
There tend to be about 0–2 http: entries on the front page. A fairly large fraction of those are old things. http: submissions on domains that support https: (whether or not they redirect to it by default) are very uncommon.
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 exceptions.
I ssh'd to the server. I followed some weird little terminal prompts. I cat'd a .md file. I don't really see what's going on here.
Apart from the readme all the files are job listings. Seems pretty clear to me.
https://docs.microsoft.com/en-us/windows-server/administrati...
However, there are many versions of Windows which do not ship with ssh.
However, I believe everyone's stdout/stderr is available to everyone, if everyone is the same user, and if that user has read access to /proc, so that confidentiality is only restricted those who access to the server.