Yes. My thought was that you probably knew it wasn't secure since you were asking for ways to fix it.

That was explained. You don't need to solve that problem with workarounds, but need to avoid that situation at all. But probably I misunderstood it (completely?). I mean (for example) users are not allowed to put their keys everywhere....
I do not want to offend against you. Just wanted to give you the best hint I can.
Obviously nologin, sudoers and other things mentioned earlier are definitely good and useful, but if the keys are there you are lost. And I think even root can be compromised.

Also the accounts don't need write access to the SSH keys. You can move the AuthorizedKeysFile to a location where they can be read but not written.

Sorry, I got side tracked with work, however I want to thank everyone for their answers. This is what I've taken away from this thread.


1. There are no "service accounts" in Linux.

2. I've set the shell for accounts that certain end users keep logging into directly to /sbin/nologin,, when they should log into with their normal user account and then escalate to a different account.

thanks

did it solve your issue?

Yes and no.

Yes in that I set the account to /sbin/nologin.

No in that we want to ssh keys between servers to automate work with scripts. I'm not sure how to handle this.

(how) are these two things related to each other?

I don't understand what your asking.

I just want to prevent a user from logging into the RHEL VM into that account. However want to allow ssh keys between two RHEL VMs.

Setting that account login to /sbin/nologin, will this impact ssh keys?

do you want to allow ssh for these service accounts (among hosts?) (you should not). Do you want to allow ssh with key [only] for regular users?

So if I'm understanding you correctly, we shouldn't allow for this user account (Oracle) to have access to ssh keys between two RHEL VMs. Sounds like this is a security issue as well. If you don't mind elaborating on that, as I don't understand the why behind it.

Regular users typically login into to RHEL VMs from Windows 10 Desktop via PuTTY.

As the sys admin, I use ssh keys between all of my RHEL VMs. I may not have a firm understanding of the how, but I want to make sure security is applied correctly to the RHEL VMs that I manage.

However I have end users who can't follow the rules or don't think the rules apply to them. Should they not be allowed to generate ssh keys too since they have no regards for the rules?

ssh keys are used to allow passwordless logins using ssh. This can be convenient for regular users and also for services which should do some remote work (like ansible).
Actually I don't know if the given oracle user is meant to do some remote managing, but if I remember well it was not planned.
You need to set up [passwordless] sudo <oracle user> <some commands> for the users who allowed to manage oracle and configure ssh key for them.

Right, I know what ssh key are for.

I have ssh keys setup for my user account because it saves me time from having to type a password over and over. For another account that does port scanning, I used ssh keys because it was having issues logging in. Once setting up ssh keys, that solved that issue.

Right again, in that I've setup Oracle and white listed commands via sudo.

Its still not clear if I setup Oracle with /sbin/nologin how it will affect ssh keys or if this will be more of a security issue as I have users who can't be trusted to do the right thing.

You can use AllowGroups to whitelist groups or DenyGroups to blacklist them in sshd_config. That can keep people from logging in with the wrong accounts.

if the login shell is set to nologin the system will not allow you to log in. with or without ssh keys.

1 members found this post helpful.

While I tend to agree that your setup should probably be rethought, would it work to just disallow ssh access to these "service accounts" so they cannot be remotely logged into? This would force your users to use their own account and sudo to the service accounts.

Turbocaptialist is on the same track as well, I see.