- What is going on?
- Why do these SSH keys need to be changed at all? Is this a result of a security breach?
- We only use your services occasionally, or we are no longer Percona customers. Does this affect us?
- What do you need from us?
- Are there instructions on how to do this?
- Is there anything else I can do to make sure only Percona can access my systems?
- I have a question that isn’t answered here. Who can I ask?
What is going on?
Percona uses a technology called SSH to connect a majority of our customers. A part of using SSH is ‘SSH Keys’. These allow us to connect to customer systems without the need to transmit passwords over the internet, so it’s more secure than entering a password. Every once in a while, these SSH keys need to be changed as a standard security best practice. This is what Percona is doing now.
Why do these SSH keys need to be changed at all? Is this a result of a security breach?
This is not the result of a security breach. The best way to think of why we need to change this SSH public key is to use an analogy. Think about "SSH keys" in the same way that you think about a locked door. By installing our SSH public key on your server, you are installing a 'locked door' on your server. This door cannot be broken down and we at Percona are the only ones with the keys to this door. Some bad guys are trying to find keys that will open this door. Finding the keys is extremely difficult, but is not impossible. The longer the lock on this door is in use, the greater the chance the bad guys have of finding a key that will open the door. By periodically changing the SSH public key, we are changing the lock on this door. This means the bad guys have to start all over again trying to find a key for the new lock.
Periodically changing the lock on this door increases the security of the server because we are changing the lock before the bad guys can find a key for it.
The switching of this SSH public key is not a result of any security breach or vulnerability or issue. This is just a periodic changing of the keys that we use to connect to your systems, in accordance to what we believe are security best practices.
We only use your services occasionally, or we are no longer Percona customers. Does this affect us?
In short, yes. All current and past customers who allow(ed) Percona to connect to them through our consultant (jumphost) servers will be affected by this change. Current customers (even pay-as-you-go customers) are asked to uninstall the old key and install the new key. Past customers are asked to make sure that the old SSH key is removed from your systems because leaving the old key on your system increases the likelihood of the key being compromised.
What do you need from us?
Your system administrator will need to remove our old SSH public key and, for current customers, install our new SSH public key. We provide step-by-step instructions for this process here http://www.percona.com/ssh-key-rotation/instructions. However, we cannot go into your systems and do this for you.
Are there instructions on how to do this?
Yes! You can find the instructions page here.
Is there anything else I can do to make sure only Percona can access my systems?
We’ve built extra security into our SSH public key. Even if a bad guy got their hands on the matching private key for our public key, they would have to log into our consultant jumphost servers in order to gain access to your system. They can’t just log in from their own machines. You must make sure our public key is copied to your system exactly as it is shown on the instructions page and this functionality will work on your servers. You must also allow the IP addresses of our consultant jumphost servers through your firewall, as described on our instructions page.
I have a question that isn’t answered here. Who can I ask?
You can contact our 24/7 support using the contact information on this page: http://www.percona.com/contact/24x7-emergency