Mancha: Thanks for clearing that up! For someone who isn't expert in these matters, that line is very misleading. Mine is being amended forthwith!



--
Pete

the standard is to allow root login at install.

This is for the big amount of remote users that actually need ssh to connect to their remote server after it is installed.
After that you should make modification to your system to reject root logins over ssh, etc.

1 members found this post helpful.

The main problem here is that the OP never uses SSH for anything, but left it installed and running. Maybe allowing root login should not be the default, but then people who actually do use SSH every day would complain.

Debian recently switched to a default of "PermitRootLogin without-password" which allows only key-based root logins.
The change will likely trickle down to Debian derivatives soon.

--mancha

2 members found this post helpful.

Small thread from 10/2013 discussing the topic of what PermitRootLogin setting to ship in sshd_config:
http://marc.info/?t=138102353700001&r=1&w=3.

It didn't get much upstream play possibly because they might feel this is a decision best suited for the
vendor level (a sentiment I would agree with).

--mancha

If I remember correctly, when installing slackware the ssh service is checked by default. So for a newer user it is quite forgiveable to have the service running but not realise it. I think that given this is the case, a change to default sshd configuration to (say) not permit root logins using passwords, but only public/private keys as seems to have happened in Debian, would be very wise.

Right, thanks for pointing that out. I have fixed that then.

Yesterday I noticed sshd service starting at startup. I was WTF because I remember I disabled it at installation. rc,sshd was executable, so I chmod u-x it. Some dates on files pointed to 31st march, which is way closer than I installed slackware, I know I did not touch them myself.

I went to http://mirrors.slackware.com/slackwa...ches/packages/ and checked maybe some package touched sshd configuration.

I downloaded openssh-6.6p1-i486-2_slack14.1.txz and dived into directory structure with mc. It seems this package ships with an executable attribute of rc.sshd, so my old file got overwritten with this one and executed at start.

1 members found this post helpful.

Many Slackware installation scripts (install/doinst.sh inside the package, saved to /var/log/scripts/<package> after installation) are careful to preserve the permissions on existing rc scripts. (Often there is a little function named 'preserve_perms'). But, in the case of openssh, the script does not appear to do this. So yes, you are right, the ssh daemon was re-enabled on your system when you applied the recent openssh patch, which is perhaps not ideal. You did the right thing when you changed the permissions again.

You know what, I went and did installpkg openssh-6.6p1-i486-2_slack14.1.txz to see if rc.sshd will become an executable again, and it did not. So I am still confused how it became an executable initially, or I forgot to unselect it at slackware installation. I dont know.

Yes. If you want an email server.

It seems this is only missing from the 14.1 openssh patch, the 14.0 patch done on the same date has the correct preserve_perms, as does current. The missing preserve-perms happened probably at 14.1 release as the same problem occurs in the original script for 14.1, but there is no problem in current. I guess I'm glad I always make updates do .new files and then manually go through them.

1 members found this post helpful.

mancha,
new default will break remote installation of Slackware, because now setup doesn't create regular user and if we skip chroot to /mnt and do not create regular user manually at setup phase, this installation will be unaccessable for first remote login.
As for me, mention this potential security problem in documentation is still enough.

Well, I assume that most desktop users create a regular user just after installation, and doing that in setup doesn't look like a daunting task. Maybe we could offer that possibility in Slint, as Salix does? More or less, that'd be just running adduser.

main problem I see is this was posted on the 14th and the OP has not come back to respond to his own thread. So I usually take it with a grain of salt .

after this long. Or he figured out his fix hit the forum and left.