10. SSH - Generic term used for SSH protocols ssh - Client command for running remote command sshd - Server program SSH-1 - Version 1 of the protocol SSH-2 - Version 2 of the protocol OpenSSH - Product from open BSD project Terminology
12. SSH Architecture The brown fox jumped over the cow The brown fox jumped over the cow Anw@dc%9r&6cbditop*dekisn@h Network ??? ssh client ssh server Authentication
13. SSH Layers Ethernet Network Access Layer IP Internet Layer TCP Transport Layer ssh-transport Initial key exchange and server authentication, setup encryption ssh-userauth User authentication using public key, password, host based, etc. ssh-connection Session multiplexing, X11 and port forwarding, remote command execution, SOCKS proxy, etc. Application Layer
19. You may download the source from http://www.openssh.com/ Read installation instructions to check if you have pre-requisite packages and libraries. Downloading Source Code
24. sshd.pid - Server's PID is stored in this file System wide configuration files
25.
26. config - Client configuration file User specific configuration files
27.
28. IMPORTANT The ~/.ssh directory and the files in it must be owned by user and must be unreadable by anybody else. The ssh server will simply ignore the files with incorrect permissions. chmod -R og= ~/.ssh Configuration Permissions
32. shahhe@kubuntu1:~$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/shahhe/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/shahhe/.ssh/id_dsa. Your public key has been saved in /home/shahhe/.ssh/id_dsa.pub. The key fingerprint is: 99:51:ac:02:10:0c:d4:55:09:cc:86:36:cf:59:d0:33 Generating key pairs
36. shahhe@kubuntu1:~$ ssh [email_address] Last login: Mon Jun 18 21:26:33 2007 from d47-69-253-190. * Problems? Questions? Email: [email_address] * Type "whatsup" to see information posted to our "What's Up?" page. You have mail. You have 17 read messages. You have no new mail. /home/customer/shah {shah@typhoon} 1> Logging into remote system
43. Options for authorized_keys2 file Disable X11 forwarding no-x11-forwarding Do not allocate TTY no-pty Disable port forwarding no-port-forwarding Disable forwarding agent no-agent-forwarding Limit incoming hosts from="host or ip address" Set environment variable environment="variable=value" Specify a force command command="command name" Meaning Option
49. You want to login to the computer at work from your home computer or from from hotel while traveling. The computer at work is behind the firewall so you cannot connect to it directly. You are allowed to connect to a bastion host, but are not allowed to store private keys on it. What can you do? Agent forwarding
50. Agent Forwarding ssh ssh sshd (proxy agent) sshd ssh Login ssh Work Bastion Home
51. The configuration is stored in /etc/ssh/sshd_config file. Port 46464 Protocol 2 PasswordAuthentication no ForwardX11 yes ForwardAgent yes Compression no sshd configuration on bastion host
52. The configuration is stored in ~/.ssh/tunnel.cfg file. Host * ForwardX11 yes ForwardAgent yes NoHostAuthenticationForLocalhost yes User RemoteUser IdentityFile /home/LocalUser/.ssh/work_dsa Host bastionhost HostName 69.2.50.60 Port 46464 LocalForward 10001 10.60.80.101:22 ssh tunnel configuration on home system
53. The configuration is stored in ~/.ssh/config file. Host * ForwardX11 yes ForwardAgent yes NoHostAuthenticationForLocalhost yes IdentityFile /home/LocalUser/.ssh/work_dsa Host portmap HostName localhost port 10001 LocalForward 18080 10.60.80.101:22 LocalForward 18081 10.60.80.102:22 Host host1 User RemoteUser HostName localhost Port 18080 Host host2 User RemoteUser HostName localhost Port 18081 ssh client configuration on home system
57. Environment variables /dev/pts/48 Name of TTY SSH_TTY 10.90.10.107 45756 22 Client socket information SSH_CLIENT /tmp/ssh-FcRCI22249/agent.22249 Path to socket SSH_AUTH_SOCK 10.90.10.107 45756 10.90.10.182 22 Client and server socket information SSH_CONNECTION Example Meaning Variable
65. http://www.openssh.com/ http://fuse.sourceforge.net/sshfs.html Barrett, D., Silverman, R., & Byrnes, R. (2005). SSH The Definitive Guide, Second Edition. O'Reilly Media, Inc. SSH FAQ http://www.employees.org/~satch/ssh/faq/ssh-faq.html Excellent agent forwarding tutorial http://unixwiz.net/techtips/ssh-agent-forwarding.html Turotial on building OpenSSH http://unixwiz.net/techtips/openssh.html Resources
Editor's Notes
He designed the protocol because of a password-sniffing attack at the university. The goal was to replace telnet, rlogin, rsh commands. He documented SSH1 as an IETF internet draft. SSH-2 features both security and feature improvements over SSH-1. New features of SSH-2 include the ability to run any number of shell sessions over a single SSH connection. SCS sells its SSH products under the name Tectia There are dozens of SSH implementations but OpenSSH it the most used version.
SSH-1 Original protocol, it has serious limitation. Not recommended anymore. SSH-2 Version 2 of the protocol. Currently in use. Most common protocol in use. Defined by draft standards of IETF SECSH working group.
Once an SSH client contacts a server, key information is exchanged so that the two systems can correctly construct the transport layer. The following steps occur during this exchange: Keys are exchanged The public key encryption algorithm is determined The symmetric encryption algorithm is determined The message authentication algorithm is determined The hash algorithm to be used is determined During the key exchange, the server identifies itself to the client with a unique host key. If the client has never communicated with this particular server before, the server's key will be unknown to the client and it will not connect. OpenSSH gets around this problem by accepting the server's host key after the user is notified and verifies the acceptance of the new host key. In subsequent connections, the server's host key is checked against the saved version on the client, providing confidence that the client is indeed communicating with the intended server. If, in the future, the host key no longer matches, the user must remove the client's saved version before a connection can occur. Once the transport layer has constructed a secure tunnel to pass information between the two systems, the server tells the client the different authentication methods supported, such as using a private key-encoded signature or typing a password. The client then tries to authenticate itself to the server using one of these supported methods. SSH servers and clients can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it will support based on its security model, and the client can choose the order of authentication methods to attempt from among the available options. Thanks to the secure nature of the SSH transport layer, even seemingly insecure authentication methods, such as a host and password-based authentication, are safe to use.
Uses public/private key. OpenSSH supports 3DES, Blowfish, AES and arcfour as encryption algorithms. These are patent free. Encryption is started before authentication, and no passwords or other information is transmitted in the clear. Encryption is also used to protect against spoofed packets. The authentication methods are: .rhosts together with RSA based host authentication, pure RSA authentication, one-time passwords with s/key, and finally authentication using Kerberos.
For more configuration parameters read INSTALL file or run configure --help --disable-suid-ssh To prevent a local root compromise if a vulnerability is found with the ssh(1) command, do not install OpenSSH with the setuid bit. The setuid bit is only needed for regression to the rsh protocol, which is disabled by the following option. --without-rsh This argument prevents the regression to the insecure rsh protocol if you are unable to connect by using the Secure Shell protocol.
Private key represents your identity for outgoing connection. Client users the private key. Public key represents your identity to incoming connection. Client sends private key to the server, server then matches it with public key, according to cryptographic test, authentication succeeds and connection is allowed. Private key must be protected, public key do not need to be secret, it cannot be used to break into an account.
Using ssh-agent saves you from typing your passphrase repeatedly.
Starts xterm (X11 application) on the remote system and displays on client display. -X enables X11 forwarding. Does not use . Xauthority file and attacker may be able to monitor key strokes. -Y enables trusted X11 forwarding. Uses . Xauthority file.
sshfs is based on FUSE - userspace file system framework. Do not run is as root, run it as a user.