OpenSSH Authentications

http://sourceforge.net/docman/display_doc.php?docid=761&group_id=1

When using SSH to connect to a remote host, some form of authentication is required. In the context of SourceForge.net, SSH provides two means to authenticate to a remote host: passwords and the use of public key cryptography (SSH keys). The use of passwords is fairly well understood; this document has been created to provide an overview of the second supported authentication mechanism, the use of SSH keys.

SSH key pairs (as with most mechanisms which use public key cryptography) consist of two pieces, a public key and a private key. Your private key contains data which only you should know; this key should be retained on a machine you have direct control over and should not be given to anyone. Your public key will be uploaded to remote hosts to which you wish to connect.

Within public key cryptography, the fundamental idea is that two keys exist, a public key and a private key. The public key is derived from the private key. Messages encrypted against the public key may only be decrypted by those individuals who hold the corresponding private key. Messages signed using the private key may be validated (i.e. you can ensure that the sender holds that private key) using the public key.

Within the SSH key scheme, both the host and the user hold a key pair. When connecting to the remote host, the public key for that host is sent to the user for verification. Data sent from the user to the host is encrypted against the public key for that host; when the data is received by the host, it is decrypted using that host's private key.

When you connect to a remote host, it will check to see if it has a public key on file for your account. If the host does have a public key on file for your account, it will ask your workstation (the connecting machine) whether it holds the corresponding private key. If your workstation does hold the matching private key, your identity will have been confirmed and you will have completed authentication to the remote host. Any data subsequently sent from the host to your workstation will be encrypted with your public key (held by the remote host); when that data is received by your workstation, it will be decrypted using your private key.

The use of SSH keys for user authentication, instead of passwords, provides a number of significant benefits:

SSH comes in two flavors, SSH1 (which uses RSA public key cryptography) and SSH2 (which uses DSA public key cryptography). We recommend the use of SSH2 rather than SSH1, as result of design enhancements in the newer protocol. SSH1 makes use of RSA public keys and SSH2 makes use of DSA public keys. These keys are not interchangeable. The SSH1 and SSH2 protocols function in completely different ways to accomplish similar goals. While most SSH client suites support both the SSH1 and SSH2 protocols, it is important to realize which protocol you are using, from the perspective of using SSH keys. The protocol you choose to use will determine what type of public key pair (RSA or DSA) you will generate.

Each SSH suite provides its own mechanism for key pair generation. Please refer to the documentation which accompanied your SSH client to determine the proper procedure for adding a password to your key.

If you are making use of OpenSSH, you will make use of the "ssh-keygen" utility to generate your key pair. SSH1 (RSA) keys may be generated by executing "ssh-keygen -t rsa1". SSH2 (DSA) keys may be generated by executing "ssh-keygen -t dsa". Additional parameters are available; see the documentation accompanying OpenSSH for details.

If you are making use of PuTTY, a passphrase may be added to your private key file by using the following process:

Most SSH suites provide the means to add a password to your private key. Generally, this may be done either at time of key generation or after-the-fact. Please refer to the documentation which accompanied your SSH client to determine the proper procedure for adding a password to your key.

If you are making use of OpenSSH, a passphrase may be added to your private key file using the following command syntax:

If you are making use of PuTTY, a passphrase may be added to your private key file by using the following process:

Most SSH suites provide the means to add a password to your private key. Generally, this may be done either at time of key generation or after-the-fact. Once a password has been added to your public key file, you may generally remove it, or change it, using the tools provided in your SSH suite. Please refer to the documentation which accompanied your SSH client to determine the proper procedure for changing or removing a password from your key file.

If you are making use of OpenSSH, the passphrase on your private key file may be changed using the following command syntax:

If you are making use of PuTTY, the passphrase on your private key file may be changed using the following process:

The circumstances surrounding the loss or compromise of your SSH key should largely determine your behavior. If your key is compromised, IMMEDIATELY update your SSH key data on the SourceForge.net site and take steps to ensure your project data has not been compromised (check for changes to project content on the shell servers and CVS commits attributed to your user). If you have simply lost your key, simply generate a new key pair and update the key data for your user account to match.

Doable but it would be 100 files in a directory called known_hosts. Vi the single file and locate the key by name or ip would not be difficult at all. Security wise, single file is also easier to monitor and maintain, as opposed to 200 files (naming convention????? and a security risk as well).

*References*: to below 'authorized_keys base' for a more generally practical solution.

As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography.

The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key.

You can generate a public key (sort of like a Kerberos ticket) that will let you login to UNIX accounts that without typing your SSH password each time. When you first login to your local workstation, run "ssh-agent" and give it your passphrase. Then ssh will not prompt for the password; the target account must have your "identity.pub" key in ~/.ssh/authorized_keys.

The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in.

When the user logs in, the ssh program tells the server which key pair it would like to use for authen- tication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the challenge using the private key, proving that he/she knows the private key but without disclosing it to the server.

http://www.csua.berkeley.edu/ssh-howto.html

The security of your passphrase is of the utmost importance, because in order for ssh-agent to be of much use, your passphrase must serve to authenticate you to any machine you wish to use. This basically means that your SSH passphrase is a password that works on all the accounts of all the machines you use. Obviously, therefore, if someone figures out your SSH passphrase, they have access to all the machines you use; this is a worst-case scenario which is to be avoided. Therefore, you should take care never to type your SSH passphrase over an unencrypted network stream. Whenever you type your SSH passphrase, you NEED TO THINK about whether ANY ONE of the network connections over which you are sending your passphrase is unencrypted or otherwise "sniffable" — i.e., are you "secure to console"? If you do have insecure connections, don't enter your passphrase. Just hit return, and you can enter your UNIX password instead, or you can hit return again, log out of the insecure network connection, and try again from a secure host.

That said, here are some guidelines for picking passphrases:

After you enter your passphrase, your SSH secret key will be encrypted with your passphrase, and then saved in your ~/.ssh/identity file.

— Ssh implements the RSA authentication protocol automatically. The user reates his/her RSA key pair by running ssh-keygen(1). This stores in the user's home directory:

The "identity" file should not be readable by anyone but you.

— The user should then append the identity.pub to .ssh/authorized_keys in his/her home directory on the remote machine

— the authorized_keys file corresponds to the conventional .rhosts file, and has one key per line, though the lines can be very long.

— After this, the user can log in without giving the password. RSA authentication is much more secure than rhosts authentication.

The recommended way to start a shell in a remote machine is

so ssh form iitrc to sunshine will use

— no problem to login from iitrc to sunshine without password. the group mod for identity.pub & known_hosts is not important

— still no problem to login from iitrc to sunshine without password. authorized_keys doesn't need the execution right!

The second (and primary) authentication method is the rhosts or hosts.equiv method combined with RSA-based host authentication. It means that if the login would be permitted by .rhosts, .shosts, /etc/hosts.equiv, or /etc/shosts.equiv, and additionally it can verify the client's host key (see $HOME/.ssh/known_hosts and /etc/ssh_known_hosts in the FILES section), only then login is permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing and routing spoofing. [Note to the administrator: /etc/hosts.equiv, .rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.]

*Tags*: remote authentication

To avoid having to type your password every time for your CVS/SSH developer account, you may put your public key(s) in your ~/.ssh/authorized_keys file.

To generate a public key, run the program 'ssh-keygen' (or ssh-keygen1). The public key will be placed at '~/.ssh/identity.pub'.

Ssh implements the RSA authentication protocol automatically. The user creates his/her RSA key pair by running ssh-keygen(1). This stores the private key in .ssh/identity and the public key in .ssh/identity.pub in the user's home directory. The user should then copy the identity.pub to .ssh/authorized_keys in his/her home directory on the remote machine (the authorized_keys file corresponds to the conventional .rhosts file, and has one key per line, though the lines can be very long). After this, the user can log in without giving the password.

Newsgroups: comp.programming,comp.security.ssh,comp.security.unix,comp.unix.shell

I'd imagine that ssh would make your life easier since it's designed as a drop-in replacement for rsh. You wouldn't have to worry about terminal emulation or require something like expect to automate things.

However, if you don't pass ssh something to do on the command line, it will log you into an interactive session much the same way rsh falls back to rlogin.

The downside of using ssh in scripts is that you would need some way to store the key in memory. This is accomplished using ssh-agent in ssh2. You'd need to start cron under ssh-agent and enter the passphrase for your key once. Then any children it spawns will have access to the key in memory. Creating keys with empty passphrases is another solution, but this essentially defeats much of the security around ssh. Once someone gets your private key, they have unrestricted access to any systems that accepts it.

Mario

Here, I'll use the following terms:

As an example, our backups are done via username "backup" on host Tapeserv. On our Authserv server, user "root" is trying to connect to Tapeserv to make Authserv's backups on Tapeserv's tape drive. This means that the Server is Tapeserv, the ServerUser is backup, the Client is Authserv, and the ClientUser is "root".

Of course, install SSH on the Server and Client machines.

On the Client, cat the file /etc/ssh_host_key.pub and copy-n-paste it into Notepad or some other text editor. It will look something like this:

(the actual number will be much longer)

Remove the root@Client from the end and add the Client hostname to the beginning:

Then copy-n-paste this single, very long line into Server's /etc/ssh_known_hosts file.

This gives the Server the Client's public key so the Server can verify the Client's identity based on a public key signature. By contrast, rsh only uses the IP address for authentication.

Copy the Client's /etc/ssh2/hostkey.pub file over to the Server and name it /etc/ssh2/knownhosts/authserv.ssh-dss.pub

Of course, since your host isn't named Authserv, use your own hostname. Generally, you'll want to use the "short" hostname and not the fully qualified hostname.

This gives the Server the Client's public key so the Server can verify the Client's identity based on a public key signature. By contrast, rsh only uses the IP address for authentication.

On the Server, create a file in the ServerUser's home directory named ".shosts". The contents of this file should be the Client hostname, some tabs or spaces, and the ClientUser username.

For example, to allow root@Authserv to log into backup@Tapeserv, I'd place this .shosts file into backup's home directory on Tapeserv:

Be sure to chown and chmod the .shosts file. The .shosts file must be owned by the remote user and should be mode 0400.

Make sure that this line exists in /etc/sshd_config:

This enables the SSH1 daemon to do what we need it to do.

For safety, you may also want to verify this line:

This disables the use of rhosts-style authentication without corresponding public key authentisation.

If you had to modify the sshd_config file, you have to HUP the sshd to make the change take effect.

Check the file /etc/ssh2/sshd2_config and make sure that AllowedAuthentications contains the word "hostbased" For example, it may read:

If you had to modify the sshd2_config file, you'll have to HUP the sshd to make the change take effect.

You should be all set.

On the Client, log in as the ClientUser and try this:

You should get back the results of "uptime" run on the remote server.

The first time you run ssh to that particular server, you'll have to answer "yes" when asked if you want to connect to the server. This is because the local ssh doesn't yet have the remote server's SSH public key. This will only hapen the first time.

*References*: cmd:keychain

documented on: 2007.01.31

But is it in the path that ssh has on the remote machine _before_ it spawns your login shell?

Read the manual page for sshd and either set up your $HOME/.ssh/environment files with PATH settings which can find xauth, or set up your $HOME/.ssh/rc file to do the xauth for sshd.

man sshd

CONFIGURATION FILE

Sshd reads configuration data from /etc/sshd_config (or the file specified with -f on the command line). The file contains keyword-value pairs, one per line. Lines starting with '#' and empty lines are interpreted as comments.

LOGIN PROCESS

When a user successfully logs in, sshd does the following: