8

I'm trying to understand the concept of passwordless login via SSH. As far as I understand you create the SSH key pair on the computer on which you will connect FROM. Then copy the public key to the server which you will connect TO. So far so good? Correct me if I'm wrong on the basics...

I guess that would result in that the passwordless logins only can be made from my computer (where the key pair was created because thats where the private key exists).

But what if I want to be able to use passwordless logins from multiple computers to the same server? Do you need to create a key pair on each computer that will connect to the server and copy each public key to the server? How should I do?

Improve this question
1

3 Answers 3

Reset to default
14

You either follow that procedure for multiple machines or copy the private key. Depending on your personal security requirements and workflow one might be easier or "better" than the other.

If your private key is compromised you would need to remove it from the authorized_keys file and/or revoke it. In addition, depending on your workflow, you would need to enroll a new key for multiple machines. Having one key per machine would likely be more secure but also potentially more management overhead.

Improve this answer
4
  • 7
    That's why passphrasing the key and using ssh-agent, and never storing your key unpassphrased is good advice.
    – rackandboneman
    Commented Jan 2, 2020 at 20:11
  • 1
    Whilst I completely agree with having a passphrase on keys, doesn't that go against the passwordless login OP is asking about?
    – TMH
    Commented Jan 3, 2020 at 12:14
  • That would depend on your approach and requirements. With ssh-agent, as far as I know, you only need to unlock your key once (after login). It gets loaded and managed by the agent. That small bit of extra security can go a long way and certainly is less cumbersome that having to type your password on each server connection. Within the context of this question "passwordless login" probably "just" refers to a public key based login for SSH in comparison to interactive authentication with user and password.
    – Seth
    Commented Jan 3, 2020 at 12:50
  • To me, "passwordless login from multiple computers" strongly implies creating a build farm or other automated system (and will at least show up in searches for same, even if it's really not OP's intent). The advice for passwording keys that are used manually is useful, but it is still correct to acknowledge that truly passwordless will be legitimately better for certain scenarios/requirements/risk profiles.
    – GrandOpener
    Commented Jan 3, 2020 at 18:28
4

I use one key per host, the public keys have the name of the host they were generated on as a comment for that reason. You can use ssh-copy-id to install the key quickly.

If you have lots of different hosts you work on, it may be better to get a smartcard and a reader for it (there are readers in USB keyfob format, with enough space to hold the card inside), which allows you to take your private key with you easily, and makes sure it cannot be copied.

Improve this answer
1
  • im using a yubikey as a smartcard for ssh login... lots of work to get it functioning, but it is super fantastic, especially if combined with password authentication and touch-to-sign
    – Richie Frame
    Commented Jan 3, 2020 at 11:11
2

There are multiple 'passwordless' methods, some requiring copying keys around, other have different options:

SSH CA: you setup an SSH CA and distribute the CA Public Key to the servers. Then using the SSH CA's Private Key you sign the Public Keys you want to allow access to those systems that trust the CA. This has a number of benefits:

  • Additional keys don't have to be distributed over and over again
  • You can issue timed signed keys to limit the validity and thus exposure of key pairs, all without changing anything on the destination servers
  • You can limit what a user can do by adding extra parameters to a signature such as what usernames are allowed

as a downside, if you sign a public key for an indefinite period, the only way to undo that is to create a new CA or blacklist the specific public key on every individual system.

Other option: Kerberos. This is much more involved to setup (but made easier since systems like FreeIPA package it up quite nicely). Instead of logging in everywhere, you log in once which gives you a Kerberos ticket. This ticket can then be used to authenticate to various systems like websites, fileshares and SSH servers.

Your own option:

Use simple key pairs (a private key and a public key). Either copy the private key to every system you want to connect from and the public key to every system you want to connect to, or create unique pairs per system and copy every public key to every system you want to connect to.

Improve this answer
5
  • Shouldn't it be sufficient to revoke the key or does SSH not handle key revocation?
    – Seth
    Commented Jan 3, 2020 at 6:33
  • @Seth you revoke by removing the key from the keyfile
    – Richie Frame
    Commented Jan 3, 2020 at 11:15
  • You state that you'd need to create a new CA or blacklist the key on each system. But if you do have a CA issued certificate you would be able to revoke the key. In that case systems would be able to check whenever it's a valid key or not. Revocation for CAs is a defined process. See Certificate revocation list but I don't know whenever that's supported by SSH. Hence I was curious.
    – Seth
    Commented Jan 3, 2020 at 12:54
  • 1
    @Seth An SSH CA is not the same as a X509 pki CA, so no CRL or OCSP. An unofficial patch exists that does add x509 style certificates for authentication but that doesn’t use central revocation either. All of the SSH CA and kerberos systems rely or self-expiration as a security solution with (relatively) short lived signatures.
    – John Keates
    Commented Jan 3, 2020 at 13:47
  • Thanks for the clarification!
    – Seth
    Commented Jan 3, 2020 at 14:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .