Best practice for ssh user key management:
ssh user key pairs (typically stored in ~/.ssh/) are popular ways to access remote systems, frequently without having to use a password (unless a passphrase is set on the key, also recommended). Principles commonly associated with password management also apply to key pair management.
- Don't reuse the same key pair or password on different systems
- Adhere to recommended complexity levels
- Periodically rotate
- Immediately change if there is a known attack use
We think the end of regular NSF operations on Blue Waters marks a good opportunity to do this assessment.
Blue Waters has had no known remote vulnerabilities in it's lifetime. It has, however, experienced several local vulnerabilities through the years. Once known, each of these was responded to and mitigated with the utmost urgency, at times requiring an emergency system outage to address. Though local vulnerabilities by definition would only be exploitable by other authenticated users on the system, any vulnerability is investigated to identify any exploit attempt or malicious action, and unsurprisingly, there has never been any evidence of this. While the probability of any compromised data is extremely low, it is technically non-zero. With this in mind, we recommend periodic regeneration of access secrets stored on Blue Waters, namely ssh key pairs. If a user ssh key pair were compromised, and if you have authorized that key pair on a remote system, it would be at risk. A compromised user key presents almost no threat to Blue Waters security, except that they are used by active (running) CCM job instances. CCM will auto-generate key pairs if not present, so if key pairs exist only for CCM use, they can simply be deleted to rotate them. If the public key's comment matches the pattern user@nid#####, that is a strong indication that the key was simply auto-generated by a previous CCM job.
Mail help+bw@ncsa.illinois.edu if you have any questions or would like assistance managing key pairs.
