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 email@example.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.
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 Edit
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
Rsync and SFTP are the two recommended ways to transfer files, since there are unfixable flaws with SCP.
Using SFTP Edit
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 Edit
"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.
rsync file user@host:/path/
rsync user@host:/path/file .
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 Edit
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
scp also allows you to copy a file from a remote host to a remote host. An example of
scp firstname.lastname@example.org:~/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.
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:"<syntaxhighlight_dirname>" <destination_dirname>
Creating SSH Keys Edit
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
Establish Trust Edit
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
~/.ssh/id_rsa.pub file to the end of the remote
Transfer Method A: ssh-copy-id Edit
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 -i ~/.ssh/KEY email@example.com
Transfer Method B: Step-by-step Edit
The hard way to do that is to manually do each step that the above
ssh-copy-id command does automatically for you:
- First create the remote
~/.sshfolder on the destination server, if it does not already exist:
ssh user@host "mkdir ~/.ssh && chmod 700 ~/.ssh"
- Next upload your PUBLIC key only (not your private key).
scp ~/.ssh/KEY.pub firstname.lastname@example.org:.ssh/KEY.pub
- Then append 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 email@example.com "cat >> ~/.ssh/authorized_keys"
SSH Personal Configuration Edit
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 server1.example.com User domain\username IdentityFile ~/.ssh/KEY # Use this login as default for all hosts in the one domain # It will look for a key with the hostname in the key's file name Host *.example.com User domain\username IdentityFile ~/.ssh/%h_KEY # Generic configuration that applies to my private LAN. # Of note, the options to forward X11 lets you run remote graphical # programs while viewing and interacting with them locally. 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 # Catch-all settings which apply these settings to all hosts, # if the particular option has not yet already been set. # If there are a lot of keys in the SSH agent, then IdentitiesOnly is needed Host * IdentitiesOnly yes ServerAliveCountMax 2 ServerAliveInterval 20
You can now ssh into
server1.example.com with just
ssh Short_Name. 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.
Using an SSH Agent Edit
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.
- 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 — 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
The following presumes physical access to the server.
- 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 usually part of the distro's default installation for servers and workstations respectively.
- Be sure the following is in /etc/ssh/sshd_config and uncommented (that there's no # in front of them) in /etc/ssh/sshd_config on the server:
PubkeyAuthentication yes PasswordAuthentication no
- Open TCP port 22 on the server for incomming connections. This varies depending on your firewall. on-standard port.
- If the server is behind a router with DHCP:
- 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.
- Forward external TCP port 22 (or another port) on your router to port 22 on your server.
- Over on the client, create and test the a client key pair
- On the client command line, run
ssh-keygen -f ~/.ssh/server.key("rsa" is the default, it is not necessary to explicitly specify "rsa"). Consider annotating the key pair with a comment using the
- 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,
cat ~/.ssh/server.key >> ~/.ssh/authorized_keys
- Back over on the client, test that the new key works:
ssh -i ~/.ssh/server.key serve.example.com
- On the client command line, run
- (Re)start the sshd service.
- Log in again from the client using the key
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
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
-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 Edit