SSH - Secure Shell

© Peter R. Egli 2015 2/20 Rev. 2.50 SSH - Secure Shell indigoo.com Contents 1. SSH in a nutshell 2. SSH-1 architecture 3. SSH-1 protocol 4. SSH-1 server (host) authentication 5. SSH-1 client authentication 6. SSH-1 keys 7. SSH-1 session trace 8. SSH configuration 9. SSH port forwarding / SSH tunneling

© Peter R. Egli 2015 3/20 Rev. 2.50 SSH - Secure Shell indigoo.com 1. SSH in a nutshell (1/2) Why SSH? SSH (RFC4250 et.al.) is a secure replacement for TELNET, rcp, rlogin and rsh for login, remote execution of commands and file transfer. SSH security: Security-wise SSH provides: 1. Confidentiality (nobody can read the message content). 2. Integrity (guarantee that data is unaltered on transit). 3. Authentication (of client and server). This provides protection against: - IP spoofing - IP source routing - DNS spoofing - Password interception - Eavesdropping SSH versions: There exist 2 (incompatible) versions of SSH: - SSH-1 - SSH-2 SSH-1.x (1.5, 1.99) are updates of version 1 and thus compatible with SSH-1.

© Peter R. Egli 2015 4/20 Rev. 2.50 SSH - Secure Shell indigoo.com 1. SSH in a nutshell (2/2) SSH encryption: SSH uses symmetric and asymmetric (public/private) keys for encryption. SSH supports various different encryption algorithms like 3DES, AES, Blowfish, IDEA. SSH can be used for: - Secure remote shell (secure system administration) - Port forwarding / tunneling (securely circumvent firewalls to access a remote system) - X11- or VNC-session tunneling (secure remote desktop connection) SSH comes with some administrator tools: - SSH key generation with ssh-keygen - ssh-agent (manage private keys for client) - ssh-add (register new key with SSH agent) - make-ssh-known-hosts (list of known host keys of a domain) SSH compression: SSH optionally supports compression (gzip= GNU zip). Popular SSH clients: Windows: PuTTY, TTSSH (Teraterm), WinSCP. Linux: OpenSSH client.

© Peter R. Egli 2015 5/20 Rev. 2.50 SSH - Secure Shell indigoo.com MUX Compression Integrity Encryption 2. SSH-1 architecture User Terminal SSH Agent Locally tunneled TCP port MUX Compression Integrity Encryption Channels SSH connection H $HOME/.ssh/known_hosts /etc/ssh_known_hosts H SSH Client Shell Agent Socket TCP Connection Channels S H SSH Server Public and private host and server keys (H and S) SK Session key H,S SK Session key H H Public key Private key Plaintext Encrypted SK Session key

© Peter R. Egli 2015 6/20 Rev. 2.50 SSH - Secure Shell indigoo.com 3. SSH-1 protocol SSH uses a message based protocol (inband, same TCP connection for SSH-1 protocol and for user data). SYN SYN, ACK ACK SSH_SMSG_PUBLIC_KEY • anti-spoofing cookie • public server key (S) • public host key (H) • protocol flags • supported ciphers (3DES, Blowfish) • supported authentication protocols server protocol “SSH-1.99-Sun_SSH_1.0 client protocol “SSH-1.5-1.2.30” SSH_CMSG_SESSION_KEY • cipher_type • anti-spoofing cookie • encrypted session-key • protocol flags SSH_SMSG_SUCCESS TCP connection establishment (server TCP port 22) Plaintext communication Encrypted communication Protocol version exchange to check compatibility (SSH-1, SSH-2) Key and capability exchange; server authentication Client and server change to packet based protocol. Server identifies itself with client (host key H and server key S) and offers its session parameters. Client chooses encryption type and authentication. Client authenticates server and generates a session key SK (symmetric key) from public server key S. The session key is encrypted with the host and server keys (H and S) (double encryption). Client waits for ok from server encrypted with session key SK. Client and server activate encryption with session key SK. Server and client inform each other about their SSH version (and possibly implementation even though this might reveal valuable information for an attacker). Client authentication User data exchange After server authentication follows client authentication (client authenticated on server) and ultimately transfer of user data. SSH Client SSH Server

© Peter R. Egli 2015 7/20 Rev. 2.50 SSH - Secure Shell indigoo.com SSH_SMSG_PUBLIC_KEY H Host keys (along with host FQDNs) are stored in: $HOME/.ssh/known_hosts (user specific known hosts) and /etc/ssh_known_hosts (global known hosts as set by sysadmin). H host FQDN Client compares public host key from server with host key in ssh_known_hosts; if there is a match the client proceeds, otherwise the client issues a security warning and leaves it to user to add (new/changed) server (and host key) to ssh_known_hosts.  This thwarts man-in-the-middle attacks (but not for the first time a client connects to a host).  Sysadmin can control behavior with setting of ‘StrictHostKeyConfig’ in file /etc/ssh/ssh_config (values ‘ask’/’no’/’yes’). Server authentication is completed with SSH_SMSG_SUCCESS (encrypted with session key SK). If the client can correctly decrypt the message SSH_SMSG_SUCCESS authentication is successful because only a genuine server could have decrypted encrypted session key in SSH_CMSG_SESSION_KEY with its private host and server keys (H and S). equal? /etc/ssh/ssh_host_key.pub H H /etc/ssh/ssh_host_key SSH_CMSG_SESSION_KEY SSH_SMSG_SUCCESS H Plaintext Encrypted H Public key Private key SK S Server key in RAM (not in a file for enhanced security)H,S S H Asymmetric key(s) Symmetric keySK 4. SSH-1 server (host) authentication - client verifies if server is authentic (1/2) Server (host) authentication by the client is usually employed in order to establish an SSH connection. Servers often do not authenticate the client and simply rely on the user login (username/password) to verify if the user is authentic. SSH Client SSH Server

© Peter R. Egli 2015 8/20 Rev. 2.50 SSH - Secure Shell indigoo.com Host FQDN RSA key number of bits RSA key public exponent fhzh.ch 1024 35 1262013027273102159608907871813737119930019995093 30573487788865358391958124645875250149627765311583353258975390099 71823580290977838267552259821335446333575835614569049621613212111 49677542580895529724117297185922691874137927695315467895981581869 47064817429764437488314580261421912859857694389186305471059647293 some text (being ignored) RSA key public modulus foo.com 1024 37 2117267676734823489928349823749827349823948792834 98345798700987893287786878019809873897234405734857012309982341273 09845365987923640918230982875986918297812372085909801011209012310 67238461230090980129705130685566376485678461834071010712841963958 34652817692871037500980397019719836492165918613701701094581130701 my work key User defined text (ignored) 4. SSH-1 server (host) authentication - client verifies if server is authentic (2/2) Each trusted server has an entry in the file known_hosts (~/.ssh/known_hosts) on the client. Contents of ~/.ssh/known_hosts file (public host keys): 1 entry for each host (SSH server)

© Peter R. Egli 2015 9/20 Rev. 2.50 SSH - Secure Shell indigoo.com SSH_CMSG_USER • user login name on server Client requests to start client authentication for specified user. Server responds with SUCCESS message if no authentication is required or with FAILURE message if authentication for specified user is required. SSH_SMSG_SUCCESS SSH_SMSG_FAILURE SSH_CMSG_AUTH_RSA • public RSA key (as identifier) If authentication is required client sends message with the selected authentication method (selected on client). SSH_SMSG_AUTH_RSA_CHALLENGE • encrypted challenge SSH_CMSG_AUTH_RSA_RESPONSE • MD5 checksum of challenge and session ID SSH_SMSG_SUCCESS SSH_SMSG_FAILURE Server checks if the public key is contained in $HOME/.ssh/authorized_keys. If so the server sends 256-bit random challenge value to client (encrypted with public RSA key). Client decrypts challenge with private RSA key and sends back the MD5 checksum of the challenge and session ID (and not the plaintext challenge in order to thwart plaintext attacks). Server too calculates MD5 hash over challenge and session ID and compares it with client’s response. Server responds either with SUCCESS or FAILURE depending on the outcome of the authentication. RSA client authentication U ~/.ssh/mykey.pub ~/.ssh/mykey or anywhere else known to SSH client U 5. SSH-1 client authentication – server verifies if client is authentic (1/3) Option 1 - RSA public key client authentication: Most secure client authentication method for SSH-1 (private key is protected by passphrase). No secret authentication data is stored on server (only public RSA key). Authentication is independent of client machine (IP address, FQDN). Users must generate and manage keys and authorization files. More difficult to debug if something does not work. SSH Client SSH Server

© Peter R. Egli 2015 10/20 Rev. 2.50 SSH - Secure Shell indigoo.com Password client authentication SSH_CMSG_USER • user login name on server Client requests to start client authentication for specified user. SSH_SMSG_SUCCESS Server responds with SUCCESS message if no authentication is required or with FAILURE message if authentication for specified user is required.SSH_SMSG_FAILURE SSH_CMSG_AUTH_PASSWORD • plaintext password If authentication is required client sends message with plaintext password (user account password). SSH_SMSG_SUCCESS SSH_SMSG_FAILURE Server checks if password matches username. Server responds either with SUCCESS or FAILURE depending on the outcome of the authentication. 5. SSH-1 client authentication – server verifies if client is authentic (2/3) Option 2 - Plaintext password client authentication: Simple (no configuration required, no need to carry around a private key). No secret authentication data is stored on server (only public RSA key). Authentication is independent of client machine (IP address, FQDN). Plaintext password is naturally encrypted with session key SK. Less secure than public-key authentication (RSA) since password could be cracked on a compromised server. SSH Client SSH Server

© Peter R. Egli 2015 11/20 Rev. 2.50 SSH - Secure Shell indigoo.com 5. SSH-1 client authentication – server verifies if client is authentic (3/3) Option 3 - Trusted host client authentication (Rhosts and RhostsRSA): Simple, no need for user to enter passwords or passphrases; this makes it suited for automation (scripts, cron jobs etc.). Authentication is bound to client machine and not user. Usually this authentication method is disabled on servers since it is deemed insecure. Option 4 - Trusted Information Systems (TIS) client authentication: TIS improves password authentication in that it uses a password only once (OTP One-Time Passwords). In TIS the server sends a challenge to the client which presents challenge to user. The user is requested to enter a password that he reads from a device (SecurID etc.) or software. The client sends the response back to the server for authentication. Option 5 - Kerberos authentication Option 6 - S/Key (one-time password scheme for Unix-type systems).

© Peter R. Egli 2015 12/20 Rev. 2.50 SSH - Secure Shell indigoo.com Name Lifetime Generated by Type Description User key U Persistent User Public (asymmetric) Identification of a user on a server. This key is used by the SSH client to authenticate a user to the server. (key generated with /etc/ssh/ssh-keygen). Session key SK One session Client (and server) Private (symmetric) Used for encrypting the entire session. The session key is randomly generated and is thus independent of host and server keys (H, S). Both client and server use the same session key for encryption/decryption in both directions of the communication. Host key H Persistent Sysadmin Public (asymmetric) Used for identification / authentication of a server (host) on a client (server authentication). In case of multiple SSH servers on the same machine each instance of server may have its own host key. Also used for session key encryption (together with server key for double encryption). Server key S Limited (default 1 hour) Server Public (asymmetric) Used for encrypting the session key before transmission. Also used for server authentication on client. The server key is never stored in the file system but rather is kept in RAM (in running instance of server). 6. SSH-1 keys and keys and keys… SK U U H H S S

© Peter R. Egli 2015 13/20 Rev. 2.50 SSH - Secure Shell indigoo.com 7. SSH-1 session trace SSH trace with password client authentication: C: 1 0.000000 192.168.1.15 -> 193.5.54.112 TCP 1962 > 22 [SYN] Seq=4121554192 Ack=0 Win=16384 Len=0 S: 2 0.020510 193.5.54.112 -> 192.168.1.15 TCP 22 > 1962 [SYN, ACK] Seq=608128475 Ack=4121554193 Win=1460 Len=0 C: 3 0.020545 192.168.1.15 -> 193.5.54.112 TCP 1962 > 22 [ACK] Seq=4121554193 Ack=608128476 Win=17280 Len=0 S: 4 0.065252 193.5.54.112 -> 192.168.1.15 SSH Server Protocol: SSH-1.99-Sun_SSH_1.0 C: 5 0.073510 192.168.1.15 -> 193.5.54.112 SSH Client Protocol: SSH-1.5-TTSSH/1.5.4 Win32 S: 6 0.093569 193.5.54.112 -> 192.168.1.15 TCP 22 > 1962 [ACK] Seq=608128497 Ack=4121554219 Win=50400 Len=0 S: 7 0.099686 193.5.54.112 -> 192.168.1.15 SSHv1 Server: Public Key Packet Length: 267 Padding Length: 5 Msg code: Public Key (2) Payload: B41F1D0A80F036F30000030000062303... C: 8 0.126817 192.168.1.15 -> 193.5.54.112 SSHv1 Client: Session Key Packet Length: 148 Padding Length: 4 Msg code: Session Key (3) Payload: 03B41F1D0A80F036F3040053F168B3B7... S: 9 0.163857 193.5.54.112 -> 192.168.1.15 TCP 22 > 1962 [ACK] Seq=608128773 Ack=4121554375 Win=50244 Len=0 S: 10 0.229181 193.5.54.112 -> 192.168.1.15 SSHv1 Server: Encrypted packet len=5 (SSH_SMSG_SUCCESS) C: 11 0.356903 192.168.1.15 -> 193.5.54.112 TCP 1962 > 22 [ACK] Seq=4121554375 Ack=608128785 Win=16971 Len=0 C: 12 4.622742 192.168.1.15 -> 193.5.54.112 SSHv1 Client: Encrypted packet len=41 (SSH_CMSG_USER) S: 13 4.683739 193.5.54.112 -> 192.168.1.15 SSHv1 Server: Encrypted packet len=5 (SSH_SMSG_FAILURE) C: 14 4.684010 192.168.1.15 -> 193.5.54.112 SSHv1 Client: Encrypted packet len=41 (SSH_CMSG_AUTH_PASSWORD) S: 15 4.760309 193.5.54.112 -> 192.168.1.15 SSHv1 Server: Encrypted packet len=5 (SSH_SMSG_SUCCESS) C: 16 4.760570 192.168.1.15 -> 193.5.54.112 SSHv1 Client: Encrypted packet len=41 (user data) ... C: Client  server traffic S: Server  client traffic

© Peter R. Egli 2015 14/20 Rev. 2.50 SSH - Secure Shell indigoo.com 8. SSH configuration (1/2) SSH configuration with password client authentication (RSA keyset): 1. Add server (host) to client’s list of known hosts: TTSSH (Teraterm SSH): menu Setup->TCP/IP The entry will be added to the file ~/.ssh/known_hosts (Unix) or ssh_known_hosts (TTSSH). 2. Configure client authentication and credentials: Select RSA key authentication along with proper (private) RSA key file (copied from server in step 4.). TTSSH: menu Setup->SSH Authentication 3. Save configuration: TTSSH: menu Setup->Save setup…

© Peter R. Egli 2015 15/20 Rev. 2.50 SSH - Secure Shell indigoo.com 8. SSH configuration (2/2) SSH configuration with public key client authentication (RSA keyset): 1. Configure a public key on server: Create key on server (or wherever ssh-keygen is available): /etc/ssh/ssh-keygen (execute program on server, generates key pair (public, private) in $HOME/.ssh/identity.pub) (choose a pass-phrase for private key encryption) 2. Add created public key to key file: cd $HOME/.ssh cat identity.pub >> authorized_keys (this file is examined by SSH server (=sshd)) 3. Copy the private key in file ‘identity’ to PC where TTSSH runs:  do this through a SSH session with password authentication 4. Delete private key on server machine: rm identity 5. Add server (host) to client’s list of known hosts: TTSSH (Teraterm SSH): menu Setup->TCP/IP The entry will be added to the file ~/.ssh/known_hosts (Unix) or ssh_known_hosts (TTSSH). 6. Configure client authentication and credentials: Select RSA key authentication along with proper (private) RSA key file (copied from server in step 3.). TTSSH: menu Setup->SSH Authentication 7. Save configuration: TTSSH: menu Setup->Save setup…

© Peter R. Egli 2015 16/20 Rev. 2.50 SSH - Secure Shell indigoo.com 9. SSH port forwarding / SSH tunneling (1/5) Pass protocols (applications) securely through an unsecure network. SSH port forwarding allows applications to pass traffic through firewalls that would normally block the application protocol (but not SSH), e.g. when NAPT (Network Address Port Translation) is used on the firewall. • The Connection between application client and server is relayed through a pair of SSH client and server. • The connection between client and server host is protected (but not the connection between SSH client and application client and between SSH server and application server!). Application Client SSH Client Client host Application Server SSH Server Server host SSH connection (tunnel) Firewall Firewall Secure application to application communication

© Peter R. Egli 2015 17/20 Rev. 2.50 SSH - Secure Shell indigoo.com 9. SSH port forwarding / SSH tunneling (2/5) Local port forwarding: NSAP TSAP Sockets IP Socket TCP SSH Client P1 P2 127.0.0.1 Application Client P3 0.0.0.0 IP Socket TCP 22 Application Server 0.0.0.0 SSH Server P4 P2 127.0.0.1 SSH connection (tunnel) • Application client and SSH client are on same machine (and accordingly application server and SSH server). • Local forwarding configuration command: $ ssh -L<local port>:<local host>:<remote port> <remote host> Example: $ ssh -L 2001:localhost:143 pop.fhzh.ch • Forwarding is initiated by client sending SSH_CMSG_PORT_FORWARD_REQUEST message to SSH server (along with remote port number). SSH client and server establish a channel for this forwarding within the existing SSH connection. Client application is bound to localhost/P1 and talks to localhost/P2. P1: source port number of application client’s TCP connection (ephemeral port number). P2: port number to be forwarded; can be well-known port, e.g. 21 for FTP (2001 in example above). P3: source port number of SSH client’s SSH TCP connection (ephemeral port). P4: source port number of SSH server’s TCP connection to application server (ephemeral port).

© Peter R. Egli 2015 18/20 Rev. 2.50 SSH - Secure Shell indigoo.com • Application client and SSH client are on different machines (and accordingly application server and SSH server). • Remote forwarding configuration command: $ ssh -R<remote port>:<local host>:<local port> <remote host> Example: $ ssh -R 2001:localhost:143 pop.fhzh.ch P1: source port number of application client’s TCP connection (ephemeral port number) P2: port number to be forwarded; can be well-known port, e.g. 21 for FTP (2001 in example above) P3: source port number of SSH client’s SSH TCP connection (ephemeral port) P4: source port number of SSH server’s TCP connection to application server (ephemeral port) 9. SSH port forwarding / SSH tunneling (3/5) Remote forwarding: IP Socket TCP SSH Client 143 P4 127.0.0.1 Application Server P3 0.0.0.0 IP Socket TCP 22 Application Client 0.0.0.0 SSH Server P2 P1 127.0.0.1 SSH connection (tunnel) NSAP TSAP Sockets

© Peter R. Egli 2015 19/20 Rev. 2.50 SSH - Secure Shell indigoo.com Host C Application client SSH client Host A SSH server Host B Application server Host S $ ssh -L P:S:W B Port P Port W • Application client/server and SSH client/server are on different machines. • Local forwarding configuration command (on host A): $ ssh -L<local port>:<server host>:<remote port> <remote host> Example: $ ssh -L P:S:W B 9. SSH port forwarding / SSH tunneling (4/5) Off-host-port forwarding: SSH connection (tunnel)

© Peter R. Egli 2015 20/20 Rev. 2.50 SSH - Secure Shell indigoo.com 9. SSH port forwarding / SSH tunneling (5/5) FTP forwarding (let local FTP client use SSH): A. Configuration: 1. Configure port forwarding on TTSSH: Menu ‘Setup’->’SSH Forwarding…’ ‘Forward local port’ = 21 (for FTP). ‘to remote machine’ = server / host to which to connect through FTP in SSH tunnel. 2. Configure FTP client to enable use of SSH: Configure FTP client such that it connects to 127.0.01 (localhost) and 21 as remote port. Enable passive mode (PASV=on); in active mode the server will not be able to open a data connection since the client’s IP that the server ‘sees’ is localhost (127.0.0.1). B. Usage: 1. Log on to desired server through SSH (with TTSSH) thus establishing an SSH secured TCP connection. 2. Start FTP client (will connect to localhost which is forwarded to FTP server through SSH server). 3. Normal file upload/download operation.  But: some servers (e.g. FHZH FTP server) will rant if the client wants to open an FTP-Data connection with a different source IP address (public client IP address since FTP-Data does not pass through SSH tunnel) than the FTP control connection (localhost on server=172.10.0.1 when using SSH tunnel); the warning will be something like “425 Possible PASV port theft, can not open data connection” (this is a security feature of the FTP server). The problem is that FTP clients, when in passive mode, try to open a data connection to the address provided by the server after sending the PASV command (FTP server communicates IP/port number encoded as n1,n2,n3,n4,n5,n6) because opening a connection to localhost/20 would not be possible since server port is dynamic and there is no way to let the SSH client dynamically open (listen) a TCP port on localhost.

SSH - Secure Shell

In this document

More Related Content

What's hot

Viewers also liked

Similar to SSH - Secure Shell

More from Peter R. Egli

Recently uploaded

SSH - Secure Shell