As you have hopefully noticed, in the last few weeks we have been replacing the existing server access system based on a single SFTP/SSH user per application with a much more powerful one. This process will be completed by December 8th, when we will remove old credentials from all servers. Many of you are already using the new credentials, for those of you who still aren’t, we will outline here how you can perform this transition in the smoothest way.
The old SSH/SFTP user
Until last Wednesday, the system we were offering our customers to access their applications was a single set of SFTP/SSH credentials per application. If a customer wanted someone else to have access to his/her applications, then he/she could just somehow send these credentials to the third party or create a Team member with full access to the console, so he/she could just retrieve them from there.
That was a simple system, very easy to understand but that had some problems:
- Even if the application specific SFTP/SSH user had only read/write access to a single application, it could also read files for all other applications in the server and this was a real problem for people that wanted to completely isolate applications and access to it.
- This system was also not flexible as the same credentials could end up being shared between a large number of people and the only way to remove access to someone was to update them (something that couldn’t be done either from console) and redistribute the new username/password to everyone.
The new credentials system
To tackle these problems, we have come up with a completely refurbished credentials system that, while trying to keep simplicity intact, will be extremely more flexible and powerful for users with more complex needs.
The new system revolves around two types of server access credentials (covered in detail in this KB):
- Master Credentials – Controlled by the account owner. Give SSH/SFTP access to ALL applications in the server.
- Application Credentials – Only for Team members. One per application the team member has access to and gives SFTP access only to this specific application (and nothing else).
This simple system solves the two problems seen above with the old SFTP/SSH application user. New application credentials (linked to a team member and specific application), just  give SFTP access to one application (read/write) and no access at all to any other application. And if the account owner wants to remove access to a certain team member, he/she can just disable/delete the team member.
Transitioning from one system to the other
Moving from using one set of credentials to the other should be quite straightforward. To illustrate it, let’s assume several typical Cloudways Cloud Platform customers types and which would be the process for them:
1) Single developer/blogger
Most simple case. This type of user would have been using the application specific SFTP/SSH user for each of the applications deployed on his/her servers, to update/manage the application code.
Now with the new system, he/she just needs to use the master credentials that will give he/she SFTPÂ and SSHÂ access to all applications in the server. The option to update the master credentials is also available (both user name and password).
2) Single developer/blogger or small web agency/SMB sharing old SFTP/SSH user with few third parties
In this scenario, the account owner is sharing directly (i.e. via email, skype, etc.) the old SFTP/SSH credentials with a few third parties (designers, developers, etc.). This can be solved in two different ways with the new system, depending on your application isolation needs and security consciousness.
- If you don’t want to have anything to do with the team feature, then just share the master credentials with the third party. This will give them access (read/write) to all applications. Only difference with the old system is that you needed to share SFTP/SSH user for each of the applications they needed access to, now jut one. From a security stand point, before they had write access to one application and read to the rest, now it is read/write to all.
- Much better than the previous approach, is to simply create a team member for each of the third party collaborators, with access to some or all the applications in the server. This will properly isolate access and give you an easy way to control it.
3) Large web agency/business with many collaborators
For this type of customer, the old system was very limited. The transition is something that in fact they would have been looking forward to.
Account owner (CTO, Dev lead, etc.) will have access to everything. Additional team members with full access (lead developers, etc.) can be easily created (team member with Full console permissions). For external parties helping with specific projects, you can create team members with Limited access to only one or a few servers. If these external parties are helping with just a few applications, team members can be further limited to just the desired applications. Additionally, you have certain privileges that you can choose to give your team members (delete applications, add applications, access master credentials, etc.). For sure, you can disable access any time.
In all cases, it is important to note that through the team feature, you are creating console users (so usernames and passwords that will give access to the console) with certain privileges. Once team members login to the console with their user name and password, they will be able to create/access their Application credentials that are the ones that actually give server access.
I hope that this scenario based approach, has made understanding the new system much easier!
Pere Hospital
Pere Hospital (CISSP & OSCP) is the CTO and co-founder of Cloudways Ltd. He has over two decades of experience in IT Security, Risk Analysis and Virtualization Technologies. You can follow Pere on Twitter at @phospital and read his blog at www.perehospital.cat
