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?
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
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.
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"