Can you disable direct console login of rsaadmin - without harming normal server function?
If I want to prevent direct login to my RSA AM8 servers ( running on SuSE Linux ), can this be done at the OS level?
- Auth Manager
- Authentication Manager
- Community Thread
- Forum Thread
- RSA Authentication Manager
- RSA SecurID
- RSA SecurID Access
Kindly note that the "rsaadmin" account is mainly used to SSH to the appliance for troubleshooting purposes or to apply patches through the operations console and this SSH access can be disabled through the Operations Console >> Operating System Access >> and then uncheck the "Enable SSH" box.
However, disabling the rsaadmin account permanently at the OS level is not supported and cannot be done.
You have the following span of control over this account:
- You create the Operating system UserID and Password, typically named rsaadmin, when you run quick setup for an appliance.
- This account owns the authentication manager files in the Linux /opt/rsa/am directories
- You allow or disable SSH access to the appliance from the operations console
- You allow or disable Console access as you would another other server; for a physical appliance you keep it in a locked restricted access data center, for virtual consoles you setup to allow or deny account access as you see fit
If your use case is to track who made changes in the Linux operating system, there are Knowledge Base articles on setting up SSH accounts for each individual user on your Help Desk or Super Admin team, so that they SSH with their own Linux account for tracking purposes, the sudo su rsaadmin to perform tasks the require the rsaadmin credentials, such as
- modify the configuration of or display passwords for certain keystores or the internal database
/opt/rsa/am/server/rsaserv - to stop ans start AM appliance services
But to simply disable is an unknown, it could cause problems because it was not a use case tested by QE. So it is not supported. It might work, it might break things. If you do it and it works, there could be situations where Engineering requests that you restore to system default of enabled in order for them to troubleshoot any bugs you believe might be on the system.
Were you simply planning on disabling in /etc/passwd?
if you add individual users in linux and grant them SSH access, but disable ssh access for rsaadmin, that might achieve the obfuscation you mentioned in a earlier post.
Setting complex passwords with some password lockbox utility, or installing an RSA PAM agent on the Suse Linux of the Appliance to challenge all for Passcode for SSH (or console) access as Tiffany alluded to sounds like it is what you seek. I know other customers do this, though as Ahmed pointed out, it is not supported (which means it might work, but you might be asked to undo it to troubleshoot any reported bugs - so you have to weigh the risk here). In this situation many customers accept the risk of carefully configuring this.
I think simply disabling SSH as outlined above should satisfy the requirement to "disable direct login".
I would like to add some comments to Jay's response. Changing the system to prevent access from the system console is not recommended, could result in support difficulties, and does not improve the security of the system. Initial system console interaction is provided by the BIOS and cannot be controlled from the OS. For a secure deployment, you will need to control access to the system console regardless of any OS-level settings.
You did not mention if you're system is physical or virtual. In either case, accessing the system console requires the equivalent of physical access. I would recommend you look to secure the following:
- The physical location where the servers are racked (i.e., server cages, access-controlled doors, etc.) or...
- The virtualization system administration console login and access controls (i.e., make sure all administrative accounts are necessary and are privileged appropriately).
If you're using a virtualization system, I would recommend you following both #1 and 2 (i.e. limit physical access to the VM host physical servers).
Failure to secure this level of access renders any OS-level changes tenuous at best. From my perspective, an adversary "hacking" into a virtualization system is equivalent to them physically breaching the door to the data-center; either could be used to gain access to the system console.