• Ssh Key Security Code
• Ssh Key Based Authentication
• Ssh Key Security

Published by Martin Kleppmann on 24 May 2013.

SSH.com frontpage. Security of SSH and attacks against it The SSH protocol is believed to be secure against cryptographic attacks on the network, provided keys and credentials are properly managed. However, we do not recommend using diffie-hellman-group1-sha1 key exchange. It uses a 768 bit Diffie-Hellman group, which may be breakable by governments today. Security Ways to go 1 One SSH key-pair (NO passwd) 1 Multi SSH key-pairs (NO passwd) 2 One SSH key-pair (WITH passwd) 2 Multi SSH key-pairs (WITH. In 2019, TrickBot added SSH key-grabbing capabilities for both PuTTY (SSH client for Microsoft) and OpenSSH. CryptoSink crypto-mining campaign targeting Elasticsearch systems, backdoors the target servers by adding the attacker’s SSH keys. Kaji malware targets IoT devices that have left their SSH port exposed on the internet. According to the. For security reasons it is recommended to use SSH keys instead of password for accessing server. User SSH Key“, it will display a drop-down menu, which.

Update (July 2015): This post is now rather outdated, and the procedure for modifying yourprivate key files is no longer recommended. A better solution is to usessh-keygen -o.

Ever wondered how those key files in ~/.ssh actually work? How secure are they actually?

As you probably do too, I use ssh many times every single day — every git fetch and git push,every deploy, every login to a server. And recently I realised that to me, ssh was just some cryptovoodoo that I had become accustomed to using, but I didn’t really understand. That’s a shame — Ilike to know how stuff works. So I went on a little journey of discovery, and here are some of thethings I found.

When you start reading about “crypto stuff”, you very quickly get buried in an avalanche ofacronyms. I will briefly mention the acronyms as we go along; they don’t help you understand theconcepts, but they are useful in case you want to Google for further details.

Quick recap: If you’ve ever used public key authentication, you probably have a file ~/.ssh/id_rsaor ~/.ssh/id_dsa in your home directory. This is your RSA/DSA private key, and ~/.ssh/id_rsa.pubor ~/.ssh/id_dsa.pub is its public key counterpart. Any machine you want to log in to needs tohave your public key in ~/.ssh/authorized_keys on that machine. When you try to log in, your SSHclient uses a digital signature to prove that you have the private key; the server checks that thesignature is valid, and that the public key is authorized for your username; if all is well, you aregranted access.

So what is actually inside this private key file?

The unencrypted private key format

Everyone recommends that you protect your private key with a passphrase (otherwise anybody whosteals the file from you can log into everything you have access to). If you leave the passphraseblank, the key is not encrypted. Let’s look at this unencrypted format first, and considerpassphrase protection later.

A ssh private key file typically looks something like this:

The private key is an ASN.1 data structure, serialized to abyte string using DER, and thenBase64-encoded. ASN.1 is roughly comparable to JSON (itsupports various data types such as integers, booleans, strings and lists/sequences that can benested in a tree structure). It’s very widely used for cryptographic purposes, but it has somehowfallen out of fashion with the web generation (I don’t know why, it seems like a pretty decentformat).

To look inside, let’s generate a fake RSA key without passphrase usingssh-keygen, and then decode itusing asn1parse:

Alternatively, you can paste the Base64 string into Lapo Luchini’s excellentJavaScript ASN.1 decoder. You can see that ASN.1 structure is quitesimple: a sequence of nine integers. Their meaning is defined inRFC2313. The first integer is a version number(0), and the third number is quite small (65537) – the public exponent e. The two importantnumbers are the 2048-bit integers that appear second and fourth in the sequence: the RSA modulusn, and the private exponent d. These numbers are used directly in theRSA algorithm. The remaining five numbers canbe derived from n and d, and are only cached in the key file to speed up certain operations.

DSA keys are similar, asequence of six integers:

Passphrase-protected keys

Next, in order to make life harder for an attacker who manages to steal your private key file, youprotect it with a passphrase. How does this actually work?

We’ve gained two header lines, and if you try to parse that Base64 text, you’ll find it’s no longervalid ASN.1. That’s because the entire ASN.1 structure we saw above has been encrypted, and theBase64-encoded text is the output of the encryption. The header tells us the encryption algorithmthat was used: AES-128 inCBC mode.The 128-bit hex string in the DEK-Info header is theinitialization vector (IV) for the cipher.This is pretty standard stuff; all common crypto libraries can handle it.

But how do you get from the passphrase to the AES encryption key? I couldn’t find it documentedanywhere, so I had to dig through the OpenSSL source to find it:

1. Append the first 8 bytes of the IV to the passphrase, without a separator (serves as a salt).
2. Take the MD5 hash of the resulting string (once).

That’s it. To prove it, let’s decrypt the private key manually (using the IV/salt from theDEK-Info header above):

…which prints out the sequence of integers from the RSA key in the clear. Of course, if you wantto inspect the key, it’s much easier to do this:

but I wanted to demonstrate exactly how the AES key is derived from the password. This is importantbecause the private key protection has two weaknesses:

• The digest algorithm is hard-coded to be MD5, which means that without changing the format, it’snot possible to upgrade to another hash function (e.g. SHA-1). This could be a problem if MD5turns out not to be good enough.
• The hash function is only applied once — there is nostretching. This is a problem because MD5 and AESare both fast to compute, and thus a short passphrase is quite easy to break with brute force.

If your private SSH key ever gets into the wrong hands, e.g. because someone steals your laptop oryour backup hard drive, the attacker can try a huge number of possible passphrases, even withmoderate computing resources. If your passphrase is a dictionary word, it can probably be broken ina matter of seconds.

That was the bad news: the passphrase on your SSH key isn’t as useful as you thought it was.But there is good news: you can upgrade to a more secure private key format, and everythingcontinues to work!

Better key protection with PKCS#8

What we want is to derive a symmetric encryption key from the passphrase, and we want thisderivation to be slow to compute, so that an attacker needs to buy more computing time if they wantto brute-force the passphrase. If you’ve seen the use bcryptmeme, this should sound very familiar.

For SSH private keys, there are a few standards with clumsy names (acronym alert!) that can help us out:

• PKCS #5 (RFC 2898) definesPBKDF2 (Password-Based Key Derivation Function 2), analgorithm for deriving an encryption key from a password by applying a hash function repeatedly.PBES2 (Password-Based Encryption Scheme 2) is also defined here; it simply means using aPBKDF2-generated key with a symmetric cipher.
• PKCS #8 (RFC 5208) defines a format for storing encryptedprivate keys that supports PBKDF2. OpenSSL transparently supports private keys in PKCS#8 format,and OpenSSH uses OpenSSL, so if you’re using OpenSSH that means you can swap your traditional SSHkey files for PKCS#8 files and everything continues to work as normal!

I don’t know why ssh-keygen still generates keys in SSH’s traditional format, even though a betterformat has been available for years. Compatibility with servers is not a concern, because theprivate key never leaves your machine. Fortunately it’s easy enough toconvert to PKCS#8:

If you try using this new PKCS#8 file with a SSH client, you should find that it works exactly thesame as the file generated by ssh-keygen. But what’s inside it?

Notice that the header/footer lines have changed (BEGIN ENCRYPTED PRIVATE KEY instead ofBEGIN RSA PRIVATE KEY), and the plaintext Proc-Type and DEK-Info headers have gone. In fact,the whole key file is once again a ASN.1 structure:

Use Lapo Luchini’s JavaScript ASN.1 decoder to display a nice ASN.1 treestructure:

The format uses OIDs, numeric codes allocated by aregistration authority to unambiguously refer to algorithms. The OIDs in this key file tell us thatthe encryption scheme is pkcs5PBES2, that the keyderivation function is PBKDF2, and that theencryption is performed using des-ede3-cbc. The hashfunction can be explicitly specified if needed; here it’s omitted, which means that itdefaults tohMAC-SHA1.

The nice thing about having all those identifiers in the file is that if better algorithms areinvented in future, we can upgrade the key file without having to change the container file format.

You can also see that the key derivation function uses an iteration count of 2,048. Compared to justone iteration in the traditional SSH key format, that’s good — it means that it’s much slower tobrute-force the passphrase. The number 2,048 is currently hard-coded in OpenSSL; I hope that it willbe configurable in future, as you could probably increase it without any noticeable slowdown on amodern computer.

Conclusion: better protection for your SSH private keys

If you already have a strong passphrase on your SSH private key, then converting it from thetraditional private key format to PKCS#8 is roughly comparable to adding two extra keystrokes toyour passphrase, for free. And if you have a weak passphrase, you can take your private keyprotection from “easily breakable” to “slightly harder to break”.

It’s so easy, you can do it right now:

The openssl pkcs8 command asks for a passphrase three times: once to unlock your existing privatekey, and twice for the passphrase for the new key. It doesn’t matter whether you use a newpassphrase for the converted key or keep it the same as the old key.

Not all software can read the PKCS8 format, but that’s fine — only your SSH client needs to beable to read the private key, after all. From the server’s point of view, storing the private key ina different format changes nothing at all.

Update: Brendan Thompson has wrapped this conversion in a handyshell script called keycrypt.

Update: to undo this change

On Mac OS X 10.9 (Mavericks), the default installation of OpenSSH no longer supports PKCS#8 privatekeys for some reason. If you followed the instructions above, you may no longer be able to log intoyour servers. Fortunately, it’s easy to convert your private key from PKCS#8 format back into thetraditional key format:

The openssl command decrypts the key, and the ssh-keygen command re-encrypts it using thetraditional SSH key format.

If you found this post useful, please support me on Patreon so that I can write more like it!

To get notified when I write something new, follow me on Twitter or enter your email address:

I won't give your address to anyone else, won't send you any spam, and you can unsubscribe at any time.

More Linux resources

If you have ever worked as a sysadmin (or you want to in the future), you need a good grasp of SSH. I will not run you through the general concept as it has already been hashed out here at Enable Sysadmin. However, I do want to look at a potentially better way to use it. SSH is the single most used remote access protocol in the world. Therefore, it makes sense that we should try to improve its use as much as possible.

I used SSH to remotely connect to thousands of customer machines during my time as a support engineer, and I am sure that others have had a similar experience. With traditional SSH authentication, you need the username and password for the account you want to log in to every time that you wish to access a system. Doesn't sound that bad, right? But, what happens when you need to jump back and forth between systems regularly? Or what if your responsibilities include remote sessions to the same 100 systems throughout the day for health checks? There is another way to accomplish the log in, and with a little upfront investment, it can be far more efficient overall.

Process hardening

It is objectively true that an encrypted key is a much harder target than a username and password for those with ill intentions. Although it can take a little learning, creating and using SSH key-based authentication is worth the investment for every sysadmin.

Here is how it works. You generate a public key and a matching private key. The private key file acts as a password and should be kept safe. However, the public key is copied to the target systems that you connect to regularly. You place the public key in your account home directory on the target server. When you try to log in, the keys are verified, and access is granted.

Now, there are two ways that you can do this. One is more convenient, and the other is a bit tedious but with added protection to you. The convenient way is not to specify a password along with the private key. The result is that you do not have to enter a password when you use your private key for authentication. This means that if someone gets their hands on your private key, they can use it to authenticate, as well. The other method is to password-protect your private key so that you are prompted for the password when authenticating (think two-factor authentication using both the private key and the password).

ssh-keygen without a password

To generate an SSH key pair, use the following command:

By default, your private and public keys are saved in your ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub files, respectively.

ssh-keygen with a password

Creating a password-protected key looks something like this:

Use the -f option to specify the file where the keys will be saved. In the example above, the private and public keys are stored in the /home/user/.ssh/key-with-pass and /home/user/.ssh/key-with-pass.pub files, respectively.

Warning

During further SSH key pair generation, if you do not specify a unique file name, you are prompted for permission to overwrite the existing id_rsa and id_rsa.pub files. If you overwrite the existing id_rsa and id_rsa.pub files, you must then replace the old public key with the new one on ALL of the SSH servers that have your old public key.

Once you have generated the keys, they are stored in the /user/home/.ssh/ directory with the following permissions:

• Private key - 600
• Public key - 644

Ssh Key Security Code

You aren't done yet. Let's look at the final step in successful SSH key-based authentication.

Sharing keys

For all of this to work, you need to share your public key with the remote machines you are trying to SSH to. Adobe acrobat reader for mac mojave pro. Use the ssh-copy-id command to copy your public key over to the destination system. By default, the file path is /home/user/.ssh/id_rsa.pub. You issue the command, specify the file you are sharing, then the user/host we are sharing it with. It should look like this:

Now that you have shared the public key with the destination host, you can authenticate to the remote server by passing the matching private key. If you specified a file path for your private key, you need to give it here. Otherwise, it defaults to /home/_user_/.ssh/id_rsa.

Seen here:

Advantages and summary

Ssh Key Based Authentication

The advantages of using SSH key-based authentication are clear. Passwords are stolen every day, mainly due to human error but also due to attacker skill and determination. An encrypted key, and more specifically, a password-protected encrypted key, makes your SSH authentication even more difficult to attack. You still need to strike a balance of availability and security, but that is handled differently in every environment.

[ Free online course: Red Hat Enterprise Linux technical overview. ]

Ssh Key Security