About SSH
What is Secure Shell (SSH)
See WikiPedia if you need a full rundown Wikipedia SSH page (http://en.wikipedia.org/wiki/Secure_Shell) 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
- 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.
- Verify you have created the correct private and public keys on the client system (i.e the system you are initiating the connection from).
- Verify the permissions of those files are correct
- use ssh -v and verify that the ssh client is attempting to use the key files
- 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
- 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
- If you get to here, you should raise a clarify case to your systems administration group for investigation
============================================================
SSH Public Key Authentication
The original artical is at http://bumblebee.lcs.mit.edu/ssh2/
Basic Idea
No-password authentication works because of public key crypto. Let’s say you have a local machine Ooga and a remote machine Booga. You want to be able to ssh from Ooga to Booga without having to enter your password. First you generate a public/private RSA key pair on Ooga. Then you send your public key to Booga, so that Booga knows that Ooga’s key belongs to a list of authorized keys. Then when you try to ssh from Ooga to Booga, RSA authentication is performed automagically.
Here are detailed steps on how to do this.
NOTE: The following examples and scenarios assume you are creating only a single key, e.g. one RSA key or one DSA key. If it turns out that you’ve created both keys on your (client) system, then you will need to send both of them to the SSH/SSH2 server; otherwise, you may still be asked to enter a passphrase. Thanks to Steve McCarthy for pointing this out.
ssh1
If you’re using ssh1, then do this:
ooga% ssh-keygen -f ~/.ssh/identity
This will generate a public/private rsa1 key pair. When it asks you to enter your passphrase, just hit return (i.e. leave it empty). Now you need to send your public key to the remote server.
ooga% cd .ssh
ooga% scp identity.pub user@booga:~/.ssh
Now you need to log into Booga and add Ooga’s public key to Booga’s list of authorized keys.
ooga% ssh user@booga
booga% cd .ssh
booga% cat identity.pub >> authorized_keys
booga% chmod 640 authorized_keys
booga% rm -f identity.pub
That’s it! You can now ssh from Ooga to Booga without entering your password.
ssh2
It’s harder for ssh2. There are two common implementations of ssh2: OpenSSH and SSH2. Let’s say we want to ssh from Ooga to Booga. If Ooga and Booga both run the same implementation then it’s easy. Otherwise, we need to do some extra work to make them talk to each other properly.
My particular situation is that my local machine is running Windows 2000 with the Cygwin tools and OpenSSH 3.2.x. The remote machines may either have OpenSSH or SSH2. I’ll cover these two cases below.
ssh2: Ooga = OpenSSH, Booga = OpenSSH
First, generate a public/private DSA key pair on Ooga.
ooga% ssh-keygen -t dsa -f ~/.ssh/id_dsa
When you are asked for a passphrase, leave it empty. Now send the public key to Booga.
ooga% cd .ssh
ooga% scp id_dsa.pub user@booga:~/.ssh
Next, log in to Booga and add the public key to the list of authorized keys.
ooga% ssh user@booga
booga% cd .ssh
booga% cat id_dsa.pub >> authorized_keys2
booga% chmod 640 authorized_keys2
booga% rm -f id_dsa.pub
Note that the filename is authorized_keys2, not authorized_keys. That’s it; you’re ready to ssh from Ooga to Booga without having to enter a password.
ssh2: Ooga = OpenSSH, Booga = SSH2
First, generate a public/private DSA key pair on Ooga.
ooga% ssh-keygen -t dsa -f ~/.ssh/id_dsa
When you are asked for a passphrase, leave it empty. This key is stored in a format that OpenSSH can use, but SSH2 cannot. You need to export the key to a format that SSH2 understands.
ooga% ssh-keygen -e -f .ssh/id_dsa.pub > id_dsa_ssh2_ooga.pub
Note: the exact flags you need to specify may differ in your case. Check the man pages if the line above doesn’t work. Now send the exported public key to Booga.
ooga% scp id_dsa_ssh2_ooga.pub user@booga:~/.ssh2/
Note: the target directory is .ssh2, not .ssh. Next, log in to Booga and add the public key to the list of authorized keys.
ooga% ssh user@booga
booga% cd .ssh2
booga% cat >> authorization
key id_dsa_ssh2_ooga.pub
booga% chmod 640 authorization
For SSH2, there is an authorization file in which you list the file names of the authorized public keys. Note that this step is different than the case in which Booga is running OpenSSH. Now you are ready to ssh from Ooga to Booga without having to enter a password.
WARNING! These examples only works with
