SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
it seems to me that you are mixing different things: Slackware always tries to ship things as vanilla (as upstream ship them) as possible but never had a passive attitude towards bad choices, you can easily see it by the things it left out (until it had been humanly possible).
in this case, sorry if I state it again but it's for the sake of the answer, the default as provided by upstream is good so, IMHO, there's no passive acceptance but instead an agreement with the choice.
on a more general consideration that Linux is generally going in the wrong direction with some upstream choices (but we are talking about a completly different thing) I can agree, but this is not related to openssh.
openssh's server defaults will go also in other non-linux operating systems and this not even considering that freebsd and openbsd, for example, didn't allowed remote root login by default even before.
to answer your "that's crap" if you had brute force ssh attacks on your servers you could surely have seen that most of them use, between all the login names they try, also "root", and it's not important if they are a minority: if they get in as root it's surely worse if they get in as an unprivileged user (in fact is better to disable password authentication completely, but that's another story).
what I'm saying is that if you think the topic is pointless and you are just expressing your frustration just point it in the right direction.
linux is moving along the path of dumbing down to suit users who just want to be able to press the on/off button and use a computer in much the same way as they used Windows. That path is being actively facilitated by those who develop software, and who have decided they too will write software where they have previously decided things for the users. This for example is a case in point where the developers have decided they will take resposibility and secure the root login of systems their software is installed on.
There's no changing that. The only option is to go LFS and dump packages you don't agree with the ethos of. So dump OpenSSH and use dropbear or something instead. As I write this I'm downloading the source to build myself a toolchain.
Here's a blast from the past. What's in a name... well not a lot really. root/toor/a/fred/brian/kevin/jesus they all mean the same if passwd has them as uid 0. I've never understood this fascination with the name 'root', and the idea that preventing 'root' from logging in is an important security measure is absolutely incredible to those of us who spend our lives being 'root' in one place and another. I suppose slackware and linux could go the way of darwin, and remove the 'root' account altogether. That would make the system secure... oh hang on, no it wouldn't. I can't remember how many years ago I wrote something along those lines to someone asking a question. Or whether it was on the slackware.com forums, userlocal.com forums, or here. Nothing has changed though it seems, people are still obsessed with the name 'root' and how to secure it.
Lets see:
Code:
root ssh:notty 24.127.154.141 Wed Feb 3 05:00 - 05:00 (00:00)
ftpuser ssh:notty 66.84.13.121 Wed Feb 3 01:22 - 01:22 (00:00)
ftpuser ssh:notty 66.84.13.121 Wed Feb 3 01:22 - 01:22 (00:00)
pi ssh:notty 125.212.232.7 Tue Feb 2 22:38 - 22:38 (00:00)
root ssh:notty 104.239.151.33 Tue Feb 2 19:07 - 19:07 (00:00)
root ssh:notty 109.236.38.57 Tue Feb 2 18:17 - 18:17 (00:00)
ts ssh:notty 85.214.149.99 Tue Feb 2 14:20 - 14:20 (00:00)
ts ssh:notty 85.214.149.99 Tue Feb 2 14:20 - 14:20 (00:00)
root ssh:notty 188.227.174.163 Tue Feb 2 11:28 - 11:28 (00:00)
root ssh:notty 187.49.204.72 Tue Feb 2 06:04 - 06:04 (00:00)
support ssh:notty 176.108.2.80 Tue Feb 2 00:49 - 00:49 (00:00)
support ssh:notty 176.108.2.80 Tue Feb 2 00:49 - 00:49 (00:00)
minecraf ssh:notty 202.52.54.8 Mon Feb 1 19:17 - 19:17 (00:00)
minecraf ssh:notty 202.52.54.8 Mon Feb 1 19:17 - 19:17 (00:00)
support ssh:notty 74.208.162.27 Mon Feb 1 17:35 - 17:35 (00:00)
root ssh:notty 91.98.96.118 Mon Feb 1 13:12 - 13:12 (00:00)
Six names, only one of which is 'root'. Two strikes and you're out by IP address. ssh brute force isn't a reason to stop remote root logins.
sorry, I suppose I am not expressing myself very well as you don't seem to understand what I'm saying, but now it seems pointless for me to continue trying.
You're trying to sell that locking down the 'root' account is of some value to a man who is paid to hack into proprietary software stacks. I can assure that that just about everyone of them locked down the 'root' account from the outset, and that it doesn't prevent me getting in. All it does is make legitimate system administration of systems harder. Sorry but you were never going to be able to make a convincing argument that OpenSSH defaulting (and slackware as its chosen default settings) to not permitting 'root' logins make them anymore secure. Quite simply because it doesn't.
I'm pointing out that unless slackware is only for desktop machines, then Pat is going to need to make a decision about whether or not he wants to prevent unattended installs on far away remote systems from running slackware. Because there's absolutely no purpose in installing a distribution to a machine you can't then manage or do anything with.
If you can manage an unattended install, you can manage the config change and SSHD restart.
To be fair, the current upstream default in OpenSSH sshd_config is "PermitRootLogin prohibit-password". Given Slackware's usual policy of sticking to upstream defaults I don't think it was unexpected. (FWIW I'm also irritated by the "dumbing down" tendency in most of the mainstream Linux distros, but as far as I can see this one came from OpenBSD).
Yes I could thanks, but I've decided I'll go LFS instead and move on. Slackware has been a good distribution over the years, but this new way of accepting upstream software developers from deciding how slackware systems should run as default, doesn't work for me.
I suppose this more than anything is what makes me think linux is past its sell by date now, and that it might be time for me to look around for something else which has the "its your system, it should run how you want it to" ethos at its heart.
What? How is changing the defaults in a config preventing you from running your system as you want it to. I don't like the fact that lilo.conf has compact commented out on a default install, but guess what, I can change it. I also adjust the timer, because I think the default is far too long and I get impatient when I boot my system. Do those sane defaults make me think that Linux is now on a downward spiral and, because of that, make me want to look into alternatives? Umm... no. Now, if the OpenSSH developers completely removed the ability for you to log in as root and had no option to change it in the config, I think you'd have an argument here. But as it stands, the developers are using sane defaults.
You're always going to run into defaults that you don't agree with. That's why there are config files. You make the changes so the system is tailored to your needs. Developers have to provide sane defaults, and not everyone will agree with those defaults, but it seems like you are the outlier here, and most would prefer to go with the more secured defaults.
You pass yourself off as some amazing hacker that any amount of security won't keep you out (like a real life Harold Finch/Mr. Universe/Felicity Smoak/Seymour Birkhoff/Claudia Donovan/etc). But, even if that is true, the majority of people trying to get into systems are not that capable. They try to find an SSH server on the default port and then attempt to bruteforce their way into it. The defaults provided by OpenSSH help minimize the chance of your root account getting hacked by these people/systems. I'm sorry that with your amazing hacking skills, you find it too difficult to change the defaults in your system. Or to adjust your already custom installer to make the changes for you. If that is the case, maybe it is time to move on from Slackware. I'm sure there's a lot of other default settings that you don't like, and I'm sure there'll be more to come.
Either way, you have not provided any decent argument as to why Pat should diverge from the defaults provided by OpenSSH other than to make it easier for you to do unattended installations, which isn't supported out of the box anyway...
Yes I could thanks, but I've decided I'll go LFS instead and move on. Slackware has been a good distribution over the years, but this new way of accepting upstream software developers from deciding how slackware systems should run as default, doesn't work for me.
I don't follow your reasoning - you're swapping a simple config change to having to glue together an entire distro, which will still have those upstream defaults.
What? How is changing the defaults in a config preventing you from running your system as you want it to. I don't like the fact that lilo.conf has compact commented out on a default install, but guess what, I can change it. I also adjust the timer, because I think the default is far too long and I get impatient when I boot my system. Do those sane defaults make me think that Linux is now on a downward spiral and, because of that, make me want to look into alternatives? Umm... no. Now, if the OpenSSH developers completely removed the ability for you to log in as root and had no option to change it in the config, I think you'd have an argument here. But as it stands, the developers are using sane defaults.
You're always going to run into defaults that you don't agree with. That's why there are config files. You make the changes so the system is tailored to your needs. Developers have to provide sane defaults, and not everyone will agree with those defaults, but it seems like you are the outlier here, and most would prefer to go with the more secured defaults.
You pass yourself off as some amazing hacker that any amount of security won't keep you out (like a real life Harold Finch/Mr. Universe/Felicity Smoak/Seymour Birkhoff/Claudia Donovan/etc). But, even if that is true, the majority of people trying to get into systems are not that capable. They try to find an SSH server on the default port and then attempt to bruteforce their way into it. The defaults provided by OpenSSH help minimize the chance of your root account getting hacked by these people/systems. I'm sorry that with your amazing hacking skills, you find it too difficult to change the defaults in your system. Or to adjust your already custom installer to make the changes for you. If that is the case, maybe it is time to move on from Slackware. I'm sure there's a lot of other default settings that you don't like, and I'm sure there'll be more to come.
Either way, you have not provided any decent argument as to why Pat should diverge from the defaults provided by OpenSSH other than to make it easier for you to do unattended installations, which isn't supported out of the box anyway...
I wish people would bother to know what they're talking about before they ranted at me.
The dropbear installation used in Pat's initrd doesn't prevent me accessing the installer as root to perform remote installs. So I can do the install, attended or unattended. What I can't then do is anything with the system I just installed. At least not without yet again having to hack the initrd, just like it had to be hacked to bypass the sop to MS minded fuckwits who wanted to set their keyboard layout before the initrd startup was complete.
It seems the default slackware system now has to be hacked immediately after installation if you want to run it on a server. That's the default position OpenSSH has created for slackware.
Good luck with your PC only desktop operating system, because that's what slackware is by default now.
As for who I am, fuck off knob, I've made no such claims.
I don't follow your reasoning - you're swapping a simple config change to having to glue together an entire distro, which will still have those upstream defaults.
linux is moving along the path of dumbing down to suit users who just want to be able to press the on/off button and use a computer in much the same way as they used Windows. That path is being actively facilitated by those who develop software, and who have decided they too will write software where they have previously decided things for the users. This for example is a case in point where the developers have decided they will take resposibility and secure the root login of systems their software is installed on.
<snip>
I don't have a dog in this fight, but I'd offer the following observation.
If the previous default for root access had been to prohibit password login and it was changed to allow password login for root it's almost guaranteed that somebody (maybe not you, in fairness) would have gone on a rant about how Linux was being dumbed down by MS-minded dolts making the decision to prioritize convenience over security.
So, it really is a can't win scenario unless you take the position that original defaults are de facto "correct" and should never be changed.
maybe you missed it but LFS doesn't have any ssh client/server and so you will have an hard time connecting from remote.
but if you follow BLFS there's openssh: please read what they say in the step "Configuring OpenSSH".
I don't have a dog in this fight, but I'd offer the following observation.
If the previous default for root access had been to prohibit password login and it was changed to allow password login for root it's almost guaranteed that somebody (maybe not you, in fairness) would have gone on a rant about how Linux was being dumbed down by MS-minded dolts making the decision to prioritize convenience over security.
So, it really is a can't win scenario unless you take the position that original defaults are de facto "correct" and should never be changed.
Dave
OK let me put the decision to accept this OpenSSH default into a little context.
At the end of every install off of a default slackware installation system into a VM, or onto any remote system, the installer (person doing the install) is going to have to remember to drop to the prompt and modify sshd_config before rebooting the system. Either that or he/she is going to have open a VM console session to modify the default install, or have someone take a screen or keyboard along to the headless system, to modify the default installed state.
So a default slackware install (from the unadulterated source Pat provides) to anything other than a PC which you can physically accesss is automatically harder. OpenSSH have decided slackware only belongs on PCs with screens and keyboards attached, and you all support that. No headless ARM boxes, no S390 images, no headless PCs. That's just fine.
maybe you missed it but LFS doesn't have any ssh client/server and so you will have an hard time connecting from remote.
but if you follow BLFS there's openssh: please read what they say in the step "Configuring OpenSSH".
I haven't built an LFS system is about 6 years, so thanks for the advice. I'll have a look at BLFS now.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.