SSH Tutorial for linux

SSH Tutorial for linux

1) What is SSH

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 bits on up to as high as 32768 bits and includes ciphers like AED(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.

2) Getting Started

ssh username@username.suso.org

The first time around it will ask you if you wish to add 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 simple, 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 their machine instead so that they can sniff your ssh session, you will have something 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.

3） Generating a key

ssh-keygen -t rsa -b 2048

It should spitting out the following:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/localuser/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/localuser/.ssh/id_rsa.
Your public key has been saved in /home/localuser/.ssh/id_rsa.pub.
The key fingerprint is:
e7:06:7f:2c:32:bf:84:a8:5b:8d:63:98:f3:ee:a2:8b localuser@mybox.home.com
The key's randomart image is:
+---[RSA 4096]----+
|                 |
|                 |
|                 |
|                 |
|        S .      |
|     o + * .     |
|    + * = * o    |
| .  .* . * o     |
|E ooo=+   o.     |
+-----------------+

Next it will ask you for a passphrase and ask you to confirm it. The idea behind that you should use for a passphrase is different from that of a password.

3-1） 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 public key on the your remote machine. 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_rsa.pub to the remote machine.

scp ~/.ssh/id_rsa.pub username@host:.ssh/authorized_keys

Now when ssh to the remote machine, it should ask you for your passphrase instead of password. If it doesn’t, it could be that permission 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

3-2） Installing your public key automatically

ssh-copy-id username@host

4） 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-ternimal, 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 ssh-agent and the ssh-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@host

you will be logged in automatically without having to enter a passphrase or password.

you can add your ssh key to it by running the ssh-add command:

ssh-add ~/.ssh/id_rsa

这样你在登录远程机器的时候就不会询问你passphrase了，就能自动登录。

5） X11 Session Forwarding

One lesser known feature of X windows is its network transparency.
It was designed to be able to transmit window and bitmap information over a network connection. So essentially you can login to a remote desktop machine and run some X window program like Gnumeric, or even firefox and the program will run on the remote computer, but will display its graphical output on your local computer.

The key to making it work is using the -X option, which means “forward the X connection through the SSH connection”. This is a form of tunneling.

ssh -X username@host

If this does’t work, you may have to setup the ssh daemon on the remote computer to allow X11Forwarding, check that the following lines set in /etc/ssh/sshd_config on that computer:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

For some newer programs and newer version of X windows, you may need to use the -Y option instead for trusted X11Forwarding.
Try using this option if your X11 windows program fails to start running with a message like this one that was for Gimp:

The program 'gimp-2.2' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 154 error_code 3 request_code 38 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error()
function.)

6) TCP Port Forwarding

Like X11 sessions forwarding, SSH can also forward other TCP application level ports both forward and backward across the SSH session that you establish.

For example, you can setup a port forward for your connection from your home machine to server1.com so that it will take connection to localhost port 3306 and forward them to the remote side mysql.com port 3306. Port 3306 is the port that the MySQL server listens on, so this would allow you to bypass the normal checks that the MySQL server would make and allow you to run GUI MySQL programs on your local machine while sing the database on your suso account. Here is the command to accomplish this:

ssh -L 3306:mysql.com:3306 username@server1.com

The -L (which means Local Port ) takes one argument of

<local-port>:<connect-to-host>:<connect-to-port>

So you specify what host and port the connection will go to on the side of the SSH connection.
When you make a connection to the local-port, it sends data through the SSH connection to connect-to-host:connect-to-port on the other side. From the point of view of connect-to-host, its as if the connection came from the SSH server that you login to. In the case above, server1.com.
This is much like a VPN connection allows you to act like you are making connections from the network that you VPN into.

You can also reverse the direction and create a reverse port forward.
This can be useful if you want to connect to the machine remotely to allow connections back in. For instance, I use this sometimes so that I can create a reverse port 22 tunnel so that I can reconnect to a machine that is behind a firewall once I have gone away from that network.

ssh -R 8022:localhost:22 username@my.home.ip.address

This will connect to my home machine and start listening port 8022 there. Once I get home, I can then connect back to the machine I created the connection from using the following command:

ssh -p 8022 username@localhost

7) SOCKS5 proxying

So that’s great and all, but eventually you are going to want to know how you can do tunneling without having to specify the address that you want to forward to.
This is accomplished through the -D SOCKS5 option.

ssh -D 9999 username@remotehost.com

8) Running Commands Over SSH

Sometimes you don’t really want to run a shell like Bash on the host that you are connecting to. Maybe you just want to run a command and exit. This is simply accomplished by putting the command you wish to run at the end of your ssh connection command.

ssh username@remotehost.com ls -l /

This will probably generate output similar to the following:

total 220
drwxr-xr-x    2 root root    4096 Nov  9 04:08 bin
drwxr-xr-x    3 root root    4096 Nov 11 09:29 boot
drwxr-xr-x   23 root root  122880 Nov 14 02:36 dev
drwxr-xr-x   68 root root   12288 Jan 10 04:03 etc
drwxr-xr-x  189 root root    4096 Jan  9 00:40 home
drwxr-xr-x    2 root root    4096 Mar 12  2004 initrd
drwxr-xr-x    9 root root    4096 Nov  9 04:07 lib
drwx------    2 root root   16384 Sep 26  2004 lost+found
drwxr-xr-x    2 root root    4096 Apr 14  2004 misc
drwxr-xr-x    6 root root    4096 Nov 12 02:11 mnt
drwxr-xr-x    3 root root    4096 Oct 15 22:17 opt
dr-xr-xr-x  307 root root       0 Nov 14 02:36 proc
drwx------   44 root root    8192 Jan  9 16:23 root
drwxr-xr-x    2 root root    8192 Nov  9 04:08 sbin
drwxr-xr-x    2 root root    4096 Mar 12  2004 selinux
drwxr-xr-x    9 root root       0 Nov 14 02:36 sys
drwxrwxrwt   20 root root    4096 Jan 10 06:46 tmp
drwxr-xr-x   17 root root    4096 Dec  7  2004 usr
drwxr-xr-x   26 root root    4096 Jan 10  2005 var

9) Using SCP

SCP is basically a program that uses the SSH protocol to send files between hosts over and encrypted connection.

Here is basic command that copies a file called report.doc from the local computer to a file by the same name on the remote computer.

scp report.doc username@remote.host:

To copy the file back from the server, you just reverse the from and to.

scp username@remote.host:report.doc report.doc

If you want to specify a new name for the file on the remote computer, simply give the name after the colon on the to side.

scp report.doc username@remote.host:monday.doc

Or if you want to copy it to a directory relative to the home directory for the remote user specified.

scp report.doc username@remote.host.net:reports/monday.doc

To copy a whole directory recursively to a remote location, use the -r option. The following command copies a directory named mail to the home directory of the user on the remote computer.

scp -r mail username@remote.host.net:

Sometimes you will want to preserve the timestamps of the files and directories and if possible, the users, groups and permissions.
To do this, use the -p option.

scp -rp mail username@remote.host.net:

10) Keeping Your SSH Session Alive

Sometimes you may have trouble keeping your SSH session up and idle. For whatever reason, the connection just dies after x minutes of inactivity. Usually this happens because there is a firewall between you and the internal that is configured to only keep stateful connections in its memory for 15 or so minutes
Fortunately, in recent versions of OpenSSH, there is a fix for this problem. Simply put the following:

Host *
Protocol 2
TCPKeepAlive yes
ServerAliveInterval 60

in the file:

~/.ssh/config

Original blog site:
https://support.suso.com/supki/SSH_Tutorial_for_Linux#Using_the_ssh-agent_program