This is version 4 of the ssh jumbo patch. Apply by doing: cd /usr/src mkdir usr.bin/ssh/lib patch -p0 < 005_sshjumbo.patch cd usr.bin/ssh make obj make make install update your /etc/sshd_config and /etc/ssh_config files, as needed. Index: usr.bin/ssh/ChangeLog =================================================================== RCS file: ChangeLog diff -N ChangeLog --- /tmp/cvsyHrqq31367 Wed Dec 8 12:42:01 1999 +++ /dev/null Wed Dec 8 12:40:35 1999 @@ -1,578 +0,0 @@ -Fri Nov 17 16:19:20 1995 Tatu Ylonen - - * Released 1.2.12. - - * channels.c: Commented out debugging messages about output draining. - - * Added file OVERVIEW to give some idea about the structure of the - ssh software. - -Thu Nov 16 16:40:17 1995 Tatu Ylonen - - * canohost.c (get_remote_hostname): Don't ever return NULL (causes - segmentation violation). - - * sshconnect.c: Host ip address printed incorrectly with -v. - - * Implemented SSH_TTY environment variable. - -Wed Nov 15 01:47:40 1995 Tatu Ylonen - - * Implemented server and client option KeepAlive to specify - whether to set SO_KEEPALIVE. Both default to "yes"; to disable - keepalives, set the value to "no" in both the server and the - client configuration files. Updated manual pages. - - * sshd.c: Fixed Solaris utmp problem: wrong pid stored in utmp - (patch from Petri Virkkula ). - - * login.c (record_logout): Fixed removing user from utmp on BSD - (with HAVE_LIBUTIL_LOGIN). - - * Added cleanup functions to be called from fatal(). Arranged for - utmp to be cleaned if sshd terminates by calling fatal (e.g., - after dropping connection). Eliminated separate client-side - fatal() functions and moved fatal() to log-client.c. Made all - cleanups, including channel_stop_listening() and packet_close() - be called using this mechanism. - -Thu Nov 9 09:58:05 1995 Tatu Ylonen - - * sshd.c: Permit immediate login with empty password only if - password authentication is allowed. - -Wed Nov 8 00:43:55 1995 Tatu Ylonen - - * Eliminated unix-domain X11 forwarding. Inet-domain forwarding is - now the only supported form. Renamed server option - X11InetForwarding to X11Forwarding, and eliminated - X11UnixForwarding. Updated documentation. Updated RFC (marked - the SSH_CMSG_X11_REQUEST_FORWARDING message (code 26) as - obsolete, and removed all references to it). Increased protocol - version number to 1.3. - - * scp.c (main): Added -B (BatchMode). Updated manual page. - - * Cleaned up and updated all manual pages. - - * clientloop.c: Added new escape sequences ~# (lists forwarded - connections), ~& (background ssh when waiting for forwarded - connections to terminate), ~? (list available escapes). - Polished the output of the connection listing. Updated - documentation. - - * uidswap.c: If _POSIX_SAVED_IDS is defined, don't change the real - uid. Assume that _POSIX_SAVED_IDS also applies to seteuid. - This may solve problems with tcp_wrappers (libwrap) showing - connections as coming from root. - -Tue Nov 7 20:28:57 1995 Tatu Ylonen - - * Added RandomSeed server configuration option. The argument - specifies the location of the random seed file. Updated - documentation. - - * Locate perl5 in configure. Generate make-ssh-known-hosts (with - the correct path for perl5) in Makefile.in, and install it with - the other programs. Updated manual page. - - * sshd.c (main): Added a call to umask to set the umask to a - reasonable value. - - * compress.c (buffer_compress): Fixed to follow the zlib - documentation (which is slightly confusing). - - * INSTALL: Added information about Linux libc.so.4 problem. - -Mon Nov 6 15:42:36 1995 Tatu Ylonen - - * (Actually autoconf fix) Installed patch to AC_ARG_PROGRAM. - - * sshd.c, sshd.8.in: Renamed $HOME/.environment -> - $HOME/.ssh/environment. - - * configure.in: Disable shadow password checking on convex. - Convex has /etc/shadow, but sets pw_passwd automatically if - running as root. - - * Eliminated HAVE_ETC_MASTER_PASSWD (NetBSD, FreeBSD); the - pw_passwd field is automatically filled if running as root. - Put explicit code in configure.in to prevent shadow password - checking on FreeBSD and NetBSD. - - * serverloop.c (signchld_handler): Don't print error if wait - returns -1. - - * Makefile.in (install): Fixed modes of data files. - - * Makefile.in (install): Make links for slogin.1. - - * make-ssh-known-hosts: Merged a patch from melo@ci.uminho.pt to - fix the ping command. - -Fri Nov 3 16:25:28 1995 Tatu Ylonen - - * ssh.1.in: Added more information about X11 forwarding. - -Thu Nov 2 18:42:13 1995 Tatu Ylonen - - * Changes to use O_NONBLOCK_BROKEN consistently. - - * pty.c (pty_make_controlling_tty): Use setpgid instead of - setsid() on Ultrix. - - * includes.h: Removed redundant #undefs for Ultrix and Sony News; - these are already handled in configure.in. - -Tue Oct 31 13:31:28 1995 Tatu Ylonen - - * configure.in: Define SSH_WTMP to /var/adm/wtmp is wtmp not found. - - * configure.in: Disable vhangup on Ultrix. I am told this fixes - the server problems. - -Sat Oct 28 14:22:05 1995 Tatu Ylonen - - * sshconnect.c: Fixed a bug in connecting to a multi-homed host. - Restructured the connecting code to never try to use the same - socket a second time after a failed connection. - - * Makefile.in: Added explicit -m option to install, and umask 022 - when creating directories and the host key. - -Fri Oct 27 01:05:10 1995 Tatu Ylonen - - * Makefile.in: Added cleaning of $(ZLIBDIR) to clean and distclean. - - * login.c (get_last_login_time): Fixed a typo (define -> defined). - -Thu Oct 26 01:28:07 1995 Tatu Ylonen - - * configure.in: Moved testing for ANSI C compiler after the host - specific code (problems on HPUX). - - * Minor fixes to /etc/default/login stuff from Bryan O'Sullivan. - - * Fixed .SH NAME sections in manual pages. - - * compress.c: Trying to fix a mysterious bug in the compression - glue. - - * ssh-1.2.11. - - * scp.c: disable agent forwarding when running ssh from scp. - - * Added compression of plaintext packets using the gzip library - (zlib). Client configuration options Compression and - CompressionLevel (1-9 as in gzip). New ssh and scp option -C - (to enable compression). Updated RFC. - -Wed Oct 25 05:11:55 1995 Tatu Ylonen - - * Implemented ProxyCommand stuff based on patches from Bryan - O'Sullivan . - - * Merged BSD login/logout/lastlog patches from Mark Treacy - . - - * sshd.c: Added chdir("/"). - -Tue Oct 24 00:29:01 1995 Tatu Ylonen - - * Merged RSA environment= patches from Felix Leitner - with some changes. - - * sshd.c: Made the packet code use two separate descriptors for - the connection (one for input, the other for output). This will - make future extensions easier (e.g., non-socket transports, etc.). - sshd -i now uses both stdin and stdout separately. - -Mon Oct 23 21:29:28 1995 Tatu Ylonen - - * sshd.c: Merged execle -> execve patches from Mark Martinec - . This may help with execle bugs on - Convex (environment not getting passed properly). This might - also solve similar problems on Sonys; please test! - - * Removed all compatibility code for protocol version 1.0. - THIS MEANS THAT WE ARE NO LONGER COMPATIBLE WITH SSH VERSIONS - PRIOR TO 1.1.0. - - * randoms.c (random_acquire_light_environmental_noise): If - /dev/random is available, read up to 32 bytes (256 bits) from - there in non-blocking mode, and mix the new random bytes into - the pool. - - * Added client configuration option StrictHostKeyChecking - (disabled by default). If this is enabled, the client will not - automatically add new host keys to $HOME/.ssh/known_hosts; - instead the connection will be refused if the host key is not - known. Similarly, if the host key has changed, the connection - will be refused instead if just issuing a warning. This - provides additional security against man-in-the-middle/trojan - horse attacks (especially in scripts where there is no-one to - see the warnings), but may be quite inconvenient in everyday - interactive use unless /etc/ssh_known_hosts is very complete, - because new host keys must now be added manually. - - * sshconnect.c (ssh_connect): Use the user's uid when creating the - socket and connecting it. I am hoping that this might help with - tcp_wrappers showing the remote user as root. - - * ssh.c: Try inet-domain X11 forwarding regardless of whether we - can get local authorization information. If we don't, we just - come up with fake information; the forwarding code will anyway - generate its own fake information and validate that the client - knows that information. It will then substitute our fake - information for that, but that info should get ignored by the - server if it doesn't support it. - - * Added option BatchMode to disable password/passphrase querying - in scripts. - - * auth-rh-rsa.c: Changed to use uid-swapping when reading - .ssh/known_hosts. - - * sshd.8.in (command): Improved documentation of file permissions - on the manual pages. - -Thu Oct 19 21:05:51 1995 Tatu Ylonen - - * ssh-add.c (add_file): Fixed a bug causing ssh to sometimes refer - to freed memory (comment -> saved_comment). - - * log-server.c: Added a prefix to debug/warning/error/fatal - messages describing message types. Syslog does not include that - information automatically. - -Sun Oct 8 01:56:01 1995 Tatu Ylonen - - * Merged /etc/default/login and MAIL environment variable changes - from Bryan O'Sullivan . - - mail spool file location - - process /etc/default/login - - add HAVE_ETC_DEFAULT_LOGIN - - new function child_get_env and read_etc_default_login (sshd.c) - - * ssh-add.c (add_file): Fixed asking for passphrase. - - * Makefile.in: Fixed installing configure-generated man pages when - compiling in a separate object directory. - - * sshd.c (main): Moved RSA key generation until after allocating - the port number. (Actually, the code got duplicated because we - never listen when run from inetd.) - - * ssh.c: Fixed a problem that caused scp to hang when called with - stdin closed. - -Sat Oct 7 03:08:06 1995 Tatu Ylonen - - * Added server config option StrictModes. It specifies whether to - check ownership and modes of home directory and .rhosts files. - - * ssh.c: If ssh is renamed/linked to a host name, connect to that - host. - - * serverloop.c, clientloop.c: Ignore EAGAIN reported on read from - connection. Solaris has a kernel bug which causes select() to - sometimes wake up even though there is no data available. - - * Display all open connections when printing the "Waiting for - forwarded connections to terminate" message. - - * sshd.c, readconf.c: Added X11InetForwarding and - X11UnixForwarding server config options. - -Thu Oct 5 17:41:16 1995 Tatu Ylonen - - * Some more SCO fixes. - -Tue Oct 3 01:04:34 1995 Tatu Ylonen - - * Fixes and cleanups in README, INSTALL, COPYING. - -Mon Oct 2 03:36:08 1995 Tatu Ylonen - - * ssh-add.c (add_file): Fixed a bug in ssh-add (xfree: NULL ...). - - * Removed .BR from ".SH NAME" in man pages. - -Sun Oct 1 04:16:07 1995 Tatu Ylonen - - * ssh-1.2.10. - - * configure.in: When checking that the compiler works, check that - it understands ANSI C prototypes. - - * Made uidswap error message a debug() to avoid confusing errors - on AIX (AIX geteuid is brain-damaged and fails even for root). - - * Fixed an error in sshd.8 (FacistLogging -> FascistLogging). - - * Fixed distribution in Makefile.in (missing manual page .in files). - -Sat Sep 30 17:38:46 1995 Tatu Ylonen - - * auth-rhosts.c: Fixed serious security problem in - /etc/hosts.equiv authentication. - -Fri Sep 29 00:41:02 1995 Tatu Ylonen - - * Include machine/endian.h on Paragon. - - * ssh-add.c (add_file): Made ssh-add keep asking for the - passphrase until the user just types return or cancels. - Make the dialog display the comment of the key. - - * Read use shosts.equiv in addition to /etc/hosts.equiv. - - * sshd.8 is now sshd.8.in and is processed by configure to - substitute the proper paths for various files. Ditto for ssh.1. - Ditto for make-ssh-known-hosts.1. - - * configure.in: Moved /etc/sshd_pid to PIDDIR/sshd.pid. PIDDIR - will be /var/run if it exists, and ETCDIR otherwise. - -Thu Sep 28 21:52:42 1995 Tatu Ylonen - - * On Ultrix, check if sys/syslog.h needs to be included in - addition to syslog.h. - - * make-ssh-known-hosts.pl: Merged Kivinen's fixes for HPUX. - - * configure.in: Put -lwrap, -lsocks, etc. at the head of LIBS. - - * Fixed case-insensitivity in auth-rhosts.c. - - * Added missing socketpair.c to EXTRA_SRCS (needed on SCO), plus - other SCO fixes. - - * Makefile.in: Fixed missing install_prefixes. - -Wed Sep 27 03:57:00 1995 Tatu Ylonen - - * ssh-1.2.9. - - * Added SOCKS support. - - * Fixed default setting of IgnoreRhosts option. - - * Pass the magic cookie to xauth in stdin instead of command line; - the command line is visible in ps. - - * Added processing $HOME/.ssh/rc and /etc/sshrc. - - * Added a section to sshd.8 on what happens at login time. - -Tue Sep 26 01:27:40 1995 Tatu Ylonen - - * Don't define speed_t on SunOS 4.1.1; it conflicts with system - headers. - - * Added support for .hushlogin. - - * Added --with-etcdir. - - * Read $HOME/.environment after /etc/environment. - -Mon Sep 25 03:26:06 1995 Tatu Ylonen - - * Merged patches for SCO Unix (from Michael Henits). - -Sun Sep 24 22:28:02 1995 Tatu Ylonen - - * Added ssh option ConnectionAttempts. - -Sat Sep 23 12:30:15 1995 Tatu Ylonen - - * sshd.c: Don't print last login time and /etc/motd if a command - has been specified (with ssh -t host command). - - * Added support for passing the screen number in X11 forwarding. - It is implemented as a compatible protocol extension, signalled - by SSH_PROTOFLAG_SCREEN_NUMBER by the child. - - * clientloop.c: Fixed bugs in the order in which things were - processed. This may solve problems with some data not getting - sent to the server as soon as possible (probably solves the TCP - forwarding delayed close problem). Also, it looked like window - changes might not get transmitted as early as possible in some - cases. - - * clientloop.c: Changed to detect window size change that - happened while ssh was suspended. - - * ssh.c: Moved the do_session function (client main loop) to - clientloop.c. Divided it into smaller functions. General cleanup. - - * ssh-1.2.8 - -Fri Sep 22 22:07:46 1995 Tatu Ylonen - - * sshconnect.c (ssh_login): Made ssh_login take the options - structure as argument, instead of the individual arguments. - - * auth-rhosts.c (check_rhosts_file): Added support for netgroups. - - * auth-rhosts.c (check_rhosts_file): Added support for negated - entries. - -Thu Sep 21 00:07:56 1995 Tatu Ylonen - - * auth-rhosts.c: Restructured rhosts authentication code. - Hosts.equiv now has same format as .rhosts: user names are allowed. - - * Added support for the Intel Paragon. - - * sshd.c: Don't use X11 forwarding with spoofing if no xauth - program. Changed configure.in to not define XAUTH_PATH if - there is no xauth program. - - * ssh-1.2.7 - - * sshd.c: Rewrote the code to build the environment. Now also reads - /etc/environment. - - * sshd.c: Fixed problems in libwrap code. --with-libwrap now - takes optional library name/path. - - * ssh-1.2.6 - - * Define USE_PIPES by default. - - * Added support for Univel Unixware and MachTen. - - * Added IgnoreRhosts server option. - - * Added USE_STRLEN_FOR_AF_UNIX; it is needed at least on MachTen. - -Wed Sep 20 02:41:02 1995 Tatu Ylonen - - * sshd.c (do_child): don't call packet_close when /etc/nologin, - because packet_close does shutdown, and the message does not get - sent. - - * pty.c (pty_allocate): Push ttcompat streams module. - - * randoms.c (random_acquire_light_environmental_noise): Don't use - the second argument to gettimeofday as it is not supported on - all systems. - - * login.c (record_login): Added NULL second argument to gettimeofday. - -Tue Sep 19 13:25:48 1995 Tatu Ylonen - - * fixed pclose wait() in sshd key regeneration (now only collects - easily available noise). - - * configure.in: test for bsdi before bsd*. - - * ssh.c: Don't print "Connection closed" if -q. - -Wed Sep 13 04:19:52 1995 Tatu Ylonen - - * Released ssh-1.2.5. - - * Hopefully fixed "Waiting for forwarded connections to terminate" - message. - - * randoms.c, md5.c: Large modifications to make these work on Cray - (which has no 32 bit integer type). - - * Fixed a problem with forwarded connection closes not being - reported immediately. - - * ssh.c: fixed rhosts authentication (broken by uid-swapping). - - * scp.c: Don't use -l if server user not specified (it made - setting User in the configuration file not work). - - * configure.in: don't use -pipe on BSDI. - - * randoms.c: Major modifications to make it work without 32 bit - integers (e.g. Cray). - - * md5.c: Major modifications to make it work without 32 bit - integers (e.g. Cray). - - * Eliminated HPSUX_BROKEN_PTYS. The code is now enabled by - default on all systems. - -Mon Sep 11 00:53:12 1995 Tatu Ylonen - - * sshd.c: don't include sshd pathname in log messages. - - * Added libwrap stuff (includes support for identd). - - * Added OSF/1 C2 extended security stuff. - - * Fixed interactions between getuid() and uid-swap stuff. - -Sun Sep 10 00:29:27 1995 Tatu Ylonen - - * serverloop.c: Don't send stdout data to client until after a few - milliseconds if there is very little data. This is because some - systems give data from pty one character at a time, which would - multiply data size by about 16. - - * serverloop.c: Moved server do_session to a separate file and - renamed it server_loop. Split it into several functions and - partially rewrote it. Fixed "cat /etc/termcap | ssh foo cat" hangup. - - * Screwed up something while checking stuff in under cvs. No harm, - but bogus log entries... - -Sat Sep 9 02:24:51 1995 Tatu Ylonen - - * minfd.c (_get_permanent_fd): Use SHELL environment variable. - - * channels.c (x11_create_display_inet): Created - HPSUX_NONSTANDARD_X11_KLUDGE; it causes DISPLAY to contain the - IP address of the host instead of the name, because HPSUX uses - some magic shared memory communication for local connections. - - * Changed SIGHUP processing in server; it should now work multiple - times. - - * Added length limits in many debug/log/error/fatal calls just in - case. - - * login.c (get_last_login_time): Fixed location of lastlog. - - * Rewrote all uid-swapping code. New files uidswap.h, uidswap.c. - - * Fixed several security problems involving chmod and chgrp (race - conditions). Added warnings about dubious modes for /tmp/.X11-unix. - -Fri Sep 8 20:03:36 1995 Tatu Ylonen - - * Changed readconf.c to never display anything from the config - file. This should now be prevented otherwise, but let's play safe. - - * log-server.c: Use %.500s in syslog() just to be sure (they - should already be shorter than 1024 though). - - * sshd.c: Moved setuid in child a little earlier (just to be - conservative, there was no security problem that I could detect). - - * README, INSTALL: Added info about mailing list and WWW page. - - * sshd.c: Added code to use SIGCHLD and wait zombies immediately. - - * Merged patch to set ut_addr in utmp. - - * Created ChangeLog and added it to Makefile.in. - - * Use read_passphrase instead of getpass(). - - * Added SSH_FALLBACK_CIPHER. Fixed a bug in default cipher - selection (IDEA used to be selected even if not supported by the - server). - - * Use no encryption for key files if empty passphrase. - - * Added section about --without-idea in INSTALL. - - * Version 1.2.0 was released a couple of days ago. - Index: usr.bin/ssh/INSTALL =================================================================== RCS file: INSTALL diff -N INSTALL --- /dev/null Wed Dec 8 12:40:35 1999 +++ /tmp/cvsbLdgr31367 Wed Dec 8 12:42:01 1999 @@ -0,0 +1,409 @@ +This is a hacked-up version of ssh-1.2.12. + +The GMP and DES sources are now external to the distribution. To build +this software it is necessary to first have GMP and a DES +implementation installed somewhere. Some systems comes with GMP and +DES preinstalled. If your system doesn't; pick up the GMP sources from +your favorite GNU ftp site (ftp://prep.ai.mit.edu/pub/gnu/). There is +a free DES implementation made by Eric Young that can be found under +the name libdes-x.x.x.tar.gz, for example at +ftp://ftp.psy.uq.oz.au/pub/Crypto/DES/. + +The distribution optionally supports Kerberos version 4 authentication +and AFS. If you want to build with Kerberos support and your system +comes with Kerberos preinstalled add the switch --with-krb4=/usr to +configure. Otherwise, first build and install Kerberos and then use +--with-krb4=/usr/whatever-directory. If you don't want Kerberos +support use --without-krb4 (the default). Kerberos can be found at +ftp://ftp.pdc.kth.se/pub/krb/src/. + +Compression support is now optional. If you don't have zlib installed +configure using --without-zlib or first install zlib. We have +succesfully used zlib-1.0.4.tar.gz + +For more detailed installation instructions read the rest of this file +and README.AFS-KERBEROS. + +---------------------------------------------------------------------------- +This file describes how to install the Secure Shell (ssh). Secure Shell is +a replacement for rlogin and rsh. It seamlessly encrypts all communications, +provides improved security, and has useful new features. + + +INSTALLATION + +For most machines and configurations, the following is all you need. + + ./configure + make + make install + +Then check (and edit if needed) the following files: + /etc/sshd_config (server configuration file) + /etc/ssh_config (client configuration file - defaults for users) + +You may also want to create the /etc/ssh_known_hosts for your site and update +it periodically. See the manual page for make-ssh-known-hosts on how to +do this easily. The file format is documented on the sshd manual page. + +The source is written in ANSI C, and requires an ANSI C compiler or GCC. +A copy of GCC is available on all major FTP sites (e.g., in +ftp:/prep.ai.mit.edu/pub/gnu). + + +CONFIGURATION OPTIONS + +The package comes with an Autoconf-generated configure script. The +script accepts several options + All standard options, including: + --prefix=PREFIX where to install files (default: subdirs of /usr/local) + --exec_prefix=PREFIX where to install executables (default: same as prefix) + --srcdir=DIR find sources in DIR (default: where configure is) + Specific options: + --with-rsh=PATH Use rsh specified by PATH when needed + --with-etcdir=PATH Store system files in the given dir (default: /etc) + --with-path=PATH Default path to pass to user shell. + --with-rsaref Use rsaref2 from rsaref2 subdirectory (see below). + --with-libwrap[=PATH] Use libwrap (tcp_wrappers) and identd (see below). + --with-socks[=PATH] Include SOCKS (firewall traversal) support. + --without-idea Don't include IDEA (see below). + --with-securid[=PATH] Support for the SecurID card (see README.SECURID). + --enable-warnings Adds -Wall to CFLAGS if using gcc. + +You may also want to configure the following variables: + CC=compiler specify name of the C compiler (default: gcc or cc) + CFLAGS=flags specify flags to C compiler (default: -O -g or just -O) + LDFLAGS=flags specify flags to linker (default: none) + +Alternate values can be given to configure in the environment, e.g.: + CC=xcc CFLAGS="-O2" LDFLAGS="-L/lib/zzz" ./configure +(Note that if you have already configured, and later decide to give +some values on the command line, you may need to say "make distclean" +before reconfiguring.) + + +CONFIGURATION FILES + +The server has a configuration file /etc/sshd_config, which specifies the +permitted authentication methods, hosts, port number, etc. The defaults are +acceptable for most sites, but you may want to check this file. Its format +is documented on the sshd manual page. + +The client reads a configuration file /etc/ssh_config, which gives +site-wide defaults for various options. Options in this file can be +overridden by per-user configuration files. The file is documented on +the ssh manual page. + + +MAKEFILE + +The Makefile is generated from Makefile.in by running configure. It supports +the following targets: + all: compile everything + install: install in $exec_prefix/bin and $prefix/man/man1. + uninstall: remove installed files + clean: remove object files and executables + distclean: remove anything not in the distribution + + +PORTABILITY + +This software has been used at least in the following environments. + + 386BSD 0.1; i386 + AIX 3.2.5, 4.1; RS6000, PowerPC + BSD 4.4; several platforms + BSD/OS 1.1, 2.0.1; i486 + BSD/386 1.1; i386 + ConvexOS 10.1; Convex + DGUX 5.4R2.10; DGUX + FreeBSD 1.x, 2.x; Pentium + HPUX 9.0x, 10.0; HPPA + IRIX 5.2, 5.3; SGI Indy + IRIX 6.0.1; Mips-R8000 + Linux 1.2.8 Slackware 2.1.0; i486 + Mach3; Mips + Mach3/Lites; i386 + Machten 2.2 + NetBSD 1.0A; Pentium, Sparc + OSF/1 3.0, 3.2, 3.2a; Alpha + Sequent Dynix/ptx 3.2.0 V2.1.0; i386 + SCO Unix; i386 (client only) + SINIX 5.42; Mips R4000 + Solaris 2.3, 2.4; Sparc + Sony NEWS-OS 3.3 (BSD 4.3); m68k + SunOS 4.1.2, 4.1.3, 4.1.4; Sparc + SysV 4.x; several platforms + Ultrix x.x; Mips + Unicos 8.0.3; Cray C90 + +Please report back any other environments where you have used ssh, +and send back any patches you had to do so that they can be integrated +to the distribution. The proper address is ossh-bugs@sics.se. +Always remember to mention the ssh version number and machine type in +your bug reports. Please include also the output of the -v option +from the client side, and the output of the -d option from the server, +if applicable. + +Not all compilers work in all environments. If you have problems, try +compiling with gcc-2.7. *** SPARC NOTE: gcc-2.7.0 appears to generate +bad code on Sparc (Solaris 2.3) when compiling without -O. Try +gcc-2.6.3 or compile with -O. *** + +Solaris 2.4 note: you need to install "kernel jumbo patch number +101945-32" (dated August 31, 1995) for ssh to work. The symptom is +that ssh dies with a "Resource temporarily unavailable" error. + +Linux note: Some linux systems have a bug which causes an error about +libc.so.4 when compiling ssh. This can be solved by any of the +following ways: + - Do "ln -s libc.sa /usr/lib/libg.sa" as root. + - Install gcc-2.7.0. + - Configure ssh with "CFLAGS=-O ./configure" (i.e., without debug info). +More information on this problem is available in +ftp://ftp.netcom.com/pub/ze/zenon/linux. + +BSDI BSD/OS note: Apparently the gcc that comes with BSD/OS is +broken. Use "CC=cc ./configure" or "setenv CC cc; ./configure" when +configuring to force it to use cc instead of gcc. + +ConvexOS note: Convex "make" is broken. Install GNU make first if you +have trouble compiling ssh. + + +COMPILING WITH RSAREF2 + +If you are using ssh in the United States, you may want to use the +RSAREF2 library from RSADSI. This may make it legal to use ssh +without a separate license for non-commercial purposes. RSAREF2 is +not included in the distribution; however, it is available on any +major ftp site around the world (e.g., +ftp://ftp.funet.fi/pub/crypt/cryptography/asymmetric/rsa/rsaref2.tar.gz). +The RSAREF2 distribution should be unpacked into "rsaref2" +subdirectory in the ssh distribution directory (a symbolic link to +rsaref2 is not sufficient). Configure should be given the +--with-rsaref option. (Note that there is no need to *compile* +rsaref2 manually; the ssh Makefile will compile those files it needs.) + +Using RSAREF outside the United States is not recommended and only +causes legal complications. + +RSAREF2 does not work for large key sizes (> 1024). This may be the +problem if you get "RSAPrivateDecrypt failed". + +On alpha, one should edit rsaref2/source/global.h, and make UINT4 +"unsigned int" instead of "unsigned long int". + + +LIBWRAP AND IDENTD + +Ssh does not normally use identd or tcp-wrappers. However, it can be +compiled to use these by adding --with-libwrap on the command line. +This requires that the tcp_wrappers libwrap.a library and the +associated tcpd.h have been installed somewhere where the compiler can +find them. With libwrap support, ssh will process the +/etc/hosts.allow and /etc/hosts.deny files, and use identd if required +by them. The name of the user on the client side (as returned by +identd) will be logged if requested by the configuration files. See +tcp_wrappers documentation for more information. + + +COMPILING WITHOUT IDEA + +The IDEA cipher can be freely used for non-commercial use. However, +commercial use may require a license in a number of countries. + +Ssh can be compiled without IDEA by using the --without-idea configure +option. This disables IDEA, and causes 3DES to be used for encrypting +key/identity files and as the default session cipher. (The default +session cipher can be changed by editing SSH_FALLBACK_CIPHER in +ssh.h.) + +If one disables IDEA after having used it for some time, it is +possible that there are key files around that were encrypted with IDEA. + +Key files can be converted to use 3DES by creating a special version +of ssh-keygen that includes IDEA (was compiled without +--without-idea), but that generates key files encrypted with 3DES +(edit SSH_AUTHFILE_CIPHER to be SSH_CIPHER_3DES even when WITHOUT_IDEA +is not defined). Any operation with re-encrypts the key file can be +used, such as changing the comment or changing the passphrase. + + +STARTING THE SERVER + +The server should be started at boot from /etc/rc or equivalent. It +need not be given any arguments; however, an optional "-b bits" flag +may be used to specify RSA key size (default is 768). Key sizes less +than 512 can be broken; larger key sizes generally mean more security +but require more time to generate and use. 1024 bits is secure for +any practical time with current technology. + +The server is not started using inetd, because it needs to generate +the RSA key before serving the connection, and this can take about a +minute on slower machines. On a fast machine, and small (breakable) +key size (< 512 bits) it may be feasible to start the server from +inetd on every connection. The server must be given "-i" flag if +started from inetd. + + +REPLACING RLOGIN AND RSH + +This software has been designed so that it can be installed with the +names rlogin, rsh, and rcp, and it will use the Secure Shell +protocol whenever the remote machine supports it, and will +automatically execute rlogin/rsh (after displaying a warning that +there is no encryption) if the remote host does not support Secure +Shell. + +Rlogin/rsh replacement is done as follows: + ./configure --with-rsh=RSH-PATH --program-transform-name='s/^s/r/' + make install + +where RSH-PATH is the complete pathname of the real rsh program. (You +may want to copy the old rsh program to a suitable location). + +This will create links for rlogin, rsh, and rcp. If you are +installing them in the same directory where rlogin etc. normally are +(e.g., /usr/bin), you must first move the original programs to some +other directory (e.g., /usr/lib/rsh). + +When doing this, you should also build a file containing the host keys of all +machines in your organization, and copy this file to /etc/ssh_known_hosts +on every machine. This will make .rhosts and /etc/hosts.equiv authentication +work for users without any changes to the user configuration, but will be +much more secure than conventional .rhosts and /etc/hosts.equiv authentication. +This will also protect the users against router attacks where someone (perhaps +remotely) reconfigures the routers to direct connections to a certain host +to a different machine, which can then grab any passwords which the user +types thinking he/she is connected to the real machine. + + +CLIENT SUID ROOT, SERVER RUN AS ROOT + +This package installs two programs that need special privileges. Ssh +is the client program, and it is by default installed as suid root, +because it needs to create a privileged port in order to use .rhosts +files for authentication. If it is not installed as suid root, it will +still be usable, but .rhosts authentication will not be available. Also, the +private host key file is readable by root only. + +Sshd is the daemon that listens for connections. It should preferably +be run as root, because it is by normally listening on a privileged +port, and it needs to be able to do setuid(), update utmp, chown ptys +etc. when a user logs in. If it is not run as root, explicit "-p +port" option must be given to specify an alternate port (same port +must also be specified for clients), "-h host_key_file_path" must be +given to specify an alternate host key file, and it cannot be used to +log in as any other user than the user running it (because it cannot +call setuid()). Also, if your system uses shadow passwords, password +authentication will not work when running as someone else than root. + +Both the server and the client have been carefully screened for +possible security problems, and are believed to be secure. However, +there can be no guarantee. If you find any problems, please report +them immediately. + + +COMMON PROBLEMS + +This section lists some common installation problems. + +Shadow passwords + + There are many different shadow password schemes. Ssh currently recognizes + and supports many of them; however, there are probably still many that + it does not understand. This may not be visible at compile time. + If your system uses shadow passwords, and password authentication does not + work even if sshd is running as root, this is probably your problem. + Please contact the author if this happens. Code to recognize (configure.in) + and use (auth-passwd.c) the shadow password mechanism on new systems + is highly welcome. + +login.c does not compile, or logging of logins does not work properly + + Mechanisms for updating wtmp, utmp, lastlog, and similar mechanisms + are not standardized. Ssh substitutes many of the functions of the + conventional login program. These functions are implemented in login.c. + You may need to modify this file to make it work on exotic systems. + Please send any modifications and bug fixes back to the author for inclusion + in the distribution. If you just want to try ssh, and cannot get this file + to compile, if is safe to define all of the functions as empty; however, + in that case logins will not be logged. + +Sshd does not start or dies immediately + + The easiest thing to do is to give the -d option to sshd. It will + then send debugging output to stderr (and syslog). The -d option + also has other side effects, e.g. the daemon will not fork and will + only serve a single connection before exiting. However, it is very + useful for debugging problems. + + Sshd sends debugging output to the system log. Check your system + log (and syslogd configuration) to see why it dies. One possible + reason is that your system does not have a proper host key in + /etc/ssh_host_key. You can either generate a key with ssh-keygen + (it is automatically generated by "make install"), or specify an + alternative key with the -h option to the server. Another reason + could be that the port which the server tries to listen is already + reserved by some other program. + +Rhosts authentication does not work + + By default, the server does not accept normal .rhosts or /etc/hosts.equiv + authentication, because they are fundamentally insecure and can be spoofed + by anyone with access to the local network. Rhosts authentication can be + enabled at compile time by giving the --with-rhosts option to configure. + + The preferred alternative is to collect the public host keys of the entire + site to a file, and copy this to /etc/ssh_known_hosts on every machine in + the organization running sshd. This will prevent all IP spoofing attacks + and provides improved security (provided rshd, rlogind, and rexecd are + disabled). + +Opening connections is too slow + + On very slow machines, encrypting and decrypting the session key may + be too slow. For example, on a heavily loaded sun3 it took + several minutes to log in with the default key sizes. When we changed it + to use shorter host key (512 bits) and server key (384 bits), + login time dropped to about a second. A symptom of this problem is + that "ssh -v hostname" waits for a long time after printing "Sent + encrypted session key". + + Shorter host keys can be generated with "ssh-keygen -b 512", giving + /etc/ssh_host_key as the file in which to save the key (with empty + passphrase). The server key size can be specified with the -b + option on sshd command line (typically, in /etc/rc.local). The + server must be restarted for changes to take effect. + +The program complains "Could not set controlling tty" or something similar + + There are many different styles of pseudo ttys. Ssh currently + supports about five different styles (plus variations of them). It + is quite possible that there are more variations, some of which are + not supported by existing code. Fixing the problem may require + adding new code in pty.c and configure.in. You are encouraged to + write the needed code and send a patch to the author, or at least + report the problem. + +General problem solving + + The client has -v option, which sends verbose output to stdout. It + is very helpful in solving problems. + + The server has -d option, which causes it to send verbose debugging + output to system log and stderr. This option also causes the server + to only serve a single connection and not fork, which helps debugging. + + +REPORTING PROBLEMS AND OTHER CONTACTS + +Please report any bugs, problems, and enhancements to +ossh-bugs@sics.se. + +There is a mailing list for ossh. It is ossh@sics.se. If you would +like to join, send a message to majordomo@sics.se with "subscribe +ossh" in body. + +Copyright (c) 1995 Tatu Ylonen , Espoo, Finland. Index: usr.bin/ssh/Makefile =================================================================== RCS file: /cvs/src/usr.bin/ssh/Makefile,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- usr.bin/ssh/Makefile 1999/09/27 23:47:43 1.4 +++ usr.bin/ssh/Makefile 1999/10/25 20:27:26 1.5 @@ -1,8 +1,8 @@ -# $OpenBSD: Makefile,v 1.4 1999/09/27 23:47:43 deraadt Exp $ +# $OpenBSD: Makefile,v 1.5 1999/10/25 20:27:26 markus Exp $ .include -SUBDIR= ssh sshd ssh-add ssh-keygen ssh-agent scp +SUBDIR= lib ssh sshd ssh-add ssh-keygen ssh-agent scp distribution: install -C -o root -g wheel -m 0644 ${.CURDIR}/ssh_config \ Index: usr.bin/ssh/Makefile.in =================================================================== RCS file: Makefile.in diff -N Makefile.in --- /dev/null Wed Dec 8 12:40:35 1999 +++ /tmp/cvsLSrVi31367 Wed Dec 8 12:42:01 1999 @@ -0,0 +1,344 @@ +# +# Makefile.in +# +# Author: Tatu Ylonen +# +# Copyright (c) 1995 Tatu Ylonen , Espoo, Finland +# All rights reserved +# +# Created: Wed Mar 22 17:37:49 1995 ylo +# +# $Id: Makefile.in,v 1.2 1999/09/26 21:47:52 deraadt dead $ +# + +srcdir = @srcdir@ + +VPATH = $(srcdir) + +install_prefix = +prefix = @prefix@ +exec_prefix = @exec_prefix@ +bindir = $(exec_prefix)/bin +sbindir = $(exec_prefix)/sbin +mandir = $(prefix)/man +man1dir = $(mandir)/man1 +man8dir = $(mandir)/man8 +etcdir = @ETCDIR@ +piddir = @PIDDIR@ + +CC = @CC@ +CFLAGS = @CFLAGS@ +LDFLAGS = @LDFLAGS@ +DEFS = @DEFS@ +LIBS = @LIBS@ +LIBOBJS = @LIBOBJS@ +CONFOBJS = @CONFOBJS@ + +MAKEDEP = @MAKEDEP@ +LN_S = @LN_S@ +RANLIB = @RANLIB@ +INSTALL = @INSTALL@ +INSTALL_PROGRAM = @INSTALL_PROGRAM@ +INSTALL_DATA = @INSTALL_DATA@ +WISH = @WISH@ + +GMPLIBS = @GMPLIBS@ +GMPINCS = @GMPINCS@ + +KRB4_AUTH = @KRB4_AUTH@ +KRB4_ROOT = @KRB4_ROOT@ +KRB4_INCS = @KRB4_INCS@ +KRB4_LIBS = @KRB4_LIBS@ +RADIX = @RADIX@ + +RSAREFDEP = @RSAREFDEP@ + +transform = @program_transform_name@ + +HOST_KEY_FILE = $(etcdir)/ssh_host_key +HOST_CONFIG_FILE = $(etcdir)/ssh_config +SERVER_CONFIG_FILE = $(etcdir)/sshd_config + +SHELL = /bin/sh + +#ZLIBLIBS = -L$(ZLIBDIR) -lz +#ZINCS = + +RSAREFDIR = rsaref2 +RSAREFSRCDIR = $(RSAREFDIR)/source + +CIPHER_OBJS = cipher.o $(CONFOBJS) +COMMON_OBJS = $(LIBOBJS) \ + rsa.o randoms.o ssh_md5.o buffer.o packet.o \ + xmalloc.o ttymodes.o channels.o bufaux.o authfd.o authfile.o crc32.o \ + rsaglue.o match.o mpaux.o minfd.o $(CIPHER_OBJS) +SSHD_OBJS = sshd.o $(KRB4_AUTH) auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o pty.o \ + log-server.o login.o hostfile.o canohost.o servconf.o tildexpand.o \ + uidswap.o serverloop.o $(RADIX) $(COMMON_OBJS) +SSH_OBJS = ssh.o sshconnect.o log-client.o readconf.o hostfile.o readpass.o \ + tildexpand.o uidswap.o clientloop.o canohost.o $(RADIX) $(COMMON_OBJS) +KEYGEN_OBJS = ssh-keygen.o log-client.o readpass.o rsa.o randoms.o ssh_md5.o \ + buffer.o xmalloc.o authfile.o $(CIPHER_OBJS) mpaux.o \ + bufaux.o $(LIBOBJS) +AGENT_OBJS = ssh-agent.o log-client.o rsa.o randoms.o ssh_md5.o buffer.o \ + xmalloc.o bufaux.o authfd.o authfile.o rsaglue.o $(CIPHER_OBJS) \ + mpaux.o minfd.o $(LIBOBJS) +ADD_OBJS = ssh-add.o log-client.o readpass.o rsa.o randoms.o ssh_md5.o buffer.o \ + xmalloc.o bufaux.o authfd.o authfile.o $(CIPHER_OBJS) \ + mpaux.o minfd.o $(LIBOBJS) +SCP_OBJS = scp.o xmalloc.o +GEN_MINFD_OBJS = gen_minfd.o $(LIBOBJS) + +USER_SHELLS = sh jsh ksh csh tcsh bash zsh ash + +SRCS = $(SSHD_OBJS:.o=.c) $(SSH_OBJS:.o=.c) $(KEYGEN_OBJS:.o=.c) \ + $(AGENT_OBJS:.o=.c) $(ADD_OBJS:.o=.c) \ + $(SCP_OBJS:.o=.c) \ + $(GEN_MINFD_OBJS:.o=.c) +EXTRA_SRCS = memmove.c strerror.c remove.c random.c putenv.c osfc2.c \ + socketpair.c +MAN1PAGES = ssh-keygen.1 ssh-agent.1 ssh-add.1 scp.1 +MAN1GENERATED = ssh.1 +MAN1SOURCES = ssh.1.in ssh-keygen.1 ssh-agent.1 ssh-add.1 scp.1 +MAN8GENERATED = sshd.8 +MAN8SOURCES = sshd.8.in + +DISTFILES = COPYING.Ylonen README.AFS-KERBEROS README README.SECURID \ + INSTALL TODO OVERVIEW \ + configure configure.in config.guess config.sub Makefile.in \ + ssh-askpass.wish host_config.sample config.sample \ + acconfig.h config.h.in server_config.sample \ + $(MAN1SOURCES) $(MAN8SOURCES) *.c *.h install-sh \ + RFC.nroff RFC \ + ChangeLog + +DISTNAME = `sed 's/.*"\(.*\)".*/\1/' version.h` + +NORMAL_PROGRAMS = ssh-keygen ssh-askpass ssh-agent ssh-add scp + +SBIN_PROGRAMS = sshd +PROGRAMS = ssh $(SBIN_PROGRAMS) $(NORMAL_PROGRAMS) +SSH_PROGRAM = $(bindir)/ssh + +all: $(PROGRAMS) + +RFC: RFC.nroff rfc-pg + tbl RFC.nroff | nroff -ms | sed 's/FORMFEED\[Page/ [Page/' | ./rfc-pg -n5 >RFC + +rfc-pg: rfc-pg.c + $(CC) -o rfc-pg rfc-pg.c + +.c.o: + $(CC) -c -I. $(KRB4_INCS) $(GMPINCS) $(ZINCS) $(DEFS) -DHOST_KEY_FILE=\"$(HOST_KEY_FILE)\" -DHOST_CONFIG_FILE=\"$(HOST_CONFIG_FILE)\" -DSERVER_CONFIG_FILE=\"$(SERVER_CONFIG_FILE)\" -DSSH_PROGRAM=\"$(SSH_PROGRAM)\" -DETCDIR=\"$(etcdir)\" -DPIDDIR=\"$(piddir)\" $(CFLAGS) $< + +sshd: $(SSHD_OBJS) $(RSAREFDEP) + -rm -f sshd + $(CC) $(LDFLAGS) -o sshd $(SSHD_OBJS) $(GMPLIBS) $(ZLIBLIBS) $(KRB4_LIBS) $(LIBS) + +ssh: $(SSH_OBJS) $(RSAREFDEP) + -rm -f ssh + $(CC) $(LDFLAGS) -o ssh $(SSH_OBJS) $(GMPLIBS) $(ZLIBLIBS) $(KRB4_LIBS) $(LIBS) + +ssh-keygen: $(KEYGEN_OBJS) $(RSAREFDEP) + -rm -f ssh-keygen + $(CC) $(LDFLAGS) -o ssh-keygen $(KEYGEN_OBJS) $(GMPLIBS) $(KRB4_LIBS) $(LIBS) + +ssh-agent: $(AGENT_OBJS) $(RSAREFDEP) + -rm -f ssh-agent + $(CC) $(LDFLAGS) -o ssh-agent $(AGENT_OBJS) $(GMPLIBS) $(KRB4_LIBS) $(LIBS) + +ssh-add: $(ADD_OBJS) $(RSAREFDEP) + -rm -f ssh-add + $(CC) $(LDFLAGS) -o ssh-add $(ADD_OBJS) $(GMPLIBS) $(KRB4_LIBS) $(LIBS) + +scp: $(SCP_OBJS) $(LIBOBJS) + -rm -f scp + $(CC) $(LDFLAGS) -o scp $(SCP_OBJS) $(LIBOBJS) $(KRB4_LIBS) $(LIBS) + +ssh-askpass: ssh-askpass.wish + -rm -f ssh-askpass + echo "#! $(WISH) -f" >ssh-askpass + cat $(srcdir)/ssh-askpass.wish >>ssh-askpass + chmod +x ssh-askpass + +gen_minfd: $(GEN_MINFD_OBJS) + $(CC) $(LDFLAGS) -o gen_minfd $(GEN_MINFD_OBJS) $(LIBS) + +minfd.o: minfd.h +minfd.h: gen_minfd + rm -f minfd.h minfd.h~ + ./gen_minfd $(USER_SHELLS) > minfd.h~ + mv -f minfd.h~ minfd.h + +$(RSAREFSRCDIR)/librsaref.a: + -if test '!' -d $(RSAREFDIR); then \ + (cd $(srcdir); tar cf - $(RSAREFSRCDIR)) | tar xf -; fi + cd $(RSAREFSRCDIR); $(MAKE) -f ../../Makefile librsaref.a + +RSAREFSRCS = desc.c digit.c md2c.c md5c.c nn.c prime.c r_dh.c r_encode.c \ + r_enhanc.c r_keygen.c r_random.c r_stdlib.c rsa.c + +# Note: this target is used in a recursive make, with VPATH pointing to source +librsaref.a: + for i in $(RSAREFSRCS); do $(CC) $(CFLAGS) -c $$i; done + $(AR) rc librsaref.a $(RSAREFSRCS:.c=.o) + $(RANLIB) librsaref.a + +# Creates /etc/ssh_host_key +generate-host-key: + -@if test -f $(install_prefix)$(HOST_KEY_FILE); \ + then echo "You already have a host key in $(install_prefix)$(HOST_KEY_FILE)."; \ + else \ + umask 022; echo "Generating 1024 bit host key."; \ + ./ssh-keygen -b 1024 -f $(install_prefix)$(HOST_KEY_FILE) -N ''; \ + fi + +# Creates install directories +make-dirs: + -umask 022; if test '!' -d $(install_prefix)$(prefix); then \ + mkdir $(install_prefix)$(prefix); fi; \ + if test '!' -d $(install_prefix)$(exec_prefix); then \ + mkdir $(install_prefix)$(exec_prefix); fi; \ + if test '!' -d $(install_prefix)$(etcdir); then \ + mkdir $(install_prefix)$(etcdir); fi; \ + if test '!' -d $(install_prefix)$(bindir); then \ + mkdir $(install_prefix)$(bindir); fi; \ + if test '!' -d $(install_prefix)$(sbindir); then \ + mkdir $(install_prefix)$(sbindir); fi; \ + if test '!' -d $(install_prefix)$(mandir); then \ + mkdir $(install_prefix)$(mandir); fi; \ + if test '!' -d $(install_prefix)$(man1dir); then \ + mkdir $(install_prefix)$(man1dir); fi; \ + if test '!' -d $(install_prefix)$(man8dir); then \ + mkdir $(install_prefix)$(man8dir); fi + +# Ssh is much to large and hairy to be installed suid root by +# default. Disabled for now/bg. If you really need rhosts +# authentication do a manual chmod u+s $(install_prefix)$(bindir)/ssh. +# +# Ssh is preferably installed suid root. It can also be used non-root, +# but then it cannot connect from a privileged socket, and rhosts +# authentication will be disabled. +# +# Sshd is not suid root, but should preferably be run as root +# (otherwise it can only log in as the user it runs as, and must be +# bound to a non-privileged port). Also, password authentication may +# not be available if non-root and using shadow passwords. +install: $(PROGRAMS) make-dirs generate-host-key + $(INSTALL_PROGRAM) -o root -m 0755 ssh $(install_prefix)$(bindir)/ssh + -if test "`echo ssh | sed '$(transform)'`" '!=' ssh; then \ + rm -f $(install_prefix)$(bindir)/`echo ssh | sed '$(transform)'`; \ + $(LN_S) ssh \ + $(install_prefix)$(bindir)/`echo ssh | sed '$(transform)'`; fi + rm -f $(install_prefix)$(bindir)/slogin + $(LN_S) ssh $(install_prefix)$(bindir)/slogin + -if test "`echo slogin | sed '$(transform)'`" '!=' slogin; then \ + rm -f $(install_prefix)$(bindir)/`echo slogin | sed '$(transform)'`;\ + $(LN_S) ssh \ + $(install_prefix)$(bindir)/`echo slogin | sed '$(transform)'`; fi + -for p in $(NORMAL_PROGRAMS); do \ + $(INSTALL_PROGRAM) -m 0755 $$p $(install_prefix)$(bindir)/$$p; \ + if test "`echo $$p | sed '$(transform)'`" '!=' $$p; then \ + rm -f $(install_prefix)$(bindir)/`echo $$p | sed '$(transform)'`; \ + $(LN_S) $$p \ + $(install_prefix)$(bindir)/`echo $$p | sed '$(transform)'`; fi; \ + done +# Remove $(etcdir)/sshd_pid as it is now $(bindir)/sshd.pid + -rm -f $(install_prefix)$(etcdir)/sshd_pid +# Remove $(bindir)/sshd to avoid confusion since it is now in $(sbindir) + -rm -f $(install_prefix)$(bindir)/sshd + -rm -f $(install_prefix)$(bindir)/`echo sshd | sed '$(transform)'` + -for p in $(SBIN_PROGRAMS); do \ + $(INSTALL_PROGRAM) -m 0755 $$p $(install_prefix)$(sbindir)/$$p; \ + if test "`echo $$p | sed '$(transform)'`" '!=' $$p; then \ + rm -f $(install_prefix)$(sbindir)/`echo $$p | sed '$(transform)'`;\ + $(LN_S) $$p \ + $(install_prefix)$(sbindir)/`echo $$p | sed '$(transform)'`; fi;\ + done + -for p in $(MAN1PAGES); do \ + $(INSTALL_DATA) -m 0644 $(srcdir)/$$p $(install_prefix)$(man1dir)/$$p ; \ + if test "`echo $$p | sed '$(transform)'`" '!=' $$p; then \ + rm -f $(install_prefix)$(man1dir)/`echo $$p | sed '$(transform)'`;\ + $(LN_S) $$p \ + $(install_prefix)$(man1dir)/`echo $$p | sed '$(transform)'`; \ + fi; \ + done + rm -f $(install_prefix)$(man1dir)/slogin.1 + $(LN_S) ssh.1 $(install_prefix)$(man1dir)/slogin.1 + if test "`echo slogin.1 | sed '$(transform)'`" '!=' slogin.1; then \ + rm -f $(install_prefix)$(man1dir)/`echo slogin.1 | sed '$(transform)'`;\ + $(LN_S) ssh.1 \ + $(install_prefix)$(man1dir)/`echo slogin.1 | sed '$(transform)'`; \ + fi + -for p in $(MAN1GENERATED); do \ + $(INSTALL_DATA) -m 0644 $$p $(install_prefix)$(man1dir)/$$p ; \ + if test "`echo $$p | sed '$(transform)'`" '!=' $$p; then \ + rm -f $(install_prefix)$(man1dir)/`echo $$p | sed '$(transform)'`;\ + $(LN_S) $$p \ + $(install_prefix)$(man1dir)/`echo $$p | sed '$(transform)'`; \ + fi; \ + done + -for p in $(MAN8GENERATED); do \ + $(INSTALL_DATA) -m 0644 $$p $(install_prefix)$(man8dir)/$$p; \ + if test "`echo $$p | sed '$(transform)'`" '!=' $$p; then \ + rm -f $(install_prefix)$(man8dir)/`echo $$p | sed '$(transform)'`;\ + $(LN_S) $$p \ + $(install_prefix)$(man8dir)/`echo $$p | sed '$(transform)'`; fi;\ + done + -if test '!' -f $(install_prefix)$(HOST_CONFIG_FILE); then \ + $(INSTALL_DATA) -m 0644 $(srcdir)/host_config.sample \ + $(install_prefix)$(HOST_CONFIG_FILE); fi + -if test '!' -f $(install_prefix)$(SERVER_CONFIG_FILE); then \ + cat $(srcdir)/server_config.sample | \ + sed "s#_ETCDIR_#$(etcdir)#g" >/tmp/ssh_inst.$$; \ + $(INSTALL_DATA) -m 0644 /tmp/ssh_inst.$$ \ + $(install_prefix)$(SERVER_CONFIG_FILE); \ + rm -f /tmp/ssh_inst.$$; fi + +uninstall: + for p in ssh $(NORMAL_PROGRAMS); do \ + rm -f $(install_prefix)$(bindir)/$$p; \ + rm -f $(install_prefix)$(bindir)/`echo $$p | sed '$(transform)'`; \ + done + for p in $(SBIN_PROGRAMS); do \ + rm -f $(install_prefix)$(sbindir)/$$p; \ + rm -f $(install_prefix)$(sbindir)/`echo $$p | sed '$(transform)'`; \ + done + rm -f $(install_prefix)$(bindir)/slogin + rm -f $(install_prefix)$(bindir)/`echo slogin | sed '$(transform)'` + for p in $(MAN1PAGES) $(MAN1GENERATED); do \ + rm -f $(install_prefix)$(man1dir)/$$p; \ + rm -f $(install_prefix)$(man1dir)/`echo $$p | sed '$(transform)'`; \ + done + for p in $(MAN8GENERATED); do \ + rm -f $(install_prefix)$(man8dir)/$$p; \ + rm -f $(install_prefix)$(man8dir)/`echo $$p | sed '$(transform)'`; \ + done + +clean: + -rm -f *.o minfd.h gmon.out core $(PROGRAMS) gen_minfd rfc-pg +# cd $(RSAREFSRCDIR); rm -f *.o *.a + +distclean: clean + -rm -f Makefile config.status config.cache config.log config.h + -rm -f ssh.1 sshd.8 + +dist: + -rm -rf $(DISTNAME) + -mkdir $(DISTNAME) + cp $(DISTFILES) $(DISTNAME) + -rm -f $(DISTNAME)/config.h +# tar cf - $(RSAREFDIR) | (cd $(DISTNAME); tar xf -) +# cd $(DISTNAME)/$(RSAREFSRCDIR); rm -f *.o *.a + tar cf $(DISTNAME).tar $(DISTNAME) + -rm -f $(DISTNAME).tar.gz + gzip $(DISTNAME).tar + rm -rf $(DISTNAME) + @echo Distribution left in $(DISTNAME).tar.gz +# @echo Incrementing version number... +# @old_version=`sed 's/.*\.\([0-9][0-9]*\)"$$/\1/' version.h`; \ +# new_version=`expr $$old_version + 1`; \ +# (echo "s/\.$$old_version\"/.$$new_version\"/g"; echo w; echo q) | ed version.h >/dev/null + +depend: + $(MAKEDEP) -I$(srcdir) -I. $(GMPINCS) $(ZINCS) $(DEFS) $(SRCS) Index: usr.bin/ssh/Makefile.inc =================================================================== RCS file: /cvs/src/usr.bin/ssh/Makefile.inc,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- usr.bin/ssh/Makefile.inc 1999/10/07 21:45:02 1.10 +++ usr.bin/ssh/Makefile.inc 1999/10/25 20:27:26 1.11 @@ -1 +1,11 @@ CFLAGS+= -I${.CURDIR}/.. + +.include + +.if exists(${.CURDIR}/../lib/${__objdir}) +LDADD+= -L${.CURDIR}/../lib/${__objdir} -lssh +DPADD+= ${.CURDIR}/../lib/${__objdir}/libssh.a +.else +LDADD+= -L${.CURDIR}/../lib -lssh +DPADD+= ${.CURDIR}/../lib/libssh.a +.endif Index: usr.bin/ssh/OVERVIEW =================================================================== RCS file: /cvs/src/usr.bin/ssh/OVERVIEW,v retrieving revision 1.2 retrieving revision 1.5 diff -u -r1.2 -r1.5 --- usr.bin/ssh/OVERVIEW 1999/09/27 21:15:53 1.2 +++ usr.bin/ssh/OVERVIEW 1999/11/20 10:42:35 1.5 @@ -1,8 +1,9 @@ -This document is inteded for those who wish to read the ssh source +This document is intended for those who wish to read the ssh source code. This tries to give an overview of the structure of the code. Copyright (c) 1995 Tatu Ylonen Updated 17 Nov 1995. +Updated 19 Oct 1999 for OpenSSH-1.2 The software consists of ssh (client), sshd (server), scp, sdist, and the auxiliary programs ssh-keygen, ssh-agent, ssh-add, and @@ -22,14 +23,13 @@ Compression Library - - Ssh uses the GNU GZIP compression library (ZLIB). It resides in - the zlib095 subdirectory. + - Ssh uses the GNU GZIP compression library (ZLIB). Encryption/Decryption - Ssh contains several encryption algorithms. These are all accessed through the cipher.h interface. The interface code is - in cipher.c, and the implementations in des.c, ssh_md5.c, rc4.c. + in cipher.c, and the implementations are in libc. Multiple Precision Integer Library @@ -70,11 +70,11 @@ channels inside the secure channel, and uses this framework to implement X11 forwarding, TCP/IP forwarding, and authentication agent forwarding. + The new, Protocol 1.5, channel close implementation is in nchan.c Authentication agent - - Code to communicate with the authentication agent is in - authfd.c. The files gen-minfd.c, minfd.h, minfd.c + - Code to communicate with the authentication agent is in authfd.c. Authentication methods @@ -83,8 +83,7 @@ code is linked into the server. The routines also manipulate known hosts files using code in hostfile.c. Code in canohost.c is used to retrieve the canonical host name of the remote host. - Code in match.c is used to match host names. Code for osf C2 - extended security is in osfc2.c. + Code in match.c is used to match host names. - In the client end, authentication code is in sshconnect.c. It reads Passwords/passphrases using code in readpass.c. It reads Index: usr.bin/ssh/README =================================================================== RCS file: /cvs/src/usr.bin/ssh/README,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- usr.bin/ssh/README 1999/09/26 20:53:32 1.1 +++ usr.bin/ssh/README 1999/11/20 10:42:35 1.2 @@ -1,7 +1,7 @@ Ssh (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and -secure communications over insecure channels. It is inteded as a +secure communications over insecure channels. It is intended as a replacement for rlogin, rsh, rcp, and rdist. See the file INSTALL for installation instructions. See COPYING for Index: usr.bin/ssh/README.AFS-KERBEROS =================================================================== RCS file: README.AFS-KERBEROS diff -N README.AFS-KERBEROS --- /dev/null Wed Dec 8 12:40:35 1999 +++ /tmp/cvsIYFSU31367 Wed Dec 8 12:42:01 1999 @@ -0,0 +1,44 @@ + +ssh-1.2.26-afs-kerberos.patch-1 +AFS, Kerberos v4 support for SSH + +Here are the extra flags to configure, and what they do: + +--with-krb4[=PATH] Compile in Kerberos v4 support: + Kerberos v4 authentication + Kerberos v4 password authentication + Kerberos v4 ~/.klogin authorization + +These are all enabled by the 'KerberosAuthentication' config option. +Kerberos v4 and Kerberos v5 support are mutually exclusive for now. +PATH default is /usr/kerberos. + +--with-hesiod[=PATH] Compile in support for Hesiod: + getpwnam(), getpwuid() replacements + +--with-afs Compile in AFS support (requires KTH krb4): + ticket/token passing + process authentication groups + local Xauthority files (for AFS home dirs) + /ticket TKT_ROOT directory (if it exists) + +Binaries built with AFS support will work just fine on non-AFS machines! +You will need to use the KTH krb4 libs (ftp://ftp.pdc.kth.se/pub/krb/src), +or just their libkafs, also available separately from CMU as libkrbafs +(http://andrew2.andrew.cmu.edu/dist/krbafs.html). + +Additional Kerberos client and server config options (and their defaults): + + KerberosAuthentication yes + KerberosOrLocalPasswd no + KerberosTgtPassing yes + AFSTokenPassing yes + KerberosTicketCleanup yes + +See sshd(8) and ssh(1) for details. + +The latest version of this patch can be found at + + http://www.monkey.org/~dugsong/ssh-afs-kerberos.html + +dugsong@monkey.org Index: usr.bin/ssh/README.DEATTACK =================================================================== RCS file: README.DEATTACK diff -N README.DEATTACK --- /dev/null Wed Dec 8 12:40:35 1999 +++ /tmp/cvsviUUX31367 Wed Dec 8 12:42:01 1999 @@ -0,0 +1,109 @@ +============================================================================ + + CORE SDI S.A. + Buenos Aires, Argentina + + + + SSH insertion attack detection +============================================================================ + + +Crc32 Compensation attack detector +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +This document describes the scope and characteristics of SSH crc32 +compensation attack detector engine. It will inspect an encrypted SSH protocol +1.5 stream for suspicious patterns. If either the server or client is under +attack, the detector closes the conection and logs the attack. + + +Attack characteristics +~~~~~~~~~~~~~~~~~~~~~~ +An attacker, with sniffing and spoofing capabilities on the SSH network stream, may perform an active network attack by constructing a packet using a +known cipher/plaintext pair and computing addditional data to fill the packet +in a way that will produce a valid CRC-32 field and pass as a valid packet when +decryped and integrity checked on the server side. + If the attack succeeds, arbitrary commands will get executed on the server. + + This attack doesnt affect the confidential security characteristics of the +products using this protocols. However, integrity and authentication +of packets can no longer be trusted. + +Solution +~~~~~~~~ + This is not an implementation bug, but a protocol design vulnerability. The +protocol must be updated to use cryptographic strong message authentication +codes. SSH Protocol version 2 as published in [1] includes the use of a real +strong MAC. + However, this will require to update all clients and servers simultaneusly +while disabling compatibility with protocol version 1.5. On many installations +this is not practical. + + A mid-term solution exists, that will help protecting the server from the +auth/integrity vulnerabilities. On most scenarios it will be enough to upgrade +only the servers. + + This approach is based on the fact that an attacker will need to exploit some +of the linear characteristics of the integrity function in order to implement +the attack. In that context, the constructed packets will follow certain +patterns that could be detected on the encrypted stream. + + This is not a general solution, but a countermeasure against a model of all +of the possible attacks that exploits this vulnerabilities. + + The provided patch looks for patterns of repeated ciphered blocks in +each SSH packet received, the performance loss in speed is less 2% in an +uncompressed stream compared to an unpatched server. Memory usage increases +in about 8k per conection. + The chances of reporting a false attack in a 32GB file transfer is around +1 in 2**51. + +Contact information +~~~~~~~~~~~~~~~~~~~ + + These vulnerabilities were discovered by Ariel Futoransky + and Emiliano Kargieman. + + Comments and questions regarding this vulnerability and the fix + should be sent to: + + Ariel Futoransky + Emiliano Kargieman + + For more information about CORE SDI S.A. contact + or visit + + For more information about this problem and related ones visit: + + + + You can contact CORE SDI S.A. at using the + the following PGP key: + +-----BEGIN PGP PUBLIC KEY BLOCK----- +Version: 2.6.3ia +Comment: Requires PGP version 2.6 or later. + +mQCNAzVgfMgAAAEEAJSfJNdvCwIAc4AK0ckeimubLIwzsRVDRhjPQIOYt/7kxxio +DZybr53fwMEjyT8cHXRL08i0R9rcuFeCNAez6XcalbhqUKXDcLL/cZK80CCDSCs5 +tRCZGGOEBnXQIoyvbvi4gNYhBS5wUvmh3b/mvRFTvhmRrUy9m/nO/LnPTgz1AAUR +tCBDT1JFTEFCUyA8Y29yZWxhYnNAY29yZS1zZGkuY29tPokAlQMFEDVgfMn5zvy5 +z04M9QEBC6ED/0Szt3f54JTvkZG3ezQ8G60HvAw4/A5Ti6i3oze6jsXxzGp6pA1x +i0jaZpKaUSpo0MLc7BcijMKneuUHnN3XtN5YxtFt0aEoot1MIvv4BsdeUb3x257G +3+vr8SxGk44Vm4tfuN8F/2dNo/00yYP9rd3zQ8Tl+gmr5VxnLViZIDuh +=ulRg +-----END PGP PUBLIC KEY BLOCK----- + +Copyright +~~~~~~~~~ + +This file, deattack.c and deattack.h are copyright (c) 1998 +CORE SDI S.A., Buenos Aires, Argentina. All rights reserved. +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that this copyright notice is retained. + +THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES +ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT, +INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING +FROM THE USE OR MISUSE OF THIS SOFTWARE. + Index: usr.bin/ssh/RFC =================================================================== RCS file: RFC diff -N RFC --- /dev/null Wed Dec 8 12:40:35 1999 +++ /tmp/cvsoUndI31367 Wed Dec 8 12:42:01 1999 @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group T. Ylonen +Internet-Draft Helsinki University of Technology +draft-ylonen-ssh-protocol-00.txt 15 November 1995 +Expires: 15 May 1996 + + + The SSH (Secure Shell) Remote Login Protocol + +Status of This Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other docu- + ments at any time. It is inappropriate to use Internet-Drafts as + reference material or to cite them other than as ``work in pro- + gress.'' + + To learn the current status of any Internet-Draft, please check the + ``1id-abstracts.txt'' listing contained in the Internet- Drafts + Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), + munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or + ftp.isi.edu (US West Coast). + + The distribution of this memo is unlimited. + +Introduction + + SSH (Secure Shell) is a program to log into another computer over a + network, to execute commands in a remote machine, and to move files + from one machine to another. It provides strong authentication and + secure communications over insecure networks. Its features include + the following: + + o Closes several security holes (e.g., IP, routing, and DNS spoof- + ing). New authentication methods: .rhosts together with RSA + [RSA] based host authentication, and pure RSA authentication. + + o All communications are automatically and transparently + encrypted. Encryption is also used to protect integrity. + + o X11 connection forwarding provides secure X11 sessions. + + o Arbitrary TCP/IP ports can be redirected over the encrypted + channel in both directions. + + + +Ylonen [Page 1] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + o Client RSA-authenticates the server machine in the beginning of + every connection to prevent trojan horses (by routing or DNS + spoofing) and man-in-the-middle attacks, and the server RSA- + authenticates the client machine before accepting .rhosts or + /etc/hosts.equiv authentication (to prevent DNS, routing, or IP + spoofing). + + o An authentication agent, running in the user's local workstation + or laptop, can be used to hold the user's RSA authentication + keys. + + The goal has been to make the software as easy to use as possible for + ordinary users. The protocol has been designed to be as secure as + possible while making it possible to create implementations that are + easy to use and install. The sample implementation has a number of + convenient features that are not described in this document as they + are not relevant for the protocol. + + +Overview of the Protocol + + The software consists of a server program running on a server + machine, and a client program running on a client machine (plus a few + auxiliary programs). The machines are connected by an insecure IP + [RFC0791] network (that can be monitored, tampered with, and spoofed + by hostile parties). + + A connection is always initiated by the client side. The server + listens on a specific port waiting for connections. Many clients may + connect to the same server machine. + + The client and the server are connected via a TCP/IP [RFC0793] socket + that is used for bidirectional communication. Other types of tran- + sport can be used but are currently not defined. + + When the client connects the server, the server accepts the connec- + tion and responds by sending back its version identification string. + The client parses the server's identification, and sends its own + identification. The purpose of the identification strings is to + validate that the connection was to the correct port, declare the + protocol version number used, and to declare the software version + used on each side (for debugging purposes). The identification + strings are human-readable. If either side fails to understand or + support the other side's version, it closes the connection. + + After the protocol identification phase, both sides switch to a + packet based binary protocol. The server starts by sending its host + key (every host has an RSA key used to authenticate the host), server + + + +Ylonen [Page 2] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + key (an RSA key regenerated every hour), and other information to the + client. The client then generates a 256 bit session key, encrypts it + using both RSA keys (see below for details), and sends the encrypted + session key and selected cipher type to the server. Both sides then + turn on encryption using the selected algorithm and key. The server + sends an encrypted confirmation message to the client. + + The client then authenticates itself using any of a number of authen- + tication methods. The currently supported authentication methods are + .rhosts or /etc/hosts.equiv authentication (disabled by default), the + same with RSA-based host authentication, RSA authentication, and + password authentication. + + After successful authentication, the client makes a number of + requests to prepare for the session. Typical requests include allo- + cating a pseudo tty, starting X11 [X11] or TCP/IP port forwarding, + starting authentication agent forwarding, and executing the shell or + a command. + + When a shell or command is executed, the connection enters interac- + tive session mode. In this mode, data is passed in both directions, + new forwarded connections may be opened, etc. The interactive ses- + sion normally terminates when the server sends the exit status of the + program to the client. + + + The protocol makes several reservations for future extensibility. + First of all, the initial protocol identification messages include + the protocol version number. Second, the first packet by both sides + includes a protocol flags field, which can be used to agree on exten- + sions in a compatible manner. Third, the authentication and session + preparation phases work so that the client sends requests to the + server, and the server responds with success or failure. If the + client sends a request that the server does not support, the server + simply returns failure for it. This permits compatible addition of + new authentication methods and preparation operations. The interac- + tive session phase, on the other hand, works asynchronously and does + not permit the use of any extensions (because there is no easy and + reliable way to signal rejection to the other side and problems would + be hard to debug). Any compatible extensions to this phase must be + agreed upon during any of the earlier phases. + +The Binary Packet Protocol + + After the protocol identification strings, both sides only send spe- + cially formatted packets. The packet layout is as follows: + + o Packet length: 32 bit unsigned integer, coded as four 8-bit + + + +Ylonen [Page 3] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + bytes, msb first. Gives the length of the packet, not including + the length field and padding. The maximum length of a packet + (not including the length field and padding) is 262144 bytes. + + o Padding: 1-8 bytes of random data (or zeroes if not encrypting). + The amount of padding is (8 - (length % 8)) bytes (where % + stands for the modulo operator). The rationale for always hav- + ing some random padding at the beginning of each packet is to + make known plaintext attacks more difficult. + + o Packet type: 8-bit unsigned byte. The value 255 is reserved for + future extension. + + o Data: binary data bytes, depending on the packet type. The + number of data bytes is the "length" field minus 5. + + o Check bytes: 32-bit crc, four 8-bit bytes, msb first. The crc + is the Cyclic Redundancy Check, with the polynomial 0xedb88320, + of the Padding, Packet type, and Data fields. The crc is com- + puted before any encryption. + + The packet, except for the length field, may be encrypted using any + of a number of algorithms. The length of the encrypted part (Padding + + Type + Data + Check) is always a multiple of 8 bytes. Typically + the cipher is used in a chained mode, with all packets chained + together as if it was a single data stream (the length field is never + included in the encryption process). Details of encryption are + described below. + + When the session starts, encryption is turned off. Encryption is + enabled after the client has sent the session key. The encryption + algorithm to use is selected by the client. + + +Packet Compression + + If compression is supported (it is an optional feature, see + SSH_CMSG_REQUEST_COMPRESSION below), the packet type and data fields + of the packet are compressed using the gzip deflate algorithm [GZIP]. + If compression is in effect, the packet length field indicates the + length of the compressed data, plus 4 for the crc. The amount of + padding is computed from the compressed data, so that the amount of + data to be encrypted becomes a multiple of 8 bytes. + + When compressing, the packets (type + data portions) in each direc- + tion are compressed as if they formed a continuous data stream, with + only the current compression block flushed between packets. This + corresponds to the GNU ZLIB library Z_PARTIAL_FLUSH option. The + + + +Ylonen [Page 4] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + compression dictionary is not flushed between packets. The two + directions are compressed independently of each other. + + +Packet Encryption + + The protocol supports several encryption methods. During session + initialization, the server sends a bitmask of all encryption methods + that it supports, and the client selects one of these methods. The + client also generates a 256-bit random session key (32 8-bit bytes) + and sends it to the server. + + The encryption methods supported by the current implementation, and + their codes are: + + SSH_CIPHER_NONE 0 No encryption + SSH_CIPHER_IDEA 1 IDEA in CFB mode + SSH_CIPHER_DES 2 DES in CBC mode + SSH_CIPHER_3DES 3 Triple-DES in CBC mode + SSH_CIPHER_TSS 4 An experimental stream cipher + SSH_CIPHER_RC4 5 RC4 + + + All implementations are required to support SSH_CIPHER_DES and + SSH_CIPHER_3DES. Supporting SSH_CIPHER_IDEA, SSH_CIPHER_RC4, and + SSH_CIPHER_NONE is recommended. Support for SSH_CIPHER_TSS is + optional (and it is not described in this document). Other ciphers + may be added at a later time; support for them is optional. + + For encryption, the encrypted portion of the packet is considered a + linear byte stream. The length of the stream is always a multiple of + 8. The encrypted portions of consecutive packets (in the same direc- + tion) are encrypted as if they were a continuous buffer (that is, any + initialization vectors are passed from the previous packet to the + next packet). Data in each direction is encrypted independently. + + SSH_CIPHER_DES + The key is taken from the first 8 bytes of the session key. The + least significant bit of each byte is ignored. This results in + 56 bits of key data. DES [DES] is used in CBC mode. The iv + (initialization vector) is initialized to all zeroes. + + SSH_CIPHER_3DES + The variant of triple-DES used here works as follows: there are + three independent DES-CBC ciphers, with independent initializa- + tion vectors. The data (the whole encrypted data stream) is + first encrypted with the first cipher, then decrypted with the + second cipher, and finally encrypted with the third cipher. All + + + +Ylonen [Page 5] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + these operations are performed in CBC mode. + + The key for the first cipher is taken from the first 8 bytes of + the session key; the key for the next cipher from the next 8 + bytes, and the key for the third cipher from the following 8 + bytes. All three initialization vectors are initialized to + zero. + + (Note: the variant of 3DES used here differs from some other + descriptions.) + + SSH_CIPHER_IDEA + The key is taken from the first 16 bytes of the session key. + IDEA [IDEA] is used in CFB mode. The initialization vector is + initialized to all zeroes. + + SSH_CIPHER_TSS + All 32 bytes of the session key are used as the key. + + There is no reference available for the TSS algorithm; it is + currently only documented in the sample implementation source + code. The security of this cipher is unknown (but it is quite + fast). The cipher is basically a stream cipher that uses MD5 as + a random number generator and takes feedback from the data. + + SSH_CIPHER_RC4 + The first 16 bytes of the session key are used as the key for + the server to client direction. The remaining 16 bytes are used + as the key for the client to server direction. This gives + independent 128-bit keys for each direction. + + This algorithm is the alleged RC4 cipher posted to the Usenet in + 1995. It is widely believed to be equivalent with the original + RSADSI RC4 cipher. This is a very fast algorithm. + + +Data Type Encodings + + The Data field of each packet contains data encoded as described in + this section. There may be several data items; each item is coded as + described here, and their representations are concatenated together + (without any alignment or padding). + + Each data type is stored as follows: + + 8-bit byte + The byte is stored directly as a single byte. + + + + +Ylonen [Page 6] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + 32-bit unsigned integer + Stored in 4 bytes, msb first. + + Arbitrary length binary string + First 4 bytes are the length of the string, msb first (not + including the length itself). The following "length" bytes are + the string value. There are no terminating null characters. + + Multiple-precision integer + First 2 bytes are the number of bits in the integer, msb first + (for example, the value 0x00012345 would have 17 bits). The + value zero has zero bits. It is permissible that the number of + bits be larger than the real number of bits. + + The number of bits is followed by (bits + 7) / 8 bytes of binary + data, msb first, giving the value of the integer. + + +TCP/IP Port Number and Other Options + + The server listens for connections on TCP/IP port 22. + + The client may connect the server from any port. However, if the + client wishes to use any form of .rhosts or /etc/hosts.equiv authen- + tication, it must connect from a privileged port (less than 1024). + + For the IP Type of Service field [RFC0791], it is recommended that + interactive sessions (those having a user terminal or forwarding X11 + connections) use the IPTOS_LOWDELAY, and non-interactive connections + use IPTOS_THROUGHPUT. + + It is recommended that keepalives are used, because otherwise pro- + grams on the server may never notice if the other end of the connec- + tion is rebooted. + + +Protocol Version Identification + + After the socket is opened, the server sends an identification + string, which is of the form "SSH-.- + \n", where and are integers + and specify the protocol version number (not software distribution + version). is server side software version string (max 40 + characters); it is not interpreted by the remote side but may be use- + ful for debugging. + + The client parses the server's string, and sends a corresponding + string with its own information in response. If the server has lower + + + +Ylonen [Page 7] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + version number, and the client contains special code to emulate it, + the client responds with the lower number; otherwise it responds with + its own number. The server then compares the version number the + client sent with its own, and determines whether they can work + together. The server either disconnects, or sends the first packet + using the binary packet protocol and both sides start working accord- + ing to the lower of the protocol versions. + + By convention, changes which keep the protocol compatible with previ- + ous versions keep the same major protocol version; changes that are + not compatible increment the major version (which will hopefully + never happen). The version described in this document is 1.3. + + The client will + +Key Exchange and Server Host Authentication + + The first message sent by the server using the packet protocol is + SSH_SMSG_PUBLIC_KEY. It declares the server's host key, server pub- + lic key, supported ciphers, supported authentication methods, and + flags for protocol extensions. It also contains a 64-bit random + number (cookie) that must be returned in the client's reply (to make + IP spoofing more difficult). No encryption is used for this message. + + Both sides compute a session id as follows. The modulus of the + server key is interpreted as a byte string (without explicit length + field, with minimum length able to hold the whole value), most signi- + ficant byte first. This string is concatenated with the server host + key interpreted the same way. Additionally, the cookie is con- + catenated with this. Both sides compute MD5 of the resulting string. + The resulting 16 bytes (128 bits) are stored by both parties and are + called the session id. + + The client responds with a SSH_CMSG_SESSION_KEY message, which con- + tains the selected cipher type, a copy of the 64-bit cookie sent by + the server, client's protocol flags, and a session key encrypted with + both the server's host key and server key. No encryption is used for + this message. + + The session key is 32 8-bit bytes (a total of 256 random bits gen- + erated by the client). The client first xors the 16 bytes of the + session id with the first 16 bytes of the session key. The resulting + string is then encrypted using the smaller key (one with smaller + modulus), and the result is then encrypted using the other key. The + number of bits in the public modulus of the two keys must differ by + at least 128 bits. + + At each encryption step, a multiple-precision integer is constructed + + + +Ylonen [Page 8] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + from the data to be encrypted as follows (the integer is here inter- + preted as a sequence of bytes, msb first; the number of bytes is the + number of bytes needed to represent the modulus). + + The most significant byte (which is only partial as the value must be + less than the public modulus, which is never a power of two) is zero. + + The next byte contains the value 2 (which stands for public-key + encrypted data in the PKCS standard [PKCS#1]). Then, there are non- + zero random bytes to fill any unused space, a zero byte, and the data + to be encrypted in the least significant bytes, the last byte of the + data in the least significant byte. + + This algorithm is used twice. First, it is used to encrypt the 32 + random bytes generated by the client to be used as the session key + (xored by the session id). This value is converted to an integer as + described above, and encrypted with RSA using the key with the + smaller modulus. The resulting integer is converted to a byte + stream, msb first. This byte stream is padded and encrypted identi- + cally using the key with the larger modulus. + + After the client has sent the session key, it starts to use the + selected algorithm and key for decrypting any received packets, and + for encrypting any sent packets. Separate ciphers are used for dif- + ferent directions (that is, both directions have separate initializa- + tion vectors or other state for the ciphers). + + When the server has received the session key message, and has turned + on encryption, it sends a SSH_SMSG_SUCCESS message to the client. + + The recommended size of the host key is 1024 bits, and 768 bits for + the server key. The minimum size is 512 bits for the smaller key. + + +Declaring the User Name + + The client then sends a SSH_CMSG_USER message to the server. This + message specifies the user name to log in as. + + The server validates that such a user exists, checks whether authen- + tication is needed, and responds with either SSH_SMSG_SUCCESS or + SSH_SMSG_FAILURE. SSH_SMSG_SUCCESS indicates that no authentication + is needed for this user (no password), and authentication phase has + now been completed. SSH_SMSG_FAILURE indicates that authentication + is needed (or the user does not exist). + + If the user does not exist, it is recommended that this returns + failure, but the server keeps reading messages from the client, and + + + +Ylonen [Page 9] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + responds to any messages (except SSH_MSG_DISCONNECT, SSH_MSG_IGNORE, + and SSH_MSG_DEBUG) with SSH_SMSG_FAILURE. This way the client cannot + be certain whether the user exists. + + +Authentication Phase + + Provided the server didn't immediately accept the login, an authenti- + cation exchange begins. The client sends messages to the server + requesting different types of authentication in arbitrary order as + many times as desired (however, the server may close the connection + after a timeout). The server always responds with SSH_SMSG_SUCCESS + if it has accepted the authentication, and with SSH_SMSG_FAILURE if + it has denied authentication with the requested method or it does not + recognize the message. Some authentication methods cause an exchange + of further messages before the final result is sent. The authentica- + tion phase ends when the server responds with success. + + The recommended value for the authentication timeout (timeout before + disconnecting if no successful authentication has been made) is 5 + minutes. + + The following authentication methods are currently supported: + + SSH_AUTH_RHOSTS 1 .rhosts or /etc/hosts.equiv + SSH_AUTH_RSA 2 pure RSA authentication + SSH_AUTH_PASSWORD 3 password authentication + SSH_AUTH_RHOSTS_RSA 4 .rhosts with RSA host authentication + + + SSH_AUTH_RHOSTS + + This is the authentication method used by rlogin and rsh + [RFC1282]. + + The client sends SSH_CMSG_AUTH_RHOSTS with the client-side user + name as an argument. + + The server checks whether to permit authentication. On UNIX + systems, this is usually done by checking /etc/hosts.equiv, and + .rhosts in the user's home directory. The connection must come + from a privileged port. + + It is recommended that the server checks that there are no IP + options (such as source routing) specified for the socket before + accepting this type of authentication. The client host name + should be reverse-mapped and then forward mapped to ensure that + it has the proper IP-address. + + + +Ylonen [Page 10] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + This authentication method trusts the remote host (root on the + remote host can pretend to be any other user on that host), the + name services, and partially the network: anyone who can see + packets coming out from the server machine can do IP-spoofing + and pretend to be any machine; however, the protocol prevents + blind IP-spoofing (which used to be possible with rlogin). + + Many sites probably want to disable this authentication method + because of the fundamental insecurity of conventional .rhosts or + /etc/hosts.equiv authentication when faced with spoofing. It is + recommended that this method not be supported by the server by + default. + + SSH_AUTH_RHOSTS_RSA + + In addition to conventional .rhosts and hosts.equiv authentica- + tion, this method additionally requires that the client host be + authenticated using RSA. + + The client sends SSH_CMSG_AUTH_RHOSTS_RSA specifying the + client-side user name, and the public host key of the client + host. + + The server first checks if normal .rhosts or /etc/hosts.equiv + authentication would be accepted, and if not, responds with + SSH_SMSG_FAILURE. Otherwise, it checks whether it knows the + host key for the client machine (using the same name for the + host that was used for checking the .rhosts and /etc/hosts.equiv + files). If it does not know the RSA key for the client, access + is denied and SSH_SMSG_FAILURE is sent. + + If the server knows the host key of the client machine, it veri- + fies that the given host key matches that known for the client. + If not, access is denied and SSH_SMSG_FAILURE is sent. + + The server then sends a SSH_SMSG_AUTH_RSA_CHALLENGE message con- + taining an encrypted challenge for the client. The challenge is + 32 8-bit random bytes (256 bits). When encrypted, the highest + (partial) byte is left as zero, the next byte contains the value + 2, the following are non-zero random bytes, followed by a zero + byte, and the challenge put in the remaining bytes. This is + then encrypted using RSA with the client host's public key. + (The padding and encryption algorithm is the same as that used + for the session key.) + + The client decrypts the challenge using its private host key, + concatenates this with the session id, and computes an MD5 + checksum of the resulting 48 bytes. The MD5 output is returned + + + +Ylonen [Page 11] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + as 16 bytes in a SSH_CMSG_AUTH_RSA_RESPONSE message. (MD5 is + used to deter chosen plaintext attacks against RSA; the session + id binds it to a specific session). + + The server verifies that the MD5 of the decrypted challenge + returned by the client matches that of the original value, and + sends SSH_SMSG_SUCCESS if so. Otherwise it sends + SSH_SMSG_FAILURE and refuses the authentication attempt. + + This authentication method trusts the client side machine in + that root on that machine can pretend to be any user on that + machine. Additionally, it trusts the client host key. The name + and/or IP address of the client host is only used to select the + public host key. The same host name is used when scanning + .rhosts or /etc/hosts.equiv and when selecting the host key. It + would in principle be possible to eliminate the host name + entirely and substitute it directly by the host key. IP and/or + DNS [RFC1034] spoofing can only be used to pretend to be a host + for which the attacker has the private host key. + + SSH_AUTH_RSA + + The idea behind RSA authentication is that the server recognizes + the public key offered by the client, generates a random chal- + lenge, and encrypts the challenge with the public key. The + client must then prove that it has the corresponding private key + by decrypting the challenge. + + The client sends SSH_CMSG_AUTH_RSA with public key modulus (n) + as an argument. + + The server may respond immediately with SSH_SMSG_FAILURE if it + does not permit authentication with this key. Otherwise it gen- + erates a challenge, encrypts it using the user's public key + (stored on the server and identified using the modulus), and + sends SSH_SMSG_AUTH_RSA_CHALLENGE with the challenge (mp-int) as + an argument. + + The challenge is 32 8-bit random bytes (256 bits). When + encrypted, the highest (partial) byte is left as zero, the next + byte contains the value 2, the following are non-zero random + bytes, followed by a zero byte, and the challenge put in the + remaining bytes. This is then encrypted with the public key. + (The padding and encryption algorithm is the same as that used + for the session key.) + + The client decrypts the challenge using its private key, con- + catenates it with the session id, and computes an MD5 checksum + + + +Ylonen [Page 12] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + of the resulting 48 bytes. The MD5 output is returned as 16 + bytes in a SSH_CMSG_AUTH_RSA_RESPONSE message. (Note that the + MD5 is necessary to avoid chosen plaintext attacks against RSA; + the session id binds it to a specific session.) + + The server verifies that the MD5 of the decrypted challenge + returned by the client matches that of the original value, and + sends SSH_SMSG_SUCCESS if so. Otherwise it sends + SSH_SMSG_FAILURE and refuses the authentication attempt. + + This authentication method does not trust the remote host, the + network, name services, or anything else. Authentication is + based solely on the possession of the private identification + keys. Anyone in possession of the private keys can log in, but + nobody else. + + The server may have additional requirements for a successful + authentiation. For example, to limit damage due to a comprom- + ised RSA key, a server might restrict access to a limited set of + hosts. + + SSH_AUTH_PASSWORD + + The client sends a SSH_CMSG_AUTH_PASSWORD message with the plain + text password. (Note that even though the password is plain + text inside the message, it is normally encrypted by the packet + mechanism.) + + The server verifies the password, and sends SSH_SMSG_SUCCESS if + authentication was accepted and SSH_SMSG_FAILURE otherwise. + + Note that the password is read from the user by the client; the + user never interacts with a login program. + + This authentication method does not trust the remote host, the + network, name services or anything else. Authentication is + based solely on the possession of the password. Anyone in pos- + session of the password can log in, but nobody else. + +Preparatory Operations + + After successful authentication, the server waits for a request from + the client, processes the request, and responds with SSH_SMSG_SUCCESS + whenever a request has been successfully processed. If it receives a + message that it does not recognize or it fails to honor a request, it + returns SSH_SMSG_FAILURE. It is expected that new message types + might be added to this phase in future. + + + + +Ylonen [Page 13] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + The following messages are currently defined for this phase. + + SSH_CMSG_REQUEST_COMPRESSION + Requests that compression be enabled for this session. A gzip- + compatible compression level (1-9) is passed as an argument. + + SSH_CMSG_REQUEST_PTY + Requests that a pseudo terminal device be allocated for this + session. The user terminal type and terminal modes are supplied + as arguments. + + SSH_CMSG_X11_REQUEST_FORWARDING + Requests forwarding of X11 connections from the remote machine + to the local machine over the secure channel. Causes an + internet-domain socket to be allocated and the DISPLAY variable + to be set on the server. X11 authentication data is automati- + cally passed to the server, and the client may implement spoof- + ing of authentication data for added security. The authentica- + tion data is passed as arguments. + + SSH_CMSG_PORT_FORWARD_REQUEST + Requests forwarding of a TCP/IP port on the server host over the + secure channel. What happens is that whenever a connection is + made to the port on the server, a connection will be made from + the client end to the specified host/port. Any user can forward + unprivileged ports; only the root can forward privileged ports + (as determined by authentication done earlier). + + SSH_CMSG_AGENT_REQUEST_FORWARDING + Requests forwarding of the connection to the authentication + agent. + + SSH_CMSG_EXEC_SHELL + Starts a shell (command interpreter) for the user, and moves + into interactive session mode. + + SSH_CMSG_EXEC_CMD + Executes the given command (actually " -c " or + equivalent) for the user, and moves into interactive session + mode. + + +Interactive Session and Exchange of Data + + During the interactive session, any data written by the shell or com- + mand running on the server machine is forwarded to stdin or stderr on + the client machine, and any input available from stdin on the client + machine is forwarded to the program on the server machine. + + + +Ylonen [Page 14] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + All exchange is asynchronous; either side can send at any time, and + there are no acknowledgements (TCP/IP already provides reliable tran- + sport, and the packet protocol protects against tampering or IP + spoofing). + + When the client receives EOF from its standard input, it will send + SSH_CMSG_EOF; however, this in no way terminates the exchange. The + exchange terminates and interactive mode is left when the server + sends SSH_SMSG_EXITSTATUS to indicate that the client program has + terminated. Alternatively, either side may disconnect at any time by + sending SSH_MSG_DISCONNECT or closing the connection. + + The server may send any of the following messages: + + SSH_SMSG_STDOUT_DATA + Data written to stdout by the program running on the server. + The data is passed as a string argument. The client writes this + data to stdout. + + SSH_SMSG_STDERR_DATA + Data written to stderr by the program running on the server. + The data is passed as a string argument. The client writes this + data to stderr. (Note that if the program is running on a tty, + it is not possible to separate stdout and stderr data, and all + data will be sent as stdout data.) + + SSH_SMSG_EXITSTATUS + Indicates that the shell or command has exited. Exit status is + passed as an integer argument. This message causes termination + of the interactive session. + + SSH_SMSG_AGENT_OPEN + Indicates that someone on the server side is requesting a con- + nection to the authentication agent. The server-side channel + number is passed as an argument. The client must respond with + either SSH_CHANNEL_OPEN_CONFIRMATION or + SSH_CHANNEL_OPEN_FAILURE. + + SSH_SMSG_X11_OPEN + Indicates that a connection has been made to the X11 socket on + the server side and should be forwarded to the real X server. + An integer argument indicates the channel number allocated for + this connection on the server side. The client should send back + either SSH_MSG_CHANNEL_OPEN_CONFIRMATION or + SSH_MSG_CHANNEL_OPEN_FAILURE with the same server side channel + number. + + SSH_MSG_PORT_OPEN + + + +Ylonen [Page 15] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + Indicates that a connection has been made to a port on the + server side for which forwarding has been requested. Arguments + are server side channel number, host name to connect to, and + port to connect to. The client should send back either + SSH_MSG_CHANNEL_OPEN_CONFIRMATION or + SSH_MSG_CHANNEL_OPEN_FAILURE with the same server side channel + number. + + SSH_MSG_CHANNEL_OPEN_CONFIRMATION + This is sent by the server to indicate that it has opened a con- + nection as requested in a previous message. The first argument + indicates the client side channel number, and the second argu- + ment is the channel number that the server has allocated for + this connection. + + SSH_MSG_CHANNEL_OPEN_FAILURE + This is sent by the server to indicate that it failed to open a + connection as requested in a previous message. The client-side + channel number is passed as an argument. The client will close + the descriptor associated with the channel and free the channel. + + SSH_MSG_CHANNEL_DATA + This packet contains data for a channel from the server. The + first argument is the client-side channel number, and the second + argument (a string) is the data. + + SSH_MSG_CHANNEL_CLOSE + This is sent by the server to indicate that whoever was in the + other end of the channel has closed it. The argument is the + client side channel number. The client will let all buffered + data in the channel to drain, and when ready, will close the + socket, free the channel, and send the server a + SSH_MSG_CHANNEL_CLOSE_CONFIRMATION message for the channel. + + SSH_MSG_CHANNEL_CLOSE_CONFIRMATION + This is send by the server to indicate that a channel previously + closed by the client has now been closed on the server side as + well. The argument indicates the client channel number. The + client frees the channel. + + The client may send any of the following messages: + + SSH_CMSG_STDIN_DATA + This is data to be sent as input to the program running on the + server. The data is passed as a string. + + SSH_CMSG_EOF + Indicates that the client has encountered EOF while reading + + + +Ylonen [Page 16] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + standard input. The server will allow any buffered input data + to drain, and will then close the input to the program. + + SSH_CMSG_WINDOW_SIZE + Indicates that window size on the client has been changed. The + server updates the window size of the tty and causes SIGWINCH to + be sent to the program. The new window size is passed as four + integer arguments: row, col, xpixel, ypixel. + + SSH_MSG_PORT_OPEN + Indicates that a connection has been made to a port on the + client side for which forwarding has been requested. Arguments + are client side channel number, host name to connect to, and + port to connect to. The server should send back either + SSH_MSG_CHANNEL_OPEN_CONFIRMATION or + SSH_MSG_CHANNEL_OPEN_FAILURE with the same client side channel + number. + + SSH_MSG_CHANNEL_OPEN_CONFIRMATION + This is sent by the client to indicate that it has opened a con- + nection as requested in a previous message. The first argument + indicates the server side channel number, and the second argu- + ment is the channel number that the client has allocated for + this connection. + + SSH_MSG_CHANNEL_OPEN_FAILURE + This is sent by the client to indicate that it failed to open a + connection as requested in a previous message. The server side + channel number is passed as an argument. The server will close + the descriptor associated with the channel and free the channel. + + SSH_MSG_CHANNEL_DATA + This packet contains data for a channel from the client. The + first argument is the server side channel number, and the second + argument (a string) is the data. + + SSH_MSG_CHANNEL_CLOSE + This is sent by the client to indicate that whoever was in the + other end of the channel has closed it. The argument is the + server channel number. The server will allow buffered data to + drain, and when ready, will close the socket, free the channel, + and send the client a SSH_MSG_CHANNEL_CLOSE_CONFIRMATION message + for the channel. + + SSH_MSG_CHANNEL_CLOSE_CONFIRMATION + This is send by the client to indicate that a channel previously + closed by the server has now been closed on the client side as + well. The argument indicates the server channel number. The + + + +Ylonen [Page 17] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + server frees the channel. + + Any unsupported messages during interactive mode cause the connection + to be terminated with SSH_MSG_DISCONNECT and an error message. Com- + patible protocol upgrades should agree about any extensions during + the preparation phase or earlier. + + +Termination of the Connection + + Normal termination of the connection is always initiated by the + server by sending SSH_SMSG_EXITSTATUS after the program has exited. + The client responds to this message by sending + SSH_CMSG_EXIT_CONFIRMATION and closes the socket; the server then + closes the socket. There are two purposes for the confirmation: some + systems may lose previously sent data when the socket is closed, and + closing the client side first causes any TCP/IP TIME_WAIT [RFC0793] + waits to occur on the client side, not consuming server resources. + + If the program terminates due to a signal, the server will send + SSH_MSG_DISCONNECT with an appropriate message. If the connection is + closed, all file descriptors to the program will be closed and the + server will exit. If the program runs on a tty, the kernel sends it + the SIGHUP signal when the pty master side is closed. + +Protocol Flags + + Both the server and the client pass 32 bits of protocol flags to the + other side. The flags are intended for compatible protocol exten- + sion; the server first announces which added capabilities it sup- + ports, and the client then sends the capabilities that it supports. + + The following flags are currently defined (the values are bit masks): + + 1 SSH_PROTOFLAG_SCREEN_NUMBER + This flag can only be sent by the client. It indicates that the + X11 forwarding requests it sends will include the screen number. + + 2 SSH_PROTOFLAG_HOST_IN_FWD_OPEN + If both sides specify this flag, SSH_SMSG_X11_OPEN and + SSH_MSG_PORT_OPEN messages will contain an additional field con- + taining a description of the host at the other end of the con- + nection. + +Detailed Description of Packet Types and Formats + + The supported packet types and the corresponding message numbers are + given in the following table. Messages with _MSG_ in their name may + + + +Ylonen [Page 18] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + be sent by either side. Messages with _CMSG_ are only sent by the + client, and messages with _SMSG_ only by the server. + + A packet may contain additional data after the arguments specified + below. Any such data should be ignored by the receiver. However, it + is recommended that no such data be stored without good reason. + (This helps build compatible extensions.) + + 0 SSH_MSG_NONE + This code is reserved. This message type is never sent. + + 1 SSH_MSG_DISCONNECT + + string Cause of disconnection + + This message may be sent by either party at any time. It causes + the immediate disconnection of the connection. The message is + intended to be displayed to a human, and describes the reason + for disconnection. + + 2 SSH_SMSG_PUBLIC_KEY + + 8 bytes anti_spoofing_cookie + 32-bit int server_key_bits + mp-int server_key_public_exponent + mp-int server_key_public_modulus + 32-bit int host_key_bits + mp-int host_key_public_exponent + mp-int host_key_public_modulus + 32-bit int protocol_flags + 32-bit int supported_ciphers_mask + 32-bit int supported_authentications_mask + + Sent as the first message by the server. This message gives the + server's host key, server key, protocol flags (intended for com- + patible protocol extension), supported_ciphers_mask (which is + the bitwise or of (1 << cipher_number), where << is the left + shift operator, for all supported ciphers), and + supported_authentications_mask (which is the bitwise or of (1 << + authentication_type) for all supported authentication types). + The anti_spoofing_cookie is 64 random bytes, and must be sent + back verbatim by the client in its reply. It is used to make + IP-spoofing more difficult (encryption and host keys are the + real defense against spoofing). + + 3 SSH_CMSG_SESSION_KEY + + 1 byte cipher_type (must be one of the supported values) + + + +Ylonen [Page 19] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + 8 bytes anti_spoofing_cookie (must match data sent by the server) + mp-int double-encrypted session key + 32-bit int protocol_flags + + Sent by the client as the first message in the session. Selects + the cipher to use, and sends the encrypted session key to the + server. The anti_spoofing_cookie must be the same bytes that + were sent by the server. Protocol_flags is intended for nego- + tiating compatible protocol extensions. + + 4 SSH_CMSG_USER + + string user login name on server + + Sent by the client to begin authentication. Specifies the user + name on the server to log in as. The server responds with + SSH_SMSG_SUCCESS if no authentication is needed for this user, + or SSH_SMSG_FAILURE if authentication is needed (or the user + does not exist). [Note to the implementator: the user name is + of arbitrary size. The implementation must be careful not to + overflow internal buffers.] + + 5 SSH_CMSG_AUTH_RHOSTS + + string client-side user name + + Requests authentication using /etc/hosts.equiv and .rhosts (or + equivalent mechanisms). This authentication method is normally + disabled in the server because it is not secure (but this is the + method used by rsh and rlogin). The server responds with + SSH_SMSG_SUCCESS if authentication was successful, and + SSH_SMSG_FAILURE if access was not granted. The server should + check that the client side port number is less than 1024 (a + privileged port), and immediately reject authentication if it is + not. Supporting this authentication method is optional. This + method should normally not be enabled in the server because it + is not safe. (However, not enabling this only helps if rlogind + and rshd are disabled.) + + 6 SSH_CMSG_AUTH_RSA + + mp-int identity_public_modulus + + Requests authentication using pure RSA authentication. The + server checks if the given key is permitted to log in, and if + so, responds with SSH_SMSG_AUTH_RSA_CHALLENGE. Otherwise, it + responds with SSH_SMSG_FAILURE. The client often tries several + different keys in sequence until one supported by the server is + + + +Ylonen [Page 20] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + found. Authentication is accepted if the client gives the + correct response to the challenge. The server is free to add + other criteria for authentication, such as a requirement that + the connection must come from a certain host. Such additions + are not visible at the protocol level. Supporting this authen- + tication method is optional but recommended. + + 7 SSH_SMSG_AUTH_RSA_CHALLENGE + + mp-int encrypted challenge + + Presents an RSA authentication challenge to the client. The + challenge is a 256-bit random value encrypted as described else- + where in this document. The client must decrypt the challenge + using the RSA private key, compute MD5 of the challenge plus + session id, and send back the resulting 16 bytes using + SSH_CMSG_AUTH_RSA_RESPONSE. + + 8 SSH_CMSG_AUTH_RSA_RESPONSE + + 16 bytes MD5 of decrypted challenge + + This message is sent by the client in response to an RSA chal- + lenge. The MD5 checksum is returned instead of the decrypted + challenge to deter known-plaintext attacks against the RSA key. + The server responds to this message with either SSH_SMSG_SUCCESS + or SSH_SMSG_FAILURE. + + 9 SSH_CMSG_AUTH_PASSWORD + + string plain text password + + Requests password authentication using the given password. Note + that even though the password is plain text inside the packet, + the whole packet is normally encrypted by the packet layer. It + would not be possible for the client to perform password + encryption/hashing, because it cannot know which kind of + encryption/hashing, if any, the server uses. The server + responds to this message with SSH_SMSG_SUCCESS or + SSH_SMSG_FAILURE. + + 10 SSH_CMSG_REQUEST_PTY + + string TERM environment variable value (e.g. vt100) + 32-bit int terminal height, rows (e.g., 24) + 32-bit int terminal width, columns (e.g., 80) + 32-bit int terminal width, pixels (0 if no graphics) (e.g., 480) + 32-bit int terminal height, pixels (0 if no graphics) (e.g., 640) + + + +Ylonen [Page 21] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + n bytes tty modes encoded in binary + + Requests a pseudo-terminal to be allocated for this command. + This message can be used regardless of whether the session will + later execute the shell or a command. If a pty has been + requested with this message, the shell or command will run on a + pty. Otherwise it will communicate with the server using pipes, + sockets or some other similar mechanism. + + The terminal type gives the type of the user's terminal. In the + UNIX environment it is passed to the shell or command in the + TERM environment variable. + + The width and height values give the initial size of the user's + terminal or window. All values can be zero if not supported by + the operating system. The server will pass these values to the + kernel if supported. + + Terminal modes are encoded into a byte stream in a portable for- + mat. The exact format is described later in this document. + + The server responds to the request with either SSH_SMSG_SUCCESS + or SSH_SMSG_FAILURE. If the server does not have the concept of + pseudo terminals, it should return success if it is possible to + execute a shell or a command so that it looks to the client as + if it was running on a pseudo terminal. + + 11 SSH_CMSG_WINDOW_SIZE + + 32-bit int terminal height, rows + 32-bit int terminal width, columns + 32-bit int terminal width, pixels + 32-bit int terminal height, pixels + + This message can only be sent by the client during the interac- + tive session. This indicates that the size of the user's window + has changed, and provides the new size. The server will update + the kernel's notion of the window size, and a SIGWINCH signal or + equivalent will be sent to the shell or command (if supported by + the operating system). + + 12 SSH_CMSG_EXEC_SHELL + + (no arguments) + + Starts a shell (command interpreter), and enters interactive + session mode. + + + + +Ylonen [Page 22] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + 13 SSH_CMSG_EXEC_CMD + + string command to execute + + Starts executing the given command, and enters interactive ses- + sion mode. On UNIX, the command is run as " -c ", where is the user's login shell. + + 14 SSH_SMSG_SUCCESS + + (no arguments) + + This message is sent by the server in response to the session + key, a successful authentication request, and a successfully + completed preparatory operation. + + 15 SSH_SMSG_FAILURE + + (no arguments) + + This message is sent by the server in response to a failed + authentication operation to indicate that the user has not yet + been successfully authenticated, and in response to a failed + preparatory operation. This is also sent in response to an + authentication or preparatory operation request that is not + recognized or supported. + + 16 SSH_CMSG_STDIN_DATA + + string data + + Delivers data from the client to be supplied as input to the + shell or program running on the server side. This message can + only be used in the interactive session mode. No acknowledge- + ment is sent for this message. + + 17 SSH_SMSG_STDOUT_DATA + + string data + + Delivers data from the server that was read from the standard + output of the shell or program running on the server side. This + message can only be used in the interactive session mode. No + acknowledgement is sent for this message. + + 18 SSH_SMSG_STDERR_DATA + + string data + + + +Ylonen [Page 23] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + Delivers data from the server that was read from the standard + error of the shell or program running on the server side. This + message can only be used in the interactive session mode. No + acknowledgement is sent for this message. + + 19 SSH_CMSG_EOF + + (no arguments) + + This message is sent by the client to indicate that EOF has been + reached on the input. Upon receiving this message, and after + all buffered input data has been sent to the shell or program, + the server will close the input file descriptor to the program. + This message can only be used in the interactive session mode. + No acknowledgement is sent for this message. + + 20 SSH_SMSG_EXITSTATUS + + 32-bit int exit status of the command + + Returns the exit status of the shell or program after it has + exited. The client should respond with + SSH_CMSG_EXIT_CONFIRMATION when it has received this message. + This will be the last message sent by the server. If the pro- + gram being executed dies with a signal instead of exiting nor- + mally, the server should terminate the session with + SSH_MSG_DISCONNECT (which can be used to pass a human-readable + string indicating that the program died due to a signal) instead + of using this message. + + 21 SSH_MSG_CHANNEL_OPEN_CONFIRMATION + + 32-bit int remote_channel + 32-bit int local_channel + + This is sent in response to any channel open request if the + channel has been successfully opened. Remote_channel is the + channel number received in the initial open request; + local_channel is the channel number the side sending this mes- + sage has allocated for the channel. Data can be transmitted on + the channel after this message. + + 22 SSH_MSG_CHANNEL_OPEN_FAILURE + + 32-bit int remote_channel + + This message indicates that an earlier channel open request by + the other side has failed or has been denied. Remote_channel is + + + +Ylonen [Page 24] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + the channel number given in the original request. + + 23 SSH_MSG_CHANNEL_DATA + + 32-bit int remote_channel + string data + + Data is transmitted in a channel in these messages. A channel + is bidirectional, and both sides can send these messages. There + is no acknowledgement for these messages. It is possible that + either side receives these messages after it has sent + SSH_MSG_CHANNEL_CLOSE for the channel. These messages cannot be + received after the party has sent or received + SSH_MSG_CHANNEL_CLOSE_CONFIRMATION. + + 24 SSH_MSG_CHANNEL_CLOSE + + 32-bit int remote_channel + + When a channel is closed at one end of the connection, that side + sends this message. Upon receiving this message, the channel + should be closed. When this message is received, if the channel + is already closed (the receiving side has sent this message for + the same channel earlier), the channel is freed and no further + action is taken; otherwise the channel is freed and + SSH_MSG_CHANNEL_CLOSE_CONFIRMATION is sent in response. (It is + possible that the channel is closed simultaneously at both + ends.) + + 25 SSH_MSG_CHANNEL_CLOSE_CONFIRMATION + + 32-bit int remote_channel + + This message is sent in response to SSH_MSG_CHANNEL_CLOSE unless + the channel was already closed. When this message is sent or + received, the channel is freed. + + 26 (OBSOLETED; was unix-domain X11 forwarding) + + 27 SSH_SMSG_X11_OPEN + + 32-bit int local_channel + string originator_string (see below) + + This message can be sent by the server during the interactive + session mode to indicate that a client has connected the fake X + server. Local_channel is the channel number that the server has + allocated for the connection. The client should try to open a + + + +Ylonen [Page 25] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + connection to the real X server, and respond with + SSH_MSG_CHANNEL_OPEN_CONFIRMATION or + SSH_MSG_CHANNEL_OPEN_FAILURE. + + The field originator_string is present if both sides specified + SSH_PROTOFLAG_HOST_IN_FWD_OPEN in the protocol flags. It con- + tains a description of the host originating the connection. + + 28 SSH_CMSG_PORT_FORWARD_REQUEST + + 32-bit int server_port + string host_to_connect + 32-bit int port_to_connect + + Sent by the client in the preparatory phase, this message + requests that server_port on the server machine be forwarded + over the secure channel to the client machine, and from there to + the specified host and port. The server should start listening + on the port, and send SSH_MSG_PORT_OPEN whenever a connection is + made to it. Supporting this message is optional, and the server + is free to reject any forward request. For example, it is + highly recommended that unless the user has been authenticated + as root, forwarding any privileged port numbers (below 1024) is + denied. + + 29 SSH_MSG_PORT_OPEN + + 32-bit int local_channel + string host_name + 32-bit int port + string originator_string (see below) + + Sent by either party in interactive session mode, this message + indicates that a connection has been opened to a forwarded + TCP/IP port. Local_channel is the channel number that the send- + ing party has allocated for the connection. Host_name is the + host the connection should be be forwarded to, and the port is + the port on that host to connect. The receiving party should + open the connection, and respond with + SSH_MSG_CHANNEL_OPEN_CONFIRMATION or + SSH_MSG_CHANNEL_OPEN_FAILURE. It is recommended that the + receiving side check the host_name and port for validity to + avoid compromising local security by compromised remote side + software. Particularly, it is recommended that the client per- + mit connections only to those ports for which it has requested + forwarding with SSH_CMSG_PORT_FORWARD_REQUEST. + + The field originator_string is present if both sides specified + + + +Ylonen [Page 26] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + SSH_PROTOFLAG_HOST_IN_FWD_OPEN in the protocol flags. It con- + tains a description of the host originating the connection. + + 30 SSH_CMSG_AGENT_REQUEST_FORWARDING + + (no arguments) + + Requests that the connection to the authentication agent be for- + warded over the secure channel. The method used by clients to + contact the authentication agent within each machine is imple- + mentation and machine dependent. If the server accepts this + request, it should arrange that any clients run from this ses- + sion will actually contact the server program when they try to + contact the authentication agent. The server should then send a + SSH_SMSG_AGENT_OPEN to open a channel to the agent, and the + client should forward the connection to the real authentication + agent. Supporting this message is optional. + + 31 SSH_SMSG_AGENT_OPEN + + 32-bit int local_channel + + Sent by the server in interactive session mode, this message + requests opening a channel to the authentication agent. The + client should open a channel, and respond with either + SSH_MSG_CHANNEL_OPEN_CONFIRMATION or + SSH_MSG_CHANNEL_OPEN_FAILURE. + + 32 SSH_MSG_IGNORE + + string data + + Either party may send this message at any time. This message, + and the argument string, is silently ignored. This message + might be used in some implementations to make traffic analysis + more difficult. This message is not currently sent by the + implementation, but all implementations are required to recog- + nize and ignore it. + + 33 SSH_CMSG_EXIT_CONFIRMATION + + (no arguments) + + Sent by the client in response to SSH_SMSG_EXITSTATUS. This is + the last message sent by the client. + + 34 SSH_CMSG_X11_REQUEST_FORWARDING + + + + +Ylonen [Page 27] + +Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 Nov 1995 + + + string x11_authentication_protocol + string x11_authentication_data + 32-bit int screen number (if SSH_PROTOFLAG_SCREEN_NUMBER) + + Sent by the client during the preparatory phase, this message + requests that the server create a fake X11 display and set the + DISPLAY environment variable accordingly. An internet-domain + display is preferable. The given authentication protocol and + the associated data should be recorded by the server so that it + is used as authentication on connections (e.g., in .Xauthority). + The authentication protocol must be one of the supported X11 + authentication protocols, e.g., "MIT-MAGIC-COOKIE-1". Authenti- + cation data must be a lowercase hex string of even length. Its + interpretation is protocol dependent. The data is in a format + that can be used with e.g. the xauth program. Supporting this + message is optional. + + The client is permitte