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

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

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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) 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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. 25.02.2019 Andre E. Bar’yudin

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

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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) 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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. 25.02.2019 Andre E. Bar’yudin

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

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 25.02.2019 Andre E. Bar’yudin

Implementations For Unix: open source (utilize OpenSSL) and commercial For Windows: servers commercial, clients: both A free Windows client: http://www.ssh.com 25.02.2019 Andre E. Bar’yudin

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 25.02.2019 Andre E. Bar’yudin

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. 25.02.2019 Andre E. Bar’yudin