How to setup ssh, key-based ("password-less") logins to a Linux/MacOSX sshd server via Windows, Linux, or MacOSX clients?

Question

How does one setup ssh, key-based ("password-less") client logins to a Linux/MacOSX sshd server via Windows, Linux, or MacOSX clients?

[Seeking both basic, conceptual understanding of key-based, ssh/sshd logins, as well an an operational example of setup for all, aforementioned operating systems.]

Answer 1

Prefer to:

1. Discuss concise fundamentals of key-encryption concept (trying to demystify the magic)
2. Apply said concepts to login-over-network (authentication) stuff
3. Provide a detailed, operational example/procedure.

1: Base encryption, authentication concepts

A public key generates encrypted data that only a private key can decrypt. Doesn't matter what this data is. [Could be a simple text file... or some sort of challenge-response authentication system (details below)... its just an encryption-decryption mechanism.] eg, somone can encrypt email content with "Johnny Utahh's" public key, and the resulting, encrypted output that can only be decrypted with Johnny Utahh's private key. So it's important that said private key is kept in a secure place (preferably not travelling over the network) in order to support "secure and private" communcation.

2: Applying said concepts to enable password-less logins

A "password-less" login is often enabled with a challenge-response authentication system. The system "getting logged into" (call it MachineA) comes up with a "question" (probably just a random string), encrypts said question with a public key associated with the "machine that wants to log in (call it MachineX)." MachineX decrypts said question and transmits the decrypted question back as an "answer" to be validated by MachineA. Once validated, MachineA grants a MachineX login (to MachineA).

This all presumes that MachineA has MachineX's public key (on Linux systems typically stored at ~/.ssh/authorized_keys of the account "getting logged into") before the above exchange happens. This is why one needs a copy of said public key at MachineA:~/.ssh/authorized_keys file. This file could also, theoretically, be named ~/.ssh/authorized__public__keys...and might proactively avoid a lot of confusion amongst many users if it were named as such...but it's presumed that "distributed" keys are public keys, and therefore we suspect the designers figured the "public" adjective might be superfluous.

3: Detailed, operational example/procedure

(Preface: This assumes the server/machine to log into has a running sshd daemon. Also, an alternative example/procedure/notes can be found at an answer to "How do I set up SSH so I don't have to type my password?", but it doesn't cover Windows clients, among other things.)

Create a key pair for the client-side (ssh) login process. On Windows, consider using PuTTYgen and create new key pair, including a public key (of course). For Linux/MacOSX, recommend ssh-keygen(1). See this example key-pair creation session ran on Unbuntu (Linux) 11.04:

joeschmo@MachineX:~$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/joeschmo/.ssh/id_rsa): 
Created directory '/home/joeschmo/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/joeschmo/.ssh/id_rsa.
Your public key has been saved in /home/joeschmo/.ssh/id_rsa.pub.
The key fingerprint is:
e8:36:69:c5:9a:d2:e3:e0:53:f3:34:d4:d0:a2:8a:80 joeschmo@MachineX
The key's randomart image is:
[... <output truncated by author to save space> ...]
joeschmo@MachineX:~$ ls -la .ssh
total 16
drwx------ 2 joeschmo joeschmo 4096 Oct 20 12:26 .
drwxr-xr-x 3 joeschmo joeschmo 4096 Oct 20 12:26 ..
-rw------- 1 joeschmo joeschmo 1679 Oct 20 12:26 id_rsa
-rw-r--r-- 1 joeschmo joeschmo  408 Oct 20 12:26 id_rsa.pub
joeschmo@MachineX:~$ cat .ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCp8nle6B68HgVQoQ8hCyQI9yKjsKnThRS0FjWsOwXId8Mc6i9E3zM0ByxBeneIFP8O42dwYmM9zwWrpP8zvpSbo0J2qIfhm+kZibClJnIIY8nVJt5AbXGdoQHOnxKOJUqP9EZgOgMqEjBNB3IVi7jPw2AXcMeZb1SCCbwsLWXzueECJP7Z4oJTU5+hD0grFMaWNhSszdpSD2Xo1hWi2fPdBu/cRMV4LTD3L7pOI57HeXS2mcLoznQohV7OV4RvDgRS9hhHi1A5/bzg9zRHJBISB0sxnwjmfz/kTaljBVZ8xtM9LenkmQYyj6B+0P+BFDAxzHIJKNOrf+i92fuLktoP joeschmo@MachineX
joeschmo@MachineX:~$ 

In above Linux exmaple, /home/joeschmo/.ssh/id_rsa contains the private key (it's just text), /home/joeschmo/.ssh/id_rsa.pub contains the public key (it's also just text). I also entered no passphrase in above example, just entering "return" for "no passphrase."

[Author's note: never used a passphrase for a public key before, but when doing so, one needs to re-enter the passphrase to "access" the public key... presumably the passphrase is encrypting the public key, but I'm not sure. If said passphrase is needed to be entered every time, then that kind of defeats the purpose of a password-less login. Maybe it's a one-time only entry? Homework for later, possibly...]

All the above procedures represent the client-side (the machine to "log in from") procedures. Now on to the server-side (the machine to "log in to") setup.

You'll need to append the id_rsa.pub contents to the ~/.ssh/authorized_keys file of the machines granting a password-less login from joeschmo@MachineX. (NOTE: make sure to turn off 'group' and 'other/world' permissions on ~/.ssh/authorized_keys, othwerise sshd typically won't read said file, presumably because it's deemed "unsecure"). NOTE: ssh-copy-id automates/simplifies this procedure.

That's it. If you want to only password-less login from one machine to another, you're done.

But...more generally...

Keep the private key on one machine (thus identifying said machine--let's call it "MachineX") and copy the public key part of the pair to every machine that will grant a login to MachineX. Thus machines A, B, C all put a copy of MachineX's public key in their respective ~/.ssh/authorized_key file to enable MachineX to login to machines A, B, and C. (Further, you can record many other public keys... from DIFFERENT key pairs, in Machine A, B, and C's respective ~/.ssh/authorized_keys to enable logins from machines other than MachineX.) eg:

Machine X pub key  --- copied to ~/.ssh/authorized_keys at -->  Machine A
Machine X pub key  --- copied to ~/.ssh/authorized_keys at -->  Machine B
Machine X pub key  --- copied to ~/.ssh/authorized_keys at -->  Machine C

The above allows a login from MachineX to login to any of A, B, or C without typing a password.

Alternatively:

Machine Y pub key  --- copied to ~/.ssh/authorized_keys at -->  Machine A
Machine Y pub key  --- copied to ~/.ssh/authorized_keys at -->  Machine B
Machine Y pub key  --- copied to ~/.ssh/authorized_keys at -->  Machine C

The above allows a login from MachineY to login to any of A, B, or C without typing a password.

Thus.... when all the above is "applied".... Machines A, B, and C all have a copy of both X and Y's public key in A, B, and C's ~/.ssh/authorized_keys.

Note also each pub/priv key pair is typically associated with a certain account on a machine (in the above cases, Machines X and Y). eg, johnnyutahh@MachineX, pappas@MachineY, etc.

In any case, the private key in a pub/priv key pair only lives on only one machine (if you're "doing it right") and never gets transported over a network. Thus it's private. Thus it's "secure." Conversely, the public key gets thrown hither and dither to the wind and gets copied all over the place.

The ~/.ssh/authorized_keys file example below has public keys from my johnnyutahh@my-laptop, [e-mail], [e-mail], joeschmo@MachineX (from ssh-keygen example above), and could contain others. Note these "addresses" at the end of each line are just comments; they're just arbitrary text to help a human figure out which key is which and aren't actually used by the any of the automated systems/programs to do anything.

root@MachineA Oct 20 02:20:12 ~# cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAyTNCV7NUBssxobBZqWormtzcUmICSeGPTSp1i48FVIAebvpgAv7Pb3lFG3vFP8e88w9zGjFnZ6GzTQEwQaTL9YJ/Q9zOvAuxjb8chJz86j9Pg+S8ic4G34c2Og8UoNbTDWYOAZaP/axpoC9W81bh0tjldPnGQuifm9ELHXMXjfGq9QazyPqOcgNG6QL7cl8TYGoj4yJxRwoSytYG65l0/bCFX8JubkFdbWDXNY4tFEfollFIlm10xzQIfz6S6I80Bu0XesFvCjgfLwiLdt+8nT7U9Tawwq8jBc1U0yisQzkSJ9UwXYcKkYX2SJMQ8Ld3Nn82wsisXcEn+Zpe3A6Usw== johnnyutahh@my-laptop
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0zPre+WkOlNgc4KzFRxGj2Y5UwG0gW+kI2LjvgwNYZLHGQqQ0GQGkmg5rulSbyx3WPo1KNCiaqafQ8fWFmXIgKreGWMwEOehnKLyXLhhxvzpYDgJhI1QbwgInLjUCj8krvsdj9fCLY6sFTYFCXLKUptJGbXThcB170kFhJCUlR33H4WfWn4NWzwpmma4HsVDR7F7eUmJE8FD+6AG4Uw9bljDaUS++XghAZ5oXUofGx7FE2vcQKdNAMF5jYIN/XbL4cj4HuJUonqYgyxCX2JpvJePEwMBW1qQffAjgtgs85217OFmfLIVL6rB3RHh1mmIHSVLtOhAZo1okg708scPCw== [e-mail]
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC84JdXtzFhQgcFj7/1pz+li2qzZSThJalddkUubuvI71i/Bk7fJ5uI8CCQDPvzr1P+HGaY//RxBG0S2jINXk4LEE1mA3Ogyo+r2ykMaqcNa2JJycHs0sdczZhZR0OOxf5KGz8hhy5W1cdhca6q0AcHmbj+KWz5N0U1qlLptMD4C45QgxtUjFYPWM7r9bDdt6kTo9J39LP4w3S1GTM9uDC8V5NUZX+lFZMap+Tch/YcEiPxAm4VaTM7CGXly+w5XpjlEVUNEb5xu51dOoOXbjueD5Vl3wdPwC6A511v2k9mD/1F4GXjRDzlelKiu4TJ9mVAI2J9+UC0iMUyYj52RO53 [e-mail]
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCp8nle6B68HgVQoQ8hCyQI9yKjsKnThRS0FjWsOwXId8Mc6i9E3zM0ByxBeneIFP8O42dwYmM9zwWrpP8zvpSbo0J2qIfhm+kZibClJnIIY8nVJt5AbXGdoQHOnxKOJUqP9EZgOgMqEjBNB3IVi7jPw2AXcMeZb1SCCbwsLWXzueECJP7Z4oJTU5+hD0grFMaWNhSszdpSD2Xo1hWi2fPdBu/cRMV4LTD3L7pOI57HeXS2mcLoznQohV7OV4RvDgRS9hhHi1A5/bzg9zRHJBISB0sxnwjmfz/kTaljBVZ8xtM9LenkmQYyj6B+0P+BFDAxzHIJKNOrf+i92fuLktoP joeschmo@MachineX
root@MachineA Oct 20 02:20:19 ~#