
Ask HN: What are the best practises for using SSH keys? - TheCustardKing
Following the recent post about upgrading SSH keys to ED25519, I am wondering what the best practises (regarding security) for using SSH keys are.<p>For example:<p>- Is it better to use a different passphrase on each key, or does using the same one not matter much?<p>- How much less secure is it to not use a passphrase on a key?<p>- Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?<p>- Does increasing the amount of bits in a key <i>really</i> have an effect on the security of the key, or does it not make much difference in a real-world use?<p>- How&#x2F;Where should private keys be stored on a device using them?<p>- What are some of the pros and cons from a security standpoint, and how may doing different things affect the usability of a key?
======
dsl
From my experince as an attacker --

    
    
       - Is it better to use a different passphrase on each key, or does using the same one not matter much?
       - How much less secure is it to not use a passphrase on a key?
       - Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?
    

None of these things really matter that much. Make sure you use full disk
encryption and never stand up from your machine without locking it, and make
sure you keep your local machine patched. If I get code execution on your
machine, I am going to use whatever keys are loaded in your ssh-agent to
pivot, hijack your existing open sessions, or modify your ssh client to dump
the keys I need.

    
    
       - Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?
    

Key length is a protection against the future, and against state level actors.
Right now, key length doesn't matter much to me because I'm more focused on
just stealing your keys from you regardless of length.

~~~
carlesfe
Nobody seemed to answer this question, and neither did the original blog post
(besides "trust me and do it"), so maybe you can shed more light on the main
point:

Why are ED25519 keys better than RSA, how compatible are they with different
systems, and are they worth the hassle and risk of generating and using a new
one?

~~~
lisper
> Why are ED25519 keys better than RSA

Two reasons: 1) they are a lot shorter for the same level of security and 2)
any random number can be an Ed25519 key. To generate an RSA you have to
generate two large random primes, and the code that does this is complicated
an so can more easily be (and in the past has been) compromised to generate
weak keys.

~~~
carlesfe
If I understood it correctly, you're saying that RSA requires the two numbers
to be big AND random, otherwise the algorithm isn't strong? Therefore Ed25519
is better because it's strong regardless of the key?

What I don't get then is how can a short key be secure, that goes against what
I was taught in college. Aren't shorter keys more prone to collisions and
bruteforce attacks?

~~~
rosser
_Aren 't shorter keys more prone to collisions and bruteforce attacks?_

Given the same cipher, more or less, yes. Between ciphers, though, key-lengths
are less relevant, and the differences in those ciphers become more so.

EDIT: Think of it in terms of Shannon Entropy: because RSA requires a pair of
primes, the keyspace is so much sparser — that is to say, more "predictable"
(if, granted, at a mostly theoretical level) — so keys need to be that much
larger to be secure.

Contrarily, with ED25519, keys can be smaller, because the keyspace is denser.

(Or am I just talking out my ass here?)

EDIT 2: s/smaller/sparser/, s/bigger/denser/, regarding keyspaces. Thanks,
'lisper!

~~~
lisper
Not bigger -- denser.

~~~
carlesfe
Great replies, I got it now, it makes sense. Thanks to both of you!

------
daurnimator
I consider best practice to be using a hardware token.

My favoured solution is to use a yubikey via gpg: with this method you use
your gpg subkey _as_ an ssh key. The yubikey 4 supports RSA 4096 bit keys, if
you need NFC then the Yubikey Neo supports max RSA 2048 bit keys.

~~~
eeZi
This. It's so cheap and easy to use a hardware token for your GPG and SSH keys
nowadays (YubiKey 4! TPM! Smartcards!). If you're not using one, you should.

~~~
zerkten
Do you have a list of guides you recommend for getting started with YubiKey?

~~~
helper
I found this guide to be pretty comprehensive:
[https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-
yubike...](https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubikey-neo/)

------
regularfry
The first rule: never share a private keys between physical devices. Apart
from reducing the opportunities for it to go walkies in transit, or
accidentally get left on a USB stick, it allows you to revoke a single
credential if you lose (control over) that device.

From that, we get:

    
    
      - you're not sharing passphrases between keys, you're 
      sharing them between devices, and whether that's safe
       depends how likely it is that a compromised passphrase 
      on one device can be transferred by an attacker to another.
      - Similarly, whether a blank passphrase is a good idea or
       not depends on what other measures are protecting access 
      to that private key.
      - If a private key ever turns up on the wrong machine, 
      you *know* the key and both source and destination 
      machines have been compromised.

~~~
lawpoop
If I understand this properly, how do you use the same identity from two
different machines on a service like github?

If they only allow you to upload one public key per account, then you aren't
able to use that account on both your desktop and laptop, if you have separate
private keys on them, no?

Edit: Actually I just looked at github and they allow multiple keys. Is it
generally the case that any service that offers ssh keys will allow multiple
keys?

~~~
regularfry
There's no reason not to. The `authorized_keys` file on a host does exactly
that. Whether a specific service does the same is down to that service.

~~~
lawpoop
How do you revoke the keys when a machine a compromised? Log in to each
service and remove it when you become aware?

------
facetube
If you have a lot of machines, SSH certificates are supported in OpenSSH 5.6+
and are awesome: [https://www.digitalocean.com/community/tutorials/how-to-
crea...](https://www.digitalocean.com/community/tutorials/how-to-create-an-
ssh-ca-to-validate-hosts-and-clients-with-ubuntu). They allow for centralized
management of authentication/authorization without having to touch each
machine (beyond an initial trust relationship setup).

~~~
rkeene2
Additionally there is a fork of OpenSSH called PKIXSSH that supports X.509
certificates in addition to keys and OpenSSH certificates. This is useful for
using the same credential (certificate) to authenticate using other protocols
such as TLS (via TLS client certificate) and Kerberos (via PKINIT).

It supports OCSP responders as well as CRLs.

It can allow or deny access based on X.509v3 extensions.

Using this and a hardware token with an X.509 certificate you can completely
eliminate passwords for most cases and have no ability to leak your keying
material (barring HSM vulnerability).

Android and iOS devices have historically had little support for smartcards so
that's a downside of you use those devices. There's a smartcard framework in
Android but I've not used it since 4.x and it was not useful.

Support on ChromeOS, Linux, Windows, Mac OS X, Solaris, and *BSD has been a
lot more reliable.

Also, this is a fairly common usage scenario thanks to HSPD-12 and the tens of
millions of affected PKI users.

------
mlonkibjuyhv
This is probably the wrong forum, but I have a question or two that I see as
related.

I have setup a VPS, disabled passwords, and setup a key with a passphrase to
gain access. At this point my greatest worry is losing this private key, as
that means I can't access the server.

What is a reasonable way to backup my private key?

Encode it as something similar to a QR-code, print it, and store it in a hole
in the wall? Copy it to an USB-stick and hide that somewhere safe?

Alternatively, I have access to more than one computer, so I could also
authorize a couple of other keys to access the server. So I would transfer the
public key to the authorized machine, and add them to the authorizedkeys from
there?

How to deal with the possibility of death? Do I trust someone with my keys and
passphrases?

~~~
lastofus
For backing up your keys, they can be encrypted to a device with full disk
encryption, or to a mountable disk image that's encrypted, and then push that
file off site.

As for access if you lose a key, unless you somehow run a VPS that also uses
full-disk encryption (and requires a passphrase on boot), then your hosting
provider has access to your VPS.

For instance, with DO or Linode, you can log in to the admin console and reset
the root password of a server. Once done, you can use the terminal built into
the admin panel to access to the server even if SSH is disabled.

Presumably, someone could work with the provider, prove you are dead, and that
they should gain access to your servers. At that point it would come down to
the policy of the hosting provider.

~~~
cyberpunk
An account that can only login on the local ptys is a good enough backup plan.

The disk encryption doesn't buy you much in such an environment, though...
Even with whole disk encryption if you're running virtualized; then your
provider can just read your VM's memory anyway...

Unless your VPS is going to be forever shutdown, disk encryption under a
hypervisor you don't control seems reasonably pointless -- I only use it for
physical security to stop people being able to use disks they yank from
physical boxes -- even then if they were motivated enough they could probably
grab the memory from the server(s) and get the keys anyhow...

AFAIK, there is no possible protection from this besides running your own
gear. There were recently published attacks where someone managed to pull keys
from other machines by abusing some either intel or vmware's memory dedupe
tech bugs iirc (don't have the link handy) -- so; it's not even limited to
what your provider may be doing...

------
zimbatm
If you use fail2ban make sure to pin the right key to the right host.
Otherwise ssh will try all the keys and get you banned from your own host. The
easiest way is to use the ~/.ssh/config:

    
    
        Host myhost
          IdentityFile ~/.ssh/myhost

~~~
chmike
Good advise. This happenned to me. By luck I had another account I could use
to recover. I wish I could disable that feature. I use config now but the
default should not be to try every key in ssh directory.

~~~
kardos
Agreed. That seems like a weakness in OpenSSH. One should have to turn on a
"try all keys" option to get that behaviour ..

~~~
jlgaddis
Yeah, it's on by default. See _IdentitiesOnly_ to turn it off.

------
mynameislegion
The classical document about this:

[http://lackof.org/taggart/hacking/ssh/](http://lackof.org/taggart/hacking/ssh/)

------
daenney
> \- How much less secure is it to not use a passphrase on a key?

This is a question of layers. If you don't have a passphrase on your key, what
stops someone from gaining access to it? Just your account password? If they
steal your device, is there some form of storage encryption involved?

> \- Should you use a different key per user account, per server, or per use-
> case (i.e. personal or work)?

I have different keys for different purposes per client device. This is mostly
because sometimes I need to login to places that are ancient enough I need to
use a weaker key than I would like to use in other places or vice-versa,
there's places I can only login with ed25519 keys.

Though having different keys per purpose isn't necessary it allows me to keep
certain identities separate. I have a different one for GitHub for example,
mainly because GitHub exposes my public key and therefor allows for clever
tricks like tying the key to an established identity should I use that key to
authenticate in other places.

I would also recommend configuring SSH so that it doesn't send over any/all
keys by default. Take a look at the IdentitiesOnly option in ssh_config.

------
Normal_gaussian
\- Is it better to use a different passphrase on each key, or does using the
same one not matter much?

Yep in an ideal world, though I suspect in practice it doesn't matter much.

\- How much less secure is it to not use a passphrase on a key?

You are relying completely on the security of your disk, against either
physical or cyber. Use a passphrase, use an agent to manage it.

\- Should you use a different key per user account, per server, or per use-
case (i.e. personal or work)?

Per client device. This is the device that can be compromised and cause
invalidation to be required, so this is the one which should be seperate. For
convenience you can maintain all your devices public keys concatenated
together and hand them out like that - comment each with hostname and date
created for ease of identification.

\- Does increasing the amount of bits in a key really have an effect on the
security of the key, or does it not make much difference in a real-world use?

Up to a point. RSA in 8 bits is trivial. Go for a highish key length,
different key types have different recommended lengths. Note some machines
dont support higher lengths.

\- How/Where should private keys be stored on a device using them?

In $home/.ssh

Permissions should be set for only you to read with no writing. Even better if
your home drive is encrypted as it is only vulnerable whilst you are logged
in.

\- What are some of the pros and cons from a security standpoint, and how may
doing different things affect the usability of a key?

If you hop machines a lot key per client can be problematic. In this case a
portable secure drive is useful. Of course one leak can be fatal here.

Try not to fall back on passwords, they have nothing like the same security.

Most usability issues are caused by the people running the servers not
reacting in a timely fashion to key updates.

~~~
Filligree
If necessary, it's possible to fall back to password plus OTP.

That's a reasonable compromise, since you carry the OTP generator around with
you.

------
asdfaoeu
Some general advice based on most requirements.

\- Is it better to use a different passphrase on each key, or does using the
same one not matter much?

If they are being used on different device then different passphrases makes
sense otherwise no.

\- How much less secure is it to not use a passphrase on a key?

10? Not sure you can really quantify an answer. I'd recommend a passphrase if
you aren't already using disk encryption with that it's probably less of a
concern however with agents there's not much issue with not having one.

\- Should you use a different key per user account, per server, or per use-
case (i.e. personal or work)?

Use a different key per client device but you don't need a different key for
logging into different servers unless you care about people correlating those
users.

\- Does increasing the amount of bits in a key really have an effect on the
security of the key, or does it not make much difference in a real-world use?

Use more than 2048bit for RSA/DSA beyond that it doesn't matter.

\- How/Where should private keys be stored on a device using them?

~/.ssh on some local filesystem.

~~~
ptman
Don't use DSA

------
po1nter
> \- Is it better to use a different passphrase on each key, or does using the
> same one not matter much?

It is better to use a different passphrase for each key but it is also less
convenient unless you're using a password manager (personally, I'm using
KeePass)

> \- How much less secure is it to not use a passphrase on a key?

That depends on the security of the computer where the keys are. I remember a
Firefox vulnerability where one site exploiting it was looking for ssh keys on
the local file system. So I'd say that a passphrase is very important.

> \- Should you use a different key per user account, per server, or per use-
> case (i.e. personal or work)?

Personally I'm using a key per account per host.

> \- Does increasing the amount of bits in a key really have an effect on the
> security of the key, or does it not make much difference in a real-world
> use?

Yes up until 2048 where the returns of increasing the amount of bits will
start diminishing.[1]

    
    
      [1]: https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

~~~
asdfaoeu
> It is better to use a different passphrase for each key but it is also less
> convenient unless you're using a password manager (personally, I'm using
> KeePass)

If you are going to use a password manager to store them there's no point in
using different passphrases.

~~~
daenney
Why not? Granted the passphrase are in one place but as long as your password
store doesn't get compromised managing to brute force a key's password then
only gives you access to the machine(s) that one key is accepted on.

Also, the keys don't have to reside on the same device the password store is
on. If you have one key per client device for example.

~~~
eddieroger
Because if your password manager is compromised, so are all of the passphrases
stored in it. So what would the point, then, be of using different ones?

~~~
a3n
So because a password manager is one-stop shopping (something that I'm
subconsciously uneasy about, to be sure), it's pointless to use different
passphrases, one of the major selling points of password managers.

So to protect against that, don't use a password manager. Which means that
you're more likely to re-use passphrases, because lots of them are hard to
remember and keep straight. So breaking one gets access to many others.

My head spins.

~~~
vitus
I was originally going to post something along these lines, but then I
realized that this argument doesn't work the same in this particular context,
and the parent isn't necessarily arguing against password stores in general.
Sure, it might be better (in the sense of not concentrating your risk to a
single file) to have a strong (importantly, private) scheme for creating
passwords (say, based on the site and account name). But if you're restricted
to some inane restrictions ("6-10 alphanumeric characters"), then there's not
really a strong argument against a password manager in this case.

Sure, in general, you want to avoid password reuse to isolate password
compromises / security breaches (some companies are still storing passwords in
plaintext in 2016, ugh). But in this case, we're talking about private keys
that should never leave your local machine. If those are compromised (even
passphrase-protected), then it's not inconceivable to think that your password
store might also be compromised.

~~~
a3n
> he parent isn't necessarily arguing against password stores in general.

Yeah, reliazed that, my post was just my "logical" progression.

------
zimbatm
> How much less secure is it to not use a passphrase on a key?

It's better to think about specific attack scenarios. If your keys get
exfiltrated because of some local exploit (like a browser vulnerability, a
malware download or physical access) then the attacker has access to your
servers.

~~~
nothrabannosir
the same holds for keys with passphrases; the attacking process just has to
wait until you enter it.

~~~
berdario
As I mentioned in my other comment: stealing local files does not necessarily
have to happen via unrestricted-RCE (which would allow you access to the ssh
agent)

~~~
Godel_unicode
This, for instance.

[http://m.theregister.co.uk/2013/01/25/github_ssh_key_snafu/](http://m.theregister.co.uk/2013/01/25/github_ssh_key_snafu/)

------
steventhedev
It depends heavily on your threat model. Just about any key is an improvement
over using passwords to authenticate. If you want protection from state-level
actors, you need to be really careful and consistent.

Regarding key types:

\- DSA keys (ssh-dss) suffer from several issues (fewer bits, bad RNGs in
Debian, other issues), and modern versions of OpenSSH deprecate it.

\- RSA is pretty standard, and generally speaking is fairly secure for key
lengths >=2048. RSA-2048 is the default for ssh-keygen, and is compatible with
just about everything.

\- ECDSA is largely considered compromised because the constants NIST chose
for the cryptosystem weren't well documented how they got them, and the
assumption is that the NSA chose them to provide a "backdoor" (so it would
provide the same security for a general attacker, but significantly easier for
them). This was confirmed as being theoretically possible, and there is of
course concern that the NSA could potentially leak those constants, instantly
breaking the security of this cryptosystem.

\- ED25519 is more or less the same as ECDSA, but was put together by DJB. The
big advantage here is speed. EC crypto is much faster to sign, slightly slower
to verify, and equivalent security can be achieved with fewer key bits.

\- Notes for the future: both RSA and ED25519 become insecure against quantum
computing (integer factorization and discrete log are both in BQP).

Generally, use RSA if you work with older servers that only support it, or
ED25519 if you like shiny things. Otherwise it's a bit of a tossup.

Regarding using separate keys:

\- I follow the philosophy that a private key should _never_ leave the host it
was generated on. If you aren't sharing keys between machines, you remove the
risk that you'll accidentally share it publicly.

\- Beyond that, I'd recommend at a minimum having separate work/personal keys.
Keeping separate keys for each user/host you want to log into is a tad
excessive, but can be useful for key revocation/rotation.

Regarding passphrases on keys:

\- _Yes_. FDE is sometimes trivial to bypass, and you want to be protected in
case someone sets your ~/.ssh folder to be synced to dropbox/samba/etc. You
can use an agent to keep the decrypted keys in memory, but I'd avoid using
agent forwarding.

Regarding bastion hosts:

\- You didn't ask about this, but it is essential for a "best practice" setup.

\- Bastion hosts are small VPS hosts that basically run sshd and have a static
IP. You disallow any ssh traffic except from your bastion hosts to your
servers.

\- You'll want to have at least 2 bastion hosts with different hosting
services, in case one isn't available.

\- Run sshd on your bastion host on a port other than 22. Not for security,
but for reducing log volume.

\- Run fail2ban on your bastion host, even if you've disabled password authn.
Again, not for security, but for reducing log volume.

\- Set up fail2ban to alert when a new IP successfully logs in.

Other stuff:

\- SSH can use certificates for authentication, and this can make the key
distribution problem much easier to solve. I have a script that makes this
easier.

\- Push for everyone in your organization to use SSH keys, and only SSH keys.

\- Defense in depth. All it takes is skipping one step and you expose
yourself. Assume that something that was exposed has been compromised. An
attacker only needs to succeed once.

tl;dr - the defaults are fine and password protect your keys.

------
jijojv
From a pragmatic end-user perspective.

1) Disable passwords and only allow keys even for root with PermitRootLogin
without-password

2) public-key authentication has somewhat unexpected side effect of preventing
MITM per this security consulting firm [http://www.gremwell.com/ssh-mitm-
public-key-authentication](http://www.gremwell.com/ssh-mitm-public-key-
authentication)

------
mixmastamyk
I upgraded to ed209 the other day as well.

Two questions came up, how many iterations to use via "-a ", and should I add
the private key to my home folder repo in version control? I don't want to
lose it in a disk crash, but don't want to give it to bithub either.

------
jamiesonbecker
> Is it better to use a different passphrase on each key, or does using the
> same one not matter much?

Using a passphrase is _highly_ recommended except for server-to-server
accounts, which should be locked down (and specify the specific command that
server can execute in the authorized_keys file - Userify[1] supports this).

You should _definitely_ use a different passphrase for keys stored on separate
computers, and it's not a bad idea to use a different passphrase for separate
keys stored on the same computer, especially if they have different servers
they can access. However, practically speaking, if your computer was
compromised (ie keylogger etc) then it's game over anyway.

> Does increasing the amount of bits in a key really have an effect on the
> security of the key, or does it not make much difference in a real-world
> use?

Yes, it does make a difference, depending on what you mean by "real-world".
Anyone less than a state-level actor will probably be unable to cost-
effectively attack even a 1024 bit key, but that won't be true for long. We
suggest 2048 bit keys if you are using RSA, with 4096 if you prefer extra
security and don't mind slight latency during a connection, or ED25519 for
keys on systems that support it. Generally the defaults are pretty good. We
have a HOWTO for different OS's here: [https://userify.com/docs/generating-
ssh-keys-on-ec2/](https://userify.com/docs/generating-ssh-keys-on-ec2/)

> How much less secure is it to not use a passphrase on a key?

From the server's perspective, it's EXACTLY the same, but from the client
(your laptop's) side, it's completely different. While it's possible that your
laptop could still contain your decrypted key in its key manager's RAM or
suspended state (ie unencrypted swap file etc), the use of a passphrase even
on (actually, ESPECIALLY on) a non-full-disk encrypted system will raise the
level of effort to access your key to near-impossibility levels, especially
from non-state actors, whereas a key that has NO passphrase is a piece of
cake. Use a passphrase EVEN WITH full disk encryption (for example, the evil
maid attack)

> Should you use a different key per user account, per server, or per use-case
> (i.e. personal or work)?

If you're using a different key and storing them on different computers, you
should probably use a different passphrase on each key. The passphrase (or
even if one exists) is not visible to remote servers (or Userify[1] - we
provide a free-text field that becomes your authorized_keys on remote
servers.)

You don't need to use a different key per user account, although you can. You
also should not use a different key per server.. that will turn into a
management nightmare. It's perfectly ok to use one key everywhere, but you
should probably use a different key on your laptop and desktop, or if the keys
have different levels of access (Userify[1] can automate that for you too).

> How/Where should private keys be stored on a device using them?

Ideally on a device using full-disk encryption, including swap and laptop
suspend space, to prevent access to a decrypted key in RAM (you are using a
passphrase, right?). However, FDE does not protect you from other compromises
on your system (i.e., another user that gains escalation to root and installs
a key logger), and does not protect against a compromise of your BIOS (i.e.,
Intel UEFI) or boot process (evil maid attack again).

> What are some of the pros and cons from a security standpoint, and how may
> doing different things affect the usability of a key?

Keys are safer than certificates because there are less moving parts and no
outside requirements for your internal CA or dependency on a CA that might go
down. Keys can be a management nightmare at scale, but there is software to
manage them (ie Userify[1], ManageEngine[2], BeyondTrust[3], ssh universal key
manager[4], keybox[5] (free/open source), etc). If you are doing a small
project with few team members, you can also do management with Chef, Puppet,
etc, or just by hand.

In terms of usability, a real key solution that manages keys across entire
groups of servers with a few clicks can be really helpful... you can do all of
the regular SSH things like tunneling (replace stun/sslwrap, etc), proxying
all of your other traffic (SOCKS5), keep SSH connection alive (autossh etc),
smart ban based on failed attempts (fail2ban, deny hosts), forward encrypted
X11 or VNC connections, forward SSH itself (tunnel SSH within itself), and so
much more.

We're going to start blogging about all the awesome things you can do with SSH
soon, since it's really an amazing and deep protocol.

1\. Userify [https://userify.com](https://userify.com) Free cloud and on-
premises versions available; full disclosure: I work there

2\. ManageEngine:
[https://www.manageengine.com/](https://www.manageengine.com/)

3\. BeyondTrust: [https://www.beyondtrust.com/](https://www.beyondtrust.com/)

4\. SSH Universal Key Manager: [http://www.ssh.com/](http://www.ssh.com/) (no
TLS?)

5\. Keybox [http://sshkeybox.com/](http://sshkeybox.com/)

------
Tharkun
If you use multiple identities, and want to reduce the odds of accidentally
using the wrong one, then having different passwords is a good idea.

------
gupi
I would also recommend using two-factor authentication (see services like Duo
or Twilio's Authy) along with password-protected keys.

~~~
fragmede
Absolutely use 2FA, but it's no guarantee.

With large scale hacks in mind and apropos of the Yahoo hack, an attacker has
_miniscule_ chances of getting into _your_ account, but 500 million accounts /
a 6-digit auth code means with a full compromise (ie, username and plaintext
passwords, which the Yahoo compromise was _not_ ), the attacker would still
get into 5 accounts.

Given how much full email access is "keys to the kingdom" given password
resets, thats the ( _tiniest_ ) bit worrying.

------
benkaiser
Relevant xkcd: [https://xkcd.com/538/](https://xkcd.com/538/)

------
xaduha
[https://github.com/philipWendland/IsoApplet](https://github.com/philipWendland/IsoApplet)
\+ some blank java cards + card reader. Something about Yubico rubs me the
wrong way.

~~~
mugsie
Use a GPG Card - much simpler than acquiring blank Java cards.

~~~
xaduha
And what is hard exactly about acquiring blank Java cards? Not harder than
ordering anything else over the Internet.

~~~
mugsie
Well, finding a reliable seller in Europe seems to be hard.

~~~
xaduha
We live in the age of globalization, these guys better be delivering
worldwide, they ask $25 for it.

[http://javacardos.com/store](http://javacardos.com/store)

Or if you have a friend that knows Russian you can use this [http://www.smart-
card.ru/_catalog/?search=jcop](http://www.smart-card.ru/_catalog/?search=jcop)

------
anonymousDan
What about for the host key of the server (assuming ssh2)?

~~~
jlgaddis
RSA and Ed25519 only, in my opinion. Don't use DSA or ECDSA.

------
sztwiorok
Most important is - keep it safe

Passphrase is strongly advised

------
yellowapple

        Is it better to use a different passphrase on each key, or does using the same one not matter much?
    

If the keys are for the same thing (i.e. your personal `id_rsa` and
`id_ed25519`), then I'd personally be comfortable with the same passphrase.
Different passphrases should be used for different purposes (e.g. you
shouldn't use your personal passphrase on work-specific keys).

    
    
        How much less secure is it to not use a passphrase on a key?
    

Depends on the situation. I personally err on the side of caution and use a
passphrase on all keys unless it's not physically possible.

If you expect to be moving your SSH keys across machines (e.g. to use your
same personal key on both your laptop and your desktop), then they should
absolutely be passphrase-protected, even if they're only transferred via
encrypted media.

    
    
        Should you use a different key per user account, per server, or per use-case (i.e. personal or work)?
    

There's not really a right or wrong answer to this besides "don't reuse the
same key everywhere". I personally maintain one key (really two: one RSA, one
ED25519) for all of my personal devices, and maintain a strict policy of full-
disk encryption on such devices. I've occasionally maintained separate work
keys so that I'm not ever in a position where I need to make my personal keys
available to an employer.

Meanwhile, for situations where a server needs to connect to another machine
via SSH, each such server gets its own key. That way, if a server is
compromised or decommissioned, I can revoke access by key.

    
    
        Does increasing the amount of bits in a key really have an effect on the security of the key, or does it not make much difference in a real-world use?
    

It makes a significant difference. More bits → exponentially more attempts
required to brute-force it.

    
    
        How/Where should private keys be stored on a device using them?
    

Depends on the device.

A reasonable balance between security and practicality is for any portable
media (including portable devices, like laptops/tablets/phones) to be
encrypted (in addition to the key itself being passphrase-protected). Better
security would be to extend this to non-portable media and machines as well
(but this is painful to enforce on servers unless you have physical access).

The directory in which keys are stored should only be accessible to the OS
user actually using those keys (so, for example, `~/.ssh` should have
permissions `drwx------` when viewing with `ls -la`).

Basically, server SSH keys should be treated like you'd treat your SSL/TLS
keys.

    
    
        What are some of the pros and cons from a security standpoint
    

...of?

    
    
        and how may doing different things affect the usability of a key?
    

Pretty much everything involves security v. convenience tradeoffs. Generally,
the more secure, the less convenient, and vice versa. While absolute security
is ideal, a lack of convenience makes it more difficult to effectively enforce
(e.g. as part of a company-wide security policy) unless you're willing to put
in the work to build up an effective workflow around it.

------
sztwiorok
I agree with following comment.i was wrong. Thanks asdfaoeu for it.

~~~
asdfaoeu
> Private key is a "password", we need to treat it as such!

This is harmful advice in my opinion. A key has sufficient entropy to resist
brute force attacks and is never directly exposed to a server. The same key
between multiple servers is fine.

------
gregorygraf
i can recommend this link:

Upgrade your SSH keys! [https://blog.g3rt.nl/upgrade-your-ssh-
keys.html?_utm_source=...](https://blog.g3rt.nl/upgrade-your-ssh-
keys.html?_utm_source=1-2-2)

