1. SSH – the practical solution
Secure Shell protocol and its uses
Andre E. Bar’yudin

2. The problem Connection to remote machines (surprise!)
Existing solutions (telnet, rsh, rlogin)
What about X?
What about file transfer (FTP, HTTP)?
Andre E. Bar’yudin

3. SSH – pleased to meet you
Designed by and for Unix people
Still usable for Windows
Emphasis on usability and practical usage
A few usage examples
Details on
Versions: 1, 1.5, 2
Andre E. Bar’yudin

4. Features Client/server architecture
Transparent encryption, compression and integrity preservation of data
Encryption algorithms: 3DES, Blowfish, public/private etc., details coming
Secure remote console and command execution
Secure file transfer
Andre E. Bar’yudin

5. Features (cont.) Flexible authentication model TCP/IP port forwarding
Prevents IP/DNS spoofing
Prevents IP source routing
Extensibility – new algorithms can be added, new layers can be defined
Multi-language support
Andre E. Bar’yudin

6. SSH protocol – details The following layers (protocols) exist:
Transport (over TCP/IP or other), data integrity/compression, host authentication
User authentication layer
Connection layer
File transfer protocol (sftp)
Authentication agent protocol (ssh-agent)
Protocol version, encryption algorithms, authentication schemes are negotiated
Andre E. Bar’yudin

7. Transport layer Works over TCP/IP or other reliable protocol
Initiated by the client
Initialization
Sides exchange a message in the form “SSH-protoversion-softwareversion comments”
“protoversion” determines what version of the protocol will be used. We will concentrate on version 2.0
Andre E. Bar’yudin

8. Key exchange Negotiation of the encryption algorithms and compression
Data flow directions client->server and server->client are independent, may use different algos (i.e. 3DES+SHA1 and Blowfish+MD5)
If compression is enabled, the data is first compressed and only then encrypted
Exchange lists of supported algorithms
Andre E. Bar’yudin

9. Key exchange (cont.)
In particular, server gives the list of available host key algorithms: Diffie-Hellman, RSA etc. There are certain issues with DH, so RSA is recommended
Determine an algorithm/key acceptable for both parties – first algo listed by each side is regarded as the preferred by it
The actual key exchange
Andre E. Bar’yudin

10. Key exchange (cont.)
A server key may include a certificate, signed by a CA, known to the client
Client may have a public key of the server (based on server’s host name)
In neither case – what do we do? The authenticity of host ‘gw ( )' can't be established. RSA key fingerprint is 81:f5:da:26:77:31:fc:51:64:3f:97:ec:d7:e9:97:ab. Are you sure you want to continue connecting (yes/no)?
It’s usability versus security – the usual key distribution problem
Andre E. Bar’yudin

11. Key exchange (cont.)
Key exchange gives us a shared secret K, and a hash H (also serves as session id at the start) from which we build:
Server IV and client IV
Encryption keys C->S and S->C
Signature (integrity) keys C->S and S->C
From here on every message exchanged should be encrypted/signed by an appropriate key (MAC signatures)
Andre E. Bar’yudin

12. Key exchange (done)
After the key exchange client requests a service – server satisfies it or rejects. Services are defined as higher-level protocols on top of transport layer
User authentication
Connection
File transfer and so on
Can repeat key exchange at any time
Andre E. Bar’yudin

13. Security of the Transport Layer
Key distribution – a general problem
Hostname-key association
Currently only CBC encryption is used – potential attacks using the “birthday paradox” and other techniques
The specification recommends key renegotiation every hour or 1G of info
“IGNORE” messages to complicate traffic analysis
Andre E. Bar’yudin

14. Authentication layer Runs atop of transport layer
Relies on data privacy and integrity, provided by it
Service ID: “ssh-userauth”
Has access to the shared secret session id from transport layer
Many authentication methods are available and they are negotiated
Andre E. Bar’yudin

15. Authentication layer (cont.)
Client requests service “ssh-userauth”
Server responds with the list of available authentication methods. More than one authentication may be required
Methods:
Public key – how it works (UNIX, ssh-agent). The usual key distribution problems
Password etc.
Andre E. Bar’yudin

16. Security of the authentication layer
Assumes that the data transfers are secure and integer
Method-specific considerations may apply
Andre E. Bar’yudin

17. Connection Layer
Runs over the transport layer, utilizes the authentication layer
Multiplexes the encrypted tunnel provided by it into several logical channels
Provides
Interactive sessions
Remote command execution
X11 forwarding
TCP/IP port forwarding
Andre E. Bar’yudin

18. Connection Layer (cont.)
Channels – can be opened by either side
To open a new channel
Allocate a channel number
Send a request to the other side, giving channel type
The other side either rejects or accepts and returns its channel number
Therefore a channel is identified by two numbers
Andre E. Bar’yudin

19. Connection Layer (cont.)
While building a channel window size can be negotiated and adjusted
A single channel may support different data types (depends on the channel type)
Channel-specific requests can be sent (request a PTY in interactive session)
A channel can be half-closed or closed
Andre E. Bar’yudin

20. Interactive session
Remote execution (shell, command or a predefined subsystem – like sftp)
With or without TTY
With or without X11 forwarding
Started by opening a channel of type “session”
X11 and PTY are provided upon request (subject to server’s policy)
Andre E. Bar’yudin

21. Interactive session (cont.)
X11 forwarding has its own channel
X11 “cookie” exchanged should be fake, it is replaced by the real one when talking with the local X11 server
Environment can be adjusted
Stderr, signals, flow control, exit codes are exchanged
Andre E. Bar’yudin

22. TCP/IP Port Forwarding
Client asks the server to forward it any data, coming to the server on a given port
Subject to server’s policy
Useful to access services that don’t have built-in security: POP3, IMAP etc.
Andre E. Bar’yudin

23. Security of the connection layer
The port forwarding
Remote command execution – influences the security of the server
Andre E. Bar’yudin

24. File Transfer Layer (sftp)
Runs on top of Connection Layer
Provides file transfer
Provides general file system access
Driven by commands similar to FTP
There’s a Linux module implementing a file system using sftp
Security – since it gives access to the file system, can be potentially dangerous
Andre E. Bar’yudin

25. Implementations For Unix: open source (utilize OpenSSL) and commercial
For Windows: servers commercial, clients: both
A free Windows client:
Andre E. Bar’yudin

26. Beyond the telnet The traditional usage – secure telnet, FTP
A way to do remote automation securely
A lot of applications over it: CVS, RSYNC, pretty easy and cheap (via sftp, connect)
File systems (part of sftp)
The standard allows extensions – more stuff can be added
Andre E. Bar’yudin

27. Conclusion – SSH versus SSL
A library versus stand-alone application
Use similar cryptographic ideas and schemes
In real world SSL is much more platform neutral
SSH – about 2M of users around the world
SSL – almost every computer, e-commerce, MS Messenger etc.
Andre E. Bar’yudin