Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Configuration is hard and customers suck. It's so much easier to just put out what's quick and convenient and say the solution is buy the new version🤷♀️
endor649160d@SortOfTested sure, but hardcoding stuff straight in the openssh source just to roll your own? (Added link in the post) Who the fuck does that? Why would you even do that?
I mean sure, it's your commercial product and everything, feel free do customize it to shit. But don't touch ssh for fuck's sake! It's the one thing that's supposed to be reliable!
I'm kinda tempted to grab the official source and try to recompile it, but I'm too afraid of losing access to the client's NAS (and I really don't wanna have to call him and tell him I borked something in there).
endor649160d@SortOfTested What I really don't understand is this:
I'm trying to run a second sshd instance to test my modified config, right? All I've done is some security hardening for stuff like key exchange algos and connection encryption algos. Other than that, it's the same config that the original sshd daemon has (supposedly?) been using for the last 183(!) days.
So why on earth would the main daemon allow me to log in just fine, but the second one shits its pants?
linuxxx15433858dCan't you recompile it by any chance?
endor649158d@linuxxx I was tempted to, but was kinda worried to hit some other weird edge case (a real possibility, given the fuckery that they've done to their custom OS).
I eventually managed to solve the issue (after accidentally locking myself out after a reboot with a 'bad' config and figuring out how to telnet back in while in half-panic): turns out, Synology's sshd doesn't like it when you set your listening port to anything other than 22.
I wish I could gouge the eyes of the moron who decided that that was a good idea (or did whatever the fuck is actually going on under the hood).