SSH – the practical solution

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 http://www.ietf.org/html.charters/secsh-charter.html • 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 (10.0.0.10)' 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: http://www.ssh.com 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