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  in a terminal window. If you don't specify the username, the user that entered the command 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.

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.

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



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

Rsync and SFTP are the two recommended ways to transfer files, since there are unfixable flaws with SCP.

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.

Using Rsync
"rsync" is not part of the SSH suite but is nearly ubqiquitous. It uses SSH to secure connections when transferring to or from a remote system.

or

One of the best parts of "rsync" is that it only transfers any changes, if an earlier version the file is on the destination. That saves on time and bandwidth. There are a lot of useful options for "rsync" including the -a option which combines recursive copying with preserved times, attributes, owner, and group, among others.

Using SCP
The SSH suite still includes a neat utility "scp", which stands for secure copy, which has a great way to copy files between machines. In recent version it is a wrapper for SFTP but it works almost exactly like the default unix  command. also allows you to copy a file from a remote host to a remote host. An example of :

which means copy files from  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.

, aka Secure Copy, works just like. Note : If your filename contains spaces then, use scp like this:- Note : If you want to copy the whole directory then use
 * 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.
 * Copy from a remote host ,
 * Copy from a remote host ,
 * file name is /media/sda6/Tutorials/Linux Unix/linux_book.pdf then destination directory is home/narendra/data
 * file name is /home/narendra/linux_book.pdf then destination directory is /media/Tutorials/Linux Unix/
 * file name is /home/narendra/linux_book.pdf then destination directory is /media/Tutorials/Linux Unix/

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 using SSH keys, 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  file to the end of the remote   file.

Transfer Method A: ssh-copy-id
The easiest way to do that is using. 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).



Transfer Method B: Step-by-step
The hard way to do that is to manually do each step that the above  command does automatically for you:


 * First create the remote  folder on the destination server, if it does not already exist:


 * Next upload your PUBLIC key only (not your private key).


 * Then append your PUBLIC key to the server's list of authorized keys:

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

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
Host Short_Name HostName server1.example.com User domain\username IdentityFile ~/.ssh/KEY
 * 1) Specific configuration applied to one host
 * 2) This configuration applies specifically to a host which uses Windows Domain login

Host *.example.com User domain\username IdentityFile ~/.ssh/%h_KEY
 * 1) Use this login as default for all hosts in the one domain
 * 2) It will look for a key with the hostname in the key's file name

Host localnetwork 192.168.1.0/24 User USERNAME IdentityFile ~/.ssh/key_37_rsa AddKeysToAgent yes ForwardX11 yes # In a pesky lab environment, add the following to your config # CheckHostIP no
 * 1) Generic configuration that applies to my private LAN.
 * 2) Of note, the options to forward X11 lets you run remote graphical
 * 3) programs while viewing and interacting with them locally.

Host * IdentitiesOnly yes ServerAliveCountMax 2 ServerAliveInterval 20 You can now ssh into  with just. The configuration options are chosen on a first-match basis, so put very specific rules torwards the beginning and more general rules towards the end.
 * 1) Catch-all settings which apply these settings to all hosts,
 * 2) if the particular option has not yet already been set.
 * 3) If there are a lot of keys in the SSH agent, then IdentitiesOnly is needed

Using an SSH Agent
Most desktop environments provide SSH agents automatically these days. So if you wish to see the details, look for the environment variables $SSH_AUTH_SOCK and $SSH_AGENT_PID, though only the former is used for connecting to it and must be available in to any program which needs to connect to the agent.

Keys can be added to the agent easily manually,



Or they can be added automatically on first use by setting AddKeysToAgent to "yes" in the appropriate rule set in the client configuration file.

However, keep in mind that once you go over six keys in the agent, special considerations have to be taken to keep the agent from trying the wrong keys in the wrong order and preventing logging in. Specifically, IdentitiesOnly should be set to "yes" for each host, ideally using the client configuration file. See below.

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


 * The server or domain to which you are trying to connect generates a pair of 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 &mdash; 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
The following presumes physical access to the server or some out-of-band equivalent.

With your distro's package manager, install sshd (or openssh-server) on the server, and on the client install ssh (or openssh-client). It is likely that they're already installed since they're usually part of the distro's default installation for servers and workstations respectively. Be sure the following is in /etc/ssh/sshd_config on the server and uncommented there. That is to say, that there's no # in front of them: PubkeyAuthentication yes PasswordAuthentication no 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.
 * 1) On the server,
 * 2) Open TCP port 22 on the server for incomming connections. This varies depending on your firewall. on-standard port.
 * 3) If the server is behind a router with DHCP:
 * 4) Stop using DHCP and assign a static IP address to your server. See the Gentoo Handbook or Arch Linux Wiki for instructions if you do not know how.
 * 5) Forward external TCP port 22 (or another port) on your router to port 22 on your server.
 * 6) Over on the client, create and test the a client key pair
 * 7) On the client command line, run   ("rsa" is the default, it is not necessary to explicitly specify "rsa").  Consider annotating the key pair with a comment using the   option.
 * 8) Copy the public key to removable media and transfer that media to the server and mount it.  Copy the public key to the server, say to ~/.ssh/server.key there.  Then append the key to the authorized_keys file,
 * 9) Back over on the client, test that the new key works:
 * 10) (Re)start the sshd service.
 * 11) Log in again from the client using the key

SSH as a Proxy
If you can make an SSH connection, you can (most likely) use that connection as a SOCKS5 proxy, without any extra setup on the remote computer. Traffic can then be tunneled securely through the SSH connection. If you are on a 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, unless specific provisions are made to do so.

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  option for dynamic port forwarding.

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.