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 firstname.lastname@example.org 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
- 2 Public-key cryptography
- 3 Setting up OpenSSH with public key cryptography
- 4 SSH as a Proxy
- 5 SSH from your webbrowser
- 6 Further reading
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
scp also allows you to copy a file from a remote host to a remote host. An example of
scp email@example.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'.
The secure shell client is conveniently called
ssh. It is typically used to access a remote host. A typical usage of
This means that the client intends to login as
host machine. On successful authentication, an SSH session is established between the client and the
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.
scp, aka Secure Copy, works just like
- 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:
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.
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
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
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 firstname.lastname@example.org
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
~/.sshfolder 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:
cat ~/.ssh/KEY.pub >> ~/.ssh/authorized_keys
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 email@example.com
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
#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
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.
- 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
- This will prompt you for a password (if you gave your key one!).
- Unload your key
- Stop the agent
BASH configuration Change
add the following lines to
- 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_dsa.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:
- Stop using DHCP and assign a static IP address to your server. See the Gentoo Handbook for instructions if you do not know how.
- 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