SSH Keys – Public Keys Authentication Issues
by Hanz Makmur September, 26, 2016 • Modified Mar 17, 2023
With the latest role out of CentOS/Ubuntu on our public machines since Fall 2015, public keys authentication has been disabled for All CS public resources because of issue with private key security. This means, you have to reenter your username and password every time you login.
As of fall 2017, we moved to kerberized Network File System which requires kerberos credential to access your home directory and other network storage. With public key you don’t have a kerberos credential, and so file access won’t work. Read on to learn why we don’t recommend it for personal machines.
Pubic/Private key is convenience with security implications. Convenience applies to both users and attackers. For security reasons, we don’t recommend it even for non kerberized machines.
The need for stronger authentication.
The main issue for non kerberized machine is that the world has changed and username and password are not enough. When large company with big budget security teams can loose private info like Goldman Sachs and Half a Billion Yahoo password breached, we need to move to stronger authentication instead of making it weaker. SSH Public/Private keys weakens security.
Issue 1: Insecure private key
Essentially, people use private key to avoid using password which lead them to remove passphrase from SSH Key. This resulted in private key without password (passwordless private key), and not to mention many issues with weak keys of which the corresponding private keys could be easily recovered even if they are protected by password.
Issue 2: Compromised Computer causing lost of key
Private keys are stored in end user’s computer where likely hood of malware infections is very high. If users don’t put password on their private key when that private key is compromised, the entire system is compromised easily. When combined with mistakes on mailto:?attach function, which is making it easier for people to steal one’s private keys, we can end up in a total disaster when stolen keys is used to login to all the system easily.
Issue 3: Easy for you, easy for them
With today security issues, we are going the opposite direction where multi factor authentication is recommended. This means after password is entered another pin, token or keys must be supplied to get access. Instead of zero key, now at least 2 keys are required.
The problem with security is that easy access for a user also means easy access for the bad guys. Since our security is as strong as its weakest link, we have to make hard choices between easy or secure. To raise it on another level, there were also discussion to allow Rutgers access only for all our machines and requiring VPN to access our resources. So far we have not gone this way but I doubt they will stay world accessible for long.
The Move to use Two Factor Authentication (2FA)
The trend in general is to move to Two Factor Authentication. You see with the banks and other service provider sending your SMS text containing codes that you have to enter to login to their resources. This is an example of 2FA. Despite SMS based 2FA is deemed as insecured, it is better to have one than not having one at all. Here is a list of what you we are doing:
On CS Linux Machines:
All users of CS CentOS/Ubuntu machines now can use Two Factor Authentication on our Kerberos server or use Google authenticator to ensure better security on their Linux account.
On University Resources
University is also enabling NetID+ which is two factor authentication using Duo Security and centralizing all Web services authentication using Central Authentication System (CAS).
On University Email
-
- Centralized Email: To enforce more security, University as a whole is centralizing all email for faculty and staff as part of University Strategic Plan. No more ad-hoc email servers anywhere at university. All faculty and staff MUST use Rutgers Connect email system and can not use any other system including Scarletmail for their email. These email system is going to require people to use NetID+ to login very soon.
- Managed Mobile Device: To be able to read email from mobile devices, All mobile devices regardless who own it, must enroll in mobile device management system where university requires all mobile devices to be locked with password and must be able to wipe your phone remotely along with other privacy info you must surrender to university.
Alternative Solution
To enable one-time login similar to public keys authentication, where you can ssh without typing password every time, your home machine should support kerberos login. If you are willing to do some work, please follow Setting up Kerberos Support for your Home or Office Machine.
Conclusion
It’s interesting world we live in today, Education environment is now treated as corporate environment for security reason. Many of our faculty and staff are not happy with many changes but the order comes straight from the top and understandably so.
The lesson here is, security is important. We certainly can’t afford any data lost and get publicized in the news that we get data breached like what happen recently to UC Berkeley. I think DDOS lesson from last 2 years awoken many people at Rutgers that heads will role if such event ever took place. Thus we are in a new “Better safe than sorry at any cost” era. I suspect it will cost more to clean up than to prevent data lost so expect more security changes happening.
Further Reading