Access to ilifu cloud infrastructure Friday 5th June 2026 12:07:16

Dear colleagues

As hosts of the ilifu cloud infrastructure, the University of Cape Town (UCT), in coordination with the Inter-University Institute for Data Intensive Astronomy (IDIA), are issuing this advisory because SSH keys used to access ilifu may have been compromised. If you use SSH keys for access, please rotate them immediately and replace the old public keys on all systems and services where they are trusted.

SSH keys are commonly used across servers, code repositories, cloud platforms and automation systems. If a private key is exposed, an unauthorised person may be able to authenticate as you on any system that trusts the matching public key.

Please note that SSH private keys are not limited to the computer where they were created. If a private key is compromised, it may be used from another system wherever the corresponding public key is still trusted.

Required action

If you use SSH keys, please complete the following steps:

1. Generate a new SSH key pair.
2. Add the new public key to every system or service where you use SSH authentication.
3. Test that the new key works as expected.
4. Remove the old public key from all systems and services where it was previously trusted.

Systems and services that may be affected include Linux or Unix servers, bastion or jump hosts, code repositories such as GitHub, GitLab or Bitbucket, cloud platforms, automation or deployment systems, backup or monitoring systems, and any system where your public key appears in an authorised_keys file.

Best practice guidance

Please follow these SSH key hygiene practices:

• Use separate SSH keys for different purposes, such as work, personal use, production access and code repositories.
• Protect private keys with a strong passphrase.
• Never share private keys with anyone.
• Never send private keys by email, chat, ticketing systems or file-sharing platforms.
• Do not store private keys in scripts, shared folders, source code repositories or documentation.
• Remove old or unused public keys from systems and services.
• Avoid SSH agent forwarding unless specifically required and approved.
• Review your ~/.ssh/config, shell history, Git remotes, scripts and automation files for references to old keys.
• Ensure private key files have restrictive permissions and are readable only by your user account.

What to do with old keys

After your new key is working, remove the old public key from every system or service where it was configured. Deleting the old private key from your workstation is not enough; the old public key must also be removed everywhere it was trusted.

If you are unsure where your SSH key is used or need assistance rotating it, please contact the relevant support team as soon as possible.

Should you have any questions relating to this email, please direct your query to idia-security@uct.ac.za.

Regards

University of Cape Town, in coordination with the Inter-University Institute for Data Intensive Astronomy