May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor


News SSH Recommended Links Reference Passwordless SSH login Private and Public key management FAQs
ssh-keygen SCP sftp Securing SSH daemon Tips Humor Etc

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

ssh-keygen -t rsa
If you have multiple accounts you might want to create a separate key on each of them. For example


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/ 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/ 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/ 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/ 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:

1. Verify that the openssh-askpass package is installed. If it isn't, install it
2. From the System menu on the top panel of the desktop, select Preferences, More Preferences, Sessions.
3. When the Sessions window appears, select the Startup Programs tab.
4. Click Add and enter /usr/bin/ssh-add as the startup command. Click OK
5. Click Close to save the settings and exit.

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

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


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

5. Copy the public key to the server with scp '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

ssh-keygen command options description
-b bits Specifies the number of bits in the key to create. The minimum bit length is 512 bits and the default length is 2048 bits.
-p Requests changing the passphrase of a private key file instead of creating a new private key.
-t Specifies the type of key to create.
-q quiets ssh-keygen. It is used by the /etc/rc file while creating a new key.
-N Provides a new Passphrase.

Changing passphase in existing key

Use ssh-keygen -p -t rsa or ssh-keygen -p -t dsa to change your old passphrase. Copy the public key component ( in the example) to the remote machine and save it to ~/.ssh/authorized_keys. You will be asked to authenticate yourself with your passphrase the next time you establish a connection. If this does not occur, verify the location and contents of these files.

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:

Top updates

Bulletin Latest Past week Past month
Google Search


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: cantin
would mean you trust user cantin from 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/
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/

In this case, the content of file is

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEArkwv9X8eTVK4F7pMlSt45pWoiakFkZMw
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/, was copied to your account, file .ssh/authorized_keys on, then user cantin@sodium is allowed to SSH into your own account on 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 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


  4. 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 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/ burly:.ssh/authorized_keys2
    Copy the file to the other host's .ssh dir with the name authorized_keys2.
  5. 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


  6. 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:


  2. 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.
  3. 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 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 files to each of the other machines' authorized_keys2 file, you'd have the equivalent of a .rhosts file with two added benefits: This command will do it without requiring an scp and vi session:

cat |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 in your .ssh dir.


  2. cp ~/.ssh/ 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==
  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 > /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 | ssh burly'


    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 Top Visited

Softpanorama Recommended


ssh-keygen - authentication key generation, management and conversion

     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]
     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

     -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

     -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

     -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-

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


     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.


             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.

             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.

             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.

             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.

             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.

             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.

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

     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.

     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



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


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


Vol 26, No.1 (January, 2013) Object-Oriented Cult : Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks: The efficient markets hypothesis : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Vol 23, No.10 (October, 2011) An observation about corporate security departments : 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.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haters 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

Copyright 1996-2014 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: (the fastest) and


The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Created June 11, 2001; Last modified: February 19, 2014