SSH An Introduction

1
SSH- An Introduction
2
Contents

• Conventional ways of remote access
• What is SSH
• SSH functionality
• SSH Protocols
• Transport
• Authentication

3
Conventional ways of Remote Access

• telnet Internet standard Protocol for remote
  login.Runs on top of TCP/IP
• rlogin Unix version of telnet
• rsh Unix networking command to execute commands
  on remote hosts
• rcp Unix equivalent of FTP

4
Problems Associated with conventional ways

• No encryption used in transmission
• Eavesdropping Listening to data while in
  transmission
• Hijacking Taking over communication
• IP Spoofing Faking network addresses

5
What is SSH?

• Definition De-facto standard for remote logins
  and encrypted file transfer
• Secure shell provides an open protocol for
  securing network communications that is less
  expensive and complex than VPN based solutions

6
SSH Provides

• Secure Command Shell
• Secure File Transfer
• Data Tunneling for TCP/IP Applications

7
History of SSH

• The first version came out in 1995 to replace the
  non-secure UNIX r-commands
• The second version SSH2 was drafted by IETF in
  1997 to address serious vulnerabilities in SSH1

8
Intended Services provided by SSH

• Confidentiality data must not be readable by
  unauthorized parties
• Integrity data must not be modified during
  transmission
• Authentication both parties must be able to
  identify each other reliably

9
Functionality

• Secure Command Shell
• Used to edit files,view contents of directories
  and access custom database applications.

10
Functionality

• Secure File Transfer (SFTP)
• SFTP encrypts both username/password and data
• Uses the same port as Secure Shell server
• Avoids the Network Address Translation (NAT)
  issues

11
Functionality

• Port Forwarding (Tunneling)
• This enables system administrators to secure
  otherwise unsecured network protocols through
  their network

12
SSH Components

• Transport Layer Protocol server authentication,
  confidentiality, and integrity
• User Authentication Protocol authenticates
  client side user to server
• Connection Protocol multiplexes encrypted
  tunnel into several logical channels

13
Protocol Architecture
Connection
User Authentication
Transport Layer
14
Protocol Basics

• User Authentication
• Consists of Password Authentication and Public
  key Authentication
• Passwords are sent after encrypting them unlike
  the way followed in telnet and rlogin
• The private key has a passphrase associated
  with it which is required to gain access

15
Protocol Basics

• Host Authentication
• Each server has a host key associated with it
• Client should have prior knowledge of servers
  host key
• If a machine is running multiple SSH servers,it
  may have multiple host keys
• Host keys are generally persistent and asymmetric

16
2 Trust Models

• Local Database at client side containing an
  association of different hosts with corresponding
  host keys
• 2. Name-to-host key association is done by
  some trusted third party certification
  authority.The main advantage in this scheme is
  that only one CA key needs to be stored securely

17
SSH The Transport Layer
18
Protocol Basics

• The transport layer typically runs on top of
  TCP/IP
• Secure low level transport protocol
• Is Simple and Flexible
• Provides strong encryption, server authentication
  and Integrity protection
• Providing compression is optional
• Provides host based authentication. DOES NOT
  PROVIDE USER AUTHENTICATION

19
Connection Setup

• SSH works over any 8-bit binary transport
  protocol
• Client initiates the connection on the port 22 on
  the server
• Underlying transport protocol should provide
  protection against transmission errors
• Once the connection has been established, both
  client and server send a version exchange id
  string of the form SSH-protoversion-softwareversi
  on comments followed by carriage return new
  line character.

20
Connection Setup (contd.)

• Before the id string is sent, the server might
  send other strings with useful information to the
  client.
• The client should be capable of handling these
  strings and may/may not display it to the user.
• These are used by TCP wrappers to display an
  error message before disconnecting.
• Key exchange begins after the initial
  client-server version string exchange.

21
Binary Packet Protocol

• Each packet is defined as follows
• packet_length length of packet in bytes and
  excluding MAC
• padding_length length of badding in bytes
• payload useful contect in the packet
• -gt payload packet_length-padding_length-1
• random padding arbitrary length padding
• Minimum packet size is 16 bytes

22
Binary Packet Protocol (contd.)

• Data integrity is maintained by evaluating and
  transmitting a MAC with each packet sent
• Sha1 is the MAC algorithm that is required
• If compression is selected, only the payload
  field will be compressed and the length of the
  MAC will be computed from the compressed payload
  value
• macMAC(key,sequence_numberunencrypted_packet)

23
Binary Packet Protocol (contd.)

• The sequence no. is 0 for the first packet and is
  incremented there on
• It wraps to 0 after every 232 packets
• Encryption and decryption algorithms are
  negotiated during the key exchange
• Ciphers use keys of at least 128 bit length
• One time session keys are exchanged using the
  Diffie hellman key exchange

24
Key Exchange

• Begins with each side (client and server) sending
  a list of supported algorithms.
• server_host_key_algorithms lists the algorithms
  for which the server has got the host keys
• Client lists the algorithms which it would accept
• A server might have multiple host keys( maybe for
  different algorithms used)
• A key may/may not provide both encryption and
  signature (depending upon the algorithm) and
  hence, not all host keys are valid for all key
  exchanges.

25
Key Exchange

• Both the client and the server have a preferred
  algorithm in each category. So each side makes a
  guess at each other sides algorithm being used
  and sends an initial key (the first key)
  accordingly
• If the guess is correct (i.e. both sides make the
  same guess) that algorithm is used
• If a wrong guess is made, then an iterative
  procedure is followed over the key exchange
  algorithms of the client

26
SSH User Authentication Protocol
27
Contents

• Authentication Protocol Basics
• The Authentication Protocol Framework
• Details of Authentication
• Authentication Protocol Message Numbers
• Authentication methods

28
Authentication Protocol Basics

• Its a general-purpose user authentication
  protocol.
• It is intended to be run over the SSH transport
  layer protocol
• It assumes that the underlying protocols provide
  integrity and confidentiality protection.

29
Basics continued..

• The service name for this protocol is
  "ssh-userauth".
• When this protocol starts, it receives the
  session identifier from the lower-level protocol
  , which is used for signing to prove ownership of
  private key.

30
The Authentication Protocol Framework

• Client is a machine and not the user
• The server has complete control over
  authentication as it tells client which
  authentication methods can be used.
• The client can choose the order making it
  flexible.

31
Framework Continued

• Client sends an authentication request
  SSH_MSG_USERAUTH_REQUEST with none as preferred
  authentication method
• This request should always be denied by the
  server except in some special cases.
• This request is basically used for getting the
  list of acceptable authentication methods.

32
Framework Continued

• The Server responds to none request with
  SSH_MSG_USERAUTH_FAILURE message with a list of
  supported authentication methods.
• This gives server control over the authentication
  process.
• Client can select the authentication methods in
  any order this makes the protocol flexible.

33
Framework Continued

• There is a timeout period for authentication
  (Recommended period 10 minutes).
• Also there is a limit on number of failed
  attempts in a single session (Recommended 20
  attempts).
• If the threshold is exceeded, the server SHOULD
  disconnect.

34
Details of Authentication

• Client request message format
• byte SSH_MSG_USERAUTH_REQUEST
• string user name
• (in ISO-10646 UTF-8 encoding
  RFC2279)
• string service name (in US-ASCII)
• string method name (US-ASCII)

35
Details Continued

• Failure or partial success from Server
• byte SSH_MSG_USERAUTH_FAILURE
• string authentications that can continue
• boolean partial success
• Success Message from Server
• byte SSH_MSG_USERAUTH_SUCCESS

36
Details continued

• Banner Message
• byte SSH_MSG_USERAUTH_BANNER
• string message (ISO-10646 UTF-8)
• string language tag (as defined in RFC1766)

37
Authentication Protocol Message Numbers

• define SSH_MSG_USERAUTH_REQUEST 50
  define SSH_MSG_USERAUTH_FAILURE 51
• define SSH_MSG_USERAUTH_SUCCESS 52
  define SSH_MSG_USERAUTH_BANNER 53
• In addition to the above, there is a range
  of message numbers (60..79) reserved for
  method-specific messages.
• All these numbers are sent by the server.

38
Authentication methods

• Public Key method
• possession of a private key serves as
  authentication.
• This method works by sending a signature created
  with a private key of the user.
• User sends a request for use of a public-key
  algorithm
• Server rejects the request if it doesnt support
  that algorithm.

39

• Public Key Method continued..
• If it supports, it sends message
  SSH_MSG_USERAUTH_PK_OK
• After deciding upon the algorithm User sends a
  signed message
• The server MUST check that the key is a valid
  authenticator for the user, and the signature is
  valid.
• If both are valid User is Authenticated.

40
Password Method User sends the following
packet byte SSH_MSG_USERAUTH_REQUEST
string user name string service
string "password" boolean FALSE
string plaintext password
41

• Password Method Continued
• Even though the clear text password is
  transmitted in the packet, the entire packet is
  encrypted by the transport layer.
  (ISO-10646 UTF-8)

42

• Host Based Authentication
• It works by having the client send a signature
  created with the private key of the client host,
  which the server checks with that host's public
  key.
• Once the client host's identity is established,
  authorization (but no further authentication) is
  performed based on the user name.
• Care should be taken to ensure that a regular
  user doesnt obtain the client host key.