Generating an OpenSSH key pair
Rules and guidelines
- Always use a (strong) passphrase on your private keys!
- Use a unique private/public key pair for each username, host combination.
- It is more secure to not use a key agent or multiplexing (
ControlMaster
), as any process running on your computer can abuse those mechanisms to perform commands on hosts you were permitted to log in to.
If you fail to follow these rules and guidelines, a compromise of the server's security may actually be more likely than if we were still using fixed passwords.
Generating a new OpenSSH private/public key pair
To generate key pair, issue the following command in ~/.ssh
:
ssh-keygen -t ed25519 -C "<description>" -f <username>@<host_shorthand>
Ed25519 is the best key type as it is fast, small and particularly secure (it has all parameters set to known secure values by default). If you must use something else, use RSA with a 2048 bits key size:
ssh-keygen -t rsa -o -b 2048 -C "<description>" -f <username>@<host_shorthand>
where:
- <description> describes: your identity (suggested: your common Unix username), the date the key was generated and if possible more details.
- <username> is your OS username on the host the key pair is used to log in to.
- <hostname> is the shorthand in
~/.ssh/config
or, if absent, the canonical FQDN of the host the key pair is used to log in to.
For example:
ssh-keygen -t ed25519 -C 'sanmai 21-7-2015' -n sanmai -f ~/.ssh/sanmai@clarinvm ssh-keygen -t ed25519 -C 'sanmai -> root 21-7-2015' -n root -f ~/.ssh/root@clarinvm ssh-keygen -t ed25519 -C "willem@clarin.eu" -f wilelb@clarinvm.ics.muni.cz
This will create two new files, the private and public (same file name, with postfix .pub
) key at the specified paths:
-rw------- 1 wilelb staff 464 Jul 7 12:38 wilelb@clarinvm.ics.muni.cz -rw-r--r-- 1 wilelb staff 98 Jul 7 12:38 wilelb@clarinvm.ics.muni.cz.pub
Mac OS X
If your ssh-keygen
fails to generate keys of the Ed25519 type, install openssh
via homebrew (reference).
$ brew update $ brew tap homebrew/dupes $ brew install homebrew/dupes/openssh
Configuring an OpenSSH client and server for secure root login
Suppose you want to be able to log in to host B from host A, both as your user and as the superuser. The latter you need in case you want to use e.g. rsync
from B to A as superuser to read otherwise inaccessible files on B's filesystem. You want to use key pairs with passphrase-protected private keys and no password authentication. The only exception where passwords are at play at all, is for your OS account and sudo
. You want the barrier to log in as root to be at least as strong as logging in as your user and then performing sudo su
.
- Generate two key pairs, with base file names
root@B
andyourusername@B
. - Make sure the contents of the public keys you generated have been appended to respectively
B:/root/.ssh/authorized_keys
andB:/home/yourusername/.ssh/authorized_keys
. - Edit your OpenSSH client configuration on A to point to the file paths of these keys, for instance:
~/.ssh/config
:
Match originalhost B HostName B.Bdomain.Btld Match originalhost B user root IdentityFile "%d/.ssh/keypairs/root@B" ProxyCommand ssh yourusername@B -W %h:%p Match originalhost B user yourusername IdentityFile "%d/.ssh/keypairs/yourusername@B"
- Make sure you can log in to B as your user and that you are allowed to perform
sudo -e
. Also make sure that the OpenSSH server configuration is otherwise secure, f.i. forbidding any authentication method other thanPubKeyAuthentication
. - Now edit the OpenSSH server configuration and put at the end of the file:
/etc/ssh/sshd_config
:
PermitRootLogin no Match Address {WAN-IP-B} PermitRootLogin without-password
- Replace
{WAN-IP-B}
with the WAN IP address of B (as in, the IP address that A uses to refer to B). - Restart the OpenSSH daemon.
You now have the following setup:
Logging in
Using this setup is rather simple:
ssh yourusername@B
vs.
ssh root@B
When authenticating as root, you will be asked both the passphrase of the private key you associated with yourusername as well as that of the private key for root.
You can verify that rsync
etc. work as well, without sudo
:
rsync root@B:/etc/hostname /tmp/hostname
Final remarks
Only use the root private key when it's absolutely necessary.
This way you concentrate your activity within the easier to audit sudo
framework, and you will reduce your susceptibility to a compromise of the passphrase for root@B due to keylogging on A.
Attachments (2)
-
OpenSSH root config.svg (4.6 KB) - added by 9 years ago.
Diagram of root login
- OpenSSH root config.png (12.7 KB) - added by 9 years ago.
Download all attachments as: .zip