In this blog we will look at how to ssh into your remote server. For many purposes the backend provided by the framework might not be enough and there might be a need for command line management this is where SSH comes in handy.
The first time around it will ask you if you wish to add the remote host to a list of known_hosts, go ahead and say yes.
It is important to pay attention to this question however because this is one of SSH's major features. Host validation. To put it simply, ssh will check to make sure that you are connecting to the host that you think you are connecting to. That way if someone tries to trick you into logging into their machine instead so that they can sniff your SSH session, you will have some warning, like this:
5) Enter your login address and it will ask for password after giving that the connection will be established and you can start working.
What Is SSH?
There are a couple of ways that you can access a shell (command line) remotely on most Linux/Unix systems. One of the older ways is to use the telnet program, which is available on most network capable operating systems. Accessing a shell account through the telnet method though poses a danger in that everything that you send or receive over that telnet session is visible in plain text on your local network, and the local network of the machine you are connecting to. So anyone who can "sniff" the connection in-between can see your username, password, email that you read, and commands that you run. For these reasons you need a more sophisticated program than telnet to connect to a remote host.
SSH, which is an acronym for Secure SHell, was designed and created to provide the best security when accessing another computer remotely. Not only does it encrypt the session, it also provides better authentication facilities, as well as features like secure file transfer, X session forwarding, port forwarding and more so that you can increase the security of other protocols. It can use different forms of encryption ranging anywhere from 512 bit on up to as high as 32768 bits and includes ciphers like AES (Advanced Encryption Scheme), Triple DES, Blowfish, CAST128 or Arcfour. Of course, the higher the bits, the longer it will take to generate and use keys as well as the longer it will take to pass data over the connection.
These two diagrams on the left show how a telnet session can be viewed by anyone on the network by using a sniffing program like Ethereal (now called Wireshark) or tcpdump. It is really rather trivial to do this and so anyone on the network can steal your passwords and other information. The first diagram shows user jsmith logging in to a remote server through a telnet connection. He types his username jsmith and password C0lts06!, which are viewable by anyone who is using the same networks that he is using.
The second diagram shows how the data in an encrypted connection like SSH is encrypted on the network and so cannot be read by anyone who doesn't have the session-negotiated keys, which is just a fancy way of saying the data is scrambled. The server still can read the information, but only after negotiating the encrypted session with the client.
Requirements
Before you start, you'll need:
- Your Server adress s00000.gridserver.com ( Replace 00000 with the number of your site)
Now we will consider the instructions for the three major operating systems used : Linux, Mac OS , Windows
Mac OS
Open your Terminal application. You will see a window with a $ symbol and a blinking cursor. This is your basic command prompt. From here, you may issue the command to establish the SSH connection to your server. The most basic usage of this is as follows. Be sure to replace 00000 with your site number.
Connect to your service via SSH
Open your Terminal application. You will see a window with a $ symbol and a blinking cursor. This is your basic command prompt. From here, you may issue the command to establish the SSH connection to your server. The most basic usage of this is as follows. Be sure to replace 00000 with your site number.
ssh example.com@s00000.gridserver.com
Immediately after issuing this command, your computer will attempt to establish a connection to your server. If it is your first time connecting to that server, you will see a message asking you to confirm the identity of the machine:
The authenticity of host 'example.com (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is f9:9b:06:11:75:d4:1f:d1:3c:51:0d:22:4a:13:ff:9f.
Are you sure you want to continue connecting (yes/no) _
a
Immediately after issuing this command, your computer will attempt to establish a connection to your server. If it is your first time connecting to that server, you will see a message asking you to confirm the identity of the machine:
The authenticity of host 'example.com (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is f9:9b:06:11:75:d4:1f:d1:3c:51:0d:22:4a:13:ff:9f.
Are you sure you want to continue connecting (yes/no) _
Make sure you entered the address properly, and type yes, followed by the return key, to proceed.
You will then be prompted to enter your password:
example.com@s00000.gridserver.com's password: _
Type or copy/paste your SSH user's password into Terminal. You will not see the cursor move while entering your password. This is normal. Once you are finished inputting your password, press return on your keyboard. At that point, you will be connected to your server remotely through SSH.
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
example.com@XX:~$LINUX
This tutorial isn't going to cover how to install SSH, but will cover how to use it for a variety of tasks. Consult your Linux distribution's document for information on how to setup OpenSSH.
Chances are that if you are using a version of Linux that was released after 2002, that you already have OpenSSH installed. The version of SSH that you will want to use on Linux is called OpenSSH. As of this writing (October 2009), the latest version available is 5.3, but you may encounter versions from 3.6 on up. If you are using anything lower than version 3.9, I'd strongly advise you to upgrade it.
OpenSSH can be obtained from http://www.openssh.org/
To really make ssh useful, you need a shell account on a remote machine, such as on a Suso account.
The first thing we'll do is simply connect to a remote machine. This is accomplished by running 'ssh hostname' on your local machine. The hostname that you supply as an argument is the hostname of the remote machine that you want to connect to. By default ssh will assume that you want to authenticate as the same user you use on your local machine. To override this and use a different user, simply use remoteusername@hostname as the argument. Such as in this example:
ssh username@username.suso.org
The first time around it will ask you if you wish to add the remote host to a list of known_hosts, go ahead and say yes.
The authenticity of host 'arvo.suso.org (216.9.132.134)' can't be established.
RSA key fingerprint is 53:b4:ad:c8:51:17:99:4b:c9:08:ac:c1:b6:05:71:9b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'arvo.suso.org' (RSA) to the list of known hosts.
It is important to pay attention to this question however because this is one of SSH's major features. Host validation. To put it simply, ssh will check to make sure that you are connecting to the host that you think you are connecting to. That way if someone tries to trick you into logging into their machine instead so that they can sniff your SSH session, you will have some warning, like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for arvo.suso.org has changed,
and the key for the according IP address 216.9.137.122
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/suso/.ssh/known_hosts:10
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
96:92:62:15:90:ec:40:12:47:08:00:b8:f8:4b:df:5b.
Please contact your system administrator.
Add correct host key in /home/suso/.ssh/known_hosts to get rid of this message.
Offending key in /home/suso/.ssh/known_hosts:53
RSA host key for arvo.suso.org has changed and you have requested strict
checking.
Host key verification failed.
If you ever get a warning like this, you should stop and determine if there is a reason for the remote server's host key to change (such as if SSH was upgraded or the server itself was upgraded). If there is no good reason for the host key to change, then you should not try to connect to that machine until you have contacted its administrator about the situation. If this is your own machine that you are trying to connect to, you should do some computer forensics to determine if the machine was hacked (yes, Linux can be hacked). Or maybe your home computer's IP address has changed such as if you have a dynamic IP address for DSL. One time I received this message when trying to connect to my home machine's DSL line. I thought it was odd since I hadn't upgraded SSH or anything on my home machine and so I choose not to try to override the cached key. It was a good thing that I didn't try because I found out that my dynamic IP address had changed and that out of chance, another Linux machine running OpenSSH took my old IP.
After saying yes, it will prompt you for your password on the remote system. If the username that you specified exists and you type in the remote password for it correctly then the system should let you in. If it doesn't, try again and if it still fails, you might check with the administrator that you have an account on that machine and that your username and password is correct.
Generating a key
Now that you have spent all that time reading and are now connected, go ahead and logout. ;-) Once you're back to your local computer's command prompt enter the command 'ssh-keygen -t dsa'.
ssh-keygen -t dsa
It should begin spitting out the following:
Generating public/private dsa key pair.
Enter file in which to save the key (/home/localuser/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/localuser/.ssh/id_dsa.
Your public key has been saved in /home/localuser/.ssh/id_dsa.pub.
The key fingerprint is:
93:58:20:56:72:d7:bd:14:86:9f:42:aa:82:3d:f8:e5 localuser@mybox.home.com
It will prompt you for the location of the keyfile. Unless you have already created a keyfile in the default location, you can accept the default by pressing 'enter'.
Next it will ask you for a passphrase and ask you to confirm it. The idea behind what you should use for a passphrase is different from that of a password. Ideally, you should choose something unique and unguessable, just like your password, but it should probably be something much longer, like a whole sentence. Here are some examples of passphrases I've used in the past:
The right thing changes from state to state
the purpose of life is to give it purpose
They're not going to guess this passphrase!
The RIAA can just suck my big ass
It is never a good day at Teletron
Some passphrases that I've used have had as many as 60 characters along with punctuation and numbers. This makes the passphrase harder to guess. To give you an idea of how much more secure a passphrase is than a password. Consider this. Even if you narrowed down the number of words someone could use in a passphrase to 2000 potential words, if that person used 5 words in a sentence from that 2000 word set, it would mean there are 32,000,000,000,000,000 different combinations. Compare this with 6,095,689,385,410,816, which is the total possible combinations in an 8 character password using upper and lower case characters, numbers and punctuation (about 94 potential characters). So an 8 character password has 5.25 times less combinations than a 5 word passphrase. In actuality, most people choose words from a set of 10,000 or more words, bringing the complexity of a 5 word passphrase to 16,405 or more times greater than that of a 8 character password. So on average, the difficulty of cracking a passphrase is much greater than any password that could be used. Interestingly, the potential number of combinations of 8 word passphrase of someone with an adult vocabulary (8000 words or more) is almost equal to the number of 8 character password combinations multiplied by itself or about 16,777,216,000,000,000,000,000,000,000,000 combinations.
Don't use any famous quotes or phrases for your passphrase, they may be easily guessed by another person or by a brute force cracking program.
The reason why you would generate a keyfile is so that you can increase the security of your SSH session by not using your system password. When you generate a key, you are actually generating two key files. One private key and one public key, which is different from the private key. The private key should always stay on your local computer and you should take care not to lose it or let it fall into the wrong hands. Your public key can be put on the machines you want to connect to in a file called .ssh/authorized_keys. The public key is safe to be viewed by anybody and mathematically cannot be used to derive the private key. Its just like if I gave you a number 38,147,918,357 and asked you to find the numbers and operations I used to generate that number. There are nearly infinite possibilities.
Whenever you connect via ssh to a host that has your public key loaded in the authorized_keys file, it will use a challenge response type of authentication which uses your private key and public key to determine if you should be granted access to that computer It will ask you for your key passphrase though. But this is your local ssh process that is asking for your passphrase, not the ssh server on the remote side. It is asking to authenticate you according to data in your private key. Using key based authentication instead of system password authentication may not seem like much of a gain at first, but there are other benefits that will be explained later, such as logging in automatically from X windows.
Installing your public key manually
If you do not have the ssh-copy-id program available, then you must use this manual method for installing your ssh key on the remote host. Even if you do have the ssh-copy-id program, its good to do the manual installation at least once so that you have a good understanding of what is going on, because this is where a lot of people end up having problems.
Go ahead and copy your public key which is in ~/.ssh/id_dsa.pub to the remote machine.
scp ~/.ssh/id_dsa.pub username@arvo.suso.org:.ssh/authorized_keys
It will ask you for your system password on the remote machine and after authenticating it will transfer the file. You may have to create the .ssh directory in your home directory on the remote machine first. By the way, scp is a file transfer program that uses ssh. We'll talk more about it later.
Now when ssh to the remote machine, it should ask you for your key passphrase instead of your password. If it doesn't, it could be that the permissions and mode of the authorized_keys file and .ssh directory on the remote server need to be set more restrictively. You can do that with these commands on the remote server:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
You can also put the public key in the remote authorized_keys file by simply copying it into your paste buffer, logging into the remote machine and pasting it directly into the file from an editor like vi, emacs or nano. I would recommend using the 'cat' program to view the contents of the public key file though because using less will end up breaking the single line into multiple lines.
cat ~/.ssh/id_dsa.pub
Installing your public key automatically
A newer way that you can quite easily install your public ssh key on a remote host is with the ssh-copy-id program like this:
ssh-copy-id yourusername@your.website.com
It will prompt you for your password on the remote host and take care of the rest. That was easy. So why didn't I just tell you how to use this program in the first place? Well, in my experience, many of the problems people have with ssh revolve around trying to get their ssh public key installed correctly. Its a good thing that they've made a program to do the dirty work for you, but in the interest of building your skills, you should at least do the manual install once so that you know what is involved.
Using the ssh-agent program
The true usefulness of using key based authentication comes in the use of the ssh-agent program. Usually, the ssh-agent program is a program that starts up before starting X windows and in turn starts X windows for you. All X windows programs inherit a connection back to the ssh-agent, including your terminal windows like Gnome Terminal, Konsole, xfce4-terminal, aterm, xterm and so on. What this means is that after you've started up X windows through ssh-agent, you can use the ssh-add program to add your passphrase one time to the agent and the agent will in turn pass this authentication information automatically every time you need to use your passphrase. So the next time you run:
ssh username@arvo.suso.org
you will be logged in automatically without having to enter a passphrase or password. Most recent distributions will automatically start ssh-agent when you login to X windows through a session manager like gdm (graphical login). I found that as of this writing the following distributions started ssh-agent by default.
- Debian
- Fedora
- Gentoo
- SuSE
- Ubuntu
Most distributions prior to about 2002 did not start it.
Don't worry if you don't see your distro listed in here. You can check if it is already running by running this command.
ps auxw
If there is an ssh-agent process listed there, then you can just start using it, otherwise, you should consult your distribution's documentation on OpenSSH and running the ssh-agent.
Once you've verified that ssh-agent is running, you can add your ssh key to it by running the ssh-add command:
ssh-add
If the program finds the DSA key that you created above, it will prompt you for the passphrase. Once you have done so it should tell you that it has added your identity to the ssh-agent:
Identity added: /home/username/.ssh/id_dsa (/home/username/.ssh/id_dsa)
Now you can try logging into that remote machine again and this time you will notice that it just logs you right in without prompting you for any password or passphrase.
Windows
Using SSH on Windows is not as quick and easy as on UNIX, but it's still possible using PuTTY. This article will explain how to connect to an SSH server using PuTTY.
1) Download putty from here. There is no installation required for putty. You directly download the executable file and run it.
1) Download putty from here. There is no installation required for putty. You directly download the executable file and run it.
2) Open your putty client by double-clicking. You should get this screen
3) Enter your host address in the space provided and select the connection type as SSH ( It is SSH by default)
4) Now click on open. If this is the first time you are doing it from your system it will ask you whether to trust or not. Just click on yes. This should open up a command screen asking for login address:
5) Enter your login address and it will ask for password after giving that the connection will be established and you can start working.
