On Wed 11 May 2022 at 07:05:47 (+0200), to...@tuxteam.de wrote: > On Tue, May 10, 2022 at 10:08:20PM -0500, David Wright wrote: > > On Tue 10 May 2022 at 17:12:25 (-0600), Charles Curley wrote: > > [...] > > > IOW, though logging in to root by password is ok at the console, > > it's not ok when remote. ➀ > > I assume you know all that you can set "PermitRootLogin yes" in > your /etc/ssh/sshd_config (the default is "prohibit-password", > which fits the behaviour you are describing). > > It's not recommended, (for good reasons!), but hey, it's your box, > and you decide what you deem to be "secure enough". After all, > security is context-dependent, and the worst antipattern is to > misuse tech to force people to follow some nonsensical rituals > (it happens far too often, alas, but OpenSSH isn't that sort of > software). > > So you can change that, if you wish so. What's your point?
Well, Charles seemed to have difficulty with understanding my first paragraph, which I wrote merely to explain that I assume a root password has been set. It seems odd to get three follow-ups, all of which centre on the consequences of the ssh configuration chosen by the Debian developers for a bullseye installation. When you write a script to unlock and mount a partition, you can do it in two lines: # udisksctl unlock --block-device /dev/foo # mount /dev/bar /baz but that's useless as it stands, and needs to be embedded into your ecosystem to be useful, which is why I posted my script, a real example. But after two posts about background information on setuid shell scripts, you now write "the worst antipattern is to misuse tech to force people to follow some nonsensical rituals". Strong words. Perhaps you could elaborate on which specific rituals you find offensive. I can't work out whether you're criticising my script, or the Debian developers for the way they're now choosing to configure ssh, or the linux kernel developers for the ban on setuid shell scripts. Cheers, David.