|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|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 rsaIf 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:
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:
|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 ssh-add
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 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/'.
|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.|
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
The SSH-Keygen utility uses various files for storing public and private keys. The files used by SSH-Keygen utility are as follows:
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 cantinwould 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 isssh-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.
Paul Keck, 2001
- 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.
- 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.
- 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.
- 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 usernamesBy 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:
This command will do it without requiring an scp and vi session:
- 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.
cat foo.pub |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'
Single-purpose keysSo now you're sshing and scping your brains out. Sooner or later you'll come across one or both of these situations:
Single-purpose keys to the rescue!
- 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.
- 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.)
- 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.
- 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@example.com
- 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== whoisitnowThat 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.
- cat tempfile |ssh burly 'sh -c "cat - >>~/.ssh/authorized_keys2"'
Append tempfile to your authorized_keys2 file on burly.
- 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.
- 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'
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!
Google matched content
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.
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.
~/.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
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
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
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
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
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
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
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 development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 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: September 12, 2017