Our today’s release of Moss supports password authentication to log into your servers via SSH/SFTP. In this post I try to explain the use cases behind this decision, and how we’ve addressed this feature without putting at risk the security of your servers.

Some people tend to use very weak passwords which are easily guessed using dictionary-based brute force attacks. The situation has improved a lot thanks to the widespread adoption of password managers, but they’re not commonly used when it comes to generate (and retrieve) passwords to access the servers that host your applications.

Hence, since we started Moss, we’ve been reluctant to let our users log into their servers using passwords. There’s an easy alternative which is way more secure and also more convenient – because you won’t be prompted for the password whenever you try to log in: SSH Key pairs. Basically, you hold a private key that you only know (and no one else have access to) and upload the corresponding public key on your servers. Moss helps you add and remove these public keys to/from your servers from our web application. Therefore, until now, Moss enforced public key auth in all the servers it helps you manage.

Easy, isn’t it? Well, the truth is that there are cases in which SSH Keys might be more of a pain than an advantage.

• Many Linux and Mac OS users are familiar with the concept of SSH Keys. In addition, these operating systems package tools like the OpenSSH Client, which obviously supports the key format of the OpenSSH Server (the de facto standard for server-side SSH software in Linux). However, this isn’t generally true for Windows users, who have to rely on 3rd-party tools like PuTTY and PuTTYgen. In addition, the format of the keys these applications use is different from the OpenSSH format (although they can convert between formats). So, while not unsurmountable, managing SSH Keys in Windows is slightly more involved than in other operating systems.
• Moss is targeted at web developers (including website owners), so they’re assumed to have some technical skills. However, the clients of our users might not be that knowledgeable. They might require SSH/SFTP access to upload content or perform any other task. Forcing them to generate and use a SSH Key pair is fairly unrealistic in many cases. So password authentication is the only feasible alternative sometimes.

Given this reality, now Moss supports password authentication. But we have done it in a way that minimizes the risk of suffering a security breach because of this. Let’s be clear: Most breaches are due to vulnerabilities in the application layer, not the systems layer – this is especially true for low-profile attacks (the most common ones, e.g. in popular ecosystems like WordPress). But that’s no excuse to forget the systems layer. Our responsibility is to help you protect your servers in the best possible way without sacrificing usability. On the other hand, you must take care of the security of your applications (and we have some ideas to help you with this too, but let’s keep focusing on SSH password authentication).

So, what have we done to achieve the former goal?

• You can create a server user with a password (or add a password afterwards), change the password, or disable password auth, right from Moss.
• Moss rejects short passwords.
• Moss can generate long random (secure) passwords on your behalf. You can always retrieve such passwords from Moss itself.
• If a given server user has a password, password auth is enabled in such account – but the remaining users on the server still require public key auth as their only valid method (unless you also add a password to them). So someone trying to break into your server using one of those users, won’t even be offered the possibility of entering a password. I.e. your server will spend fewer CPU cycles with them.
• The first time you add a password on a server, Moss automatically installs and sets up fail2ban. Hence, repeated failed attempts of remote login will provoke that the corresponding IP address gets banned temporarily. On the other hand, if you only use SSH Keys, fail2ban won’t be installed automatically because it’s not that useful in such case.
• Finally, Moss still recommends you to use SSH Keys whenever possible because of their advantages in terms of security and convenience.

With these decisions, we’ve achieved a good trade-off in terms of security and usability. In case you’re curious about alternative auth methods, SSH Certificates are another excellent option but they’re a bit more involved and require specific tooling.

If you don’t have a Moss account yet and want to give it a try, sign up and share your feedback with us. Also, you can subscribe below to our blog in case you want us to send you an email as we publish new stuff here.