*tries to SSH into my laptop to see how that third kernel compilation attempt went*
… From my Windows box.

Windows: aah nope.

"Oh God maybe the bloody HP thing overheated again"
*takes laptop from beneath the desk indent*
… Logs in perfectly. What the hell... Maybe it's SSH service went down?

$ systemctl status sshd
> active (running)

Well.. okay. Can I log in from my phone?

*fires up Termux*
*logs in just fine*

What the fuck... Literally just now I added the laptop's ECDSA key into the WSL known_hosts by trying to log into it, so it can't be blocked by that shitty firewall (come to think of it, did I disable that featureful piece of junk yet? A NAT router * takes care of that shit just fine Redmond certified mofos).. so what is it again.. yet another one of those fucking WanBLowS features?!!

condor@desktop $ nc -vz 192.168.10.30 22
Connection to 192.168.10.30 22 port [tcp/ssh] succeeded!

ARE YOU FUCKING FOR REAL?!

Fucking Heisen-feature-infested piece of garbage!!! Good for gaming and that's fucking it!

Edit: (*) this assumes that your internal network doesn't have any untrusted hosts. Public networks or home networks from regular users that don't audit their hosts all the time might very well need a firewall to be present on the host itself as well.

To Windows' credit, eventually the SSH connection succeeded. No idea what made it fail in the first place though.

What was the error/output? This made me curious

Windows network type? (public, private, home)

@netikras That's the thing.. none at all. Even with -vv switches enabled, it didn't output anything, just stalled at "debug1: Connecting to 192.168.10.30 [192.168.10.30] port 22." and had to Ctrl-C.

@xewl private network with firewall at the time enabled. As shown in the rant, that didn't prevent connections to my laptop over port 22 (as per nc). I've disabled that firewall at this point though.. I manage that stuff at the gateway and the VPN servers.

I'd call this a Heisenbug.. currently it connects properly so that's nice.. but I doubt that I can reproduce it in a controlled environment.

Interesting.. Could it be a temporary nw blip? Sometimes that blip is weirdly caused by a windows fw...

Did you know that windows has an OpenSSH server and client built in?

The client would probably work.

@ewpratten The client is trash, and I never considered it. OpenSSH in WSL is far more familiar and compatible with Linux systems (as it's the Ubuntu package). Windows' SSH package however I tend to avoid like the plague because.. well, Windows. They add and remove "features" in pretty much everything they touch. So I doubt that their SSH package would be any different. Also, even if their SSH server would be halfway decent, the system's instability makes me refrain from running services of any kind on it. Heck, I even put everything that I execute on servers from that shit OS (Windows being the client) in screen sessions just in case it BSOD's again.. at least then I wouldn't lose whatever the process on the SSH server I'm logged into at the time has done so far.

@YeahOkay If it was repetitive (and replicable), I would go with that. However the server IP (my laptop) was recently changed as I had to move my laptop from 192.168.10.20 to 192.168.10.30 yesterday (perhaps the day before.. I'm up for over 24h at this point so meh), since I ran out of IP space between 192.168.10.10 and 192.168.10.19 which was originally reserved to the VM's and I had to expand. In other words, server moved and actually got both its soft- and hardware unfucked as well recently.

The client (Windows 10) I didn't bother setting as a remembered IP in my router's DNS server. It's not running any services (and it better won't) so who cares. The only thing that may be subject to change at some point is the DNS server, as I'd like to harmonize the addressing into a single centralized host. As it is now, a PiHole VM is in the making for that but it's still undecided whether I'll go with a classic VM/CT running Arch or allocate one of my 4 physical Raspberry Pi's for this purpose.

TL;DR: seems like a Windows problem to me and cleaning environment/moving IP's elsewhere probably isn't going to help in this scenario.

@YeahOkay however much I wish I did, I didn't run a Wireshark test at the time... As things stand for me now, the client sucks and was at fault until proven otherwise, especially since the tests I've done showed that other hosts could access the "server" just fine and that there was nothing wrong with the "server" machine. Windows seems to be a valid suspect.

(server with some quotes attached of course.. obviously a laptop isn't going to be a real server by any means, and should only be addressed as such in e.g. this client-server scenario where the laptop is running a service. Just that that's the only thing that this HP turd is really useful for, given HP's stock cooling shitdesign. If worth my time I'll probably revisit that cooling design, slap a huge fan on it and reuse that LCD panel on a wall somewhere, but that ain't happening for now.)

@YeahOkay It isn't. Well it was at some point where the laptop came back into the network as 192.168.10.20, which was already occupied by a VM and I forgot about - InspIRCd-testnet which I thought would've remained down - and after noticing I powered off immediately, along with flushing Windows' IP resolver cache. After that I logged into the laptop into a local GUI session and changed its IP configuration into its current 192.168.10.30. Following those events, it would be safe to say that the Windows host correctly assumed the NIC of my laptop to be the real 192.168.10.30, which is reaffirmed by its ability to add the ECDSA host key into its known_hosts.

That IP collision stuff all happened before this issue however and the Windows host even had a power cycle due to its explorer.exe crashing on me, so it would be safe to say that even if "ipconfig.exe /flushdns" didn't completely delete the local DNS cache (which would lead me to doubt the usefulness of that tool), the reboot most certainly would've. IP collisions did happen at some point - and I hereby admit that they did - but those shouldn't have caused that issue. Especially since said SSH issue occurred *after* that IP collision got resolved.

So "obviously you're wrong", at some point most certainly. I should've checked twice before bringing that host into my network, and have noted down the current IP configurations somewhere, preferably at a DNS server that to this day isn't configured yet. And I should've taken care of that laptop's rootfs sooner to not forget what its IP actually was. My brain can't scale to all the hosts in this network but a proper infrastructure organization should - which I should deploy. However, the arguments as expressed above should hopefully make clear that this wasn't the root cause of this issue, since it was mitigated before said issue occurred.

@YeahOkay huh?

@YeahOkay I just did? The IP collision was a thing, but it got resolved before this connectivity issue to my SSH server occurred. What else do you want me to do to soothe what I think is Microsoft fanboyism on your end?

Look, if you can tell me where else the issue may have originated based on the information given, I will gladly look into it more. But as it stands now, the server was accessible in the network, didn't experience any issues, the phone could access it and the Windows host was the only one that was acting strange again, like it usually does.

@YeahOkay As I've mentioned countless times already, that wasn't the case at the time the issue occurred. Trolling as a service, I suspect? Just like Windows but at least this has one benefit - boosting the rant in the algo. With that alone, better than Windows I'd say. That turd has no tangible benefits whatsoever.

@YeahOkay Clearly a troll. You've reached the limit on the time you've been able to have me waste. Congratulations.

@YeahOkay
Linux: Born to Be Root
Windows: Born to Re Boot

seems to be rather applicable here ;)

As for your username, I'd rather mv it to @YeahFuckOff.

@YeahOkay Of course it is, it's fucking so-called "New Technology" from the millennium shift, what did you expect? There's mold all over the place in that piece of trash.

@YeahOkay Oh come on, I thought we went past that. Clearly a mold stain in that shit OS kernel caused a bit flip in memory, which led to this Heisenshit.