上QQ阅读APP看书，第一时间看更新

Additional flags

When we generated our keys, we also added a couple of flags.

As with any software, checking the manual page for the command you're running can provide a sometimes overwhelming amount of additional detail:

$ man ssh-keygen

To save a little bit of a headache, I'm going to highlight some options that may be of interest to you, starting with -b:

-b bits

We used the -b flag to specify a large amount of bits during the generation of our RSA key. The minimum is 1024 and the default is 2048. Your place of business may have requirements on the length of RSA keys.

Next, we have the comment flag:

-C comment

We used this to add a bit of description to our keys. It might be useful if you use different keys for different things (this is my GitLab key, this is my personal server key, this is my company server key, and so on).

If you do need multiple keys, you may want to pass the name of your new key within the generation command (as opposed to typing it out when prompted):

-f filename

We also have -l to print the fingerprint of a key, and/or the ASCII art if you so wish. This can be very useful for verifying key pairs:

-l (or -lv for a pretty picture)

If you want to change the passphrase of a private half, but don't want to generate a new key, you can use the -p option:

-p

To specify the type of key you wish to generate, you can use the -t option:

-t dsa | ecdsa | ed25519 | rsa

When choosing the type of key to generate, consider your requirements. RSA is generally the most compatible, but your company may have other policies, or you may have a personal preference.

I've come across two scenarios where Ed25519 keys couldn't be used – one was an in-house script that required RSA for encrypting files, and the other was OpenStack, at the time.

Finally, there's good old -v, providing verbose output since the early days:

-v

This can be passed multiple times, that is, -vvv is also valid, with each v increasing the debug level.