Managing a CA correctly is no joke and can bite you quite hard if done improperly. It can be a highly successful if done very carefully, with a lot of security and processes around the certificates delivery workflows.
This is a very centralized way of managing your accesses, with all the power in the hands of whoever controls your CA. This specifies which account can be accessed on the server, among other things.
#Audubon ssh bastion install
You install the public certificate of your CA on all your servers, and they’ll accept any connection authenticated by a certificate delivered by said CA, relying on the subjectName of the certificate. PKI-based authenticationįor the sake of completeness – because I can hear you from here SSH gurus! – there is a third way in recent versions of SSH servers, namely authentication based on a PKI with a trusted Certificate Authority (CA). Indeed, doing it properly and maintaining it in the long-term in an enterprise context is a real challenge. Pushing your public key to your home server is easy, but when you have tens of thousands of servers/devices, as well as thousands of employees, administering some always-changing subset of said servers/devices, it quickly becomes complicated.
#Audubon ssh bastion password
It goes a long way to fixing password issues, but then the problem becomes scalability. But you’re just putting additional burden on your users and still not achieving a satisfactory level of security. Of course there are ways to mitigate the risk, such as forcing a periodic password renew, a minimum password length and/or complexity, or disabling an account after several failures, etc.
As a sysadmin, you never really sleep well when you know that the security of your systems are just one password away. They bring a whole range of problems, such as the fact that they’re always subject to bruteforce attacks, and some users might get hit by the password reuse plague. Even strong passphrases such as “ Correct Horse Battery Staple“, are nothing more than an elaborate password in the end. This forces you to use a password manager that is protected by… a master password. Either you pick one that is too easy to crack, or you pick some very complex one that you’ll never remember. Well, we all already know that passwords suck. Password authenticationįirst, the password way. The issue is that none of these two ways are really satisfactory in an enterprise context. There are two regular ways of using it: either you just type your account password when the remote server asks for it, which is more or less like rlogin (without your password transmitted in plaintext over the wire) or you use a public key authentication, by generating a so-called “keypair”, with the private key sitting on your desk (or in a smartcard), and the corresponding public key sitting on a remote server. SSH has been the de-facto admin standard for quite some time now – replacing obsolete programs such as rlogin, that were happily transferring your password in plaintext over the network – so we use it all the time, as most of the industry does. But regardless of this heterogeneity, do you know what they all have in common? Yes, they all ping, but there’s something more interesting: they can all be administered through ssh. We also have a lot of network devices, split against different constructors, spanning a wide range of model generations.Īs you’ve probably guessed, we have heterogeneous systems that are running to provide a handful of different services. We also had Solaris boxes, that later turned into OmniOS boxes, that have now turned into shiny FreeBSD boxes.
As long as it has a CPU (or vCPU), we probably booted some kind of Linux distro on it. We even had good old Gentoos once! These are all stored on bare metal servers, on VMs, and in containers everywhere. We have a lot of different flavours such as Debian, Ubuntu, Red Hat… and the list goes on. At OVHcloud, a fair amount of our infrastructures are built on top of Linux boxes.
0 kommentar(er)
