41–50 of 119 posts
Earlier quoted context omitted.
Kinda unforgivable to be on front page of HN in 2021 without https
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..
Looks like sshtron.zachlatta.com hasn't been found yet. Try it: `ssh sshtron.zachlatta.com`
Hack Club founder here. I'm so glad you know SSHTron too! 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.
Do you get rejected if you connect with agent forwarding enabled?
Earlier quoted context omitted.
In case you want to connect to a random ssh server without giving it your public ssh keys.
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…
Earlier quoted context omitted.
Is that setup common?
It doesn't have to be for at least some unsuspecting users to unwittingly share their private key with some random server on the internet. 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.
I don't understand what this is. Is this just some dude's little terminal game? 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.
Do you get rejected if you connect with agent forwarding enabled?
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.