Changes between Version 5 and Version 6 of SystemAdministration/Security/OpenSSH


Ignore:
Timestamp:
07/21/15 12:54:21 (9 years ago)
Author:
Sander Maijers
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SystemAdministration/Security/OpenSSH

    v5 v6  
    88== Generating a new ssh private/public key pair ==
    99
     10
    1011Issue the following command in '~/.ssh':
    1112{{{
    12 # using ed25519:
    13 ssh-keygen -t ed25519 -C "<email>" -f <username>@<hostname>
     13ssh-keygen -t ed25519 -C "<description>" -f <username>@<host_shorthand>
     14}}}
    1415
    15 #using rsa 4096 bits:
    16 ssh-keygen -t rsa -b 4096 -C  "<email>" -f <username>@<hostname>
     16Ed25519 is advised as it is fast, small and particularly secure (has all paraneters set to known secure values by default). If you must use something else, use RSA:
     17{{{
     18ssh-keygen -t rsa -o -b 2048 -C  "<description>" -f <username>@<host_shorthand>
    1719}}}
    1820where:
    19  * <email> is your email address, this will be included as a comment and allows the administrators to contact you in case of questions.
    20  * <username> is your username on the server
    21  * <hostname> is the fully qualified hostname of the server
     21 * <description> describes: your identity (suggested: your common Unix username), the date the key was generated and if possible more details.
     22 * <username> is your OS username on the host the key pair is used to log in to.
     23 * <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.
    2224
    23 == Example ==
     25For example:
     26{{{
     27ssh-keygen -t ed25519 -C 'sanmai 21-7-2015' -n sanmai -f ~/.ssh/sanmai@clarinvm
    2428
    25 In order to generate a key pair for user 'wilelb' with the email adress 'willem@clarin.eu' on the 'clarinvm.ics.muni.cz' server, the following command would be used:
    26 {{{
     29ssh-keygen -t ed25519 -C 'sanmai -> root 21-7-2015' -n root -f ~/.ssh/root@clarinvm
     30
    2731ssh-keygen -t ed25519 -C "willem@clarin.eu" -f wilelb@clarinvm.ics.muni.cz
    2832}}}
    2933
    30 This will create two new files, the private and public (.pub) key, in your current working directory:
     34This will create two new files, the private and public (same file name, with postfix `.pub`) key at the specified paths:
    3135{{{
    3236-rw-------  1 wilelb  staff    464 Jul  7 12:38 wilelb@clarinvm.ics.muni.cz
     
    3438}}}
    3539
    36 == OSX ==
     40== Mac OS X ==
    3741
    38 If ed25519 is not available on OSX, install `openssh` via homebrew ([http://epocsquadron.com/a-comprehensive-ssh-key-primer/ reference]).
     42If Ed25519 is not available on your computer, install `openssh` via homebrew ([http://epocsquadron.com/a-comprehensive-ssh-key-primer/ reference]).
     43
     44{{{
     45$ brew update
     46$ brew tap homebrew/dupes
     47$ brew install homebrew/dupes/openssh
     48}}}
    3949
    4050= Configuring an OpenSSH client and server for secure root login =
     
    4252Suppose 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`.
    4353
    44 Generate two key pairs, with base file names `root@B` and `yourusername@B`.
    45 
    46 Edit your OpenSSH client configuration on A to point to the file paths of these keys, for instance:
     54* Generate two key pairs, with base file names `root@B` and `yourusername@B`.
     55* Make sure the contents of the public keys you generated have been appended to respectively `B:/root/.ssh/authorized_keys` and `B:/home/yourusername/.ssh/authorized_keys`.
     56* Edit your OpenSSH client configuration on A to point to the file paths of these keys, for instance:
    4757`~/.ssh/config`:
    4858{{{
     
    5666}}}
    5767
    58 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 than `PubKeyAuthentication`.
    59 Now edit the OpenSSH server configuration and put at the end of the file:
     68* 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 than `PubKeyAuthentication`.
     69* Now edit the OpenSSH server configuration and put at the end of the file:
    6070`/etc/ssh/sshd_config`:
    6171{{{
     
    6676}}}
    6777
    68 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.
     78* Replace `{WAN-IP-B}` with the WAN IP address of B (as in, the IP address that A uses to refer to B).
     79* Restart the OpenSSH daemon.
    6980
    7081You now have the following setup:
    7182
    72 [[Image(https://trac.clarin.eu/attachment/wiki/ssh_key/OpenSSH%20root%20config.png)]]
     83[[Image(OpenSSH root config.svg)]]
    7384
    7485== Logging in ==
    7586Using this setup is rather simple:
    7687`ssh yourusername@B`
    77 or
     88vs.
    7889`ssh root@B`
    7990
    8091When authenticating as root, you will be asked both the passphrase of the private key you associated with yourusername as well as that or the private key for root.
    81 
     92You can verify that `rsync` etc. work as well, without `sudo`:
    8293`rsync root@B:/etc/hostname /tmp/hostname`
    8394
     
    8596'''Only use the root private key when it's absolutely necessary.'''
    8697
    87 This way you concentrate your activity within the easier to audit sudo framework, and you will reduce your susceptibility to compromise of the passphrase for root@B by means of keylogging on A.
    88 
    89 {{{
    90 $ brew update
    91 $ brew tap homebrew/dupes
    92 $ brew install homebrew/dupes/openssh
    93 }}}
     98This 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.