SSH overview

Eliot Lim 1/27/98

What is SSH?

• replacement for rlogin, rsh and rcp with slogin, ssh and scp respectively.
• fully encrypted communications with choice of ciphers
• forwarding of X11 and arbitrary TCP/IP traffic over the secure channel (currently disabled)
• additional functionality missing in BSD 'r' commands

Why should I use SSH?

SSH addresses the following traditional security weaknesses:

• DNS spoofing
• IP packet spoofing
• packet sniffing
• X windows insecurity

SSH assumes an insecure network

How does SSH work?

1. Session initialization
   • Host private and public key generated once at install time with the ssh-keygen command
   • sshd generates a server key on start up
   • server sends host public key, server key and 64 bit random number (cookie) to client
   • both sides compute a session id using these
   • client computes session key (1Kb) encrypted by server's keys and cookie, which is used to encrypt the connection

2. User authentication
   1. regular rhosts authentication. (disabled in our configuration)

   2. RSA rhosts authentication
      • server checks to see if .rhosts or /etc/hosts.equiv exist (or .shosts and /etc/shosts.equiv)
      • server checks to see if client's host public key is known (i.e. if it exists in /etc/ssh_known_hosts or ~/.ssh/ssh_known_hosts)
      • if found server uses the client's public key and generates an encrypted challenge to the client
      • client decrypts challenge using its host private key and responds
      • session is authenticated without use of a password
      • if server's public key is not known, client will ask user if ok to copy the key into ~/.ssh/known_hosts

   3. pure RSA authentication
      • does not trust host
      • User generates a private/public user key pair once with the ssh-keygen command
      • when client connects, server takes user's public key and generates an encrypted challenge
      • if client knows the user's private key, user at client end will decrypt the challenge and be authenticated.

   4. regular password authentication
      • the cleartext password is sent across the encrypted connection to the server and authenticated through regular methods.

SSH administration

• Installing a new system
  • Ensure that its public host key exists in /etc/ssh_known_hosts
  • File to edit is /tulsa/tfx/ssh-1.2.20/DEFAULT/etc/ssh_known_hosts
  • what the ssh_known_hosts file looks like: (formatted for legibility)

    [..snip..]
    
    hawking,hawking.u,hawking.u.washington.edu 1024 41 104310131580559398356361255
    634507824355880313236555619631323763977962277796093209754132085993729762498411
    702572518599153960710709508084355747661214881309982196589764411176813325487495
    466592755528762293646056154788990642027146347772470990035677437043571468308702
    411231602711750806007124391908541454749406018899
    
    homer,homer.u,homer.u.washington.edu,homer??,homer??b,homer??.u,homer??b.u,
    homer??.u.washington.edu,homer??b.u.washington.edu,veron??,veron??b,veron??.u,
    veron??b.u,veron??.u.washington.edu,veron??b.u.washington.edu,ovid??,ovid??b,
    ovid??.u,ovid??b.u,ovid??.u.washington.edu,ovid??b.u.washington.edu 1024 35 96
    689267796374610731825787486953509952732408495373811642183824301391959769798518
    316306756845543540404502150027747372513338066403155607233260320940725477931110
    924376147125707719742211823086844278240758075989634769853326489478052443917720
    251251425997424827279486124573525873494481113605240699465714012884139399
    
    hopper,hopper?,hopper??,hopper.u,hopper?.u,hopper??.u,hopper.u.washington.edu,
    hopper?.u.washington.edu,hopper??.u.washington.edu 1024 33 1035472882891167835
    035002173719475944363139167656821967641728512427363632924585813148778564508161
    043920290815327104304262296104392880288432198139883403948977938988256151257502
    427658391686314112224729250257213668750447547394829004793657364876840997885462
    62769699791698166171793456006987365911400258443897383667
    
    horton,hortonb,horton.u,hortonb.u,horton.u.washington.edu,
    hortonb.u.washington.edu 1024 35 962844736610284867602236200516910042636288208
    340764567208940129136260513149864483624864975469888615135424216510011697680869
    807584205609239676376531670857877035759903421491056964467337393023203390048075
    540757256130646478252351049426254320640590103388411834870325648045814346288233
    74867867044930249268903032569
    
    hugo?,hugo?b,hugo?.u,hugo?b.u,hugo?.u.washington.edu,hugo?b.u.washington.edu
    1024 35 5485877234352319450695808706609071414085970680821000140914559702769359
    181352584157011800999569479609926501086614861693487741308837397214935539411361
    770238868959357952946762432166175594906181078106082322030054828433067057098350
    706440382234036335121843839378656938769889160212697252812133589670084589487486
    8891
    
    [..snip..]
    

  • If new host is part of a cluster (e.g. new homer), share the host keys instead of generating a new one.
  • In this case copy the /etc/ssh_host_key and /etc/ssh_host_key.pub from another member of the cluster
  • Make sure that the entry in /etc/ssh_known_hosts includes the new host.

• Misc.
  • server executable is /usr/local/sbin/sshd
  • host keys must exist before sshd will run!
  • either generate them using ssh-keygen or copy them from a cluster member
  • if sshd is down, connection will fall back to rlogind
• User keys (optional)
  • generate it with ssh-keygen
  • output files are ~/.ssh/identity and ~/.ssh/identity.pub
  • copy the contents of identity.pub to ~/.ssh/authorized_keys to do RSA authentication
  • ssh-agent is used to keep private user keys in memory

Other ssh features

• X11 forwarding. X11 clients started from an ssh session will have the X11 traffic go through the encrypted connection. (currently disabled)
• Kerberos credentials forwarding. (currently disabled)
• choice of ciphers
  • default is IDEA (128 bits, 64% speed compared to no encryption)
  • we use blowfish for more speed (128 bits, 88% speed compared to no encryption)
  • NDC uses arcfour (128 bits, 91% speed compared to no encryption) but the ssh code considers this cipher to be insufficiently secure and doesn't permit no-password logins. This cipher also has to be explicitly enabled when building ssh.
  • DES (56 bits, 71%) and 3DES (~112 bits, 45%) is also available
  • different ciphers can be selected by "-c".
• these features and options can be easily altered by editing ~/.ssh/config or /etc/ssh_config (shown below)

  # This is ssh client systemwide configuration file.  This file provides 
  # defaults for users, and the values can be changed in per-user configuration
  # files or on the command line.
  
  # Configuration data is parsed as follows:
  #  1. command line options
  #  2. user-specific file
  #  3. system-wide file
  # Any configuration value is only changed the first time it is set.
  # Thus, host-specific definitions should be at the beginning of the
  # configuration file, and defaults at the end.
  
  # Site-wide defaults for various options
  
  # Host *
  #   ForwardAgent yes
  ForwardX11 no
  #   RhostsAuthentication yes
  #   RhostsRSAAuthentication yes
  #   RSAAuthentication yes
  #   PasswordAuthentication yes
  #   FallBackToRsh yes
  #   UseRsh no
  #   BatchMode no
  #   StrictHostKeyChecking no
  #   IdentityFile ~/.ssh/identity
  #   Port 22
  Cipher blowfish
  #   EscapeChar ~
  
  KerberosAuthentication no
  KerberosTgtPassing no
  
  

• scp command for encrypted file copy with similar syntax to rcp. If .rhosts does not exist on the destination end, a password prompt will be presented
• "-v" command line option to turn on verbose mode. Very useful for debugging purposes as well as observing the security negotiations in action
• "-C" option to turn on packet compression, with specifiable compression ratio of 1-9 like the zip command. Useful for slow links.
• windows client is available at F-Secure web site