![]() ![]() Their developers have a way to automatically request new certificates, very short lived (in the order of minutes, when the SSH connection is open, it does not matter if the certificate expires during it, it stays open), so that they can connect to any host.The Cybersecurity and Infrastructure Security Agency (CISA) has the mission to provide a common baseline of security across the Federal Civilian Executive Branch (FCEB) and to help agencies manage their cyber risk. Netflix has an elaborate mechanism like that they talked about. Then you can just issue to your users some certificates with the specific constraints they need to connect to the servers they need to connect to. For example, you do not need to configure the server with the specific set of user keys allowed to connect there, you just need to configure the server to accept all certificates signed by a specific CA, that is internal and you control, with some specific constraint. Where it may be more interesting is for user keys. X.509 certificates encapsulate a public key (where you would have the private key in a separate file) with some other metadata, such as validity dates or other constraints to use this certificate, and they are delivered by some specific Certificate Authority.įor servers, using certificates, means you basically get back the same model as today on HTTPS. So what as been added in OpenSSH (version 5.4 in 2010 for initial availability and then version 5.6 in for full support) is the possibility to use not just bare keys but X.509 certificates. ![]() You may also want more security around keys, being able to revocate access easily, etc. However you may hit mostly management problems (instead of technical problems) when you have too many hosts or users and you want fine grained control: each server must be configured with a specific set of user keys, and users need to know a specific set of server keys if they want to avoid the TOFU principle. This works well and is still probably the default most used ssh keys. When it started, it was classical asymetric cryptography, every party (servers and users) have a least one couple of private+public key and all of this is used to authenticate who connects to what. Ssh works with keys: keys attached to users and keys attached to servers. You are conflicting multiple issues, and you should start by stopping to speak about ".PEM files", the format of the file is mostly irrelevant to what follows. † I consider much cleaner to do rsync file : than RSYNC_CONNECT_PROG='ssh -i /my/keyfile %H' rsync file :). Properly configuring ssh to connect make complex setups easy to use, like accessing an internal machine jumping through an intermediate bastion host, or just performing a rsync there (which has no direct -i parameter to pass to the underlying program†) But even then, for any server I commonly connected to, I would configure ssh to pick the right key file. Not placing the key in the automatic location would only be preferable if you wanted to use different key pairs and ensure that one isn't used automatically. ![]() How is it better than the ssh model that we are using?īetter is a subjective term, but IMHO it is actually best that explicitly stating the key is not required. You are also using the key file, it is just being accessed transparently, so there's no real benefit in what they do. (In both cases, the key could be protected with a passphrase, but none of the teams seem to be doing that) There are a few other key filenames it tries by default if they exist, and you could specify a different location on ~/.ssh/config (even different keys for each host if you wanted!), so you don't need to explicitly enter the key filename on each run. In every case, ssh needs the private key file (either it accesses the private file directly, or the key is already loaded in a ssh-agent), only the place where it is located differs. Team B named the file differently (they probably used the -f parameter), and is using -i every time, as otherwise ssh wouldn't find it.¹ Then when sshing to the server, it will by default read the private key from there, thus accessing the server without having to enter any password. Which stored the private part on $HOME/.ssh/id_rsa, and added the public key to the authorized_keys file on the server. Team A used ssh-keygen, to create a private/public key pair, ![]()
0 Comments
Leave a Reply. |