Why to use .PEM file in ssh process

Question

So I come from windows background and new to SSh. We are in Linux environment now and as much as I like SSh and see its benefits, what I have realized is that it can be implemented in different ways. Now, for the longest times, we have been using ssh with public/privte key which works exactly like how it is described in this digital ocean article

Basically,

1. We used key-gen with our email to create a private/public key and then copied .PUB file to the server
2. Just keep on ssh-ing to the server without having to enter any password

Now, I came across another model where another team uses this .pem file and they have to use this .pem file to ssh to the server every time. According to them, it is more secure. To me, it's just more work. Anyways, my question is simple

1. What is benefit of using .Pem file?
2. How is it better than the ssh model that we are using?

Answer 1

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.

ssh works with keys: keys attached to users and keys attached to servers. 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.

This works well and is still probably the default most used ssh keys.

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. You may also want more security around keys, being able to revocate access easily, etc.

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. 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.

For servers, using certificates, means you basically get back the same model as today on HTTPS. Where it may be more interesting is for user keys. 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. 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.

Netflix has an elaborate mechanism like that they talked about. 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.

See this presentation of them, which may give you some ideas on why certificates may be useful: https://speakerdeck.com/rlewis/how-netflix-gives-all-its-engineers-ssh-access-to-instances-running-in-production or the corresponding video: https://www.youtube.com/watch?v=JwLGsWYVjqU

They also "open-sourced" the software they need for this architecture: https://github.com/Netflix/bless

Answer 2

Both teams are doing the same thing

Team A used ssh-keygen, to create a private/public key pair, which stored the private part on $HOME/.ssh/id_rsa, and added the public key to the authorized_keys file on the server. 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.

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.¹

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. 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 both cases, the key could be protected with a passphrase, but none of the teams seem to be doing that)


‭  

So, to answer your questions:

What is benefit of using .Pem file?

You are also using the key file, it is just being accessed transparently, so there's no real benefit in what they do.

How is it better than the ssh model that we are using?

better is a subjective term, but IMHO it is actually best that explicitly stating the key is not required. 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. But even then, for any server I commonly connected to, I would configure ssh to pick the right key 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†)

† I consider much cleaner to do rsync file server.com: than RSYNC_CONNECT_PROG='ssh -i /my/keyfile %H' rsync file server.com:).