ssh-keygen

ssh-keygen is a utility for creation of the public-private key pair.  Typically use to regenerate RSA keys:

ssh-keygen -t rsa

• office environment
• private systems
• Internet service provider (ISP) systems
• university account

To use public key authentication, the public key of the user has to be stored on the server in the home directory of the user account being accessed. These public keys are stored on the server in the file ~/.ssh/authorized_keys.

The corresponding private key must be stored on the client computer. With the keys stored in the appropriate places, the following occurs during the authentication process:

1. The client informs the server which public key is being used for authentication.
2. The server checks to see if the public key is known.
3. The server encrypts a random number using the public key and  transfers this to the client.
4. Only the client is able to decrypt the random number with its private key.
5. The client sends the server an MD5 checksum that it has  calculated from the number.

Creating a Passphrase

Instead of using a password to authenticate, OpenSSH allows the use of a passphrase. Why use a passphrase? Unlike a password, a passphrase can contain spaces and tabs and is usually much longer than a password, hence the word phrase in the name. The added length along with the spaces and tabs makes a passphrase more secure and harder to guess.

Passphrases are unique per user and must be created by each user while logged in with the corresponding username. Most modern Linuxes uses SSH Protocol 2 and RSA keys by default. To generate an RSA key pair for SSH version 2, use the following command:

ssh-keygen -t rsa

Press Enter to accept the default location of $HOME/.ssh/id_rsa after the key pair is generated. When prompted for a passphrase, type a passphrase to use and type it again to confirm. The passphrase should be different from the user's password and should contain a combination of numbers and letters to make it more secure. Remember it can contain spaces and tabs. The RSA public key is then written to $HOME/.ssh/id_rsa.pub while the private key is written to $HOME/.ssh/id_rsa.

Note:  The private key file should never be accessible by anyone other than the user who created it. It is created with read-write file permissions for the user (600) only. These permissions should never be altered.

After successfully generating the key pair, copy the contents of the public key file $HOME/.ssh/id_rsa.pub to $HOME/.ssh/authorized_keys on all the systems you want to connect to with the SSH.

If the authorized_keys file already exists, append it with the contents of $HOME/.ssh/id_rsa.pub. If the .ssh/ directory does not exist in your home directory on the remote systems, it must be created so that only you, the owner, can access it.

To change the permissions for it, execute the command chmod 0700 $HOME/.ssh on the remote system. The $HOME/.ssh/authorized_keys file on each remote system must have the same permissions as the $HOME/.ssh/id_rsa.pub file created by ssh-keygen.

Change its permissions with the chmod 644 $HOME/.ssh/authorized_keys command on each remote system to which you will be connecting.

After creating an RSA key pair and distributing the public key to the remote systems, when the ssh <hostname> command is executed, the user will be prompted for the passphrase used to create the key pair instead of being prompted for a password for authentication.

Instead of entering the passphrase each time you connect to a remote system, the ssh-agent utility from the openssh-clients package can be used to remember the passphrase.

Additionally, if a graphical desktop is used and the openssh-askpass package is installed, the desktop can be configured to prompt the user for the passphrase after the user logs in to the graphical interface. While that graphical login session is active, the passphrase will be remembered for all terminals opened within that graphical session. To configure ssh-agent as a startup program, use the following steps:

The next time the user logs in to the GUI, a dialog window will appear prompting the user for the passphrase. If the correct passphrase is entered, the user will not have to type the passphrase again when connecting to systems that contain the corresponding $HOME/.ssh/authorized_keys file.

If a graphical interface is not being used, the passphrase can be remembered by executing the following commands:

exec /usr/bin/ssh-agent $SHELL
ssh-add

After you enter the correct passphrase, it will be remembered for that session or terminal window.

Procedure

1. We assume that the user name is the same in both machines.

2. The user keys will be stored in ~/.ssh in both machines.

3. At the client, run 'ssh-keygen -t dsa' to generate a key pair. Accept default options by pressing return. Specially, do not enter any passphrase. (Option -d seems to be an alias of -t dsa in some platforms).

4. Change the permissions of the generated .pub file to 600 by commanding chmod 600 id_dsa.pub

5. Copy the public key to the server with scp id_dsa.pub 'user@server:~/.ssh/authorized_keys'. (Caution: if that destination file already exists on the server, copy first to a different file foo and then append the contents with cat foo >> authorized_keys executed on the server).

6. Done! Verify that now you can connect directly from the client with ssh user@server without being prompted for a password.

7. If it doesn't work, verify that in the server your home directory, the .ssh subdirectory, and the authorized_keys file do not have writing permissions to others. If they do, they won't be considered to grant access. You can correct this with something like:

 chmod 755 ~
 chmod 700 ~/.ssh
 chmod 600 ~/.ssh/authorized_keys

8. If it still doesn't work, try changing the authorized_keys file name to authorized_keys2, or ask your system administrator what file name is ssh actually using.

9. If it worked, you can now run SCP in batch mode with the -B option, as in scp -B foofile 'user@server:~/foodir/'.

Some of the important options

Changing passphase in existing key

Option -p requests changing the passphrase of a private key file instead of creating a new private key.

If you in addition changed sshd configuration you need to restart ssh server. This won't kill existing sessions

/etc/init.d/ssh restart

Files Used by SSH-Keygen utility

The SSH-Keygen utility uses various files for storing public and private keys. The files used by SSH-Keygen utility are as follows:

• $HOME/.ssh/identity: The $HOME/.ssh/identity file contains the RSA private key when using the SSH protocol version 1.

• $HOME/.ssh/identity.pub: The $HOME/.ssh/identity.pub file contains the RSA public key for authentication when you are using the SSH protocol version 1. A user should copy its contents in the $HOME/.ssh/authorized_keys file of the remote system where a user wants to log in using RSA authentication.

• $HOME/.ssh/id_dsa: The $HOME/.ssh/id_dsa file contains the protocol version 2 DSA authentication identity of the user.

• $HOME/.ssh/id_dsa.pub: The $HOME/.ssh/id_dsa.pub file contains the DSA public key for authentication when you are using the SSH protocol version 2. A user should copy its contents in the $HOME/.ssh/authorized_keys file of the remote system where a user wants to log in using DSA authentication.

• $HOME/.ssh/id_rsa: The $HOME/.ssh/id_rsa file contains the protocol version 2 RSA authentication identity of the user. This file should not be readable by anyone but the user.

• $HOME/.ssh/id_rsa.pub: The $HOME/.ssh/id_rsa.pub file contains the protocol version 2 RSA public key for authentication. The contents of this file should be added to $HOME/.ssh/authorized_keys on all computers where a user wishes to log in using public key authentication.

NEWS CONTENTS

• 20110611 : ssh-keygen password-less SSH login ( ssh-keygen password-less SSH login, Jun 11, 2011 )
• 20110610 : HOWTO set up ssh keys ( HOWTO set up ssh keys, Jun 10, 2011 )

Old News ;-)

[Jun 11, 2011] ssh-keygen password-less SSH login

SSH is often used to login from one system to another without requiring passwords.

A number of methods may be used for that to work properly, one of which is to setup a .rhosts file (permission 600) with its content being the name of the remote system you trust, followed by the username your trust:

nickel.sao.nrc.ca cantin

would mean you trust user cantin from nickel.sao.nrc.ca to connect to your account, without requiring a password.

But for that to work, SSH itself must be configured to trust .rhosts files (which it does not for most OpenSSH installations - but we do on most systems RCSG maintains), and the private/public key pair of each system must be properly set in the system-wide ssh_known_hosts public key file.

This, of course, requires help from the local systems administrator.

The second method does not require any help from the systems administrator. And it does not require modifications to the .rhosts file. Instead, it requires you generate your own personal set of private/public pair.

ssh-keygen is used to generate that key pair for you. Here is a session where your own personal private/public key pair is created:

cantin@sodium:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/cantin/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/cantin/.ssh/id_rsa.
Your public key has been saved in /home/cantin/.ssh/id_rsa.pub.
The key fingerprint is:
f6:61:a8:27:35:cf:4c:6d:13:22:70:cf:4c:c8:a0:23 cantin@sodium

The command ssh-keygen -t rsa initiated the creation of the key pair.

No passphrase was entered (Enter key was pressed instead).

The private key was saved in .ssh/id_rsa. This file is read-only and only for you. No one else must see the content of that file, as it is used to decrypt all correspondence encrypted with the public key.

The public key is save in .ssh/id_rsa.pub.

In this case, the content of file id_rsa.pub is

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEArkwv9X8eTVK4F7pMlSt45pWoiakFkZMw
G9BjydOJPGH0RFNAy1QqIWBGWv7vS5K2tr+EEO+F8WL2Y/jK4ZkUoQgoi+n7DWQVOHsR
ijcS3LvtO+50Np4yjXYWJKh29JL6GHcp8o7+YKEyVUMB2CSDOP99eF9g5Q0d+1U2WVdB
WQM= cantin@sodium

It is one line in length.

Its content is then copied in file .ssh/authorized_keys of the system you wish to SSH to without being prompted for a password.

The example shown here generated keys on sodium by user cantin. If the public key generated, file .ssh/id_rsa.pub, was copied to your account, file .ssh/authorized_keys on nickel.sao.nrc.ca, then user cantin@sodium is allowed to SSH into your own account on nickel.sao.nrc.ca without the use of a password.

To summarize, a personal private/public key pair is generated using the ssh-keygen command. The public key is then copied onto a remote systems' .ssh/authorized_keys file. And you can now SSH to the remote systems's account without the use of a password.

[Jun 10, 2011] HOWTO set up ssh keys

Paul Keck, 2001

Getting Started

1. First, install OpenSSH on two UNIX machines, hurly and burly. This works best using DSA keys and SSH2 by default as far as I can tell. All the other HOWTOs I've seen seem to deal with RSA keys and SSH1, and the instructions not surprisingly fail to work with SSH2.
2. On each machine type ssh somemachine.example.com and make a connection with your regular password. This will create a .ssh dir in your home directory with the proper perms.
3. On your primary machine where you want your secret keys to live (let's say hurly), type

ssh-keygen -t dsa

This will prompt you for a secret passphrase. If this is your primary identity key, make sure to use a good passphrase. If this works right you will get two files called id_dsa and id_dsa.pub in your .ssh dir. Note: it is possible to just press the enter key when prompted for a passphrase, which will make a key with no passphrase. This is a Bad Idea ™ for an identity key, so don't do it! See below for uses of keys without passphrases.

scp ~/.ssh/id_dsa.pub burly:.ssh/authorized_keys2

Copy the id_dsa.pub file to the other host's .ssh dir with the name authorized_keys2.

Now burly is ready to accept your ssh key. How to tell it which keys to use? The ssh-add command will do it. For a test, type

ssh-agent sh -c 'ssh-add < /dev/null && bash'

This will start the ssh-agent, add your default identity(prompting you for your passphrase), and spawn a bash shell. From this new shell you should be able to:

ssh burly

This should let you in without typing a password or passphrase. Hooray! You can ssh and scp all you want from this bash shell and not have to type any password or passphrase.

Using X Windows

Now this is all well and good, but who wants to run their whole life from a single bash instance? If you use an X window system, you can type your passphrase once when you fire up X and all subprocesses will have your keys stored.

1. In the ~/.xinitrc file, modify your line which spawns windowmaker to read:

exec ssh-agent sh -c 'ssh-add </dev/null && exec /usr/local/bin/wmaker'

This will prompt you for your passphrase when you start up X, and then not again. All shells you spawn from X will have your keys stored.

This brings up a security issue- if someone comes upon your X session, they can spawn ssh sessions to burly and other hosts where you have put your id_dsa.pub information into the authorized_keys2 file. A locking screensaver like xlock is vital.

Different usernames

By default ssh assumes the same username on the remote machine. If you have a different username on the other machine, follow the normal ssh procedure:

[pkeck@hurly /]$ ssh -l paulkeck burly

More keys!

You are not limited to one public key in your authorized_keys2 file. Append as many as you like! If you, say, generated a unique private key on every machine you log into, and then appended the id_dsa.pub files to each of the other machines' authorized_keys2 file, you'd have the equivalent of a .rhosts file with two added benefits:

• Someone would need to know your passphrase to use it, so a cracker gaining access to an account on one machine will not jeopardize the other accounts. (If you foolishly use the same passphrase or, heaven forbid, id_dsa file on all the hosts, it would make it easier to exploit, so don't do that.)
• Traffic is encrypted.

This command will do it without requiring an scp and vi session:

cat foo.pub |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'

Single-purpose keys

So now you're sshing and scping your brains out. Sooner or later you'll come across one or both of these situations:

1. You want to automate some ssh/scp process to be done after hours, but can't because no one will be around to type the passphrase.
2. You want to allow an account to do some sort of ssh/scp operation on another machine, but are hesitant to append a key to your authorized_keys2 file because that essentially "opens the barn door" to anything that other account wants to do, not just the one operation you want to let it do. (This is the situation if you use a .shosts file.)

Single-purpose keys to the rescue!

1. Make yourself another key:

   ssh-keygen -t dsa -f ~/.ssh/whoisit

   Just press return when it asks you to assign it a passphrase- this will make a key with no passphrase required. If this works right you will get two files called whoisit and whoisit.pub in your .ssh dir.

2. cp ~/.ssh/whoisit.pub tempfile

   We want to work on it a little. tempfile should consist of one really long line that looks kind of like this:

   ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== [email protected]
   

3. Edit tempfile and prepend some things to that line so that it looks like this:

   command="echo I\'m `/usr/ucb/whoami` on `/usr/bin/hostname`",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== whoisitnow
   

   That will do what we want on Solaris; to try this example on Linux use this:
   

   command="echo I\'m `/usr/bin/whoami` on `/bin/hostname`",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3NzaC1k[...]9qE9BTfw== whoisitnow
   

   The stuff to prepend is your command that will be run when this key is activated, and some options to keep it from being abused (hopefully). The last thing on the line is just a comment, but you probably want to set it to something meaningful.

   Also, most examples I see use no-pty as an additional option, but this messes up the carriage-return/linefeediness of the output of the above example. (Try it.) I haven't looked into it enough to see why you would want it, but there you go.

4. cat tempfile |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'

   Append tempfile to your authorized_keys2 file on burly.

5. To "activate" (or perhaps "detonate") the key from hurly (or anywhere that has the secret key), do this (maybe there is a better way?):
   ssh -i ~/.ssh/whoisit burly

   The following also works but is cumbersome:
   ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && ssh burly'

   You can also append this "command key" to a different account's authorized_keys2 file and trigger it from a different username. You just need the secret key. Like so:
   ssh -i ~/.ssh/whoisit -l paulkeck burly'

   The next leap in the pattern is something like this:
   ssh -i /home/pkeck/.ssh/whoisit -l paulkeck burly'

   This could be run by any user on the box if they could read your secret key, so always keep your .ssh dir and all your keys chmodded to 700 and 600 respectively.

6. You could make single-purpose keys with commands to (haven't tested all these):
   mt -f /dev/nst0 rewind
   Rewind a tape on a remote machine
   nice -n 19 dd of=/dev/nst0
   Send STDIN to that tape drive. Maybe STDIN is a tar stream from tar -cf -.
   nice -n 19 dd if=/dev/nst0
   Read stuff from there to my STDIN
   cat claxon.au > /dev/audio
   Play an alarm noise on a remote machine
   cat - > /dev/audio
   Play any sound you send on STDIN
   cat - > /etc/dhcpd.conf
   Replace /etc/dhcpd.conf with some stuff from STDIN on the triggering machine (sounds like a temp file would be better)

   You can send the stuff on STDIN with something like this on the triggering machine:
   ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && cat alarm.au | ssh burly'

   or

   ssh-agent sh -c 'ssh-add ~/.ssh/whoisit < /dev/null && tar cf - /home/pkeck | ssh burly'

   Maybe for that one the corresponding command to "catch" that stream would be:

   cat - > ~/backups/pkeck.tar.`date +%Y%m%d.%H-%M-%S`

   You get the idea! Go crazy!

   Tape examples from Ed Cashin's Gettin' Fancy with SSH Keys, my inspiration for getting into this whole thing!

Recommended Links

Softpanorama Recommended

Top articles

Sites

• ssh-keygen - Wikipedia, the free encyclopedia
• ssh-keygen(1) - Linux man page
• SSH with Keys HOWTO SSH with Keys in a console window
• HOWTO set up ssh keys
• ssh-keygen Tutorial – Generating RSA and DSA keys by Guy Rutenberg
• How To Use ssh-keygen - a knol by Tom Harrison

Reference

ssh-keygen - authentication key generation, management and conversion

SYNOPSIS

     ssh-keygen [-q] [-b bits] -t type [-N new_passphrase] [-C comment]
                [-f output_keyfile]
     ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]
     ssh-keygen -i [-f input_keyfile]
     ssh-keygen -e [-f input_keyfile]
     ssh-keygen -y [-f input_keyfile]
     ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile]
     ssh-keygen -l [-f input_keyfile]
     ssh-keygen -B [-f input_keyfile]
     ssh-keygen -D reader
     ssh-keygen -F hostname [-f known_hosts_file]
     ssh-keygen -H [-f known_hosts_file]
     ssh-keygen -R hostname [-f known_hosts_file]
     ssh-keygen -U reader [-f input_keyfile]
     ssh-keygen -r hostname [-f input_keyfile] [-g]
     ssh-keygen -G output_file [-v] [-b bits] [-M memory] [-S start_point]
     ssh-keygen -T output_file -f input_file [-v] [-a num_trials]
                [-W generator]
DESCRIPTION

     ssh-keygen generates, manages and converts authentication keys for
     ssh(1).  ssh-keygen can create RSA keys for use by SSH protocol version 1
     and RSA or DSA keys for use by SSH protocol version 2.  The type of key
     to be generated is specified with the -t option.

     ssh-keygen is also used to generate groups for use in Diffie-Hellman
     group exchange (DH-GEX).  See the MODULI GENERATION section for details.

     Normally each user wishing to use SSH with RSA or DSA authentication runs
     this once to create the authentication key in ~/.ssh/identity,
     ~/.ssh/id_dsa or ~/.ssh/id_rsa.  Additionally, the system administrator
     may use this to generate host keys, as seen in /etc/rc.

     Normally this program generates the key and asks for a file in which to
     store the private key.  The public key is stored in a file with the same
     name but “.pub� appended.  The program also asks for a passphrase.  The
     passphrase may be empty to indicate no passphrase (host keys must have an
     empty passphrase), or it may be a string of arbitrary length.  A
     passphrase is similar to a password, except it can be a phrase with a
     series of words, punctuation, numbers, whitespace, or any string of char-
     acters you want.  Good passphrases are 10-30 characters long, are not
     simple sentences or otherwise easily guessable (English prose has only
     1-2 bits of entropy per character, and provides very bad passphrases),
     and contain a mix of upper and lowercase letters, numbers, and non-
     alphanumeric characters.  The passphrase can be changed later by using
     the -p option.

     There is no way to recover a lost passphrase.  If the passphrase is lost
     or forgotten, a new key must be generated and copied to the corresponding
     public key to other machines.

     For RSA1 keys, there is also a comment field in the key file that is only
     for convenience to the user to help identify the key.  The comment can
     tell what the key is for, or whatever is useful.  The comment is initial-
     ized to “user@host� when the key is created, but can be changed using the
     -c option.

     After a key is generated, instructions below detail where the keys should
     be placed to be activated.

     The options are as follows:

     -a trials
             Specifies the number of primality tests to perform when screening
             DH-GEX candidates using the -T command.

     -B      Show the bubblebabble digest of specified private or public key
             file.

     -b bits
             Specifies the number of bits in the key to create.  Minimum is
             512 bits.  Generally, 2048 bits is considered sufficient.  The
             default is 2048 bits.

     -C comment
             Provides a new comment.

     -c      Requests changing the comment in the private and public key
             files.  This operation is only supported for RSA1 keys.  The pro-
             gram will prompt for the file containing the private keys, for
             the passphrase if the key has one, and for the new comment.

     -D reader
             Download the RSA public key stored in the smartcard in reader.

     -e      This option will read a private or public OpenSSH key file and
             print the key in a ‘SECSH Public Key File Format’ to stdout.
             This option allows exporting keys for use by several commercial
             SSH implementations.

     -F hostname
             Search for the specified hostname in a known_hosts file, listing
             any occurrences found.  This option is useful to find hashed host
             names or addresses and may also be used in conjunction with the
             -H option to print found keys in a hashed format.

     -f filename
             Specifies the filename of the key file.

     -G output_file
             Generate candidate primes for DH-GEX.  These primes must be
             screened for safety (using the -T option) before use.

     -g      Use generic DNS format when printing fingerprint resource records
             using the -r command.

     -H      Hash a known_hosts file.  This replaces all hostnames and
             addresses with hashed representations within the specified file;
             the original content is moved to a file with a .old suffix.
             These hashes may be used normally by ssh and sshd, but they do
             not reveal identifying information should the file's contents be
             disclosed.  This option will not modify existing hashed hostnames
             and is therefore safe to use on files that mix hashed and non-
             hashed names.

     -i      This option will read an unencrypted private (or public) key file
             in SSH2-compatible format and print an OpenSSH compatible private
             (or public) key to stdout.  ssh-keygen also reads the ‘SECSH
             Public Key File Format’.  This option allows importing keys from
             several commercial SSH implementations.

     -l      Show fingerprint of specified public key file.  Private RSA1 keys
             are also supported.  For RSA and DSA keys ssh-keygen tries to
             find the matching public key file and prints its fingerprint.

     -M memory
             Specify the amount of memory to use (in megabytes) when generat-
             ing candidate moduli for DH-GEX.

     -N new_passphrase
             Provides the new passphrase.

     -P passphrase
             Provides the (old) passphrase.

     -p      Requests changing the passphrase of a private key file instead of
             creating a new private key.  The program will prompt for the file
             containing the private key, for the old passphrase, and twice for
             the new passphrase.

     -q      Silence ssh-keygen.  Used by /etc/rc when creating a new key.

     -R hostname
             Removes all keys belonging to hostname from a known_hosts file.
             This option is useful to delete hashed hosts (see the -H option
             above).

     -r hostname
             Print the SSHFP fingerprint resource record named hostname for
             the specified public key file.

     -S start
             Specify start point (in hex) when generating candidate moduli for
             DH-GEX.

     -T output_file
             Test DH group exchange candidate primes (generated using the -G
             option) for safety.

     -t type
             Specifies the type of key to create.  The possible values are
             “rsa1� for protocol version 1 and “rsa� or “dsa� for protocol
             version 2.

     -U reader
             Upload an existing RSA private key into the smartcard in reader.

     -v      Verbose mode.  Causes ssh-keygen to print debugging messages
             about its progress.  This is helpful for debugging moduli genera-
             tion.  Multiple -v options increase the verbosity.  The maximum
             is 3.

     -W generator
             Specify desired generator when testing candidate moduli for DH-
             GEX.

     -y      This option will read a private OpenSSH format file and print an
             OpenSSH public key to stdout.

MODULI GENERATION

     ssh-keygen may be used to generate groups for the Diffie-Hellman Group
     Exchange (DH-GEX) protocol.  Generating these groups is a two-step pro-
     cess: first, candidate primes are generated using a fast, but memory
     intensive process.  These candidate primes are then tested for suitabil-
     ity (a CPU-intensive process).

     Generation of primes is performed using the -G option.  The desired
     length of the primes may be specified by the -b option.  For example:

           # ssh-keygen -G moduli-2048.candidates -b 2048

     By default, the search for primes begins at a random point in the desired
     length range.  This may be overridden using the -S option, which speci-
     fies a different start point (in hex).

     Once a set of candidates have been generated, they must be tested for
     suitability.  This may be performed using the -T option.  In this mode
     ssh-keygen will read candidates from standard input (or a file specified
     using the -f option).  For example:

           # ssh-keygen -T moduli-2048 -f moduli-2048.candidates

     By default, each candidate will be subjected to 100 primality tests.
     This may be overridden using the -a option.  The DH generator value will
     be chosen automatically for the prime under consideration.  If a specific
     generator is desired, it may be requested using the -W option.  Valid
     generator values are 2, 3, and 5.

     Screened DH groups may be installed in /etc/moduli.  It is important that
     this file contains moduli of a range of bit lengths and that both ends of
     a connection share common moduli.

FILES

     ~/.ssh/identity
             Contains the protocol version 1 RSA authentication identity of
             the user.  This file should not be readable by anyone but the
             user.  It is possible to specify a passphrase when generating the
             key; that passphrase will be used to encrypt the private part of
             this file using 3DES.  This file is not automatically accessed by
             ssh-keygen but it is offered as the default file for the private
             key.  ssh(1) will read this file when a login attempt is made.

     ~/.ssh/identity.pub
             Contains the protocol version 1 RSA public key for authentica-
             tion.  The contents of this file should be added to
             ~/.ssh/authorized_keys on all machines where the user wishes to
             log in using RSA authentication.  There is no need to keep the
             contents of this file secret.

     ~/.ssh/id_dsa
             Contains the protocol version 2 DSA authentication identity of
             the user.  This file should not be readable by anyone but the
             user.  It is possible to specify a passphrase when generating the
             key; that passphrase will be used to encrypt the private part of
             this file using 3DES.  This file is not automatically accessed by
             ssh-keygen but it is offered as the default file for the private
             key.  ssh(1) will read this file when a login attempt is made.

     ~/.ssh/id_dsa.pub
             Contains the protocol version 2 DSA public key for authentica-
             tion.  The contents of this file should be added to
             ~/.ssh/authorized_keys on all machines where the user wishes to
             log in using public key authentication.  There is no need to keep
             the contents of this file secret.

     ~/.ssh/id_rsa
             Contains the protocol version 2 RSA authentication identity of
             the user.  This file should not be readable by anyone but the
             user.  It is possible to specify a passphrase when generating the
             key; that passphrase will be used to encrypt the private part of
             this file using 3DES.  This file is not automatically accessed by
             ssh-keygen but it is offered as the default file for the private
             key.  ssh(1) will read this file when a login attempt is made.

     ~/.ssh/id_rsa.pub
             Contains the protocol version 2 RSA public key for authentica-
             tion.  The contents of this file should be added to
             ~/.ssh/authorized_keys on all machines where the user wishes to
             log in using public key authentication.  There is no need to keep
             the contents of this file secret.

     /etc/moduli
             Contains Diffie-Hellman groups used for DH-GEX.  The file format
             is described in moduli(5).

SEE ALSO

     ssh(1), ssh-add(1), ssh-agent(1), moduli(5), sshd(8)

     J. Galbraith and R. Thayer, SECSH Public Key File Format, draft-ietf-
     secsh-publickeyfile-01.txt, March 2001, work in progress material.


AUTHORS

     OpenSSH is a derivative of the original and free ssh 1.2.12 release by
     Tatu Ylonen.  Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo
     de Raadt and Dug Song removed many bugs, re-added newer features and cre-
     ated OpenSSH.  Markus Friedl contributed the support for SSH protocol
     versions 1.5 and 2.0.

BSD                           September 25, 1999                           BSD

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created June 11, 2001; Last modified: March 12, 2019