Hey, is it not just a simple honeypot reverse hack ssh server? People understand that reverse hacking can happen when connecting to random ssh server, right?
Prove it, I'll connect to any server you point me to, using default openssh client flags.
Show HN: ssh ssh.place
51–60 of 126 posts
Re: Show HN: ssh ssh.place
#52Earlier quoted context omitted.
> People understand that reverse hacking can happen when connecting to random ssh server, right? No, actually, I've never heard of such a vector. How would that work?
Vulnerability in your ssh client (unlikely) or terminal emulator (more common but lower reach).
Terminal emulators have, on occasion, had all kinds of interesting escape codes that I wouldn't want to expose to an attacker. Whether this is even a true "vulnerability" is somewhat a matter of opinion (in the sense that the feature works as designed, but that's maybe a bad thing).
Re: Show HN: ssh ssh.place
#53Time for your regular reminder that ssh has no PKI and is trivial to mitm during tofu.
Agreed. Amid all this hype, once again we continue to see such disregard for basic security implications and using ssh outside it's intended use-case; especially sshing into random servers.
Now we wait for the discovery of an RCE, key leakage vulnerability or a security bypass that leads to a trivial mitm attack to magnify why ssh apps make no sense security wise.
Re: Show HN: ssh ssh.place
#54Earlier quoted context omitted.
There has never been a real-world OpenSSH exploit that allows a server to RCE a client that connected to it without a bunch of dubious qualifiers. Connecting to a random SSH server is much, much less dangerous than running a random binary or executing a random curl install script, both of which people do all the time, and is probably about on par with the likelihood of a random website escaping your browser's sandbox…
If you properly set up your ssh client (No agent forwarding or X11 forwarding)
Terminal, too; some escape sequences are able to perform attacks in old or buggy terminal emulators.
Re: Show HN: ssh ssh.place
#55Re: Show HN: ssh ssh.place
#56If you have a slight interest in originality of presentation, whatever website copy first comes out of Claude is not there yet. Its preoccupation with "no x, no y" and annoying runs of sentence fragments might have been a punchy rhetoric for a short while before it became a tired cliché, but by now it stylistically makes it look more like you're bragging on LinkedIn than presenting something fun and creative. I menti…
Yeah it kinda feels like a great, original meal but served on plasticware
Re: Show HN: ssh ssh.place
#57If you have a slight interest in originality of presentation, whatever website copy first comes out of Claude is not there yet. Its preoccupation with "no x, no y" and annoying runs of sentence fragments might have been a punchy rhetoric for a short while before it became a tired cliché, but by now it stylistically makes it look more like you're bragging on LinkedIn than presenting something fun and creative. I menti…
> I've wondered what in the training process causes the model to develop this peculiar style of writing
I think this might just be inherent to the currently deployed LLM architecture. If the training process works at all, any model will come out of it with some (default) voice that it'll apply everywhere.
Human voices are not like that, both because one copywriter does not write a significant fraction of all texts in the world and because unlike LLMs they remember all of their own prior writing, which gives them an opportunity to get tired of their old tropes.
Re: Show HN: ssh ssh.place
#58Earlier quoted context omitted.
An ssh server would exploit a vulnerability in the ssh client when it connects. For example, openssh has both a client and server. There’s been vulnerabilities in openssh, in the client. Those vulnerabilities aren’t reachable unless you’re connecting to a server attempting to exploit you, so the risk is quite low because you know and trust most servers you’re connecting to with ssh. To sum it up: Connecting to this s…
There has never been a real-world OpenSSH exploit that allows a server to RCE a client that connected to it without a bunch of dubious qualifiers. Connecting to a random SSH server is much, much less dangerous than running a random binary or executing a random curl install script, both of which people do all the time, and is probably about on par with the likelihood of a random website escaping your browser's sandbox…
Agreed, bugs in the terminal emulator are probably more concerning. The attack surface of those is much larger (there are some pretty wild ANSI escape sequences, and terminal emulators are often granted pretty wide disk access permissions on systems that have them if they're also used for local development).
Re: Show HN: ssh ssh.place
#59Earlier quoted context omitted.
An ssh server would exploit a vulnerability in the ssh client when it connects. For example, openssh has both a client and server. There’s been vulnerabilities in openssh, in the client. Those vulnerabilities aren’t reachable unless you’re connecting to a server attempting to exploit you, so the risk is quite low because you know and trust most servers you’re connecting to with ssh. To sum it up: Connecting to this s…
> To sum it up: Connecting to this server is probably fine And what are you basing this statement on?
[deleted]
Re: Show HN: ssh ssh.place
#60If you have a slight interest in originality of presentation, whatever website copy first comes out of Claude is not there yet. Its preoccupation with "no x, no y" and annoying runs of sentence fragments might have been a punchy rhetoric for a short while before it became a tired cliché, but by now it stylistically makes it look more like you're bragging on LinkedIn than presenting something fun and creative. I menti…
I don't think Claude's writing style is peculiar, it is just that we are being flooded with it. Everything becomes stale with overuse.