Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: ssh ssh.place

ssh.place

Post reply on HN
Print view View original

81–90 of 126 posts

Re: Show HN: ssh ssh.place

#81

Post by jolmg »

arghwhat wrote: post #70
3dedb728-3f77 wrote: post #23

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?

People understand that such "reverse hacking" can happen when their browser connects to any site (including all the indirect connections from dependent resources), right? Or when resolving any domain name? Or when even just pinging an IP? The risk is far, far lower than browsing the internet. Unlike the massive surface of a browser and all the libraries and processes it is comprised of, the OpenSSH client is a tiny,…

There's also the terminal to consider, via terminal escape sequences.

Re: Show HN: ssh ssh.place

#82

Post by mr_mitm »

scubbo wrote: post #35
3dedb728-3f77 wrote: post #23

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?

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

Here is a recent example. Currently unpatched in Debian stable.

https://www.cve.org/CVERecord?id=CVE-2026-60002

As I understood this, a malicious server can change its host key somewhere during key exchange and trigger a use-after-free in the client, which might be exploitable for code execution.

Re: Show HN: ssh ssh.place

#84

Post by applfanboysbgon »

boomlinde wrote: post #47

If 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…

It's an extremely pervasive misconception, but a model's voice is not really a matter of its training data, not by the time it reaches consumer eyes. The voice these models use are specifically selected for in RLHF, ie, curated by humans by telling it it did a good job when it uses this voice and telling it it did a bad job when it didn't use this voice.

Why do they specifically push for this voice? Because it is effective. This is "headline voice", the voice that gets people to endlessly click on Youtube clickbait and garbage articles. Most of the population gets a dopamine hit from this style of writing, making it legitimately addicting to them. Those who recognize it for what it is and find it insufferably grating are in a tiny, tiny minority.

Re: Show HN: ssh ssh.place

#85

Post by fulafel »

soblemprolver wrote: post #79
applfanboysbgon wrote: post #44

Earlier 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…

I believe the recent cve-2026-55200 in libssh2 (client-side library) was allowing exactly this. https://nvd.nist.gov/vuln/detail/cve-2026-55200 ("Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution.") Of course the other abouts that you whatted (such as random curl install scripts, binaries, etc.) are still more dangerous.

OpenSSH doesn't use this library.

Re: Show HN: ssh ssh.place

#86

Post by tyingq »

LoganDark wrote: post #54
Oxodao wrote: post #46

Earlier quoted context omitted.

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.

Even newer ones. Iterm2 had CVE-2026-41253 recently. Or things like Tmux.

Re: Show HN: ssh ssh.place

#87

Post by soblemprolver »

fulafel wrote: post #85
soblemprolver wrote: post #79

Earlier quoted context omitted.

I believe the recent cve-2026-55200 in libssh2 (client-side library) was allowing exactly this. https://nvd.nist.gov/vuln/detail/cve-2026-55200 ("Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution.") Of course the other abouts that you whatted (such as random curl install scripts, binaries, etc.) are still more dangerous.

OpenSSH doesn't use this library.

Good to know, but OpenSSH is not the scope here.

Re: Show HN: ssh ssh.place

#89

Post by jolmg »

hdgvhicv wrote: post #72
QuantumNomad_ wrote: post #45

Earlier quoted context omitted.

The ones I connect to the most often from my personal laptop I don’t physically own but I do pay to rent them and I installed the OS on them myself.

The main ones I don’t own are VPS servers from fairly large providers, or GitHub.

When I said "own", I meant more in the sense of personally administering. It's like how you own a domain, but you're really renting it from a registrar. Rented hardware and VPSs count, as well as other servers/hosts you're responsible for.

Re: Show HN: ssh ssh.place

#90

Post by singpolyma3 »

jolmg wrote: post #40
bulbar wrote: post #30

Earlier quoted context omitted.

Is that more likely than getting hacked when visiting a website?

Visiting a random website is the normal use of HTTP. With SSH, there might be assumptions of connecting to a trusted server you have an account with and likely own. It's not very normal to ssh to a random server.

This is simply not true
Post reply on HN