research and analysis of ssh
TRANSCRIPT
College Computer Engineering
Class CMPE 208 Professor Name Shai Silberman
Student Name Ikwhan Chang Student ID 010754107
Student Name Kunal Goswami Student ID 010772541
Student Name Mithila Dhawade Student ID 010106551
Student Name Akhil Pal Student ID 010694840
Project SSH Protocol
SSH Research and Analysis of SSH
1
Table of Contents
1. Individual Contribution............................................................................................ 3
2. Lab Setup ................................................................................................................... 3 Our topologies................................................................................................................. 3 Network Setup ................................................................................................................ 3 SSH Service Setup .......................................................................................................... 4
SSH Protocol 2 .............................................................................................................. 4 SSH Protocol 1 .............................................................................................................. 5
3. Overview ................................................................................................................... 7 Objective:......................................................................................................................... 7 Expected findings:........................................................................................................... 7 Expected Learning Outcomes: ........................................................................................ 7
4. Execution .................................................................................................................... 7 SSH Protocol 2 ................................................................................................................. 8 SSH Protocol 1 ............................................................................................................... 15
5. History of SSH ....................................................................................................... 19
6. Structure of SSH .................................................................................................... 20 SSH Protocol: Definition and Importance................................................................... 20 Key features of SSH ...................................................................................................... 20
1) Automatic Public private key generation.......................................................... 20 2) Manual public private key generation .............................................................. 21
Characteristics of SSH .................................................................................................. 21 Versions of SSH ............................................................................................................ 21 Advantages of using SSH Protocol .............................................................................. 23
7. SSH Authentication .............................................................................................. 23
8. SSH: Key Generation............................................................................................ 24 Listing 1. Create a list of SSH key pair ........................................................................ 25 Listing 2. Copying the private key in the authorized_keys file on the source host to a
destination host ................................................................................................................... 26 ssh-agent configuration and use .................................................................................. 27 List 4. An example of using a ssh-keyscan .................................................................. 28 SSH configured using the UNIX applications and scripts ......................................... 29 Listing 5. Example configuration that limits the authorized_keys file on the remote
host....................................................................................................................................... 30 Reliable Host configuration environment that can use SSH...................................... 31 Conclusion..................................................................................................................... 32
9. Difference between SSH protocol 1 and protocol 2 ....................................... 32
10. SSH Protocol and Packet structure ................................................................. 33 SSH Protocol Stack ....................................................................................................... 33 SSH Packet Formation .................................................................................................. 34
2
11. SSH Packet Exchange ........................................................................................ 35 SSH_MSG_KEXINIT .................................................................................................... 36 • SSH_MSG_KEXINIT................................................................................................. 36 • SSH_MSG_SERVICE_REQUEST ............................................................................. 36
12. Port Forwarding(SSH Tunneling) .................................................................. 37 Definition ...................................................................................................................... 37 Type of port forwarding ............................................................................................... 38
Dynamic Port Forwarding.......................................................................................... 38 How to SSH tunneling(Window) ................................................................................. 38
13. SSH Attacks ........................................................................................................ 42
14. References ............................................................Error! Bookmark not defined.
3
1. Individual Contribution
The following are the tasks which every team member performed while executing this lab.
Name Research Tasks Lab Env tasks
Report Tasks
Kunal Goswami 5,1 (from references) SSH
commands
Overview, SSH
definition, learning outcomes.
Ikwhan Chang 6,9(from references) SSH Client
and Server
Environment
Setup, commands and conclusion
Akhil Pal 3,4,7 (from
references)
Wireshark
capturing of the packets
Other SSH
details and findings
Mithila Dhawade 2,8 (from references)
Stimulate SSH Traffic
Structure of SSH and meaning.
2. Lab Setup
Our topologies
We have simple hypothetical simulation topologies. There are two VMs and one will be
working as SSH server and the other will be working as SSH client. For SSH service, we
installed Open SSH each machine. The most important thing in our simulation environment
is we use 6.9 version of Open SSH though there are newest and more secure version 7.1 because we want to establish SSH protocol 1 and 2 therefore we can compare each version.
Network Setup
4
(Fig: server’s IP)
(Fig: Client’s IP)
SSH Service Setup
SSH Protocol 2
Since SSH protocol version 2 is most commonly used, we can setup openssh protocol 2
by using simple command: apt-get install openssh-server. It will install openssh server into server’s machine and then we simply run the command of “service ssh start” to run the
service.
5
If we need to configure SSH, open the /etc/ssh/sshd_config and then modify something. For example, we can open Protocol 1 while we change the number of Protocol environment.
Or, we can change the SSH port from 22 to other via Port environments in sshd_config file.
Finally, we can see there are port number of 22 as SSH server, which means ready to SSH
service.
SSH Protocol 1
6
As we mentioned above, we can open both of the protocol 2 and 1 by modifying
sshd_config file. However, due to vulnerability of Protocol 1, the current openssh-
server , provided by Ubuntu repository, cannot provide protocol 1. For enable protocol 1,
we need install the other version which possible to enable protocol 1
We can install that version via command of apt-get install openssh-server=1:6.9p1-
2ubuntu0.1 Once installed, we need to modify the sshd_config file followed by these
steps:
1) Modify from “Protocol 2” to “Protocol 2,1”
2) Add “HostKey /etc/ssh/ssh_host_key”
Since we configured that we will use the public key of /etc/ssh/ssh_host_key, we need
7
to create ssh key via ssh-keygen commands.
For making ssh key, we need to input “ssh-keygen –f /etc/ssh/ssh_host_key –N ‘’ –t rsa1’ and then just restart the ssh service via command of “service ssh restart” and finally we are
ready to provide the SSH server with protocol 1
3. Overview
Objective:
The objective of this project is to be able to demonstrate the usage of SSH protocol over a client server model along with the packet analysis with the help of WireShark.
Expected findings:
- The structure of SSH protocol and the exchange of messages for the establishment of
an SSH Session.
- Vulnerabilities of SSH
- Information about the various standards involving SSH. - Various attacks which can be used against SSH.
- The reason for its robustness and security.
Expected Learning Outcomes:
- Insights from the analysis of packets involved during the creation of a session.
- Mitigation techniques for the various attacks which exploit the vulnerabilities of SSH. - Importance of SSH in communication.
4. Execution
8
SSH Protocol 2
Client can connect the server via command of “ssh –v 192.168.0.18”. The parameter of
–v is just let ssh know we’ll use debug mode. Here is debug file of when SSH client try
to connect the SSH server.
SSH Client log file
9
OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.18 [192.168.0.18] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/cmpe208/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cmpe208/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cmpe208/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cmpe208/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cmpe208/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cmpe208/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cmpe208/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cmpe208/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.9p1 Ubuntu-
2ubuntu0.1
debug1: match: OpenSSH_6.9p1 Ubuntu-2ubuntu0.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.18:22 as 'cmpe208'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client [email protected] <implicit> none
debug1: kex: client->server [email protected] <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256
SHA256:efgc35v8G7pHnn7d/FsoWhHXHqq1VWDOGYcXxAxaKuQ
debug1: Host '192.168.0.18' is known and matches the ECDSA host key.
debug1: Found key in /home/cmpe208/.ssh/known_hosts:1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/cmpe208/.ssh/id_rsa
debug1: Trying private key: /home/cmpe208/.ssh/id_dsa
debug1: Trying private key: /home/cmpe208/.ssh/id_ecdsa
debug1: Trying private key: /home/cmpe208/.ssh/id_ed25519
debug1: Next authentication method: password
10
debug1: Authentication succeeded (password).
Authenticated to 192.168.0.18 ([192.168.0.18]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 2 clearing O_NONBLOCK
Connection to 192.168.0.18 closed.
Transferred: sent 3072, received 5176 bytes, in 65.4 seconds
Bytes per second: sent 47.0, received 79.2
debug1: Exit status 0
In this log, the client will follow the server’s configurations. Overall steps are as follow:
11
First, client send the TCP SYN packet to establish TCP session.
Then, server will send TCP SYN,ACK to response client’s request.
12
After client will resent the TCP ACK, then TCP session will successfully establish so
we can send the SSH packet via TCP. Once TCP established, we need to check each
version of SSH due to compare the server’s ability of SSH protocol version.
Server’s version of SSH is SSH-1.99-OpenSSH_6.9p1
13
Client’s version of SSH is SSH-2.0-OpenSSH_6.9p1. Even version of SSH is quite
different, we can establish connection because we request protocol 2.
After establish SSH session, both server and client will initialize the key exchange mode
and server will check the key exchange algorithm.
14
Once client and server check the version to verify the possibility of SSH protocol, then
client try to initialize the key exchange algorithm. The Diffie-Hellman Key Exchange
algorithm is commonly used for key exchange system.
Once client request key initialization, server will create the key and then send new key
into client.
15
Finally, client will adjust the new key and then response to the server so all done to
setup the SSH session and we can send some command via SSH session securely.
The screenshot above is some encrypted message from client. Since that packet is highly
encrypted, there are no way to decrypt that packet so we can securely communicated
between server and client.
SSH Protocol 1
16
SSH protocol 1 is more simple than protocol 2 because there is no key exchange process.
Just establish of TCP session and then share their public key and session key are all steps of establish of SSH session. That’s why it is more vulnerable than protocol 2.
17
To connect SSH protocol 1, we need to attach the parameter of -1 (-2 is protocol 2).
Most of procedures are same as protocol 2.
18
The first step of the check of SSH version is same as protocol 2. In this case, server has
SSH-1.99-OpenSSH_6.9p1 and client has SSH-1.5-OpenSSH_6.9p1 so it can verify to
connect between them
Once verified the SSH version, server will send the public key.
19
After client send the session key, the SSH session will done to establish.
Above screenshot is in case of client’s simple command (whoami) even it encrypted, it
is some kind of vulnerable.
5. History of SSH
In 1995, a researcher named Tatu Ylonen at Helsinki University of Technology
Finland, developed SSH protocol. In 1995 he released his protocol to the general public
as a free software with source code which was later adopted by 50 countries. In the same
year he documented his protocol with IETF (Internet Engineering Task Force) as an
IETF draft. Due to some limitation in the software, later new versions of the protocol
such as SSH-2 or SSH 2.0 was developed which incorporated new algorithms which
were incompatible with SSH -1. IETF also formed a working group called as SECSH to
standardize the protocol and guide its development in public interest.
With the advancement in technology the newer versions SSH 1 protocol is still freely
available for educational and commercial purposes. Whereas the SSH2 on the other
hand is sold commercially but educational and non-profit entities are granted free access.
In spite of new advances in the protocol that came up with SSH 2.0 protocol, SSH 1.0 is
still most widely used protocol.
With the advent in technology and based on the last free releases of SSH protocol, Open
SSH has been developed and it supports both SSH1 & SSH2 in a single set of program.
As open SSH was developed under open BSD, it is now ported to operating systems
such as AIX, Solaris and Linux with back compatibility. Although Open SSH is new
and it doesn’t includes the all the features of both SSH1 and SSH2, it is still developing
and a holds a very promising future. And moreover it has been estimated that SSH has
over two Million users worldwide proving its metal.
20
6. Structure of SSH
SSH Protocol: Definition and Importance
SSH is a network protocol which provides the network administrators a way which is secure
to access the remote computers/devices. SSH is also known as the secure socket shell and is
also referred to as suite of utilities that implement the protocol. SSH works both ways, it uses
a public key cryptography to authenticate the remote computer and also authenticates the user
if necessary. SSH is cryptographic protocol which allows only a valid user to access the
remote computer using a key. This protocol operates at layer 7 OSI MODEL and provides the
user with the facility of remote login and a secure operation on an unsecured network in a
client server model connecting SSH server with SSH client.
Early used protocols such as Telnet, rsh, rexec which used to transmit passwords in plaintext
and were not robust and secure since they were susceptible to interception and disclosure.
SSH proved its metal by being more reliable, robust and providing confidentiality and
integrity of the data over Internet, which is an unsecure network. Thus SSH provides with
encryption, which helps maintaining a secure connection over unsecure network b y
encrypting every information, the user types in, transmitting it through the Internet and
decrypting the information on the receiving end.
Login Session Through Telnet 1 Login Session through SSH 1
Key features of SSH
As we know SSH authenticates the remote computer as well as the end user if necessary,
SSH generates a public private key pairs for this purpose, which can be generated
automatically or manually to encrypt a connection and then a password is used to authenticate
to log on to access the network. Thus there are two ways to access the SSH:
1) Automatic Public private key generation
Under this scheme a public private key pairs are generated automatically to simply
encrypt a network and then the user requires a password to log on to access the
21
connection established by the SSH.
2) Manual public private key generation
Under this scheme public private key is generated manually and the user is allowed to
log in without specifying password. The public key is kept in all computers, and the
private key is held by the owner which is kept as secret. Only that user is allowed access
to the network whose private key matches with that of the public key kept on the
computer, SSH verifies that only the authorized person is allowed access who owns the
private key matches with the key provided by the public key. The most important fact is
that the key is never transmitted on the network during authentication. SSH is also
responsible for association of the keys which are unknown public keys, these keys are
verified to avoid authorizing an attacker as authentic user.
Characteristics of SSH
Since Telnet transfers all its data in an unencrypted format and moreover transfers the
username and password in plaintext format over the network, this implies that the
connection is prone to snooping attacks and the attacker is able to retrieve your login
information or any data over the network. Thus SSH is used instead of telnet since it is
more reliable and provides an encrypted connection over the network. The
characteristics of SSH are:
SSH provides a secure client server connection and this protocol encrypts the
data or user information over the network thus masking the vulnerability of any
attacks.
Unlike unsecure network applications such as Telnet and FTP SSH doesn’t
allows accessing the root.
SSH also provides with strong authentication methods which helps
authenticating the remote system and sometimes authenticating the user if
needed to ensure that the communication between the SSH client and SSH server
is trusted.
Both versions of SSH i.e. SSH1 AND SSH 2 have an option of selecting several
authentication and encryption mechanisms to choose from.
SSH is widely available as a free source and also for commercial purposes and is
transparent to the end user.
Versions of SSH
Version 1.x: It was the first SSH protocol developed by a researcher at Helsinki
University of Technology. This protocol was developed to replace the existing non
secure network applications such as telnet, rlogin and rsh protocols in 1995 this protocol
was available for free and later in the year was adopted as an IETF draft.
Version1.99: This was not a new protocol version but an improved version of
22
the existing protocols. It was adopted after version 2.1 was established and was
simply formulated for backward compatibility.
Open SSH (OSSH): due to the need of free software versions by the developers
OSSH version was formulated which was an extension or improved version of
the old 1.2.12 release of the original SSH program. OSSH is most popular SSH
implementation which comes in large number of operating systems. OSSH also
supports versions 1.0 and 2.0 of the SSH protocol and is still maintained in
today’s world.
Version 2.x: IETF formulated a working class group for this protocol namely
SECSH. SSH 2.0 proved to be incompatible with its earlier feature i.e. SSH
1.0 .SSH 2.0 is an advanced version of SSH providing improved features such as
better security and strong data integrity using authentication codes. SSH also
provides security against the threat of eavesdropping by using the mechanism of
encryption of data. SSH V2 helps avoiding man in the middle attack by checking
the client for the server supplied public host key against list of all known hosts.
It also provides strong authentication for clients since public keys and
certificates are immune to attacks but not the password. Thus SSH v2 hold
various key features that provide the user with secure connection.
Simple Working of SSH:
When the user wants a connection through SSH he is connected to a text based interface shell
session to connect well with the server, which is nothing but a simple client server model.
During the session the commands that the user enters in his local machine are sent to be
executed on the remote server with the help of SSH tunnel. SSH daemon is always running
on the machines which is nothing but a piece of software, SSH daemon listens for connection
on port. It also authenticates the connection and as and when the user provides his credentials
which are accurate, the SSH daemon generates proper environment.
SSH SERVER: SSH server is basically a software program which tends to use the SSH
protocol to establish connection with the remote computers. SSH provides a reliable
connection with the remote computers, which is secure and authorized. Connection with
the remote terminal and SFTP/SCP file transfer are few most widely uses cases of SSH
server. The following are few example of SSH servers:
1. Open SSH
2. Apache Mina
3. CopSSH
4. DropBear
5. Tiny SSH
SSH CLIENT: SSH client is basically a software program which tends to use the SSH
protocol to establish connection with the remote computers .File transfers and terminal
access are few uses in which SSH protocol is used .
23
SSH Login Credentials Required
To establish a secure SSH connection, the server requires few login credentials of the
user so that the user is able to log into the server via SSH. Thus the server requires the
following information:
1. User Name: user name is a custom made user name and completely depends on the
choice of the user depending on what the user typed as the user name. For future use
the custom name entered by the user will be used as a user name for that user.
2. Server: This comprises of knowing the IP address to enter in the system as a part of
login credential. Example: www.sjsu.edu or www.google.com .
3. Password: Password depends on which user you chose to enable.
Advantages of using SSH Protocol
SSH allows for a secured connection between a SSH client and a SSH server via
tunneling. SSH protocol encrypts the data that the user wants to send via network, transfers
the information to the other end and decrypts the information on the other end .SSH protocol
is reliable and it maintains the integrity of the data unlike other protocols such as telnet, rsh
etc which are prone to the attacks of malicious users. The following are few advantages of
using SSH protocol:
1. When an attacker creates packet with forged source IP address , masquerading
and gaining advantage is called as spoofing.Thus SSH protocol provides
prevention against IP address spoofing .
2. SSH also prevents against IP source routing and manipulation of data at
intermediate routers in the network since the attacker tends to manipulate the
data at the intermediary routers.
3. SSH also prevents eavesdropping or sniffing of data. When the user uses a
unsecure connection, the malicious attacker may keep a track of ongoing data on
the network. Thus SSH provides a secure authorized connection for reliable
transmission of data.
4.
7. SSH Authentication
Client Authentication and Server Authentication
This secure channel is set up between the client and server, then the authentication
server,
The search server, it calls the associated software to authenticate the client
24
8. SSH: Key Generation
Make it easy to verify the validity of the identity has a related SSH agent and key management. When configured with a public key authentication using the keys proves the
identity against a remote SSH host. Is the identity that is based SSH is composed of two
parts (public key and private key). SSH private key is required for the user's identity
outbound SSH connection and must be kept confidential. When a user starts an SSH or SCP
session to a remote host or server, these users called SSH client. The private key is similar to the ID card in the electronic mathematical algorithms and public key surface is similar to the
lock or gate mechanism to present the ID card. When delivered through the private key that
"I am the Fred Smythe" public key and answer "Now that you can come in and actually Fred
Smythe is now certified".
Public key represents a person to allow inbound access through a gate or lock. The public key must be kept secret. Therefore, the user or the system does not jeopardize the
warranty must not use the public key to access the system. On Linux or UNIX systems, these
private and public key pair, but stored in ASCII text files, and Windows systems, some of
these programs are stored in a text file, and some of the key pair is stored in the Windows registry.
When the SSH Protocol 2 has a configuration to create a multi-ID to use a plurality of
private keys. Let's look at how to create a common set SSH private key and public key pair
and configure the Linux host (see Figure 5).
25
Figure 5. defined in the SSH architecture model defined as SSH private-public key pair
diagram of the transaction
Example in Step 1 (see Listing 1) uses the ssh-keygen utility for users fsmythe SSH
private dsa type - creates a public key pair.
Listing 1. Create a list of SSH key pair
[[email protected] ~] $ / usr / bin / ssh-keygen -t dsa
Generating public / private dsa key pair. Enter file in which to save the key (/home/fsmythe/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): ****** (Enter 'mypassword')
Enter same passphrase again: ****** (Enter 'mypassword')
26
Your identification has been saved in /home/fsmythe/.ssh/id_dsa.
Your public key has been saved in /home/fsmythe/.ssh/id_dsa.pub.
The key fingerprint is:
33: af: 35: cd: 58: 9c: 11: 91: 0f: 4a: 0c: 3a: d8: 1f: 0e: e6 [email protected]
[[email protected] ~] $
In the example (Listing 2) in Phase 2 describes the process of copying the private key of
the key pair from the source host to the authorized_keys file on the target host. This file is in
the .ssh subdirectory under the user account that you want the destination host's home directory.
Listing 2. Copying the private key in the authorized_keys file on the source host to a
destination host
[[email protected] ~] $ scp -p /home/fsmythe/.ssh/id_dsa.pub
[email protected]: /home/fsmythe/.ssh/authorized_keys
fsmythe @ thor01.com's password:
id_dsa.pub 100% 624 0.6KB / s 00:00
Step 3 example (Listing 3), we first aimed at the target server calls the remote SSH (ls -d /
tmp). The key is cached in the .ssh / known_hosts on the server. SSH private - If you enter a
passphrase, such as when you create a public key pair, the result of a command run on a
remote target server is displayed on the source server locally.
Run remote commands on the remote host to verify the destination list 3. SSH access.
[[email protected] ~] $ ssh [email protected] ls -d / tmp
The authenticity of host 'thor01.com (10.12.53.118)' can not be established. RSA key fingerprint is 84: 4f: e5: 99: 0b: 7d: 54: d0: 1b: 3e: 2b: 96: 02: 34: 41: 25.
Are you sure you want to continue connecting (yes / no)? yes
Warning: Permanently added 'thor01.com, 10.12.53.118' (RSA) to the list of known hosts.
Enter passphrase for key '/root/.ssh/id_dsa': ****** (Enter 'mypassword')
/ Tmp file1.txt
file2.txt
dir3_5432
Note: In the example above there is no need to enter the password for the user fsmythe.
Instead, you must enter a passphrase set in the first step. When you access a remote target
server, if you do not need to enter a password phrase is to create an empty passphrase by
typing enter in Step 1 when prompted for a passphrase. So, you do not need to enter
anything when you access a remote target system with a user thor01.com fsmythe.
27
ssh-agent configuration and use
SSH public without a password - If you do not want to create a private key pair, you can
use the ssh-agent utility. Simply use the ssh-agent utility to disclose the password phrase for
the current set of shell session exists - to approve SSH access without a password on your private key pair configuration temporarily. Before using the ssh-agent utility, enter the
passphrase correctly, as follows:
[[email protected] ~] # ssh [email protected]
Enter passphrase for key '/root/.ssh/id_dsa':****** (User must type password)
Last login: Sat May 8 06:37:26 2010 from 10.12.53.118
Next to query the ssh-agent creates a Bourne shell commands from standard output.
[[email protected] ~] # ssh-agent -s
SSH_AUTH_SOCK = / tmp / ssh-vxZIxF1845 / agent.1845; export SSH_AUTH_SOCK;
SSH_AGENT_PID = 1849; export SSH_AGENT_PID;
echo Agent pid 1849;
In step 3, set the environment variable in the current shell session mentioned above.
[Root @ example01 ~] # SSH_AUTH_SOCK = / tmp / ssh-vxZIxF1845 / agent.1845;
export SSH_AUTH_SOCK
SSH_AGENT_PID = 1849; export SSH_AGENT_PID; echo Agent pid 1849 Agent pid 1849
Then, make sure that ssh-agent is running.
[[email protected] ~] # ps -fp $ SSH_AGENT_PID
UID PID PPID C STIME TTY TIME CMD
root 1849 1 0 06:14? 00:00:00 ssh-agent –s
Now, list the identity of the currently loaded within the ssh-agent running. [[email protected] ~] # ssh-add –l
The agent has no identities.
In step 6, add the desired identity SSH (SSH pre-authenticate identity using the correct password of the SSH key phrases).
[[email protected] ~] # ssh-add
Enter passphrase for /root/.ssh/id_dsa: Identity added: /root/.ssh/id_dsa (/root/.ssh/id_dsa) ****** (Entered 'mypassword')
Now, verify that these identities are loaded into the running ssh-agent.
28
[[email protected] ~] # ssh-add -l
1024 33: af: 35: cd: 58: 9c: 11: 91: 0f: 4a: 0c: 3a: d8: 1f: 0e: e6 /root/.ssh/id_dsa (DSA)
Finally, use the SSH command syntax to test the ssh-agent. Now that does not prompt
you to enter your passphrase. # Assuming target remote host has correct authorized key for private key from
example01
[[email protected] ~] # ssh -A [email protected]
Last login: Sat May 8 06:36:27 2010 from 10.12.53.118 [Root @ example02 ~] #
# Assuming target remote host has correct authorized key for private key from
example03 [[email protected] ~] # ssh -A [email protected]
Last login: Sat May 8 07:04:05 2010 from 10.12.53.119 [Root @ example03 ~] #
In fact, the private key when a user enters the password phrase using the ssh-add
command, and are placed in memory decrypted via the SSH agent to connect to the
passphrase later. You can enter multiple private keys, and you can use the ssh-add
command to verify the private key in advance.
With ssh-keyscan the SSH tool that can collect a list of four public SSH host keys from a
number of remote SSH host. This tool helps you build your / etc / ssh_known_hosts files,
and is especially fast and effective. It is mainly suitable for shell scripts for automation.
List 4. An example of using a ssh-keyscan
[Root @ example01 ~] # / usr / bin / ssh-keyscan -t rsa, dsa example02.com
# Example02.comSSH-2.0-OpenSSH_4.3
example02.comssh-dss AAAAB3NzaC1kc3MAAACBALd5 /
TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs ewHGo841JdInfE825mVe0nB / UT15iylLOsI / jFCac + ljQRlO +
h2q7WOwGveOUN7TxyKlejM + G1pg5DndGt05iYn + 2
dDfn5CmEsI + K0F2vk / + mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN /
nTYoqENBmW3SwAAAIEAryoKa + VaG5LQNj wBujAuA7hGl + DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8 /
OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa
F6niL7A / VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu /
LruVF2m3XLvR5XVwUgyWvw + AAAACAaK12k3uC / OOokBgi
eu / SuD5wCSBsf9rqG9ZFa32ujZwRZmA / AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo / 7pqiQNRs
29
OZXqlQyaXyrDout6CI683b1 / rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec =
# Example03.comSSH-2.0-OpenSSH_4.3
example03.comssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb /
miiWsWnNTW8ZWYj 2IvU7rKpk / dBIp64WecYYYgDqTK5u0Q +
yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz
7PxQAY76NmweaUyGEDfIErty4gCn /
ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w + Cu0T9MY77AqLWj Moo0WoQArIvYa0soS3VhzgD / Biwu /
sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W + U1FhEjFGN
r7KeZXH99uFpuUWFA7xO7uaG / MLWSjPJMxw ==
# Example04.comSSH-2.0-OpenSSH_4.3
example04.comssh-dss AAAAB3NzaC1kc3MAAACBALd5 / TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs
ewHGo841JdInfE825mVe0nB / UT15iylLOsI / jFCac + ljQRlO +
h2q7WOwGveOUN7TxyKlejM + G1pg5DndGt05iYn + 2
dDfn5CmEsI + K0F2vk / + mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN /
nTYoqENBmW3SwAAAIEAryoKa + VaG5LQNj wBujAuA7hGl + DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8 /
OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa
F6niL7A / VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu /
LruVF2m3XLvR5XVwUgyWvw + AAAACAaK12k3uC / OOokBgi
eu / SuD5wCSBsf9rqG9ZFa32ujZwRZmA / AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo / 7pqiQNRs
OZXqlQyaXyrDout6CI683b1 / rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec =
# Example05.comSSH-2.0-OpenSSH_4.3
example05.comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb /
miiWsWnNTW8ZWYj
2IvU7rKpk / dBIp64WecYYYgDqTK5u0Q +
yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz
7PxQAY76NmweaUyGEDfIErty4gCn / ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w + Cu0T9MY77AqLWj
Moo0WoQArIvYa0soS3VhzgD / Biwu /
sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W + U1FhEjFGN
r7KeZXH99uFpuUWFA7xO7uaG / MLWSjPJMxw ==
SSH configured using the UNIX applications and scripts
Maintenance, access is to configure SSH for use in remote backup and remote recording
system with tools for remote shell script useful, but there were always a lot of controversy
with regard to the security of the server. Most shell scripts that you want to run is as follows:
$ Ssh [email protected] /usr/local/bin/dangerous_script.pl
30
It cannot handle the required SSH passphrase that prompt the user for authentication.
However, the password is not private-public SSH key pair, ssh-agent configuration or
trusted (the mechanism prompt does not appear that request SSH password), host network
mechanisms that unless pre-configured, in fact, this shell script prepared fragile to be. For this reason, SSH expects the passphrase from the current terminal associated with the shell
session. You can avoid this problem by using an expect script or Perl (see CPAN Module
Net :: SSH :: Perl) script. (Or, you can call one of the scripts in the previously mentioned
types of shell scripts.)
#! / Usr / local / bin / expect
spawn sftp $ argv
expect "password:"
send "mysshpassowrd \ r"
It is common for users to access the remote host via the SSH password mechanism
without merit from the point of view of materials, some system administrator. However,
using the SSH password mechanism can not be other security measures that can be justified
to access the remote host. For example, a full account instead of bash or Bourne shell rksh (Restricted Korn Shell) account or rssh (Restricted Shell) user accounts only given remote
host system corresponds to this. Also, by limiting which you can use only the commands
subset of the list to the authorized_keys file in fact you accidentally run a command that
could result in damage to the system or while avoid unnecessary access available only to the
exact commands needed to run remotely it is also possible to be able. SSH access limited example in Listing 5 has this type of restriction.
Listing 5. Example configuration that limits the authorized_keys file on the remote
host
[Fsmythe @ example02 .ssh] $ more authorized_keys
command = "/ usr / local / bin / secureScript.sh", no-port-forwarding, no-X11-forwarding,
no-agent-fo
rwarding, no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAOFsC6C7cJUGOZG4Ur9W0J6mxTTk5 +
MYTu5XfRESPLVwQ
A7HlUxhsXsxgmb1L1RgvR / g0JZnipDS + fGOrN2 /
IerSpgyzegTVxYLPrOovvuyCn5TA0 + rmyrkV27so6yRDkdqTJc YzWNJOyDndnTrDc /
LNmqLFKoGMQ33aur6RNv4VAAAAFQD4leC5Fc1VJqjvXCNsvazBhi84vQAAAIAWbshT8
0cTESg
dX / srxX4KVNAzY1uhBz5V0UYR4FGP + aoe6laxRj + gQvFIvAKIrpikvBjgyW6cdT8 +
k0t8HGIQp20MzSBdY9sH8xdj 05AG97Nb /
L8xzkceB78qfXhV6txaM1CzssUtiOtaAygrywNPBDEN9MbEbwpVVVyd6iqZNgAAAIAmV
31
0SUZoUr8dHdC
tagRye4bGOQjoztpb4C0RbXQw + w7Jpzr6cZISdZsK4DTBjODvv2 + /
OWPm7NEzzWyLzHPBNul8hAHOUCOpp + mYWbXX
F78BTk2Ess0SZu8dwpOtasTNEp + xPcsOvQx2Kdr17gTp + 28SfpREuLudOr6R3KeTb +
hw == fsmythe @ example01 In this example, the user can only run the fsmythe = "/ usr / local / bin / secureScript.sh
command of the host example01.
Reliable Host configuration environment that can use SSH
Finally, SSH public-host looks at the trusted environment that can be an alternative to setting the private key pair. In the case of the automation or scripting environment that
require these types of calls is still a trusted host are present even if some of the security risks
associated with the network public-private key pair has the advantage compared to the
scenario. Trusted host authentication in the network or host that you can be trusted depends
mainly on the pre-configured file access is listed in the allowed user and host combinations. Trusted host authentication is that there are two types. In (compared with OpenSSH and
SSH1) authentication type and previous authentication type uses a feature lacking a
common test protocol commands (rsh, rcp and rlogin), check the following two files, and set
a single keyword in the sshd_config file. /etc/hosts.equiv
~ / .rhosts
The SSH Protocol 2 does not support this method. Instead, he should change the
following in order to be more secure, reliable network that hosts the file / etc / ssh / sshd_config (allows the host name or IP address), and configure the shosts.equiv and /
or .shosts file.
/etc/shosts.equiv
~ / .shosts
To enable the trusted environment that can host in / etc / ssh / sshd_config file of the SSH
Protocol 2 to the following:
PermitEmptyPasswords yes
AllowSHosts remoteclient.com
DenySHosts
For example, when the reader is in the server example.com constitute /etc/shosts.equiv
file as follows.
+ Remoteclient.com fsmythe + Secureserver.net sallyh
+192.168.100.12 Fsmythe
-hackers.org james
Sallyh users to access from your fsmythe secureserver.net and accessed from a remote source and remoteclient.com is 192.168.100.12, but access is granted, users accessing from a
32
remote source hackers.org james is denied access.
Trusted hosts and authentication in a public-private key pair, the authentication method
is similar in that it is an excellent way to achieve the same result. Table 1 shows the results of
side-by-side comparison of these two authentication methods.
If an administrator with the idea of allowing the host authentication, trusted by using a remote SSH access without a password on your network Current laughing at the public
using scripts that occurs when you perform a remote SSH features - think of the
shortcomings of the private key pair The look.
The private key pair configuration breaks - • Due to a known public server host that the cache when the host name or IP address has changed. Remove the previous entries in
the .ssh / known_hosts file, and should be cached SSH remote host name and / or IP address.
This script is a public-private key pair is not to rely on.
• a public-private key pair authentication scheme requires a client and server
configuration. When the SSH public keys is changed or re-generated key pair must create a new public key in the authorized_keys file on all remote hosts.
• If the .ssh / folder permissions using the public key and private key, or to change the
SSH password-free access impossible. If you do not want to use strict check file and
directory permissions / etc / ssh / sshd_config file and set the keyword to StrictModes no.
• There is no centralized way once the key pair is generated to cancel a key or keys that you can know exactly whom to distribute.
Conclusion
SSH is a powerful and secure network utilities that are used to perform a variety of tasks
from millions of users around the world. SSH is a very important tool that has a large
number of offerings consisting of r * SSH and telnet client and a server capable of providing a safe alternative to being freely distributed on the plain-text protocols, such as the series of
commands. Indicates that SSH is widely used for automation in the large-scale remote
monitoring, system maintenance, remote system auditing, reporting, and SSH scripting
technology, which is widely used and will continue to be evolved.
9. Difference between SSH protocol 1 and protocol 2
SSH protocol, version 2 SSH protocol, version 1
Separate transport, authentication, and connection protocols
One monolithic protocol
Strong cryptographic integrity check Weak CRC-32 integrity check; admits an insertion attack in conjunction with some bulk ciphers.
Supports password changing N/A Any number of session channels per connection (including none)
Exactly one session channel per connection (requires issuing a remote command even when you don't want one)
Full negotiation of modular cryptographic and compression algorithms, including bulk encryption, MAC, and public-key
Negotiates only the bulk cipher; all others are fixed
33
Encryption, MAC, and compression are negotiated separately for each direction, with independent keys
The same algorithms and keys are used in both directions (although RC4 uses separate keys, since the algorithm's design demands that keys not be reused)
Extensible algorithm/protocol naming scheme allows local extensions while preserving interoperability
Fixed encoding precludes interoperable additions
User authentication methods: • publickey (DSA, RSA*, OpenPGP) • hostbased • password • (Rhosts dropped due to insecurity)
Supports a wider variety: • public-key (RSA only) • RhostsRSA • password • Rhosts (rsh-style) • TIS • Kerberos
Use of Diffie-Hellman key agreement removes the need for a server key
Server key used for forward secrecy on the session key
Supports public-key certificates N/A
User authentication exchange is more flexible, and allows requiring multiple forms of authentication for access.
Allows for exactly one form of authentication per session.
hostbased authentication is in principle independent of client network address, and so can work with proxying, mobile clients, etc. (though this is not currently implemented).
RhostsRSA authentication is effectively tied to the client host address, limiting its usefulness.
periodic replacement of session keys N/A
10. SSH Protocol and Packet structure
SSH Protocol Stack
34
(Source: http://images.slideplayer.com/10/2816002/slides/slide_19.jpg)
- SSH authentication protocols: provides user authentication (User Authentication)
- SSH connection protocol: one encrypted tunnels through the plurality of logical
channels multiplexed - SSH Transport Protocol: provides authentication, confidentiality, integrity, and
compression (optional) - SSH communication protocols: TELNET, RLOGIN, SMTP, etc.
SSH Packet Formation
35
- Packet length: length of the packet (the length of the MAC is not included) - Padding length: the length of the random padding
- Payload: packet of information that is contained. What encryption algorithm
after the decision to use compressed - Random padding: after determining the encryption algorithm, the more random
padding field, a random byte long and mandeum be a multiple of the total packet length of the ciphertext block size, in the case of the 8-byte Stream Cipher
- MAC:. After the message authentication MAC value added, excluding the MAC
field full packets and Sequence Num (32 bits) for calculating the MAC value - Sequence Num : 0 then increased by 1 starting from
11. SSH Packet Exchange
36
SSH_MSG_KEXINIT
• In order of preference between the server and the client algorithm that can support
each other
• Transfer the sorted list of key exchange
• password • MAC algorithm
• SSH_MSG_KEXINIT
- Notice that the key exchange is completed between the server and the client
• SSH_MSG_SERVICE_REQUEST
- Service Request - Send a REQUEST packet requesting a connection protocol
- All data are listed in the exchange, and encryption security to the MAC Payload
37
12. Port Forwarding(SSH Tunneling)
• Convert in secure TCP connectioninto a secure SSH connection => SSH Tunneling
Definition
Port (HTTP) is currently 80 times Suppose the state is referred to the firewall does not block the direct access (Direct Connection). How can transmit / receive the desired data it
does not take on the firewall in these situations? Whether or not a number of ways, but it is
that when you look at a summary of a word instead of a port that does not block the
transmission / reception of the data port on the firewall, the firewall is blocking accepted
transmit / receive (port forwarding). That is, instead of installing the various network
38
daemon to accept and process the data line of the service (Proxy), and that it can receive a
desired service to bypass the firewall. This configuration gives a protocol called (Secure
Shell) SSH support, by running the SSH Client Client side can make the role of Proxy. And
there must be a line SSH Server SSH Client receives the data, the connection sections
(Tunnel) between the two there is a unique feature of SSH (data encryption / decryption, etc.) is applied, specifically called tunneling (Tunneling).
Type of port forwarding
Type of SSH Port Forwarding, which is provided by the Local, Remote, Dynamic of three.
But in this article in order to deal with more information, Remote typically covers SSH
Server Settings, Local deals with the information to set the port used to access from the SSH
Client. However, Local, Remote methods, such as the distance is the common treatment
methods. So it will cover only the Dynamic Port Forwarding.
Dynamic Port Forwarding
This is when you request an SSH client to bypass the local port (http services, messenger
services, etc.) that attempts to access the outside, SSH server received data has a mechanism
to handle and interpret the data requested.
How to SSH tunneling(Window)
SSH is also a very special and we will look for the important feature of tunneling (Tunneling). Tunneling is known as bureuneunde Forwarding it will be easy to understand,
look at the following figure.
39
[Figure 1] "SSH, The Secure Shell: The Definitive Guide" Note 317p, SSH forwarding
Let's say the above Figure 1. Host A, as there is an SSH client installed and Host B, the SSH server is installed. If the connection to the SSH server through the SSH client called
making a connection is established between the two tunnels connect the two passages.
Because like a tunnel through the encryption to protect the connection from the outside. So
called tunneling. The important fact is that a number of other applications made available through such a
tunnel SSH. That port forwarding (Port Forwarding) that make this one because it is a
technique also called forwarding.
If so, this could mean? It uses this tunnel is means that it can soon be available all the benefits of the SSH encryption. In other words, that you can safely use a program that does
not support encryption. (Only it supports programs that use different protocols, such as
UDP and TCP as a reference is not supported.)
Let's again look at Figure 1 above. When Host A of the application client to connect to
the application server of Host B is usually a direct connection (direct connection). However, you can use SSH tunneling through the application client to connect to the SSH server and
SSH client, and data necessary to deliver application server.
That is, as shown in Figure forwarded connection. Let's note that SSH tunneling client is
available only when connected to the SSH server, and can only be set when connecting.
Let's look at these in more detail with respect to tunneling. Tunneling is made up largely
Local port forwarding and Remote port forwarding.
Local port forwarding is the Linux client can use the following format:
$ SSH -L port number 1: Host Name: Name server port number 2
40
[Figure 2] "SSH, The Secure Shell: The Definitive Guide" Note 329p, Local port
forwarding
Fort No. 1 is to specify the port number for SSH client is checking (Listen). Usually the port number 1 is designated as any number within the range from 1024 to 65535. 1 ports
from 1 to 1023 is that it can usually only reserved ports as the superuser. When the data
came to the port number 1 SSH client to SSH server and transmit data to, SSH server and
sends the data to the data back to the host name port number 2.
The host name is the host name of the server entry. Let's look at the illustration below to understand.Local port forwarding if you use SSH client for Host A user is able to (Listen)
checks the specified local port. If the Application client is connected to this port SSH client
shows that transfers the data to the SSH server on Host B, and the SSH server is sent to the
application server.
Conversely Remote port forwarding is the opposite. The first Linux uses the following
format: $ Ssh -R port number 1: Host Name: Name server port number 2
The port number is 1 haejugo before this data to the SSH client to SSH server and allows
a check (Listen) and data came here, SSH client and transmits the data to the host name port
number 2.
At this time, the host name is the host name of the SSH client perspective. [Figure 3] shows the Remote port forwarding.
41
[Figure 3] "SSH, The Secure Shell: The Definitive Guide" 329p Note, Remote port
forwarding
Now let's look for the actual use of tunneling. Using a tunneling will look at an example
of how to safely send and receive mail and example to bypass the firewall. Use the first
tunneling Learn how to bypass the firewall. These days, a lot of places, it is important that the security company have a firewall installed.
Server, PC, and in the meantime there may be a firewall. If you have a firewall installed
If we can not access the service that you want to live, just do that? no. Unless there is a
possibility of the SSH service is blocked by the firewall is the right tunnel. Consider the following [Figure 4].
[Figure 4] "SSH, The Secure Shell: The Definitive Guide" 333p reference, bypass firewall
tunneling using
IMAP mail reader is connected to the port (143 times) to try to to the IMAP mail server is
42
a situation that is blocked by a firewall on the server. However, SSH port on the server (22)
is open. In this case mail reader is capable of connecting to the IMAP mail server using
tunneling as illustrated.
13. SSH Attacks
Even though SSH provides a complete authenticated connection between a client and a
server using encryption keys, even the SSH is prone to network attacks such as:
SSH Insertion Attack: In Insertion attack during the connection establishment between
the client and server, they both perform a protocol negotiation. In Protocol negotiation
Selections of cipher algorithm, authentication and a selection of session key, such
parameters are decided. Using these parameters encrypted communication is maintained.
Using these algorithms along with CSC integrity check is used to perform plaintext attack, which inserts encrypted packets in the client to server direction which undermines the
integrity check on the servers and decrypts the given plaintext thus this allows the malicious
attacker to carry out commands that he wishes to be executed on the remote server .the
attack can also be in the direction from the server to the client in which the server is able to transmit arbitrary data, but this attack is less severe in comparison to the one which takes
place form the client to the server .. The attack is equally feasible on the server to client
stream, although it just gives the ability to send arbitrary data the user's terminal.
SSH insertion attack mitigation methods: 1. The insertion attack can be mitigated by using version 2 of SSH protocol which is
more advanced but the key factor to this is that when using version 2 of SSH protocol,
this protocol does not support backward compatibility i.e. this version of the
protocol is not compatible with the previous versions of the protocol. With the
adoption of the version 2 of SSH protocol, we will also have to upgrade all the SSH clients as well.
BRUTE-FORCE ATTACK: It is also known as exhaustive key search and is a
cryptanalytic attack. This type of attack is used against crypted data and this type of
attack is used in a system where there is no possibility to exploit any of the weakness of the system. This method comprises of checking all the possible keys and passwords in
the system until the correct one is found and the worst case in this mechanism is that the
entire list is checked until the correct keys is found. In these cryptosystems the key
length plays a crucial role in the performance of the brute force attack. Brute force attacks works fairly well for passwords with shorter length and for the password
guessing for longer password dictionary attack is used since brute force attack takes a lot
of time for search.
Brute Force attack mitigation methods: brute force attack can be mitigated by Making the data to be encrypting more confusing
or unclear so that it becomes more difficult for the attacker when he cracks the code can
mitigate brute force attack.
43
Multi User Attack: This attack is even more powerful attack. In this type of attack the
malicious user also has an account on the remote system in which the user is trying to login
through SSH. This attack will allow the malicious user to keep track of all the commands
entered by the user who is accessing the remote host computer using SSH and in case the user enters command that requires any password.