Internet Technologies/SSH

From Wikibooks, open books for an open world
(Redirected from SSH)
Jump to navigation Jump to search

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 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[edit | edit source]

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 . which means copy files from files/ directory in user's home directory on the 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[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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:"<syntaxhighlight_dirname>" <destination_dirname>

Creating SSH Keys[edit | edit source]

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/ You can use different filenames, but these are the default filenames, so it's easiest to not change them.

Permissions[edit | edit source]

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/
$ chmod 700 ~/.ssh

Establish Trust[edit | edit source]

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/ file to the end of the remote ~/.ssh/authorized_keys file.

ssh-copy-id[edit | edit source]

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

Step-by-step[edit | edit source]

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/ user@host:.ssh/
  • Then ssh-copy-id appends your PUBLIC key to the server's list of authorized keys:
ssh user@host
cat ~/.ssh/ >> ~/.ssh/authorized_keys
rm ~/.ssh/

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

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

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

$ ssh-copy-id

SSH Personal Configuration[edit | edit source]

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[edit | edit source]

#Specific configuration applied to one host
#This configuration applies specifically to a host which uses Windows Domain login
Host Short_Name
        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 with just ssh Short_Name.

Using an SSH Agent[edit | edit source]

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[edit | edit source]

  • 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[edit | edit source]

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

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

Public-key cryptography[edit | edit source]

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[edit | edit source]

  1. 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.
  2. 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
  1. On the client command line, run ssh-keygen ("rsa" is the default, it is not necessary to explicitly specify "rsa").
  2. Copy where you saved your generated keys/ to portable storage.
  3. 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.
  4. cat portable storage mount point/>>~/.ssh/authorized_keys
  5. Add either sshd:ALL or sshd:IP of client to /etc/hosts.allowed.
  6. 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.
  7. 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.
  8. (Re)start the sshd service.
  9. 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[edit | edit source]

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 "" for "SOCKS Host", and "1080" (or whatever port you chose) for Port.

SSH from your webbrowser[edit | edit source]

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.

Further reading[edit | edit source]