181–190 of 375 posts
Earlier quoted context omitted.
Hah no. Nobody is running TCP on that link, let alone SSH.
Once upon a time I worked on a project where we SSH'd into a satellite for debugging and updates via your standard electronics hobbiest-tier 915mhz radio. Performance was not great but it worked and was cheap.
Earlier quoted context omitted.
Even if the chatbot served only as a Rubber Ducky [1], that's already valuable. I've used Claude for debugging system behavior, and I kind of agree with the author. While Claude isn't always directly helpful (hallucinations remain, or at least outdated information), it helps me 1) spell out my understanding of the system (see [1]) and 2) help me keep momentum by supplying tasks. [1] https://en.wikipedia.org/wiki/Rubb…
A rubber ducky demands that you think about your own questions, rather than taking a mental back seat as you get pummeled with information that may or may not be relevant.
Earlier quoted context omitted.
Is it possible that this is on your end? The extension is "ping@openssh.com." It shows up in the blog reliably for me across several browsers and devices.
No, it's Cloudflare munging the HTML. Cloudflare then provides JavaScript to un-munge it, but that's not reliable.
Earlier quoted context omitted.
Even if the chatbot served only as a Rubber Ducky [1], that's already valuable. I've used Claude for debugging system behavior, and I kind of agree with the author. While Claude isn't always directly helpful (hallucinations remain, or at least outdated information), it helps me 1) spell out my understanding of the system (see [1]) and 2) help me keep momentum by supplying tasks. [1] https://en.wikipedia.org/wiki/Rubb…
A rubber ducky demands that you think about your own questions, rather than taking a mental back seat as you get pummeled with information that may or may not be relevant.
https://gist.github.com/shmup/100a7529724cedfcda1276a65664dc...
Earlier quoted context omitted.
A rubber ducky demands that you think about your own questions, rather than taking a mental back seat as you get pummeled with information that may or may not be relevant.
I assure you that if you rubber duck at another engineer that doesn't understand what you're doing, you will also be pummeled with information that may or may not be relevant. ;)
The entire point of rubber duck debugging is that the other side literally cannot respond - it's an inanimate object, or even a literal duck/animal.
> Obviously forking go’s crypto library is a little scary, and I’m gonna have to do some thinking about how to maintain my little patch in a safe way This should really be upstreamed as an option on the ssh library. Its good to default to sending chaff in untrusted environments, but there are plenty of places where we might as well save the bandwidth
It sort of already is. This behavior is only applied to sessions with a TTY and then the client can disable it, which is a sensible default. This specific use case is tripping it up obviously since the server knows ahead of time that the connection is not important enough to obfuscate and this isn't a typical terminal session, but in almost any other scenario there is no way to make that determination and the client…
> Obviously forking go’s crypto library is a little scary, and I’m gonna have to do some thinking about how to maintain my little patch in a safe way This should really be upstreamed as an option on the ssh library. Its good to default to sending chaff in untrusted environments, but there are plenty of places where we might as well save the bandwidth
"where we might as well save the bandwidth" I come from a world (yesteryear) where a computer had 1KB of RAM (ZX80). I've used links with modems rocking 1200 bps (1200 bits per second). I recall US Robotics modems getting to speeds of 56K - well that was mostly a fib worse than MS doing QA these days. Ooh I could chat with some bloke from Novell on Compuserve. In 1994ish I was asked to look into this fancy new world…
Earlier quoted context omitted.
I'm anti-LLM in most cases, but: > I bet this mystery could gave been solved much quicker by simply looking at the packet capture in Wireshark. For some people who are used to using Wireshark and who know what to look for, probably yes. For the vast majority of even technical people, probably not. In my case, I did a packet capture of a single keystroke using tcpdump and imported it into Wireshark and I get just over…
And thats a huge downside when people howl about "Encryption everywhere! ". Try debugging that shit. Thats right, debugging interfaces aren't safe, by some wellakshually security goon. You want a real fun one to debug, is a SAML login to a webapp, with internal Oauth passthrough between multiple servers. Sure, I can decrypt client-server stuff with tools, but server-server is damn near impossible. The tools that work…
Anyway, VMs should not have authentication, it makes access sooo much easier. Also drop your IPs while you're at it. Might be useful for debugging later.
Earlier quoted context omitted.
Once upon a time I worked on a project where we SSH'd into a satellite for debugging and updates via your standard electronics hobbiest-tier 915mhz radio. Performance was not great but it worked and was cheap.
This is still done today in the Arducopter community over similar radio links.