On Tue 10 May 2022 at 13:02:41 (-0400), Greg Wooledge wrote: > On Tue, May 10, 2022 at 11:08:23AM -0500, David Wright wrote:
[> > On Tue 10 May 2022 at 08:21:00 (-0600), Charles Curley wrote:] > > > Why the aversion to doing things as root? Why not just run your scripts > > > as root? This is exactly the sort of thing that is reserved to root for > > > reasons of security. > > > > That complicates unlocking partitions remotely because, even if you > > can log in as root, you normally can't log in remotely as root. > > But you *can* typically sudo on the remote system, which is what is > actually being suggested here. I think. It's certainly what's being suggested by /me/, as can be seen in my: sudo udisksctl unlock --block-device "$j" but that's not how rhkramer (judging by the 12:40:25 response¹) and I would take Charles' post as meaning, but rather: $ su - # cryptsetup luksOpen /dev/sd<ann> <luks_device_name> && /bin/mount \ /dev/mapper/<luks_device_name> <mount_point> presumably with the command wrapped, as now, in a script. > (Also, you'd be surprised how many systems *do* allow remote root logins, > either from a quasi-trusted set of source IPs, or using key auth only, > or both.) I do myself, using keys, but only local-root to remote-root. Having an ordinary user use sudo means that one script suffices to unlock /home both from a remote machine or at the console. Of course, it's a separate ordinary user because of their non-/home home directory. Simplification and generalisation are quite important to me, so as you can see, the script will work unchanged on any of my hosts, and though I mentioned unlock-acer, that function is one of several that are created on the fly, in this case from: function unlock-AAAAAAAA { # unlock /home before logging in or transfers ping -c 1 -W 1 AAAAAAAA | grep 'bytes from' # wake it up first date && ssh -X AAAAAAAA -l unlock } (The ping seems to help those powerline devices that some hosts use.) ¹ "a general aversion to being in root" Cheers, David.