Since it's clear you don't know how sshd works, I'd like to point out that if you have a user "bob" with UID 0, then sshd will not allow you to log in using a password with the default of "PermitRootLogin prohibit-password". It looks at the UID, not the username.

Yeah, I know that. I said it earlier. I was taking the mick.

(Note: Nothing to do with SSH)
A few years ago I tried to increase security on some HP-UX and SunOS systems by creating an innocuous user name with ID=0 and giving the user name root an ID number with nobody type of permissions.

It worked...kind of. I reverted back to using root after a couple of weeks because most of the system administration maintenance scripts and application installation/update scripts only checked for the user name not the user ID number. It became tedious having to rewrite all the new installation/update scripts arriving every week for all of the programs we were running. I gave into convention and decided to use my extra energy elsewhere.

I remember at the time thinking the installation/update script authors were lazy by not properly checking for "god" access.

This was one amusing thread to read... usually it's a bit of TL;DR for me, but I kept reading for some reason.

I'd like to chip in a few cents, just to keep this going :-)

I like it how Dave started with ranting and now is in a state to be reasoned with. I understand your frustration, been there a few times when some defaults changed or things started to work differently "all of a sudden"; happens to all of us I suppose. Keeps things interesting, I guess.

Anyway, your prior claim that changing this default from "permissive" to "restrictive" does not make Slackware _less_ suitable for server/corporate environments, but acutally more... security is a big issue, certainly nowadays. And as Pat stated, the rant would've been worse if this was reverse(d).

Also, I think that Slackware still (and always will be, because this philosophy is so much in the heart of it) does the "it's your system, do with it what you want"... It's only a default, but you can still (easily) change it.

I recall systems like Yast, where one had to do a change manually, because it was not in the menus... and then running that dreaded Yast again reversed that manual change... And there have been more... heck, it was the same system: I had to uninstall almost everything to replace one kind of LDAP with another LDAP... because, heck: everything was eventually glued to that LDAP... about as far as the kernel. Give me Slackware any day! There will be some surprises, but none (I hope) I cannot overcome. It's my system, I can do with it what I want.

You know that realisation you get half way through the thread when it occurs to you that you're behaving like a dickead... well yes, I was angry, frustration at what seems a pointless change bought down the red-mist. It's pleasing to know someone obtained some amusement from it though.

4 members found this post helpful.

I just did a slackpkg upgrade-all and locked myself out of my box.
I did change the PermitRootLogin back to yes and also tried the new default "PermitRootLogin prohibit-password"
The authorizedkey for root is not accepted anymore and the password (obviously) is not accepted.

fail2ban now disabled the ssh port for my ip for an hour.

What strikes me as a nuisance is that everytime I do a slackpkg upgrade-all I must be prepared to spend at least a few hours on troubleshooting all the things I customized and that were undone by the upgrades.

the problem is that you shouldn't do "slackpkg upgrade-all" blindly: it's assumed you have read the ChangeLog first.

That is a good tip

I have access now again. PermitRootLogin yes works OK.
Now I will have to redo my keys. They are now 1024bit DSA style. I am not a security wiz and have used these keys as is since 2007.
What type of public-key is best to choose?

I use the defaults, that is what openssh developers consider safer: you can run (that won't cut you off as only the listener process is killed) and that should take care of regenerating all the supported keys for the server (here ssh_host_dsa_key, ssh_host_ecdsa_key, ssh_host_ed25519_key and ssh_host_rsa_key).
then you delete/move away your old key for that server from your ~/.ssh/known_host on the client box and you try to connect again to the server: this should prompt you to accept by default an ecdsa-sha2-nistp256 key.
as you can see DSA keys are not considered so secure anymore and they have been superseded by ECDSA ones that are preferred when you have no local keys for that host.

The puttyGen on the windows machine does not generate ecdsa keys. Can't get openssl-1.0.1r to accept the dsa keys.

I've tried to reinstall the 1.0.1.p package but is was removed from the mirrors and everywhere else I look. sigh. This exactly what I meant with nuissance.

I upgrade telco equipment. If I were to even suggest doing a change that could not be easily reverted I would be seriously frowned upon.

maybe you got an old version of puttygen: it supports generating ECDSA keys since 2014

http://tartarus.org/~simon/putty-sna.../Chapter8.html

http://www.chiark.greenend.org.uk/~s...ist/ecdsa.html

...and so you blindly do "slackpkg upgrade-all"?

It seems to me that you'd just modify your installer to copy your administration user's public key into /root/.ssh/authorized_keys or /root/.ssh/authorized_keys2

I think I've found my new background image for the work computer.

Some of us pick our aliases here with care, you know.

Folks who work on telco software (I used to) would put a LOT of effort into making the installers/upgraders stupid-simple and able to back out of messed up installations on their own.

We had cases of equipment sitting in a bunker out in the middle of nowhere (like an island in the Pacific) that had to be upgraded remotely over a satellite link. You really didn't want to be the one to fly out to fix the problem.