> True freedom would be when you can take yourself out of the picture and still earn income
In this case the "boss" is the cash cow and keeping it alive; also maintaining marketable skills incase the thing dies.
Having too much time and money on your hands can also pose certain social and mental health challenges. It seems everyone has a job whether they like it or not.
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.
> 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.
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.
Personally my approach is to use a unique GPG Authentication key per machine with gpg-agent. They can't log back into the current machine and unless it's a targetted attack they shouldn't have any knowledge of my other machines.
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.
Docker containers aren't provably secure. If you want isolation, use a VM that doesn't have host file system access. This way, if the VM is compromised, just throw it away and it can't leak out the way containers do.
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.
To disambiguate: I don't mean formal verification like seL4, I mean it hasn't been thoroughly audited to show it is reasonably secure. Docker security of images and running containers is pretty shit as I brought up on GH in the beginning. Developers just shrugged it off and focused on whiz-bang features.
The conflation of what amounts to fancy Linux cgroups trickery with hypervisors is a depressing misunderstanding of isolation.
It's not enabled by default, but unfortunately I've seen many SSH config related articles that advocate some scary stuff like setting ForwardAgent yes for Host * combined with ssh-add <every-key> in .zshrc/.bashrc
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.
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.
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.
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.
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.
The other reply to this comment misses the fact that an nonce is used in the client authentication process. Thus, one server to which you successfully authenticate using a public key cannot replay that against a different server that accepts the same key. There is a unique value that is sent to the client, hashed, and then signed with the private key.
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.
If you mean geofft's comment, I don't believe they're talking about a replay attack. thaumasiotes wrote "It wouldn't prove it, because anyone could be presenting the public key", but geofft is saying that if the server claims to recognize the key and requests to continue authentication using it, then your client will potentially provide the proof—invisibly and automatically, if the private key is passwordless/agent-loaded. There is no second server; this is the original server being able to confirm that you are actually in possession of a supposedly-unrelated-to-anything key. (I have not verified whether the order of operations in the protocol actually works this way; I'm just interpreting what geofft is saying.)
> (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.)
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.
> 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?
> 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.
I would say more specifically: if you have any SSH keys that are associated with non-career nyms (which is a perfectly reasonable thing to do) then keep them separate and only include them for known associated hosts, perhaps by using IdentityFile in Host blocks in .ssh/config.
I think the OP's service is pretty cool, it reminds me of ye olde BBS's. I am actually writing my personal resume as a command prompt based on old 80's PCs as well, albeit in HTML/JS, so I do dig the aesthetic.
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.
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.
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.
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"
> Why should they prioritize people who break their hard work and coerce them into paying for protection?
Because they voluntarily joined responsible disclosure programs and promised rewards?
Their hard work wasn't good enough to survive in the extremely hostile world out there. The fact is online gaming is a form of distributed computing and so people are exposed to network attacks. By failing to prioritize security they are putting their customers at risk. They can either start taking this seriously or watch people make money off of the vulnerabilities in their hard work.
Valve's stance on hackers won't change the fact they exist and are out there doing their thing. Valve's stance can now be the deciding factor between exploits being disclosed to them for a reward, or sold on black markets as cheats.
If you don't want people "breaking your hard work", don't release software. However, being on hackerone can help alleviate the negatives.
Computer science is nowhere near its maturity as a whole. It needs more people with ethics and empathy. We've seen what has happened without that factored in; we're living in it.
Innovation as a goal sounds noble initially, but in my experience it's like chasing the wind. Faithfully doing what is already known to be good seems better for everyone. It might even be the quicker road to innovation.
To your first point, software and computer science are in their infancy. To say software has reached its limit speaks of the abilities, and imagination of the author.
As to your second point, we did have people with exceptional sense of social responsibility in software, but multiple factors, including easy/fast money, unspoken agendas, both co-opted and corrupted some, and drew in 'fresh blood' that was motivated purely by the new social cachet & easy fortunes of software work. (These are the ones Alan Kay would say are the 'pop artists' of 'pop software'.)
As to innovation and "limits", there are legion and everything from the hardware, OS, libraries, to languages are on the table for innovating, to say nothing of theoretical breakthroughs in pure comp-sci.
Software is the closest thing to magic we have in the modern world. The imaginal sky is the limit.
The US was founded by entire colonies of people coming overseas to worship the Christian God freely. Many key founders were deeply religious; believing all forms of government are doomed without the help of the Christian God. The Christian God was a huge factor in government and repeatedly credited as the guiding force and inspiration for the entire endeavor.
Christian prayer and Bible reading was a public school item until the mid 1960s. Church and state separation was entirely redefined around then as well; it didn't mean back then what people think it means now. The ten commandments was in courthouses. There are people still alive today that were led in prayer to the Christian God every single day of public school (and required to read the Bible); they're everywhere.
All with different interpretations of the Christian god (or not Christian, as in the Jewish diaspora). The Spanish who settled colonies in Florida and California, the French in Louisiana, the English, Polish, and German settlers in Jamestown would all struggle to agree on a common set of definitions or rituals except there was a bible in there somewhere.
I was led in prayer at public schools, and private - doesn’t mean I or most of the other students were religious, though some were. And that is a very recent thing. Most regions didn’t have public school bible reading then.
You seem to be making a statement that the US has some strong theocratic religious foundation, when it’s more of a ‘we’ve got too many competing groups that can’t get along with each other - we’ll just kinda stay out of it where we can’. Hence the hand waves part. Which is good, we’ve never had the religious wars where a specific group had to fight against another, which is how you end up with the state religions like in Europe (anglicans vs Catholics vs Protestants for instance).
The groups you’re pointing to were often refugees from those fights and came in as waves during the various periods of repression as tides turned, or different regions fell to famine.
What if it were mathematicians from all over armed with the same Calculus book hand waving that everyone should ignore the idiosyncrasies of their alma mater or their professor's flavor of finding derivatives? What if the founding documents they wrote all spoke highly of Calculus; Calculus books in every classroom. To me it sounds like people weren't hand waving away God, but setting aside their idiosyncrasies to worship the same Christ.
You’re having a rather odd take on these words! I never said they were hand waving away God. I said they were hand waving all the important details of what religion they were referring to, and about the only thing anyone seemed to agree on is a God somewhere (Usually) and we won’t get into most of the details. Many prominent founding fathers were atheist or agnostic, but that wasn’t the majority.
The American approach is a ‘if we don’t look too hard, it’ll be ok’, since otherwise you end up with the literal large scale religious wars that pushed many of these groups here in the first place from Europe. Or society wide pogroms like Anglicans/Protestants/Catholics have done to each other constantly elsewhere.
And if you think Catholics/Protestants/Mormons/Baptists, etc are hanging out in the same church at any scale, we must hang out with very, very different crowds. They are not all deriving calculus from the same book - or all even agreeing that calculus exists.
A closer analogy would be a bunch of high school English teachers arguing that math exists, and one knows algebra one, another knows calculus, another knows trig, and another is doing arithmetic in base 16 while everyone else is using base 10. And they all think the other is wrong, but not completely so.
> The US was founded by entire colonies of people coming overseas to worship the Christian God freely
That's the source of some of the colonies. There were many other reasons that people came.
Some were looking for economic benefit. Some were prisoners that their home countries were looking to get rid of.
> Christian prayer and Bible reading was a public school item until the mid 1960s
Until the 1960s, but starting in the 1940s or 1950s. Much of that public religiosity was a response to the Cold War, opposing the anti-theistic position of the USSR.
Satoshi (or one of his friends) owns 5% of all bitcoins that will ever exist.
I wouldn't call it a get rich quick scheme for its founder(s) because I doubt they could have known it would take off the way it did.
But, at this point, I don't know that intent matters. Imagine if Bitcoin really did become a dominant currency... one guy would own 5% of it, a deflationary currency! The "fiat billionaires" don't come anywhere close to that kind of concentration of wealth.
Doesn't he deserve it? If you were to launch a world-changing project at the cost of disappearing completely, wouldn't you want to reap some benefit from that project if it ever succeeds?
My hunch is that Bitcoin is actually a project to promulgate Austro-libertarian economics and "Satoshi" is actually a bunch of people hired by stratospherically wealthy libertarians (like the guy that founded Renaissance who is tight with the Mercers). Call me crazy, but after hearing the correlation between people becoming interested in Bitcoin and Austro-libertarianism simultaneously I can't help but think it's a deliberate project.
The thing with ideologies (and other kinds of socioeconomical hypotheses) is that they're hyperstitional in nature - you can't prove they're realizable without at the same time deliberately trying to realize them, using people as fodder. (See, communism.) And at least one of the ideologies promulgated in meme-space must have some basis in potential reality (otherwise people wouldn't be at all prone to believing in world-changing ideas). Might be this one, might be not.
- Consider how you'd like to be treated; like for real. What if it was you?
- Burning bridges over something like this isn't worth it. Burning bridges over anything, is almost always a bad idea. Seek to mend.