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 key authentication has been turned off for all CS public resources because of an issue with private key security. You must reenter your username and password every time you log in.
As of fall 2017, we moved to a kerberized Network File System, which requires Kerberos credentials to access your home directory and other network storage. With a public key, you don’t have a Kerberos credential so that file access won’t work. Read on to learn why we don’t recommend it for personal machines.
The public/private key is convenient but has security implications. Convenience applies to both users and attackers. We don’t recommend it for security reasons, even for nonkerberized machines.
The need for stronger authentication.
The main issue for nonkerberized machines is that the world has changed, and usernames and passwords need to be revised. When large companies with big-budget security teams can lose private info, such as Goldman Sachs and Half a Billion Yahoo passwords being breached, we must move to stronger authentication instead of weakening it. SSH Public/Private keys weaken security.
Issue 1: Insecure private key
Essentially, people use the private keys to avoid passwords, which leads them to remove the passphrases from SSH keys. This resulted in a private key without a password (passwordless private key), not to mention many issues with weak keys of which the corresponding private keys could be easily recovered even if a password protects them.
Issue 2: Compromised Computer causing loss of key
Private keys are stored in the end user’s computer, where the hood of malware infections is very high. If users don’t put a password on their private key when compromised, the entire system is compromised easily. When combined with mistakes on mailto:?attach function makes it easier for people to steal their private keys; we can end up in a total disaster when stolen keys are used to log in to the system easily.
Issue 3: Easy for you, easy for them
With today‘s security issues, we are going in the opposite direction, where multi-factor authentication is recommended. This means another PIN, token, or key must be supplied after the password is entered to get access. Instead of a zero-key key, at least two keys are now 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 must make hard choices between easy and secure.
The Move to use Two Factor Authentication (2FA)
The trend, in general, is to move to Two Factor Authentication. You see, banks and other service providers send your SMS text containing codes you must enter to log in to their resources. This is an example of 2FA. Although SMS-based 2FA is deemed insecure, having one is better than not having one. Here is a list of what you are doing:
On CS Linux Machines:
All CS CentOS/Ubuntu machine users can now use Two Factor Authentication on our Kerberos server or Google authenticator to ensure better security on their Linux account.
On University Resources
The university requires NetID+, two-factor authentication using Duo Security, and centralizing all web service authentication using the Central Authentication System (CAS).
On University Email
- Centralized Email: To enforce more security, University is centralizing all email for faculty and staff as part of University Strategic Plan. No more ad-hoc email servers anywhere at the university. All faculty and staff MUST use the Rutgers Connect email system and can not use any other system, including Scarletmail, for their email. This email system requires people to use NetID+ to log in.
- Managed Mobile Device: To be able to read email from mobile devices, All mobile devices, regardless of who owns them, must enroll in a mobile device management system where the university requires all mobile devices to be locked with a password and must be able to wipe your phone remotely along with other privacy info you must surrender to university.
Alternative Solution
To enable a one-time login similar to public key authentication, where you can SSH without typing a password every time, your home machine should support Kerberos login. If you want to do some work, please follow the instructions for setting up Kerberos Support for your home or office machine.
Conclusion
It’s an interesting world in which we live today; the educational environment is now treated as a corporate environment for security reasons. Many of our faculty and staff are unhappy with many changes, but the order comes straight from the top, and understandably so.
The lesson here is that 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. This DDOS lesson from the last few years has awoken many people at Rutgers that heads will roll if such an event occurs. Thus, we are in a new “Better safe than sorry at any cost” era. Cleaning up will cost more than preventing data loss, so expect more security changes.
Further Reading