Even OpenSSL itself later started using a newer PKCS#8 format (which uses BEGIN PRIVATE KEY or BEGIN ENCRYPTED PRIVATE KEY headers) for all new private keys. it's weak against passphrase bruteforcing. PKCS#1 key files ( BEGIN RSA PRIVATE KEY) come from the PEM encrypted messaging project. RSA primes, or EC points) still work the same way regardless of file format, so if needed you can easily convert from one format to another (using ssh-keygen -p -m or PuTTY's puttygen tools). (Although it still understands the old format.) RSA or AES) – so it ended up creating its own private key format, initially just for Ed25519 keys, but eventually began using it for all algorithms. However, OpenSSH doesn't want to depend on OpenSSL – after all, SSH itself isn't based on SSL/TLS in any way the only reason OpenSSH is using OpenSSL at all is for its cryptography functions (libcrypto, e.g. Previously OpenSSH (the ssh program) just happened to use the PKCS#1 format because the OpenSSL library already used the same format for its own private keys and provided a convenient function for loading and storing keys in this format.

There's no standard format for storing SSH private keys in files each SSH client might use its own and in practice there are probably 4 or 5 different formats out there. (The private key is never sent to the server, so there's no question about compatibility with Azure – it only has to be compatible with your client.) So the key format that you currently have is correct if your ssh-keygen produced it, then your ssh client will be able to use it.

The only 'should' is that it should be a format that ssh itself understands.

Openssh private key