Re: [gentoo-user] Any way to automate login to host and su to root?
On 7/17/22 11:24 PM, J. Roeleveld wrote: If I have 1 desktop and 1 laptop, that means 2 client machines. Add 5 servers/vms. /Clients/ need (non-host) key pairs. Servers shouldn't need non-host key pairs. Servers should only need the clients' public keys on them. That means 10 ssh-keys per person to manage and keep track off. If you're using per-host-per-client key pairs, sure. If you're only using per-client key pairs and copying the public key to the server, no. When a laptop gets replaced, I need to ensure the keys get removed from the authorized_keys section. If the new key pair would be using the same algorithm and bit length and there is no reason to suspect compromise, then I see no reason to replace the key pair. I'd just copy the key pair from the old client to the new client and destroy it on the old client. This is especially true if the authorized_keys file has a from stanza on the public key. Same goes for when the ssh-keys need refreshing. Which, due to the amount, I never got round to. I've not run into any situation where policy mandates that a key pair be replaced unless when there isn't any reason to suspect it's compromise. I actually have more then the amount mentioned above, the amount of ssh-keys gets too much to manage without an automated tool to keep track of them and automate the changing of the keys. I never got the time to create that tool and never found anything that would make it easier. As I think about it, I'd probably leverage the comment stanza of the public key so that I could do an in place delete with sed and then append the new public key. E.g. have a comment that consists of the client's host name, some delimiter, and the date. That way it would be easy to remove any and all keys for the client in the future. When hosts can get added and removed regularly for testing purposes, this requires a management tool. It depends on how you configure things. It seems as if it's possible to use the "%h" parameter when specifying the IdentityFile. So you could have a wild card stanza that would look for a file based on the host name. You could put "root" without a valid password, making it impossible to "su -" into and add a 2nd uid/gid 0 account with a valid password. I know of 1 organisation where they had a 2nd root account added which could be used by the orgs sys-admins for emergency access. (These were student owned servers directly connected to the internet) I absolutely hate the idea of having multiple accounts using the same UID. I'd be far more likely to have a per host account with UID=0 / GID=0 and have the root account have a different UID / GID. I'll need to try this at some point in the future. I expect the "wheel" group to only be for changing into "root", that's what it's advertised as. I've seen some binaries in the wheel group and 0550 permission. Still needs the clients to be actually running when the server runs the script. Or it needs to be added to a schedule and gets triggered when the client becomes available. This would make the scheduler too complex. Why can't the script that's running ssh simply start an agent, run ssh, then stop the agent? There's no coordination necessary. I agree, but root-access is only needed for specific tasks, like updates. Most access is done using service-specific accounts. I only have 2 where users have shell-accounts. Many people forget about problems on boot that require root's password. I'd love to implement Kerberos, mostly for the SSO abilities, but haven't found a simple to follow howto yet which can be easily adjusted so it can be added to an existing environment. ACK -- Grant. . . . unix || die
Re: [gentoo-user] Any way to automate login to host and su to root?
On Sunday, 17 July 2022 21:15:05 CEST Grant Taylor wrote: > On 7/15/22 11:46 PM, J. Roeleveld wrote: > > Hmm... interesting. I will look into this. > : > :-) > : > > But, it needs the agent to be running, which will make it tricky for > > automation. > > Why can't automation start an agent? It could, but that would open up an unsecured key to interception if an intermediate host is compromised. > Why can't there be an agent > running that automation has access to? See previous answer, the agent, as far as I know, will have the keys in memory and I haven't seen evidence that it won't provide the keys without authenticating the requestor. > > I know, which is why I was investigating automating it. The passwords > > are too long to comfortably copy by hand. > > I assume that you mean "type" when you say "copy". Yes, copy/paste has no issues with multi-page texts. But manually reading a long password and copying that over by typing on a keyboard when the font can make the difference between "1" (ONE), "l" (small letter L) and "|" (pipe- character) and similar characters make it annoying to say the least. > > I will definitely investigate this. They sound interesting. I'd set > > the validity to a lot less if this can be automated easily. > > Yes, it can be fairly easily automated. > > One of the other advantages of SSH /certificates/ is when you flip > things around and use a /host/ certificate. Clients can recognize that > the target host's certificate is signed by the trusted SSH CA and not > prompt for the typical Trust On First Use (TOFU) scenario. Thus you can > actually leverage the target host SSH fingerprint and not need to ignore > that security aspect like so many people do. Currently, when that comment pops up, the first thing I do is wait and wonder why it's asking for it. As all the systems are already added to the list. -- Joost
Re: [gentoo-user] Any way to automate login to host and su to root?
On Sunday, 17 July 2022 21:10:52 CEST Grant Taylor wrote: > On 7/15/22 11:42 PM, J. Roeleveld wrote: > > True, properly done automation is necessary to make our lives easier. > > #truth > > > I tried this approach in the past and some levels of automation still > > use this, but for being able to login myself, I found having different > > keys become cumbersome and I ended up never actually replacing them. > > I'm curious what you found to be cumbersome. If I have 1 desktop and 1 laptop, that means 2 client machines. Add 5 servers/vms. That means 10 ssh-keys per person to manage and keep track off. When a laptop gets replaced, I need to ensure the keys get removed from the authorized_keys section. Same goes for when the ssh-keys need refreshing. Which, due to the amount, I never got round to. I actually have more then the amount mentioned above, the amount of ssh-keys gets too much to manage without an automated tool to keep track of them and automate the changing of the keys. I never got the time to create that tool and never found anything that would make it easier. > I make extensive use of the client SSH configuration file > (~/.ssh/config) such that I don't need to worry about which key is used > for which host. This means that anything that uses ssh / sftp / scp > /just/ /works/ (tm) using the contents of the configuration file. When hosts can get added and removed regularly for testing purposes, this requires a management tool. > > The goal is to have whichever authentication system used, the > > passwords/keys to be replaced often with hard to brute-force > > passwords/keys. I can currently replace all passwords on a daily > > basis and not have a problem with accessing any system. > > I agree in concept. Though I question the veracity of that statement > when things aren't working normally. E.g. system is offline for X hours > do to hardware failure or an old version restored from backup that is > now out of sync with the central system. Down due to hardware issues means the password-refresh fails for this host. Backup-restore scripts have a step added to update the passwords updated to whatever is in the vault before the system is brought back online. I actually considered these and made sure it can handle this. The most common issue is a network link being down due to ISP issues. > > For normal use, most systems don't need to be logged into a shell. For > > the few where this is needed, individual accounts exists. But, no > > individual account is a member of "wheel". For admin access, there are > > admin accounts on the machines. (they are all named individually and > > you won't find the same admin-account-username on more then 1 system) > > I've wondered about having the account for UID / GID 0 be named > something other than root. But the testing that I did showed that there > were too many things that assumed "root". :-/ You could put "root" without a valid password, making it impossible to "su -" into and add a 2nd uid/gid 0 account with a valid password. I know of 1 organisation where they had a 2nd root account added which could be used by the orgs sys-admins for emergency access. (These were student owned servers directly connected to the internet) > Though I did find that I was able to successfully convert a test VM to > use something other than root and the proof of concept was a success. > It's just that the PoC was too much effort / fragile to be used in > production. > > I find that the wheel group is mostly for su and a few other commands. > But the concept of you must be a member of a group or have special > permissions applied directly to your account is conceptually quite > similar to being a member of the wheel group. As such I don't think the > abstraction makes much difference other than obfuscation. I expect the "wheel" group to only be for changing into "root", that's what it's advertised as. > > True, but this needs to run from the client. Not the server. Which > > means it will need to be triggered manually and not scheduled. > > The algorithm could be refactored such that it is run from the server. > E.g. if you can ensure that the old key is replaced with the new key, it > can safely be done server side. I did this for a few colleagues that > had forgotten the passphrase for their old private key and needed their > new public key to be put into place. Still needs the clients to be actually running when the server runs the script. Or it needs to be added to a schedule and gets triggered when the client becomes available. This would make the scheduler too complex. > > I don't even have sudo installed on most systems, only where it's > > needed for certain scripts to work and there it's only used to avoid > > "setuid" which is an even bigger issue. > > I tend to prefer sudo's security posture where people need to know > /their/ password. Meaning that there was no need for multiple people to > know the shared target user's
Re: [gentoo-user] Any way to automate login to host and su to root?
On 7/15/22 11:46 PM, J. Roeleveld wrote: Hmm... interesting. I will look into this. :-) But, it needs the agent to be running, which will make it tricky for automation. Why can't automation start an agent? Why can't there be an agent running that automation has access to? (I have some scripts that need to do things on different systems in a sequence for which this could help) :-) I know, which is why I was investigating automating it. The passwords are too long to comfortably copy by hand. I assume that you mean "type" when you say "copy". I will definitely investigate this. They sound interesting. I'd set the validity to a lot less if this can be automated easily. Yes, it can be fairly easily automated. One of the other advantages of SSH /certificates/ is when you flip things around and use a /host/ certificate. Clients can recognize that the target host's certificate is signed by the trusted SSH CA and not prompt for the typical Trust On First Use (TOFU) scenario. Thus you can actually leverage the target host SSH fingerprint and not need to ignore that security aspect like so many people do. Added to my research-list. :-) -- Grant. . . . unix || die
Re: [gentoo-user] Any way to automate login to host and su to root?
On 7/15/22 11:42 PM, J. Roeleveld wrote: True, properly done automation is necessary to make our lives easier. #truth I tried this approach in the past and some levels of automation still use this, but for being able to login myself, I found having different keys become cumbersome and I ended up never actually replacing them. I'm curious what you found to be cumbersome. I make extensive use of the client SSH configuration file (~/.ssh/config) such that I don't need to worry about which key is used for which host. This means that anything that uses ssh / sftp / scp /just/ /works/ (tm) using the contents of the configuration file. The goal is to have whichever authentication system used, the passwords/keys to be replaced often with hard to brute-force passwords/keys. I can currently replace all passwords on a daily basis and not have a problem with accessing any system. I agree in concept. Though I question the veracity of that statement when things aren't working normally. E.g. system is offline for X hours do to hardware failure or an old version restored from backup that is now out of sync with the central system. For normal use, most systems don't need to be logged into a shell. For the few where this is needed, individual accounts exists. But, no individual account is a member of "wheel". For admin access, there are admin accounts on the machines. (they are all named individually and you won't find the same admin-account-username on more then 1 system) I've wondered about having the account for UID / GID 0 be named something other than root. But the testing that I did showed that there were too many things that assumed "root". :-/ Though I did find that I was able to successfully convert a test VM to use something other than root and the proof of concept was a success. It's just that the PoC was too much effort / fragile to be used in production. I find that the wheel group is mostly for su and a few other commands. But the concept of you must be a member of a group or have special permissions applied directly to your account is conceptually quite similar to being a member of the wheel group. As such I don't think the abstraction makes much difference other than obfuscation. True, but this needs to run from the client. Not the server. Which means it will need to be triggered manually and not scheduled. The algorithm could be refactored such that it is run from the server. E.g. if you can ensure that the old key is replaced with the new key, it can safely be done server side. I did this for a few colleagues that had forgotten the passphrase for their old private key and needed their new public key to be put into place. I don't even have sudo installed on most systems, only where it's needed for certain scripts to work and there it's only used to avoid "setuid" which is an even bigger issue. I tend to prefer sudo's security posture where people need to know /their/ password. Meaning that there was no need for multiple people to know the shared target user's password like su does. If I was in a different environment, I'd consider Kerberized versions of su as an alternative. -- Grant. . . . unix || die
Re: [gentoo-user] Any way to automate login to host and su to root?
On Friday, 15 July 2022 14:44:10 CEST Neil Bothwick wrote: > On Fri, 15 Jul 2022 09:53:44 +0200, J. Roeleveld wrote: > > > There's no reason you cannot change SSH keys as regularly, and good > > > reasons why you should. It's just that people don't bother to do it. > > > > I agree, but that is a tedious process. > > > > I have multiple machines I use as desktop depending on where I am. And > > either I need to securely share the private keys between them or set up > > different keys per desktop. > > I assume the same is true for most people. > > I don't share keys, each desktop/laptop has its own keys. I agree this is more secure as you can remove potentially leaked keys individually. But with more devices, the amount of keys and places where these need to be removed increases. > > Never mind that access to the servers needs to be possible for others > > as well. > > > > Either way, to do this automatically, all the desktop machines need to > > be powered and running while changing the keys. > > Not if they use their own keys. It should be simple to script generating > a new key, then SSHing to a list of machines and replacing the old key > with the new one in authorized_keys. This script will need to be run by the individual user. I prefer to control this centrally. > > Changing passwords for servers and storing them in a password vault is > > easier to automate. > > Indeed it is, and now you've found a way to do what you want with > passwords, all is well. > > However, I will look at scripting regular replacements for SSH keys, for > my own peace of mind. Most security improvements start with "simple" questions like these :) Good luck with your scripts :) -- Joost
Re: [gentoo-user] Any way to automate login to host and su to root?
On Friday, 15 July 2022 18:32:52 CEST Grant Taylor wrote: > On 7/15/22 1:53 AM, J. Roeleveld wrote: > > I agree, but that is a tedious process. > > Yes, it can be. That's where some automation comes into play. True, properly done automation is necessary to make our lives easier. > > I have multiple machines I use as desktop depending on where I am. And > > either I need to securely share the private keys between them or set > > up different keys per desktop. > > I /currently/ use unique keys /per/ /client/ /system/. > > I am /planing/ on starting to use unique keys /per/ /client/ /per/ > /server/. Meaning that each client will use a different key for each > remote server. I think that this combined with location restrictions in > the authorized_keys file will mean that SSH keys (or certificates) can't > be used from anywhere other than their approved location or for anything > other than their intended purpose. I tried this approach in the past and some levels of automation still use this, but for being able to login myself, I found having different keys become cumbersome and I ended up never actually replacing them. > > I assume the same is true for most people. > > Yes. It depends what security posture you / your organization want. The goal is to have whichever authentication system used, the passwords/keys to be replaced often with hard to brute-force passwords/keys. I can currently replace all passwords on a daily basis and not have a problem with accessing any system. > > Never mind that access to the servers needs to be possible for others > > as well. > > I assume that other users will use their own individual accounts to log > into the target systems with a similar configuration. > > E.g. I log into remote systems as "gtaylor" and you log into remote > systems as "joost", and Neil logs into remote systems as "neil". We > would all then escalate to root via "su -" with the automation providing > the password to su. For normal use, most systems don't need to be logged into a shell. For the few where this is needed, individual accounts exists. But, no individual account is a member of "wheel". For admin access, there are admin accounts on the machines. (they are all named individually and you won't find the same admin-account-username on more then 1 system) > > Either way, to do this automatically, all the desktop machines need > > to be powered and running while changing the keys. > > No, they don't. > > You just need to account for current and prior keys. > > I've done exactly this on a fleet of about 800 Unix systems that I > helped administer at my last job. You do something like the following: > > 1) Log into the remote system explicitly using the prior key. > 2) Append the current key to the ~/.ssh/authorized_keys file. > 3) Logout of the remote system. > 4) Log into the remote system explicitly using the current key. > 5) Remove the prior key from the ~/.ssh/authorized_keys file. > 6) Logout of the remote system. > > This can be fairly easily automated. True, but this needs to run from the client. Not the server. Which means it will need to be triggered manually and not scheduled. > You can then loop across systems using this automation to update the key > on systems that are online. > > You can relatively easily deal with systems that are offline currently > later when they are back online. -- There are ways to differentiate > between offline and bad credentials during day to day operations. So > when you hit the bad credentials you leverage the automation that tries > old credentials to update them. > > You end up bifurcating the pool of systems into different groups that > need to be dealt with differently. Online and doing what you want; > online but not doing what you want; and offline. > > > Changing passwords for servers and storing them in a password vault > > is easier to automate. > > I disagree. > > Using passwords tends to negate things like authenticating to sudo with > SSH keys / certificates, thus prompting the use of NOPASSWD:. I don't even have sudo installed on most systems, only where it's needed for certain scripts to work and there it's only used to avoid "setuid" which is an even bigger issue. -- Joost
Re: [gentoo-user] Any way to automate login to host and su to root?
On Friday, 15 July 2022 18:15:04 CEST Grant Taylor wrote: > On 7/15/22 1:15 AM, J. Roeleveld wrote: > > Yes. > > Okay. > > That simply means that SSH keys won't be used to authenticate to the > remote system. > > > How would it not prompt for a password. > > There is a PAM module; pam_ssh_agent_auth, which can be used to enable > users to authenticate to sudo using SSH keys. This means that the user > /does/ authenticate to sudo as necessary. It's just that the > authentication happens behind the scenes and they don't need to enter > their password. Thus you can avoid the NOPASSWD: option which means a > better security posture. Hmm... interesting. I will look into this. But, it needs the agent to be running, which will make it tricky for automation. (I have some scripts that need to do things on different systems in a sequence for which this could help) > > I need something that will take the password from the vault (I > > can do this in Python and shell-scripting. Probably also in other > > scripts). Authenticating to the vault can be done on a session basis > > and shared. So locally, I'd only login once. > > Sure. > > > Currently, yes. I never physically see the password as it currently > > goes into the clipboard and gets wiped from there after a short time > > period. Enough time to paste it into the password-prompt. It's > > the copy/pasting that I am looking to automate into a single > > "login-to-remote-host" script. > > I would not consider the copy and paste method to be secure. There are > plenty of utilities to monitor the clipboard et al. and copy the new > contents in extremely short order. As such, users could arrange to > acquire copies of the password passing through the clipboard. I know, which is why I was investigating automating it. The passwords are too long to comfortably copy by hand. > I would strongly suggest exploring options that don't use the clipboard > and instead retrieve the password from the vault and inject it into the > remote system without using the clipboard. > > Or, authenticate to sudo a different way that doesn't involve a > password. This will work for 90+ percent of the use cases. Meaning > that the sensitive password is needed for 10 percent or less of the > time. Thereby reducing the possible sensitive password exposure. }:-) > > > I prefer not to use SSH keys for this as they tend to exist for years > > in my experience. And one unnoticed leak can open up a lot of systems. > > That is a valid concern. > > I'd strongly suggest that you research SSH /certificates/. SSH > /certificates/ support a finite life time /and/ can specify what > command(s) / action(s) they can be used for. > > My $EMPLOYER uses SSH /certificates/ that last about 8 hours. I've > heard of others that use SSH /certificates/ that last for a single digit > number of minutes or even seconds. The idea being that the SSH > /certificate/ only lasts just long enough for it to be used for it's > intended purpose and no longer. I will definitely investigate this. They sound interesting. I'd set the validity to a lot less if this can be automated easily. > The ability to specify the command; e.g. "su -" that is allowed to be > executed means that people can't use them to start any other command. }:-) > > > This is why I use passwords. (passwords are long random strings that > > are changed regularly) > > Fair enough. I only counter with take a few minutes to research SSH > /certificates/ and see if they are of any interest to you. Added to my research-list. -- Joost
Re: [gentoo-user] No sound. Please, help!
чт, 14 июл. 2022 г. в 10:53, Michael : > > On Thursday, 14 July 2022 07:19:14 BST gevisz wrote: > > пт, 11 мар. 2022 г. в 20:15, gevisz : > > > пн, 19 окт. 2020 г. в 00:15, gevisz : > > > > вс, 18 окт. 2020 г. в 21:15, Dale : > > > > > gevisz wrote: > > > > > > вс, 18 окт. 2020 г. в 17:20, Dale : > > > > > >> gevisz wrote: > > > > > >>> No sound at least in Firefox. Tried it on youtube. Skype is > > > > > >>> currently > > > > > >>> uninstalled. So, I cannot check using it. > > > > > >> > > > > > >> Just a thought. Are you sure that everything is unmuted? Years > > > > > >> ago, > > > > > >> all the sound control software, Kmix, alsa and others, default to > > > > > >> mute. > > > > > >> If just one of them is muted, no sound. I seem to recall when I > > > > > >> did my > > > > > >> install on this rig that I had to unmute the sound in three places, > > > > > >> Kmix, alsa and one other that I can't recall the name of. I think > > > > > >> I had > > > > > >> to turn up the volume on alsa as it was set to a really low level > > > > > >> once > > > > > >> it was unmuted. Usually, I turn all of them to the max except the > > > > > >> one I > > > > > >> mainly use. In my case, Kmix is the one I use to really control > > > > > >> things > > > > > >> since it sits on the panel thingy. The others are set at the max. > > > > > >> > > > > > >> It's a silly thing but thought it worth a mention just in case > > > > > >> there is > > > > > >> a muted setting somewhere. > > > > > > > > > > > > Thank you for your input. Yes, it seems that something is muted but > > > > > > what? > > > > > > I have no KDE and no kmix installed. No pulseaudio. > > > > > > > > > > Type in alsamixer in a console or whatever you use and hit tab twice. > > > > > I > > > > > suspect you have that installed. You should have a text version, like > > > > > a > > > > > console uses, and a gui version, that should work in any DM. Pick > > > > > your > > > > > poison and see if anything there is muted or the volume is set really > > > > > low, like 1 out of 100 or something. I think hitting the "m" key > > > > > toggles the mute. > > > > > > > > I am sorry to confess that I forgot that I should use M to unmute > > > > a channel in alsamixer (as I did about 14 years ago) and thought > > > > that arrows up and down do all the work. :( > > > > > > > > So, now the problem has been solved. > > > > > > Last time I have ended the discussion on my > > > "no sound" problem acknowledging that I was > > > so stupid that "forgot that I should use M to > > > unmute a channel in alsamixer." > > > > > > However, it turned out that it was not the case: > > > currently I have all channels in alsamixer unmuted > > > and have sound only in about 1 from 10 bootings of > > > my Gentoo system, while I do always have sound > > > on the same computer while I boot it with Ubuntu 20.04. > > > > > > I have also compared the output of lsmod command > > > on both systems and found out that my Gentoo system > > > had all sound kernel modules that my Ubuntu system has > > > and even more. (In Gentoo, I still have quite an old 5.4.97 > > > kernel, but I do not think that it is the cause of my > > > "no sound" problem.) > > > > > > Of course, it is completely my responsibility that > > > I have built my Gentoo system in such a way that > > > I never know if I will have sound after its next boot. > > > However I am lost guessing what I did wrong. > > > (Comparing with Ubuntu 20.04, my Gentoo system > > > has no systemd and no pulseaudio, no consolekit, > > > and no policykit.) > > > > > > I leave this just for history, as I am currently > > > in a war zone and so investigating this problem > > > further is not in my priority list. :( > > > > I have accidentally found that the problem with > > absence of sound on my Gentoo box appears > > only when my USB Logitech webcam is connected > > to the computer during the boot time. > > > > Moreover, if it happens and the sound is absent, > > the alsamixer shows that my USB Logitech webcam > > is considered by the system as a default sound device. > > > > So, it tries to send sound there even though it does > > not have any speaker. > > I'll blame some relatively recent change in the kernel > or some interaction with udev. Yes, it is quite probable that udev, evdev or the like is responsible for the problem.
Re: [gentoo-user] No sound. Please, help!
вс, 17 июл. 2022 г. в 19:18, gevisz : > > чт, 14 июл. 2022 г. в 14:57, Jude DaShiell : > > > > I'll go on a guess alsa got installed on the system. Yes, it is. > > If that is correct, please try a command as root in terminal > > if necessary or on console: > > > > amixer set Master 100% unmute && alsactl store && aplay > > /usr/share/sounds/alsa/Front_Center.wav I was sure that it wouldn't work but tried: # amixer set Master 100% unmute && alsactl store && aplay /usr/share/sounds/alsa/Front_Center.wav amixer: Unable to find simple control 'Master',0 > > It's possible that doesn't work because /var/lib/alsa/asound.state exists > > or /var/lock/alsa.lock exists. The first file exists and the second one is not. > > If those two files do not exist and pulseaudio and/or pipewire hasn't > > gummed up the works that should work.
Re: [gentoo-user] No sound. Please, help!
чт, 14 июл. 2022 г. в 14:57, Jude DaShiell : > > I'll go on a guess alsa got installed on the system. If that is correct, > please try a command as root in terminal if necessary or on console: > > > amixer set Master 100% unmute && alsactl store && aplay > /usr/share/sounds/alsa/Front_Center.wav > It's possible that doesn't work because /var/lib/alsa/asound.state exists > or /var/lock/alsa.lock exists. > If those two files do not exist and pulseaudio and/or pipewire hasn't > gummed up the works that should work. I was sure that it wouldn't work but tried: # amixer set Master 100% unmute && alsactl store && aplay /usr/share/sounds/alsa/Front_Center.wav amixer: Unable to find simple control 'Master',0
