SSH (Secure Shell)

Generating SSH Keys:

Public-key authentication is based on the use of digital signatures. Each user creates a pair of ‘key’ files. One of these key files is the user’s public key, and the other is the user’s private key. The server knows the user’s public key, and only the user has the private key.

When the user tries to authenticate herself, the server checks for matching public keys and sends a challenge to the user end. The user is authenticated by signing the challenge using her private key.

Remember that your private key file is used to authenticate you. Never expose your private keys. If anyone else can access your private key file, they can attempt to login to the remote host computer as you, and claim to be you. Therefore it is extremely important that you keep your private key file in a secure place and make sure that no one else has access to it.

Do not use public-key authentication on a computer that is shared with other users. Generate keys only on your personal computer that no one else can access!

So let’s get started, let’s say you want to be able to ssh as your user “ashish” to remote.com without passwords getting in your way…

$ ssh ashish@remote.com

and ssh will ask if you want to keep connecting, type “yes”, and then it should ask for your password and open a shell in ashish’s home directory on remote.com, just like telnet. If this fails, there is a problem somewhere. Make sure ssh is installed on your end, and also make sure that remote.com is accepting ssh connections. If it’s not, you’re wasting your time.

Once ssh is functioning we will set up the keys so that it will no longer be necessary to send passwords. If you are curious about the theory of this then read up on “public key cryptography”.
Install the public key on the remote computer: (We assume the remote computer is running OpenSSH on Linux or UNIX!) Once id_dsa.pub is on the remote computer, login into the remote computer (you can use ssh to login with your password as described above). From your home directory (where you should see your newly arrived id_dsa.pub) create a .ssh folder if none exists. Then append your id_dsa.pub to a file in .ssh with

Create your keys: You need to create private and public ssh keys and put them in the proper place with the proper permissions. In your home directory create a folder .ssh ($ mkdir .ssh), if there is none. Note that Windows may make it difficult for you to create a file starting with “.” if you try to do it with their tools; e.g. Windows Explorer. Next, create the keys with the command

$ ssh-keygen -t dsa

The ssh-keygen program will ask for a passphrase, just hit the “Enter” key unless for some reason you know you want a passphrase. This creates the keys id_dsa and id_dsa.pub and puts them in .ssh/. The private key id_dsa must be readable only by you; change its permissions with

$ chmod 600 .ssh/id_dsa

Put the public key on the remote computer: In this section we are assuming the remote computer is also running OpenSSH. Somehow, you must get the .ssh/id_dsa.pub key onto the remote computer, whether by email, ftp, carrying it over on a floppy (sneakernet), etc.; the cool way to do it is to use scp, which was installed along with ssh. Suppose the remote computer is named remote.com, and your account there is “ashish”. To copy the file to remote, run

$ scp .ssh/id_dsa.pub ashish@remote.com:

Don’t forget the trailing colon. You will be asked for ashish’s password on remote before the copying commences. The file will be copied to ashish’s home directory on remote.

$ cat id_dsa.pub >> .ssh/authorized_keys

This will create the file authorized_keys if none exists. The id_dsa.pub key may be removed from the remote computer’s home directory, if you like. The .ssh folder on the remote computer must have the correct permissions, you may set them with

$ chmod 700 .ssh

Checking the password-less connection: Now the command 

$ ssh ashish@remote.com

should give you a password-less connection to remote.com. Likewise, scp should be password-free.

By the way, all the commands you do by first logging into the remote computer can be done remotely, one at a time, using ssh. For example, you can run run

“$ ssh ashish@remote.com ls”

and get a listing of your home directory files on the remote system.

SSH is recommended for remote login, making backups, remote file transfer via scp or sftp

SCP or Secure Copy is an encrypted method of transferring files over an already established SSH connection. SCP is most useful with a pre-established SSH connection, otherwise SFTP has a much richer feature set, and should be used instead. Compared to the earlier SCP protocol, which allows only file transfers, the SFTP protocol allows for a range of operations on remote files – it is more like a remote file system protocol. An SFTP client's extra capabilities compared to an SCP client include resuming interrupted transfers, directory listings, and remote file removal. [1] For these reasons it is relatively simple to implement a GUI SFTP client compared with a GUI SCP client.

Although both SCP and SFTP utilize the same SSH encryption during file transfer with the same general level of overhead, SCP is usually much faster than SFTP at transferring files, especially on high latency networks. This happens because SCP implements a more efficient transfer algorithm, one which does not require waiting for packet confirmations. This leads to faster speed but comes at the expense of not being able to interrupt a transfer, so unlike SFTP, SCP transfer cannot be canceled without terminating the session.

Default Config Files and SSH Port

§  /etc/ssh/sshd_config - OpenSSH server configuration file.

§  /etc/ssh/ssh_config - OpenSSH client configuration file.

§  ~/.ssh/ - Users ssh configuration directory.

§  ~/.ssh/authorized_keys or ~/.ssh/authorized_keys - Lists the public keys (RSA or DSA) that can be used to log into the user’s account

§  /etc/nologin - If this file exists, sshd refuses to let anyone except root log in.

§  /etc/hosts.allow and /etc/hosts.deny : Access controls lists that should be enforced by tcp-wrappers are defined here.

§  SSH default port : TCP 22

Make a note of the IP address or domain name for the ssh "server" given by the instructor.
The instructor will start the ssh server daemon on the server machine (requires root).

Establishing an encrypted login session to an ssh server using key-based authentication

ON THE CLIENT, IN CLASS

Login as user "student" (create if non-existent). Create a key pair, of dsa type

cd
ssh-keygen -t dsa (respond to all the prompts by pressing enter)

Note the resultant new directory (.ssh within your home directory) and the 2 files in it (id_dsa, id_dsa.pub).

ls -ld .ssh      (shows the directory
ls -l .ssh         (shows its contents

id_dsa.pub is your public key. Move a copy of it to the server. Per your instructor, use either ftp or sftp (this will depend on what the particular client, server, and their firewalls support). Login as the user indicated by your instructor (e.g., student01; you use your assigned user account instead please) with the password indicated (e.g., password#University). If your instructor tells you to use ftp:

cd .ssh
ftp
[supply name and password when prompted]
ftp> passive
ftp> put id_dsa.pub
ftp> quit

or else, if you're to use sftp:

cd .ssh
sftp @
[supply name and password when prompted]
sftp> put id_dsa.pub
sftp> quit

or else, if scp (sftp is interactive, scp is not):

cd .ssh
scp  id_dsa.pub  @:/home/

Now that you have a matched pair of keys, and a copy of the public one on the server, you'll  next go to the server and place the public key into the strategic file used by ssh to enable key-based authentication for logging in. That file is /home//.ssh/authorized_keys2, where is the user as whom you will want to log in.


ON THE SERVER, REMOTE FROM CLASS

Log in remotely to the server. Per your instructor, use either telnet or ssh to do so. Login as the user indicated by your instructor (e.g., student01) with the password indicated (e.g., password).

Below, in your home directory you create a subdirectory named .ssh. (Note it will be "hidden" because its name starts with a period; so if you want to see it using ls, be sure to use ls's -a option.) Then restrict access to it by explicitly setting its permissions to exclude everybody but you (an ssh requirement).

cd
mkdir .ssh
chmod 700 .ssh

In that directory create a file named authorized_keys2 containing a copy of the the public key you imported from your client in class. Make its permissions suitably restrictive (an ssh requirement):

cd .ssh
cat ../id_dsa.pub >> authorized_keys2
chmod 600 authorized_keys2

Leave the server by quitting from telnet/ssh.

exit


BACK ON THE CLIENT AGAIN, IN CLASS

Logged in as the same user as before, gain a remote prompt from the server as the indicated user (e.g., student01):

ssh student01@

answer "yes" to any question about host authenticity that may appear. You should not get any password prompt. Nevertheless, you should get the command prompt and be able to operate on the remote machine as student01 much as if you had used telnet or ssh login. (ssh can be used for a variety of non-login purposes. This key-based authentication is convenient for such uses within scripts that will run unattended, where no human would be available to supply a password on behalf of the script.) Exit the remote server by quitting from ssh:

exit

Note that what you have done here:

 What you set up:  transparent (passwordless) remote command access via ssh
 How you did it:  by remote command access via either telnet or non-transparent ssh

If you used telnet or ssh login via password for the exercise (you did!) note that logically, it's pointless to bother getting remote access when you already have it. Practically in the real world, you would not already have it. Neither telnet nor ssh would yet be available to you. Telnet in parallel with ssh makes no sense because it defeats ssh's purpose of confining remote access to secure connections. In the absence pre-existing access to the server, that is in the real world, key placement would have to be done by the ssh server's administrator, with his active and deliberate cooperation.