
Upgrade your SSH keys - mariusavram
https://blog.g3rt.nl/upgrade-your-ssh-keys.html
======
developer2
Seriously, the _default_ options to ssh-keygen should be all anybody needs. If
you need to pass arguments to increase the security of the generated key, then
the software has completely failed its purpose. Passing arguments should only
be for falling back on less secure options, if there is some limiting factor
for a particular deployment.

There is absolutely no reason to pass arguments to ssh-keygen. If it is
actually deemed necessary to do so, then that package's installation is
inexcusably broken.

~~~
mSparks
Well. OP says ->Generate your new sexy Ed25519 key

I too, say, No f'ing thanks
[https://en.wikipedia.org/wiki/Curve25519](https://en.wikipedia.org/wiki/Curve25519)
In cryptography, Curve25519 is an elliptic curve offering 128 bits of security
- The curve is birationally equivalent to Ed25519, a Twisted Edwards curve.

Ecrypt II - the EU project into encryption security says:
[https://www.keylength.com/en/3/](https://www.keylength.com/en/3/)

That gives you

Very short-term protection against small organizations Should not be used for
confidentiality in new systems

and is equivelent to an 816bit RSA key

So how is this new key "Sexy" in any way.

~~~
hannob
First of all the Ecrypt project is is really outdated. Second you're reading
the table wrong. Curve25519 gives you 128 bit of symmetric security, but the
curve is 255 bit long. So from your table this compares to 3248 RSA. Third I'm
no fan of such key number tables, it's a bit arbitrary and doesn't really
reflect the complexities of modern cryptography.

------
tete
Something I don't understand is the "hate" that RSA gets. Yeah, Elliptic
Curves are promising, have benefits (smaller/faster).

But RSA isn't broken, it is well understood, is "boring" (a plus on security,
usually), has bigger bit sizes (according to people that know a lot more to me
that's a plus point, regardless of EC requiring smaller ones, because of
certain attacks), isn't hyped and sponsored by the NSA and isn't considered a
bad choice by experts.

Not too many years ago Bruce Schneier was skeptical about EC, because of the
NSA pushing for it. Now, I also trust djb and i an sure that ed25519 is a good
cipher and there are many projects, like Tor that actually benefit from it,
increasing throughput, etc., but for most use cases of SSH that might not be
the issue, nor the bottleneck.

So from my naive, inexperienced point of view RSA might seem the more
conservative option. And if I was worried about security I'd increase the bit
size.

Am I going wrong here?

~~~
zahllos
The bit size of the RSA modulus and the bit size of ECC keys aren't really
comparable, as what matters is the number of operations required to break the
primitive.

A better comparison exists between multiplicative group crypto (DH/DSA) and
their Elliptic Curve variants. In multiplicative group crypto there is a
trivial, obvious mapping to the ring of integers (in less mathematical terms,
"factorization makes sense"), so you can use techniques like Pohlig-Hellman
([https://en.wikipedia.org/wiki/Pohlig%E2%80%93Hellman_algorit...](https://en.wikipedia.org/wiki/Pohlig%E2%80%93Hellman_algorithm))
and Index Calculus
([https://en.wikipedia.org/wiki/Index_calculus_algorithm](https://en.wikipedia.org/wiki/Index_calculus_algorithm)).
In Elliptic Curve groups we use, such a trivial mapping does not exist,
although there are some special cases where you can achieve this
([http://crypto.stackexchange.com/a/8344](http://crypto.stackexchange.com/a/8344)).
Consequently, larger numbers are needed for security in these cases (along
with strong primes).

The "bad press" RSA gets is likely due to the fact that in however many years
of existence there have been a number of attacks on implementations - for
example, side channel attacks, Bleichenbacher's attack on RSA PKCS#1_5 padding
etc. Here's a survey: [https://crypto.stanford.edu/~dabo/papers/RSA-
survey.pdf](https://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf) . A
simple explanation is that implementing RSA is a fun exercise for personal
experimentation, but implementing RSA for use in the wild is fraught with
difficulties.

Ed25519 has some nice properties aside from the size of keys and signatures.
It is deterministic, removing the requirement for cryptographically random
(and therefore almost unique) k - if you forget this with plain ECDSA you end
up in the Sony PS3 scenario. The provided software does not rely on indexes or
branch instructions, removing timing issues in those cases and making the code
constant time. It has what Bernstein calls "twist security"
([https://safecurves.cr.yp.to/twist.html](https://safecurves.cr.yp.to/twist.html)).
Ordinarily, an ECC algorithm should check that a calculated or received point,
particularly where point compression is used, exists on the curve in question
- however with DJB's "twist security" and in particular in ed25519 this is
unnecessary, simplifying the job of the implementer.

In other words, it is harder to get an implementation of ed25519 wrong.

As for the NSA pushing ECC, more intelligent people than may have different
views, but I believe that ECC in general is sound, taking into account the sum
of our knowledge so far. As with any algorithm there are specific choices of
curves and constants which weaken the setup and we have a case study where NSA
pushed poor choices deliberately:
[https://en.wikipedia.org/wiki/Dual_EC_DRBG](https://en.wikipedia.org/wiki/Dual_EC_DRBG)
. It comes down, therefore, to whether you believe the constants chosen for
the NIST curves are "cooked" or not. I can't see any evidence to support this,
but this doesn't mean it hasn't happened. However, Curve25519, Ed-448,
Curve41717, FourQ and Brainpool curves are all curves designed outside the
NIST system and not endorsed by the NSA and Bernstein includes in his security
evaluations the concept of "rigidity", i.e. a full explanation of how curve
parameters are generated (see
[https://safecurves.cr.yp.to/rigid.html](https://safecurves.cr.yp.to/rigid.html))
(although, apparently, there are some issues with Brainpool curve generation:
[https://bada55.cr.yp.to/brainpool.html](https://bada55.cr.yp.to/brainpool.html)).

If you want to measure "time of life" as a measure of safety, using the
general assumption that the longer something remains unbroken the safer it is,
RSA certainly scores better in that sense (although ECC goes back to the 90s
and Curve25519 to 2005, so have been around a while too) and for a correct,
good, well vetted implementation of RSA I see no reason personally to stop
using it, with the caveat that, as you've noticed, if you have a high
throughput system, you get equivalent security more efficiently with ed25519.

An interesting recommendation in the original article is to use smart cards
for high assurance environments. I personally use an OpenPGP card (v2.1) and
an authentication subkey on it acts as my SSH key. For this I use 4096-bit RSA
keys - the OpenPGP v2.1 spec as implemented by this card does not support ECC
at all, even though the actual hardware chip
([http://www.basiccard.com/overview.htm](http://www.basiccard.com/overview.htm))
is capable of 512-bit ECC curves. The OpenPGP Card 3.0 standard includes ECC
support but so far as I am aware no cards implementing it are available. The
same is actually true in the JavaCard world; hardware support exists, but most
JavaCard implementations you can buy are "limited" to 2048-bit RSA (If anyone
knows differently I would love to know, please yell), which should be good
enough for the moment but it would be nice to have some wiggle room.

So to summarise, the "hate" that RSA gets is likely due to the number of times
people have seen mistakes in implementations. That said, the article makes a
good point regarding the strength of brute forcing your key passphrase if you
are not storing your keys on smartcards. If you are going to regenerate your
key, I see no reason not to use ed25519 as you will likely be using it for
host authentication anyway (modern remote hosts likely generate ed25519 keys
by default, rather than RSA). I'd use it on my smartcards if I could, since
there the timing difference for a signature would be noticeable. I have
multiple ssh keys and those not stored on a smartcard are all ed25519. If you
are considering embedded environments or high throughput ones, or many
signature checks, ed25519 makes even more sense.

~~~
technion

        but implementing RSA for use in the wild is fraught with difficulties
    

Side question, is there a comprehensive list of those issues/requirements
anywhere? I built a list of about five requirements based on the Cryptopals
challenges I'm fairly sure there's more. Before anyone asks, this is an
academic interest rather than an attempt to implement crypto.

------
matt_wulfeck
I disagree with the author. Before you go upgrading into ed25519, beware that
the NSA/NIST is moving away from elliptical curve cryptography because it's
very vulnerable to cracking with quantum attacks[0].

 _" So let me spell this out: despite the fact that quantum computers seem to
be a long ways off and reasonable quantum-resistant replacement algorithms are
nowhere to be seen, NSA decided to make this announcement publicly and not
quietly behind the scenes. Weirder still, if you haven’t yet upgraded to Suite
B, you are now being urged not to. In practice, that means some firms will
stay with algorithms like RSA rather than transitioning to ECC at all. And RSA
is also vulnerable to quantum attacks."_

Stick with the battle tested RSA keys, which are susceptible but not as much
as ECC crypto. 4097 or even better 8192-bit lengths.

There's no perceptible user benefits to using ed25519 and it's not even
supported everywhere. Also you won't have to rotate all of your keys when
workable quantum computers start crackin' everything.

[0]
[https://blog.cryptographyengineering.com/2015/10/22/a-riddle...](https://blog.cryptographyengineering.com/2015/10/22/a-riddle-
wrapped-in-curve/)

~~~
tptacek
Both RSA and Elliptic Curve will fall to practical quantum computing, so the
idea that you should use (weaker, slower) RSA today instead of curves because
of QC is... dubious.

If you see quantum computing as a practical threat (because: you're encrypting
and storing static data that needs to resist cryptanalysis for 20-50 years),
you need to use a post-quantum cryptosystem. Unfortunately: nobody knows which
pq systems will truly hold up to practical quantum computing, and it's
possible --- even likely --- that implementations of pq schemes have dumb
errors that nobody has thought to check for yet.

That's why Google's first foray into deploying pq crypto feeds both a curve
computation and a Ring-LWE PQ computation into its KDF, so that unknown bugs
in the RLWE exchange can't destroy the security of TLS. That's how you would
seriously account for quantum computing in SSH.

The recommendations in this post are solid.

~~~
hannob
There is one argument to be made in favor of large key RSA when it comes to
quantum computers: ECC may fall a bit earlier. There can be a situation where
it's feasible to produce a quantum computer large enough to tackle a 255 bit
ECC key, but not a 4096 RSA key. I have heard from (a few) cryptographers that
this is a reason to stick with "old school" DH/RSA crypto.

I discussed this with various people involved in the postquantum debate and
the general feedback I got was that this is likely not a big issue, because
once quantum computers can be scaled it'll probably not be that hard to scale
them up to RSA-breaking size. I think DJB once said something like "this will
buy you a year" to me.

------
Achshar
Noob question here, why move just one step ahead. Why not 8192 or hell 16,384?
I can see it can lead to higher CPU consumption on often used keys but for
keys that are not accessed more than a couple of times a day, why is it such a
bad idea to overdo it?

~~~
karmajunkie
someone correct me if i'm wrong, but I believe its not just used once a day.
Its used for every packet you send while connected.

~~~
brandmeyer
The ssh protocol specs are actually quite readable. No, the slow asymmetric
key is only used once to derive a fast symmetric key for the session. If you a
set up a control master, then repeated logins to the same server (within some
narrow window) will all multiplex over the same channel, too.

~~~
deathanatos
For those who have never heard of ControlMasters, I highly recommend them. SSH
can multiplex multiple sessions (you invoking ssh at the terminal) over a
single TCP socket — this feature is called ControlMaster. The first ssh
command takes the normal amount of time, but every command after that is just
~a round-trip. No slow asymmetric key exchange. If you close all your
connections, there a (configurable) timeout until the ControlMaster's
connection closes.

You can combine this fact with zsh's autocomplete powers, and get pretty-
close-to-instant (on a good connection) tab-completion of directories _on the
remote server_ , which is extremely nice when trying to scp something, as you
can tab complete the paths in that command.

(It also saves a few PIDs on the server, as a single sshd child deals with all
your connections.)

~~~
Steltek
> You can combine this fact with zsh's autocomplete powers,

I found that recent versions of SSH have begun hashing `~/.ssh/known_hosts`
which nerfed zsh autocomplete pretty badly. You need to set "HashKnownHosts
no" in `~/.ssh/config`. The SSH change was made to prevent a key compromise
from giving an attacker a ready-made list of vulnerable next targets.

~~~
andromeduck
But can't they also just find the hosts by looking at your bash history?

~~~
toyg
Bash history rotates (or can be managed, which a lot of people do), whereas
known_hosts will have every server you ever accessed and is rarely ever
touched.

------
LeoPanthera
Can someone explain to me why RSA 2048 is "recommended to change"? It's still
the default for gpg keys and as far as I know is widely thought to be secure
for at least few hundred years!

~~~
fjarlq
It could have to do with the NSA's August 2015 plan for transitioning to
quantum-resistant algorithms. In their new Commercial National Security
Algorithm (CNSA) Suite, they advise a minimum 3072-bit RSA modulus:

[https://www.iad.gov/iad/programs/iad-initiatives/cnsa-
suite....](https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm)

(Doh... I don't know why I'm getting an invalid certificate authority error
when trying to access that site, but Qualys SSL Labs confirms it's a real
error. Yikes.)

~~~
mastazi
Also: with quantum computing still in its infancy, how do we actually know
which types of keys would be adequate?

~~~
fjarlq
Koblitz and Menezes explore various theories about the NSA's new policy in
their paper, A Riddle Wrapped In An Enigma:

[https://eprint.iacr.org/2015/1018.pdf](https://eprint.iacr.org/2015/1018.pdf)

~~~
cmrx64
For anyone reading the thread, this is an absolute must-read paper if you're
at all interested in the near-future of production cryptosystems in high-risk
settings.

------
brandmeyer
If you have servers too old to work with the latest keys, you can easily
modify your ~/.ssh/config to automatically use a per-machine private key file:

    
    
      Host foo.example.com
        Keyfile ~/.ssh/my_obsolete_private_keyfile

~~~
fphilipe
That you should be doing anyways, shouldn't you?

~~~
Godel_unicode
You certainly can, it's almost certainly unnecessary though. SSH keys are not
like passwords, compromise of a server with your pubkey in no way effects the
security of your private key. Many people will post pubkeys online so they're
easy to add to new servers.

~~~
Nullabillity
Adding to this: GitHub publishes the public SSH keys of all of their users,
for example: [https://github.com/teozkr.keys](https://github.com/teozkr.keys)

------
loeg
RSA 2048 is still the openssh default, i.e., best current advice from the
openssh authors. The fact that this article's author labels that as "yellow"
is a red flag.

~~~
mastazi
I agree. It would be nice if the line:

> RSA 2048: yellow recommended to change

was followed by at least some link that explains why is it unsafe. Could
anyone elaborate further?

UPDATE: there is now a link up in this thread, from the user fjarlq, which
points to an NSA recommendation from 2015. The recommendation seems to be
related to the need of having a "quantum computing resistant" key. But with
quantum computing still in its infancy, how do we know which types of keys
would be adequate?

~~~
lmm
Many theoretical aspects of quantum computing are well-understood, just as a
lot of early work on computational complexity etc. predates the existence of
(nonhuman) computers.

------
jkirsteins
Can anybody elaborate on the idea that for RSA <=2048 is potentially unsafe?
Is it true? It seems that even 1024 bit keys haven't been factored yet, much
less 2048, so why use anything else currently?

[https://en.m.wikipedia.org/wiki/RSA_Factoring_Challenge#The_...](https://en.m.wikipedia.org/wiki/RSA_Factoring_Challenge#The_prizes_and_records)

~~~
waynecochran
I want someone to explain this too -- the article does not give any strong
evidence that RSA <= 2048 is unsafe.

------
morecoffee
Ed25519 is fast, but I don't think the speed is significantly faster to be an
argument for using it. Running the borgingssl speed tool on a skylake mobile
processor:

    
    
        Did 1083 RSA 2048 signing operations in 1017532us (1064.3 ops/sec)
        Did 29000 RSA 2048 verify operations in 1016092us (28540.7 ops/sec)
        Did 1440 RSA 2048 (3 prime, e=3) signing operations in 1016334us (1416.9 ops/sec)
        Did 50000 RSA 2048 (3 prime, e=3) verify operations in 1014778us (49271.9 ops/sec)
        Did 152 RSA 4096 signing operations in 1000271us (152.0 ops/sec)
        Did 8974 RSA 4096 verify operations in 1076287us (8337.9 ops/sec)
        ...
        Did 6720 Ed25519 key generation operations in 1029483us (6527.5 ops/sec)
        Did 6832 Ed25519 signing operations in 1058007us (6457.4 ops/sec)
        Did 3120 Ed25519 verify operations in 1053982us (2960.2 ops/sec)
    

RSA key verification is still extremely fast.

(also don't look at these numbers purely as speed, but as CPU time spent)

~~~
FullyFunctional
Not everyone is using Skylakes. My gateway is a Raspberry Pi (for historical
and power reasons) and my most often used client is ARM based.

------
based2
[https://www.reddit.com/r/netsec/comments/543ncp/upgrade_your...](https://www.reddit.com/r/netsec/comments/543ncp/upgrade_your_ssh_keys_how_to_get_rid_of_dsa_and/)

~~~
technion
I always find it interesting to see the disparity between comments here, and
in /r/netsec on matters like this.

Here: Generally positive. Netsec: Most upvoted comments being complaints and
assertions that it's bad advice. And for some reason, upvoted comments about
NSA involvement in curves (which is exactly what 25519 is not).

~~~
Klathmon
I've started moving away from reddit for any kind of actual discussion about
technical topics. It's just so... Toxic.

I don't know if it's just my point of view changing, or if it's gotten worse
over the last few years, but when I see a thread there later, the top comments
are always negative, dismissive, and so full of bullshit.

Just look at the recent Lenovo issue, HN had some good discussion on on what
could be the actual causes and how to fix some of these problems (and why MS
isn't entirely off the hook there), but reddit was just full of "Microsoft
loves Linux!" Jokes and whichunting with very little to go on.

------
katzgrau
Security is not my specialty, but I obviously wade in this field, being a
developer. Having read this article I __will __say this to OP and the author:

Thank you, I am sufficiently paranoid enough to change my keys now.

------
jlgaddis
If you have any RHEL machines, you might wanna keep an RSA (or ECDSA) key
around. RHEL doesn't support Ed25519.

I haven't checked, but I presume this also goes for CentOS, Scientific Linux,
and other derivatives.

~~~
loeg
The article claims that RHEL7 supports Ed25519. Maybe RHEL6 and older do not.

------
qzervaas
For those who have just updated to macOS Sierra, the default SSH client
configuration is to not allow ssh-dss keys any longer.

Follow these instructions to update your keys.

------
tw04
This is my standard on new server setup (which is admittedly overkill but I'd
rather have it slightly slower and safer):

[http://www.catb.org/esr/sshexport/](http://www.catb.org/esr/sshexport/)

[https://stribika.github.io/2015/01/04/secure-secure-
shell.ht...](https://stribika.github.io/2015/01/04/secure-secure-shell.html)

SERVER SIDE:

sources.list (if you're on an older version of debian) deb
[http://http.debian.net/debian](http://http.debian.net/debian) wheezy-
backports main

apt-get -t wheezy-backports install --reinstall ssh

====

cd /etc/ssh

rm ssh_host_ _key_

ssh-keygen -t ed25519 -f ssh_host_ed25519_key -a 256 < /dev/null

ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

(do not password protect server side keys)

====

/etc/ssh/sshd_config

Protocol 2

HostKey /etc/ssh/ssh_host_ed25519_key

HostKey /etc/ssh/ssh_host_rsa_key

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-
sha256

Ciphers
chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-
ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-
sha2-256,hmac-ripemd160,umac-128@openssh.com

====

CLIENT SIDE:

/etc/ssh/ssh_config

Host *

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-
sha256

Ciphers
chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-
ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-
sha2-256,hmac-ripemd160,umac-128@openssh.com

====

ssh-keygen -t ed25519 -a 256 -f yourkey.key -C whateveryouwant

~~~
pbowyer
For people like me who create a new server and put our public SSH keys in
~/.ssh/authorized_keys, can you explain what doing this does, and why it's
good?

I can see you're limiting it to particular algorithms/cyphers, but the rest?

~~~
tw04
The stuff towards the top eliminates the insecure keys your server will try to
default to. No reason to keep them on the server (IMO) - they're primarily
there for backwards compatibility. I prefer to remove them entirely so I know
my client/server won't ever negotiate an insecure connection.

------
perlgeek
So I once read somewhere that RSA is simpler to implement than most other
algorithms, and hence it's a safer choice than other algorithms, because
weaknesses typically come from suboptimal implementation less than from the
cryptographic algorithm. (Unless you use known-broken things like md5 or
3DES).

And I think that was in the context of some DSA or ECDSA weakness, possibly a
side channel attack or something similar. I forgot the details :(

What are your thoughts on this? Should we focus more simplicity and robustness
of the implementation, rather than just the strength of the algorithm itself?

~~~
FullyFunctional
Actually, if you ready DJB's fine papers he very much touches on this. Curve
25519 (now X25519) is specifically designed to avoid the pitfalls. The
reference implementation is not too hard to understand, but granted the
optimized versions are a little more delicate. Still, I _imagine_ the
optimized RSA implementations are no better.

------
eatbitseveryday
Maybe a more technical/comprehensive read is this[1] writeup, which I see some
others have linked to. Prior HN[2].

[1] [https://stribika.github.io/2015/01/04/secure-secure-
shell.ht...](https://stribika.github.io/2015/01/04/secure-secure-shell.html)

[2]
[https://news.ycombinator.com/item?id=8843994](https://news.ycombinator.com/item?id=8843994)

------
Locke1689
What's the problem with ECDSA?

------
tarellel
Something I found resourceful while setting up SSH on a recent server is
Mozilla's SSH Guidelines -
[https://wiki.mozilla.org/Security/Guidelines/OpenSSH](https://wiki.mozilla.org/Security/Guidelines/OpenSSH)

------
ComodoHacker
>RSA 2048: yellow recommended to change

Could someone provide a link with decent explanation why? Is it solely out of
fear that it will be cracked soon on quantum computer?

------
franciscop
Why not usimg this year as the name for the ssh? Then when you are using
_2014.pub_ or _2013.pub_ you know it's time to upgrade

------
otabdeveloper
Nobody is going to brute-force my git keys, especially when it's so trivial to
gain access to the repos via social engineering.

------
stock_toaster
github doesn't support ed25519 keys does it?

~~~
y-satellite
Just tried it out; works fine.

~~~
stock_toaster
Oh really? Last time I tried it I think it didn't.

I assume they added support for it in the meantime... Great!

------
jamiesonbecker
In Userify (ssh key manager that only distributes sudo roles and public keys
-- you keep your private keys[1]) we're going to be disallowing DSS keys soon.

I like this post - it's good advice overall. Keys are easy to handle and in
some ways more secure than certificate management (which relies on extra
unnecessary infrastructure).

1\. [https://userify.com](https://userify.com)

~~~
manyxcxi
Off topic, but I want to thank you guys again for your service. You guys make
it so freaking easy to manage access to our various servers and VMs- I can't
even remember how we used to deal with it.

~~~
jamiesonbecker
Thank you! I don't know who you are (feel free to email me @ userify.com) but
we really really really love to hear stuff like that. We are launching in AWS
Mktplace soon too btw!

------
wyclif
_the need to generate fresh ones to protect your privates much better_

Um, I'm pretty sure he meant _privacy_ , not "privates." Time for an edit.

------
sztwiorok
very good post about security!

many people still using RSA/DSA keys :/ some people are doing even worse
things. Last week I saw one man who have shared his priv key by email message!

QWERTY people have to grow up!

------
aluhut
I wish this whole SSH business would be less complicated...

~~~
minitech
The defaults are actually fine; don’t worry. You don’t need to set a
passphrase for your key, you don’t need to run an agent. Just

    
    
        ssh-keygen -t ed25519
    

and paste your public key into ~/.ssh/authorized_keys. `-t ed25519` is
optional.

~~~
Latty
> You don’t need to set a passphrase for your key

That's highly questionable advice. The passphrase is like two factor auth, it
protects you if your private key ends up in someone else's hands. That's a
risk you have to weigh up.

