SSH User Howto - OIWiki

SSH User Howto

From OIWiki

Jump to: navigation, search

Contents [hide] 1 About SSH 1.1 What is Secure Shell (SSH) 1.2 What is SFTP 1.3 Why not use FTP or RSH etc 1.4 What are SSH keys? 1.5 SSH Versions 2 OpenSSH 2.1 Identification 2.2 Configuration 2.3 Creating Keys 2.4 Allowing Access 3 Secure SSH 3.1 Identification 3.2 Configuration 3.3 Creating Keys 3.4 Allowing Access 4 Working between Secure and OpenSSH 5 Common Issues 5.1 User Accounts 5.2 Key location 5.3 Key Formats 5.4 File Permissions 6 Troubleshooting

About SSH

What is Secure Shell (SSH)

See WikiPedia if you need a full rundown Wikipedia SSH page Essentially it is an protocol for connecting to and executing commands on a remote system, using a secure encrypted tunnel.

What is SFTP

SFTP is a File Transfer Protocol that uses an SSH to authenticate and encrypt its traffic. It is essentially a sub-service of the SSH server.

Why not use FTP or RSH etc

Both FTP and RSH use no encryption and pass passwords over the network in plain text. This makes it possible for the passwords to be captured in a number of ways, which is obviously bad for the users and the systems security. Therefore whenever possible SSH/SFTP should be used for file transfers and remote connections - use of FTP or RSH in legacy applications requires Infosec approval.

What are SSH keys?

One of the ways SSH improves security is to identify a user by use of "key". The benefit of a key is that at no time does a password or even the key traverse the network, a challenge response mechanism is used to validate that the incoming user is who they say they are.

This works because there is a "private" and a "public" key. Basically the client proves who they are by exchanging values with the server using the public keys. The client uses the private key to provide a response which validates that it has the private key associated with the public key. When the server validates a correct response, it allows access.

By using keys, there is no need to provide passwords, which allows non-interactive or passwordless interactive logins.

SSH Versions

In UNIX, there are two main flavours of SSH in common usage - OpenSSH and Secure Shell (commercial SSH). Both are compatible, but each is slightly different in syntax, file formats and configuration. The simple way to tell is once you are on a system, use the "ssh -V" command to identify what version you are using.

The below sections outline the basic usage of each from a user perspective, as well as how to work between the two versions when the need arises.

OpenSSH

Identification

OpenSSH is the more common version and "ssh -V" will have either OpenSSH or OpenSSL in the output:

$ ssh -V Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f  $ ssh -V OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f 

Configuration

OpenSSH stores its configuration files under the ".ssh" directory of the users home directory.

By default, it will identify a user using the keyfiles "~/.ssh/id_dsa" and "~/.ssh/id_rsa"

It will validate an incoming user by matching public keys stored in the "~/.ssh/authorized_keys" file.

Creating Keys

To create a key using OpenSSH, use the ssh-keygen command. The command below says to create a key using DSA encryption of 1024 bit strength with no passphrase (-N) to the file id_dsa:

$ cd ~/.ssh $ ssh-keygen -t dsa -b 1024 -N -f id_dsa 

You will see two files created - and id_dsa and an id_dsa.pub. The id_dsa will now be used by the ssh command to attempt to authenticate you to other servers.

If you have both RSA and DSA keys created, it will try them both.

Allowing Access

To allow a remote user to login to your account using SSH, you simply need to append their public key to your ~/.ssh/authorized_keys file. For example:

$ cat bobskey.pub >> ~/.ssh/authorized_keys 

Be sure the public key is in the OpenSSH format however. If it is in the SecureSSH format, use the ssh-keygen command to convert it:

$ ssh-keygen -i -f secsshkey.pub > opensshkey.pub 

You can then append the converted key to the authorized_keys file

Secure SSH

Identification

Secure SSH is a commercially produced SSH implementation. In its version output it will not reference OpenSSL and generally says a vendor:

$ ssh -V ssh2: SSH Secure Shell 2.4.0 on alphaev56-dec-osf4.0e  $ ssh -V ssh: SSH Tectia Server 4.0.5 on powerpc-ibm-aix5.1.0.0 

Configuration

Secure SSH stores its configuration under the ".ssh2" directory of a users home directory.

By default it identifies a user using key files listed the "~/.ssh2/identification" file.

It will validate an incoming user by matching public key files listed in the "~/.ssh2/authorization" file.

Creating Keys

To create a key using Secure SSH, again use the ssh-keygen command. The command below says to create a key using DSA encryption of 1024 bit strength with no passphrase (-P):

$ ssh-keygen -t dsa -b 1024 -P Generating 1024-bit dsa key pair    5 oOOo.oOo.oOo Key generated. 1024-bit dsa, root@o9030004, Thu May 31 2007 13:12:37 Private key saved to //.ssh2/id_dsa_1024_a Public key saved to //.ssh2/id_dsa_1024_a.pub 

To use this key to authenticate to remote servers, append the filename to the identification file as such:

$ echo "Key id_dsa_1024_a" >> ~/.ssh2/identification 

You can append multiple lines to this file and the SSH client will attempt them in order.

Allowing Access

To allow remote access, you need to copy the public key file (i.e id_dsa_1024_a.pub) to the remote system and place it under the users .ssh2 directory. You then need to list the key file in the ~/.ssh2/authorization file as such:

$ echo "Key  id_dsa_1024_a.pub" >> ~/.ssh2/authorization 

Generally it is helpful to identify the server and user that the key is from by the filename, for example "cdun1410-ipg_as.pub" so you know what file is what.

If you are copying the public key from an OpenSSH system, then you need to first convert it to the SECSSH format by using the ssh-keygen command on the OpenSSH system:

openssh$ ssh-keygen -e -f id_dsa.pub > securessh.pub 

You can then copy the resulting key and place on the Secure SSH system.

Working between Secure and OpenSSH

Both versions are just as secure, it just happens that the commercial version is made by a company called "Secure Communications". Both are also compatible and able to exchange keys provided that, as above, you convert the key files for use on the systems as needed.

The simple way to tell if you have a SecureSSH or OpenSSH key file is by viewing it.

A SecureSSH key file will have a "BEGIN SSH2" and "END SSH2" line surrounding the actual key text.

An OpenSSH private key will have BEGIN <keytype> PRIVATE KEY" around the key, and the public keys begin with either "ssh-dss" or "ssh-rsa" followed by the key text in a single line.

Common Issues

As a first step, try using ssh with the "-v" flag to get more verbose details on what the SSH client is attempting to do. Pay attention to what key files it attempts to use, and the responses from the remote server.

User Accounts

Even though you may authenticate to a server correctly, SSH is still at the mercy of the user account on the remote system. If the account is locked, expired or otherwise inaccessable it will appear as if the SSH connection is simply disconnecting.

If you can login using a password, then the account is ok. Most likely you have an issue with your configuration or key files as described below.

Key location

As a first step, make sure you are not using the wrong configuration directory. OpenSSH will not look at a ~/.ssh2 directory, and Commercial SSH wont look at a ~/.ssh directory.

Key Formats

Ensure that the key files have been converted as appropriate on the server system. See the above sections for details on conversion.

File Permissions

One of the more common gotchas with SSH is that it is militantly pedantic about file permissions. If the file permissions are not secure enough, SSH will ignore the key completely. This applies to the users configuration directory (~/.ssh or ~/.ssh2) as well as the key files. If the users home directory or the .ssh directory is writable by anyone other than the user, SSH will ignore it and all its contents competely. This applies to both the SSH client and the SSH server.

Here is what your permissions should be:

• user home directory - 0755
• ssh directory - 0755
• private key files - 0400
• public key files - 0644
• other config files - 0644

As a first step, these permissions should be validated and set on both the client and the server to ensure that the SSH command is not ignoring your key files.

Troubleshooting

1. Ensure you can login to the remote system interactivly with a password - if you cannot, you have account issues and should raise a Clarify case to the administrators of the system you are connecting to.
2. Verify you have created the correct private and public keys on the client system (i.e the system you are initiating the connection from).
3. Verify the permissions of those files are correct
4. use ssh -v and verify that the ssh client is attempting to use the key files
5. On the remote system, verify the public keys are installed, are converted to the correct format, in their correct locations and have the correct permissions
6. If you still cannot connect, try from another system that you know does work or has worked, to ensure that there is not some other change on the server system preventing your connection
7. If you get to here, you should raise a clarify case to your systems administration group for investigation