SSH (Secure SHell) is a network protocol which provides a replacement for insecure remote login and command execution facilities, such as telnet, rlogin and rsh. SSH encrypts traffic in directions, preventing traffic sniffing and password theft. SSH standard port 22. SSH also offers several additional useful features:
• Compression: traffic may be optionally compressed at the stream level.
• Public key authentication: optionally replacing password authentication.
• Authentication of the server: making “man-in-the-middle” attack more difficult
• Port forwarding: arbitrary TCP sessions can be forwarded over an SSH connection.
• X11 forwarding: SSH can forward your X11 sessions too.
• File transfer: the SSH protocol family includes two file transfer protocols.
Check the installation status for SSH packages on RHEL6 Linux
[root@server1 Desktop]# rpm -qa | grep openssh*
openssl-1.0.0-20.el6.x86_64
openssh-5.3p1-70.el6.x86_64
openssh-clients-5.3p1-70.el6.x86_64
openssh-askpass-5.3p1-70.el6.x86_64
openssh-server-5.3p1-70.el6.x86_64
Required service stop| start | restart
[root@client1 Desktop]# service sshd status
openssh-daemon (pid 2221) is running…
Boot level service starting
[root@client1 Desktop]# chkconfig sshd –list | on | off
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Check the SSH configuration file
[root@client1 Desktop]# rpm -qlc openssh-server
/etc/pam.d/ssh-keycat
/etc/pam.d/sshd
/etc/ssh/sshd_config – configuration file
/etc/sysconfig/sshd
Check the SSH default port number
[root@server1 Desktop]# netstat -tulnp | grep ssh
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2143/sshd
tcp 0 0 :::22 :::* LISTEN 2143/sshd
Scan the remote server default SSH port numer
[root@server1 Desktop]# nmap -sTU -p 22 station1.example.com
Starting Nmap 5.21 ( http://nmap.org ) at 2012-12-10 15:43 IST
Nmap scan report for station1.example.com (192.168.1.101)
Host is up (0.00082s latency).
PORT STATE SERVICE
22/tcp open ssh
22/udp closed ssh
MAC Address: 00:0C:29:39:E2:9B (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds
Basic SSH usage
Remote login
The basic syntax to log into a remote host is
ssh hostname
If you want to specify a username, you may do it using an rlogin-compatible format:
ssh -l user hostname or ssh user@hostname
If you are running your sshd on a non-standard port, you may also specify that on the command-line:
ssh -p 2222 user@hostname
Initial server key discovery
The first time you client connects to ssh server, it asks you to verify the server’s key.
[root@server1 Desktop]# ssh station1.example.com
The authenticity of host ‘station1.example.com (192.168.1.101)’ can’t be established.
RSA key fingerprint is 2e:53:bc:ff:f5:c7:39:34:e2:37:14:c1:59:00:fc:01.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘station1.example.com,192.168.1.101’ (RSA) to the list of known hosts.
root@station1.example.com’s password:
This is done to prevent an attacker impersonating a server, which would give them the opportunity to capture your password or the contents of your session. Once you have verified the server’s key, it is recorded by the client in ~/.ssh/known_hosts so it can be automatically checked upon each connection. If the server’s key changes, the client raises a warning:
[root@server1 Desktop]# cat /root/.ssh/known_hosts
station1.example.com,192.168.1.101 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvf/OzChNlHyidERR2Rk+kv99gdT+CUh5ghPlM+Twc0GzD3xkTpTm0HBT5qD1VyiqNP9DQWf+MTbizRHCnKon/slItM6D4pZMBKT9TnBPAPaEiG8chAiLqY7G7OaclON8VUoPofcmr15wmJHcrSFkAsaZwF6x5HwZBcbD4hw3xO5h/GK5Tk5PsmNLiRLYcOWDhz3sI5HeR2SnigpsO9FynAeK0b2N0F+WHWCIu0CJBMsq2AgfMRNj01w+Ug0aVEoVuUe7VUngxFJTJYxaMKVBks29atmUE0OG+I8U0VQsyAYgd6xozh6DznkpaGgJ1nq5mRzyu4VObf3Scf1nxu8k9Q==
Executing commands remotely
SSH also supports remote command execution. When you log in, a pseudo-terminal is assigned to your session and your session will remain open until you explicitly log out or is killed from the server end. In remote command execution mode, SSH will execute your specified command with the remote user’s shell and then exit as soon as it finished:
[root@server1 Desktop]# ssh root@station2.example.com “cat /etc/hosts”
root@station2.example.com’s password:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.102 station2.example.com station2
[root@server1 Desktop]# ssh -t root@station2.example.com “vim /etc/hosts”
root@station2.example.com’s password:
:q!
Connection to station2.example.com closed.
[root@server1 Desktop]#
File transfer
SSH offers a number of ways to transfer files between machines. Most of these take advantage of the aforementioned input/output redirection features of SSH.
scp
scp is the original SSH file transfer mechanism. It is modeled on BSD rcp, a protocol with a 15+ year history which has no RFC. Its syntax is very simple:
scp [user@]host:/path/to/source/file /path/to/destination/file
Will copy a remote file to a local destination. To copy a local file to a remote destination, one
uses the opposite syntax:
scp /path/to/source/file [user@]host:/path/to/destination/file
In either of these cases, the source file may be a wild-card matching multiple files. If a patch is left off the destination file specification, the remote user’s home directory is assumed. E.g.:
scp /home/djm/*.diff hachi:
scp does not support copying between two remote destinations very well. It is possible using the following syntax:
scp [user@]host1:/path [user@]host2:/path
For this to work, host1 must be configured for password less access to host2 (see section 4). Also
little feedback is given to the user on whether the operation succeeded. scp can also copy files recursively:
scp -r source-path [user@]host:/destination-path
scp -r [user@]host:/source-path /destination-path
rsync
Rsync4 is a package and algorithm to two sets of files into synchronisation. Rsync just sends the differences between the two sets of files over the network instead of sending their entire contents.
Rsync is often used as a very powerful mirroring process or as a replacement for the scp/rcp command. Rsync includes support for ssh with a single command-line option.
Rsync can be used to simple list files on the remote machine, in a particular directory:
rsync -e ssh djm@hachi:/tmp/
To synchronise/copy a remote set of files to a local set:
rsync -ve ssh djm@hachi:/bin/c* /tmp
To synchronise/copy a local set of files with a local set:
rsync -ve ssh djm@hachi:/bin/c* /tmp
Rsync has many more options and features, these are best described in its excellent man page.
[root@server1 Desktop]# touch a b c
[root@server1 Desktop]# rsync -r /root/Desktop/ station1.example.com:/root/Desktop/
root@client1.example.com’s password:
Public key authentication
SSH includes an ability to authenticate users using public keys. Instead of authenticating the user with a password, the server will verify a challenge signed by the user’s private key against its copy of the user’s public key. Setting up public key authentication requires you to generate a public/private key pair and install the public portion on the server. It is also possible to restrict what a given key is able to do and what addresses they are allowed to log in from.
Generating public keys
To generate a public key, use the ssh-keygen utility. ssh-keygen can generate three types of keys: rsa, dsa and rsa1. rsa1 keys are used for authentication by the legacy SSH protocol v.1, the other two types may be used for SSH protocol v.2 public key authentication. Select the type of key that you wish to generate by passing the -t option to ssh-keygen. Normally you will want to use rsa keys as they are somewhat faster to authenticate than dsa keys.
[root@server1 Desktop]# su – senthil
[senthil@server1 ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/senthil/.ssh/id_rsa):
Created directory ‘/home/senthil/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/senthil/.ssh/id_rsa.
Your public key has been saved in /home/senthil/.ssh/id_rsa.pub.
The key fingerprint is:
93:4e:69:c2:a2:5b:a6:f3:04:e1:c3:cc:2d:69:a2:a7 senthil@server1.example.com
The key’s randomart image is:
+–[ RSA 2048]—-+
| |
| |
| . |
| = + . o |
|. @ o o S |
|.o = . = . |
|. o + . |
| o.* |
|E oo. |
+—————–+
[senthil@server1 ~]$ ssh-copy-id babu@station1.example.com
The authenticity of host ‘station1.example.com (192.168.1.101)’ can’t be established.
RSA key fingerprint is 2e:53:bc:ff:f5:c7:39:34:e2:37:14:c1:59:00:fc:01.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘station1.example.com,192.168.1.101’ (RSA) to the list of known hosts.
babu@station1.example.com’s password:
Now try logging into the machine, with “ssh ‘babu@station1.example.com'”, and check in:
.ssh/authorized_keys
to make sure we haven’t added extra keys that you weren’t expecting.
Now doesn’t required ssh login password
[senthil@server1 ~]$ ssh babu@station1.example.com
[babu@station1 ~]$ logout
Connection to station1.example.com closed.
[senthil@server1 ~]$ logout
Now check other user ssh login password required
[root@server1 Desktop]# ssh babu@station1.example.com
babu@station1.example.com’s password:
Last login: Mon Dec 10 18:16:17 2012 from server1.example.com
[babu@station1 ~]$ logout
Connection to station1.example.com closed.
[root@server1 Desktop]#
[root@server1 Desktop]# ll -a /home/senthil/.ssh/
total 20
drwx——. 2 senthil senthil 4096 Dec 10 18:15 .
drwx——. 5 senthil senthil 4096 Dec 10 18:15 ..
-rw——-. 1 senthil senthil 1675 Dec 10 18:15 id_rsa
-rw-r–r–. 1 senthil senthil 409 Dec 10 18:15 id_rsa.pub
-rw-r–r–. 1 senthil senthil 416 Dec 10 18:15 known_hosts
[root@server1 Desktop]# su – senthil
[senthil@server1 ~]$ ssh babu@station1.example.com
Last login: Mon Dec 10 18:16:36 2012 from server1.example.com
[babu@station1 ~]$ pwd
/home/babu
[babu@station1 ~]$ ll -a .ssh/
total 12
drwx——. 2 babu babu 4096 Dec 10 18:15 .
drwx——. 5 babu babu 4096 Dec 10 18:15 ..
-rw——-. 1 babu babu 409 Dec 10 18:15 authorized_keys
[babu@station1 ~]$ cat .ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApcKFNDg7+12XyCTO2khbUaLTdyrxD+HoHy4e2Kq4ihghQJW7A/FPJqZdd5yreKxiolHAcqnSHFCDCiTk/v7C3l8LJpx4mifM81x6ZwXTBBfNANKFERob3cIbWstW2nv+smar+2j+KzkdXKIcc87V7IIG5mUAzHfN+1F8PUOg+bwGzbjwxuXK/aZZAR1DlrBnoqY6XZXmSLwCg0LmkPMZ0aXcL5gFHVeUEZBZOJQ0duVoJufSJm6giQu8CWqgvQJKKN4uTB/rCfLsiGzq7qOSK6As+8swtdySVP10c6PyWBf/XNQZx4mvYRu1acbY4TdjBE5gnrzHMkr5xCXIUZ4X5Q== senthil@server1.example.com
[babu@station1 ~]$ logout
Connection to station1.example.com closed
.
[senthil@server1 ~]$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApcKFNDg7+12XyCTO2khbUaLTdyrxD+HoHy4e2Kq4ihghQJW7A/FPJqZdd5yreKxiolHAcqnSHFCDCiTk/v7C3l8LJpx4mifM81x6ZwXTBBfNANKFERob3cIbWstW2nv+smar+2j+KzkdXKIcc87V7IIG5mUAzHfN+1F8PUOg+bwGzbjwxuXK/aZZAR1DlrBnoqY6XZXmSLwCg0LmkPMZ0aXcL5gFHVeUEZBZOJQ0duVoJufSJm6giQu8CWqgvQJKKN4uTB/rCfLsiGzq7qOSK6As+8swtdySVP10c6PyWBf/XNQZx4mvYRu1acbY4TdjBE5gnrzHMkr5xCXIUZ4X5Q== senthil@server1.example.com
[senthil@server1 ~]$
How to reduce the Delay in SSH Login Prompt:
You may came across this situation. At the time of logging in the shell prompt using SSH,
– Connection will be taking a fraction of second
– After/While entering the Password its taking more time to provide the shell prompt.
To fix this issue:
This is related to DNS. We have to change dns related entries in ssh config file to reduce this delay.
Note :
Be careful when doing this on production servers.
This activity may disconnect all the users from the system who are logged in to that machine using SSH.
By default UseDNS option in this file is disable. We have to uncomment this option and then edit this entry to no. As below..
# vi /etc/ssh/sshd_config
Just search for UseDNS..
#UseDNS yes
Change that to, (Simply Uncomment it)
UseDNS no
save and exit the file and then just reload ssh service to take effect what ever changes we did..
# service sshd reload
Now try to login and observe, delay will be reduced.
How to Disable SSH root login:
Providing direct login access to root via SSH is not a good practice. Administrators should use sudo to switch to root after logged in as themselves. this will helpful in auditing in terms of security.
Here is the step by step procedure to disable/deny direct root login via SSH
1. Login to the server as Root
2. Edit /etc/ssh/sshd_config
Look for the line,
PermitRootLogin=Yes
and then change the value of it to,
PermitRootLogin=No
3. Restart the sshd service and make sure its turned on
service sshd restart or /etc/init.d/sshd restart
service sshd status
Apntechunix 