Internet Technologies/SSH

SSH is a secure replacement for Telnet and rsh. All communications between the client and server are encrypted. To access an SSH client (usually OpenSSH) in most Unix OSs, type ssh user@host.com in a terminal window. If you don't specify the username, the user that entered the command ($USER) will be used. In Windows, you will need to download a 3rd-party utility such as PuTTY or Cygwin. Find more information in the ssh(1) man page. On other Operating Systems (smart phones for example), you will have to use a webbased client. There are several SSH apps for Android, including ConnectBot, Dropbear, ServerAssistant, and the Telnet / SSH Simple Client.^[1]

Uses

SSH is actually so much more than just a way to access a remote shell securely. It can be used for lots of other ways to transfer information securely. It includes a neat utility "scp", which stands for secure copy, which is a great way to copy files between machines. It works almost exactly like the default unix cp command. scp also allows you to copy a file from a remote host to a remote host. An example of scp:

scp user@host.com:~/files/ . which means copy files from files/ directory in user's home directory on the host.com machine (it will copy ALL files from the files/ directory) to the CWD (current working directory).

Another great use is to use it to encrypt the transport of any data from one machine to another. As an extreme example, you can use SSH to remotely move a disk from one machine to another (akin to ghost, but securely). This may not be the best use of SSH, or the fastest way to transfer data from one machine to another over a network, but it shows you how powerful SSH can be.

Another great feature is port forwarding. This allows you 'redirect' communication to and from a local application through SSH to another host. So, with SSH you can secure otherwise insecure communications over an encrypted 'tunnel'.

Using SSH

The secure shell client is conveniently called ssh. It is typically used to access a remote host. A typical usage of ssh is

ssh user@host

This means that the client intends to login as user on host machine. On successful authentication, an SSH session is established between the client and the host.

Using SFTP

SFTP has nothing to do with FTP. SFTP merely works like FTP, meaning you use it as you would FTP. Using SFTP requires only the SSH server. The FTP server is irrelevant to SFTP. Files are transferred as binary by default.

sftp user@host

Using SCP

scp, aka Secure Copy, works just like rcp.

Copy to a remote host - You must use the colon. REMOTE_PATH is not necessary and all REMOTE_PATHs are relative to the user's home directory.
scp FILE_PATH user@host:REMOTE_PATH
Copy from a remote host ,
scp user@host:REMOTE_PATH LOCAL_PATH

Note : If your filename contains spaces then, use scp like this:-

file name is /media/sda6/Tutorials/Linux Unix/linux_book.pdf then destination directory is home/narendra/data
- $scp user@host:"/media/sda6/Tutorials/Linux\\ Unix/linux_book.pdf" /home/narendra/data
file name is /home/narendra/linux_book.pdf then destination directory is /media/Tutorials/Linux Unix/
- $ scp /home/narendra/linux_book.pdf user@host:"/media/Tutorials/Linux\\ Unix/"

Note : If you want to copy the whole directory then use

scp -r user@host:"<source_dirname>" <destination_dirname>

Creating SSH Keys

Although SSH can be used with passwords, doing so is not recommended, and many servers will not allow password logins. Instead, use a key - this is more secure, and more convenient.

To create an SSH key ,

Most modern Unix systems include the OpenSSH client. To generate a key, run:

$ ssh-keygen

This will store your private key in $HOME/.ssh/id_rsa, and your public key in $HOME/.ssh/id_rsa.pub. You can use different filenames, but these are the default filenames, so it's easiest to not change them.

Permissions

Because the security of your private key is so important, SSH will not work if file permissions are insecure. SSH will create files and directories with the appropriate permissions, but sometimes things will go wrong. To fix permission issues:

$ chmod 600 ~/.ssh/KEY ~/.ssh/KEY.pub
$ chmod 700 ~/.ssh

Establish Trust

To log into a remote server, you'll need to put the public key on that server's list of authorized keys.

In other words, you need to append a copy of your local ~/.ssh/id_rsa.pub file to the end of the remote ~/.ssh/authorized_keys file.

ssh-copy-id

The easiest way to do that is using ssh-copy-id. This requires some alternate form of authentication, usually password (since you haven't got a key on the server you cannot use key authentication yet).

$ ssh-copy-id user@host.net

Step-by-step

The hard way to do that is to manually do each step that the above ssh-copy-id command does automatically for you:

First ssh-copy-id creates the remote ~/.ssh folder on the destination server, if it does not already exist:

ssh user@host "mkdir ~/.ssh && chmod 700 ~/.ssh"

Next ssh-copy-id uploads your PUBLIC key only (not your private key).

scp ~/.ssh/id_rsa.pub user@host:.ssh/KEY.pub

Then ssh-copy-id appends your PUBLIC key to the server's list of authorized keys:

ssh user@host

cat ~/.ssh/KEY.pub >> ~/.ssh/authorized_keys

rm ~/.ssh/KEY.pub

Advanced *nix users could do all those steps in one line:

cat ~/.ssh/id_rsa.pub | ssh user@host "cat >> ~/.ssh/authorized_keys"

All of that is automatically done for you when you run:

$ ssh-copy-id user@host.net

SSH Personal Configuration

You don't need to set up a ~/.ssh/config file, but it makes authentication easier. The important part is to specify your user name and your private key - if this is specified in the config file, you needn't provide it on the command line. Using HostName, you can shorten the ssh command to:

$ ssh servername

Example

#Specific configuration applied to one host
#This configuration applies specifically to a host which uses Windows Domain login
Host Short_Name
        HostName some_host.com
        User domain\username
        Protocol 2
        UseRsh no
        IdentityFile ~/.ssh/KEY

# Generic configuration that I apply to all hosts, especially on my private LAN
# Of note, the options to forward X11 and the SSH Agent.  X11 forwarding lets you
# tunnel and X session or programs via SSH.
Host *
        User USERNAME
        Protocol 2
        ForwardX11 yes
        ForwardAgent yes
        UseRsh no
        IdentityFile ~/.ssh/key_37_rsa
        FallBackToRsh no
        # In a pesky lab environment, add the following to your config
        # CheckHostIP no

You can now ssh into some_host.com with just ssh Short_Name.

Using an SSH Agent

This part assumes that you are not using a ssh client configuration file and that your keys are protected with a passphrase. An excellent BASH utility script called Keychain automates and simplifies the tedious use of ssh-agents. If your host does not have Keychain installed, ask your administrator. Alternatively you can download and unpack the script into your home directory from the Keychain website.

Using Keychain

Start your agent on your local host

keychain - honestly you don't need to type this, simply loading your keys causes this to happen

Access your forwarded agent from a remote host

keychain --inherit any-once

Load your key

keychain ~/.ssh/KEY

This will prompt you for a password (if you gave your key one!).

Unload your key

keychain --clear

Stop the agent

keychain --stop

BASH configuration Change

add the following lines to ~/.bash_login and ~/.bashrc

keychain

source ~/.keychain/${HOSTNAME}-sh

Public-key cryptography

The most significant difference between SSH and Telnet & rsh is in the realm of security. SSH uses RSA or DSA for public-key cryptography.

The server or domain to which you are trying to connect generates 2 keys (public and private) for a client.
The public key is given to the client the first time it tries to connect. The corresponding private key is a secret and kept with the server.
The client sends the packets of data by encrypting it through the public key and this data is decrypted by using the corresponding private key stored there.

Communication from the server to the client is also possible in the same way—the server encrypts using the client's public key and the client decrypts using it's private key.

Setting up OpenSSH with public key cryptography

With your distro's package manager, install sshd (or openssh-server) on the server, and on the client install ssh (or openssh-clients). It is likely that they're already installed since they're probably part of the distro's default installation.
Make sure the following is there and uncommented (there's no # in front of them) in /etc/ssh/sshd_config on the server:

PubkeyAuthentication yes
PasswordAuthentication no

On the client command line, run ssh-keygen ("rsa" is the default, it is not necessary to explicitly specify "rsa").
Copy where you saved your generated keys/id_rsa.pub to portable storage.
Bring the portable storage to the server and mount it as the user you will be remotely logging in as. Don't log out yet.
cat portable storage mount point/id_rsa.pub>>~/.ssh/authorized_keys
Add either sshd:ALL or sshd:IP of client to /etc/hosts.allowed.
Open TCP port 22. This varies depending on your firewall. For Fedora Core, RHEL, and derivatives, this can be done with system-config-securitylevel. For other GNU/Linux systems, echo '-A INPUT -p tcp -m tcp --dport 80 --syn -j ACCEPT'>>/etc/sysconfig/iptables and restart the iptables service. You may wish to run sshd on a non-standard port.
If the server's behind a router:
1. Stop using DHCP and assign a static IP address to your server. See the Gentoo Handbook for instructions if you do not know how.
2. Forward TCP port 22 to your server.
(Re)start the sshd service.
Test the setup by running ssh user to login as on the server@IP or domain of the server. Tip: If the username that you are logging in as on the server is the same as the one you're currently using on the client, you don't need to specify the user to log in as on the server.

SSH as a Proxy

If you can make an SSH connection, you can (most likely) use that connection as a SOCKS proxy, without any extra setup on the remote computer. Traffic is tunneled securely through the SSH connection. If you are on an unsecured wireless connection, you can use this to effectively secure all your traffic from snooping. You can also use this to bypass IP restrictions, because you will appear to be connecting from the remote computer. Note that DNS traffic is not tunneled.

Pick some big port number (bigger than 1024 so you can use it as non-root). Here I choose 1080, the standard SOCKS port. Use the -D option for dynamic port forwarding.

ssh -D 1080 user@host

That's it. Now as long as the SSH connection is open, your application can use a SOCKS proxy on port 1080 on your own computer (localhost). For example, in Firefox on Linux:

go to Edit -> Preferences -> Advanced -> Network -> Connection -> Settings...
check "Manual proxy configuration"
make sure "Use this proxy server for all protocols" is cleared
clear "HTTP Proxy", "SSL Proxy", "FTP Proxy", and "Gopher Proxy" fields
enter "127.0.0.1" for "SOCKS Host", and "1080" (or whatever port you chose) for Port.

SSH from your webbrowser

You can also use ssh from a webbrowser with javascript support even when you don't have a secure shell client. In order to do this you have to install AnyTerm, AjaxTerm or WebShell on the system where the SSH server is running or use a third party service like WebSSH.