the point is what NathanBarley says
...and that also suggests to disable root login completely (not even via a key).

Yes it does, and I've already agreed that disabling the root login is something I agree with and do. Only I'd prefer to do that when it suited the system, not when it suited the software developers.

No the point is what I said before. Accepting this OpenSSH default as the slackware default places slackware squarely in the centre of being a desktop PC only distribution. Designed and defaulting to a state which makes it suitable for installation to such systems. That was never what slackware was, in fact I can recall that one of my first posts on the slackware.com forums was about how slackware was one of the few systems I could install onto a 386 printserver and have up and running in under 30 minutes many, many years ago.

As I said before I'm fine with Pat and you all moving it onto being squarely placed in the primarily a desktop PC operating system, if that's what you all want. No doubt other changes and accepting of other upstream defaults will come along to cement that choice. I just need more flexibility than that.

System has to be hacked? Why don't you just create a user before you reboot the system? (The adduser script is even available if you don't want to remember the useradd command.) Then you can ssh in as that user when the system reboots and then su to root. It really isn't that difficult. I create a user before that initial reboot every time I install Slackware, because I want my system ready to go when I reboot. I also adjust my lilo.conf to remove the comment for compact and change the timeout and reinstall lilo. You can do a lot while still in the installer so as soon as you boot up your new system, you're good to go.

I would think that especially if you reboot a headless server in an unattended installation, you'd want decent security defaults in place, in case you forget to make your desired changes before you do your initial reboot.

Maybe not directly, but you certainly seem to imply you're a really good hacker and you did it right in this thread (emphasis is mine)... And way to be hostile. I wasn't hostile towards you, so I'd prefer the same back (although, obviously, you are able to act however you see fit). We try to keep this a friendly and respectful community.

As some in the forum will say, since Slackware doesn't have PAM, it's already been relegated to non-corporate use. A simple adjustment in the OpenSSH config did not doom this distro from being used in headless remote areas..

All it takes to fix your problem is to add a user or change the config before you reboot. It really isn't the end of the world (unless you absolutely can't remember to do this after an installation, but, if that's the case, there's probably other important things you're forgetting as well). If it is that difficult to remember, and you do a lot of these remote installs on headless machines, maybe it'd be worth creating a checklist so you can make sure you get everything done you need to.

Ummm I put appliances into corporate environments, running slackware arm. I run slackware x64 in corporate locations, and slackware x86. Slackware is in corporare environments. It's just invisible, primarily because it just sits and works. I'm currently wondering about upgrading a slackware arm appliance which must have now been sat running in a corporate environment for three plus years. It has sat there reliably, never needing attention, doing what I set it to do, exactly how I set it to do it.

Slackware is far more corporate suitable than any of the other distributions, it always has been. I've been running it in corporate environments for at least 15 years.

I did acknowledge earlier (to Alien Bob) that the starting point of this was just me venting pointlessly.

I stand by my point though that accepting the OpenSSH default as the slackware default makes slackware a desktop PC positioned OS. More interestingly the default will have to be corrected for every Raspberry Pi install of slackware ARM, for any headless ARM install, for any S390 install, and for any headless install to a real x86/64 or virtual x86/64 server. This default locks the default slackware into being installed onto systems with screens attached. I can't see that as progress or any kind of improvement.

Saying I am paid to crack my way into proprietary software stacks doesn't constitute me making any special claims, that is one of the many things my boss pays me to do. Right now I'm hacking around inside the software stack on an OEM storage array. I'm not the first person who has been inside these array controllers, and I fairly certainly won't be the last who does this to this particular storage array type. There are any number of people just like me who are employed to things like this, because it's something certain companies need people like us to do. It allows them to make sane business decisions. It does also mean I can state quite happily that if IBM/Brocade/Cisco etc can't lock their root user accounts sufficiently to stop me (or those like me), this ridiculous change won't stop me (or those like me), and we're the good guys, you can be sure it ain't going to make any difference to the bad guys. I'm afraid your previous post felt hostile, hence my semi-hostile response, I apologise if I misread you.

And one other thing.

Slackware has always been a 'technical' distribution, and over the lset couple of decades many have learned vast amounts about how a linux system works, and how to 'run' it technically from slackware. How does anyone learn anything from a distribution which comes defaulted to do all of that for them on install?

I can't see this as a desktop choice; it's from OpenBSD ('so secure you can't use it', as the joke goes) and I doubt Theo De Raadt sees that OS as desktop-focused.

Any reason you can't change the configuration or add a regular user in your unattended script? Both would allow remote access.

Hahahahahaha... Adding an "echo" to your already modified initrd's init script is soooo hard that LFS seems soooo easy ?

Honnestly, it might be a bit "overkill" to block root as default, and yes it might be because a lot of people using it don't understand the risk so it assumes a higher that .5 probability of "dumb user"...

Yet it still a good security practice (I completely remove root login from ssh, and go through a user), and it's not a "new feature", or a lost feature, it's JUST a default setting...

And again, if you had already played with Slack's installer initrd so it should be easy as a lot of persons stated here...

Unless... Unless maybe you didn't play with initrd and just "copy pasted" some howto steps from some websites, and are not able to understand how it works... So... In that case, I don't understand why you complain about "dumb down" as it would be still "thousands of light year" above your actual level (in that case)..

Well, hope that passed the frustration of the "surprise" settings you'll realize that it's not a big deal. Maybe you had a tough day, "shit happens" .

Cheers.

Indeed. The proper term is "fsck".

4 members found this post helpful.

Haha true, that's what I first thought fast-reading it the first time.

That's what I get for spending too much time talking to non-technical people on forums with word censor lists.

No offense intended about any of this Pat, I get this was an upstream decision, and you've just accepted it. As Eric said I'll just need to suck it up for now.

I wasn't saying it wasn't good for corporate use, but I know there are some out there that think it doesn't work because of the lack of PAM.

Why? As I stated earlier, it is very easy to create a user after the install process and before you reboot, or to directly modify the ssh config (although, you'd only end up changing it back again, since you do that anyway). There's countless other examples people could use in place of preventing password-based root ssh logins... Since Slackware doesn't create additional users, does that mean it "locks the default slackware into being" used for single user situations? No. It just means you need to do a bit of configuration on your own. Prior to xorg not requiring an xorg.conf file, did that mean that "locks the default slackware into being" console only? I think you can see where I'm going...

I'm not saying that this change will prevent you from accessing a system (since I have no idea what your skill levels are), but I do know it will prevent a lot of the script kiddies who bank on having root enabled, which is probably a bigger majority of the hacking attempts out there. And I'm not labeling you a bad guy. I know hackers come in many different forms, and not all of them are malicious. But, just because you can get around this type of security does not mean it is a bad security practice to have. Just because some people can break into cars doesn't mean you should leave them unlocked...

1 members found this post helpful.

I accepted it after considering it carefully and deciding that it was the right default. I'm fairly certain that the reaction from other long-time Slackware users would have been worse if I'd decided not to accept the change and shipped a package with worse security than upstream intended.

1 members found this post helpful.

Only 'the evil empire' brigade.

You and everyone else, and of course you're right.

I'm considering petitioning Pat as he's around to change the default 'root' name to Bob.
https://lh3.googleusercontent.com/-9...p9uuo1_500.gif

That'll stop the bad guys.