From pekkas at netcore.fi Thu Nov 1 01:06:16 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 31 Oct 2001 16:06:16 +0200 (EET) Subject: Recent openssl is required for OPENSSL_free [Re: Please test snapshots for 3.0 release] (fwd) In-Reply-To: Message-ID: On Wed, 31 Oct 2001, Damien Miller wrote: > On Tue, 30 Oct 2001, Lutz Jaenicke wrote: > > > Hmm, while thinking about it: the correct macro substution should therefore > > be "Free()" instead of "free()", as we must make sure that the correct > > memory handling function (CRYPTO_free()) is being called: > > That is (as the OpenSSL developers discovered) a namespace collision > waiting to happen. Can people try this patch? I put this on latest CVS, rebuilt the new RPM with contrib/redhat/openssh.spec and installed it on my RHL62 system w/ OpenSSL 0.9.5a; seems to work fine. > Index: defines.h > =================================================================== > RCS file: /var/cvs/openssh/defines.h,v > retrieving revision 1.74 > diff -u -r1.74 defines.h > --- defines.h 2001/10/30 02:50:40 1.74 > +++ defines.h 2001/10/30 23:35:22 > @@ -45,6 +45,7 @@ > #include /* For STDIN_FILENO, etc */ > #include /* Struct winsize */ > #include /* For O_NONBLOCK */ > +#include /* For OPENSSL_VERSION_NUMBER */ > > /* *-*-nto-qnx needs these headers for strcasecmp and LASTLOG_FILE respectively */ > #ifdef HAVE_STRINGS_H > @@ -448,6 +449,11 @@ > > #ifndef GETPGRP_VOID > # define getpgrp() getpgrp(0) > +#endif > + > +/* OPENSSL_free() is only available in OpenSSL 0.9.6 onwards */ > +#if !defined(OPENSSL_VERSION_NUMBER) || (OPENSSL_VERSION_NUMBER < 0x0090600f) > +# define OPENSSL_free(x) Free(x) > #endif > > /* > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From ciaran.deignan at netcelo.com Thu Nov 1 02:30:06 2001 From: ciaran.deignan at netcelo.com (Ciaran Deignan) Date: Wed, 31 Oct 2001 16:30:06 +0100 Subject: Open SSL connection to HTTPS? Message-ID: <3BE018FE.8245CF71@netcelo.com> Hi All, I just tried to test my web server with telnet. The only problem was that my web server refuses non-encrypted connections (duh!). I know that SSL and SSH are *entirely* different, but ssh is the only commonly-available encryption-enabled command-line tool around. It would be greate to have an SSL-emulation mode in OpenSSH.... Just wishful thinking, Ciaran -- +-----------------------------------------------------------------------+ Ciaran Deignan Tel: (France) 04 38 49 87 27 NetCelo, Managed Internet VPN http://www.netcelo.com/ mailto: Ciaran.Deignan at netcelo.com +-----------------------------------------------------------------------+ From djast at cs.toronto.edu Thu Nov 1 02:37:53 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 31 Oct 2001 10:37:53 -0500 Subject: Open SSL connection to HTTPS? In-Reply-To: Your message of "Wed, 31 Oct 2001 10:30:06 EST." <3BE018FE.8245CF71@netcelo.com> Message-ID: <01Oct31.103757edt.453139-11303@jane.cs.toronto.edu> On Wed, 31 Oct 2001 10:30:06 EST, Ciaran Deignan writes: > > I know that SSL and SSH are *entirely* different, but ssh is > the only commonly-available encryption-enabled command-line tool > around. It would be greate to have an SSL-emulation mode in > OpenSSH.... Since OpenSSH depends on the OpenSSL package, presumably you have the latter installed? Try: openssl s_client -connect host:443 to connect to your SSL-enabled web server. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From jjaakkol at cs.Helsinki.FI Thu Nov 1 02:40:06 2001 From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola) Date: Wed, 31 Oct 2001 17:40:06 +0200 (EET) Subject: Open SSL connection to HTTPS? In-Reply-To: <3BE018FE.8245CF71@netcelo.com> Message-ID: On Wed, 31 Oct 2001, Ciaran Deignan wrote: > > > Hi All, > > I just tried to test my web server with telnet. The only problem > was that my web server refuses non-encrypted connections (duh!). > > I know that SSL and SSH are *entirely* different, but ssh is > the only commonly-available encryption-enabled command-line tool > around. It would be greate to have an SSL-emulation mode in > OpenSSH.... If you have openssl (which you do have if you have openssh) then you should have the openssl command. Try: $ openssl s_client -connect www.server.somewhere:https and after that RTFM. And then there is stunnel, which does SSL tunneling. Both can be used from command line and do their job well. It might be good if openssh could use X.509 sertificates, but other than that I see no point in introducing SSL to openssh. - Jani From peterw at usa.net Thu Nov 1 02:41:45 2001 From: peterw at usa.net (Peter W) Date: Wed, 31 Oct 2001 10:41:45 -0500 Subject: Open SSL connection to HTTPS? In-Reply-To: <3BE018FE.8245CF71@netcelo.com>; from ciaran.deignan@netcelo.com on Wed, Oct 31, 2001 at 04:30:06PM +0100 References: <3BE018FE.8245CF71@netcelo.com> Message-ID: <20011031104145.B10972@usa.net> On Wed, Oct 31, 2001 at 04:30:06PM +0100, Ciaran Deignan wrote: > I just tried to test my web server with telnet. The only problem > was that my web server refuses non-encrypted connections (duh!). Read the man pages for OpenSSL, especially the s_client feature. I believe it does exactly what you want. If not, follow up to an OpenSSL mailing list/forum. :-) -Peter From markus at openbsd.org Thu Nov 1 03:42:01 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 31 Oct 2001 17:42:01 +0100 Subject: suggested fix for the sigchld race Message-ID: <20011031174201.A5564@faui02.informatik.uni-erlangen.de> comments? alternatives: sigsetjmp(ugly) and pselect(not portable, available) drawback: additional filedescriptors. Index: serverloop.c =================================================================== RCS file: /home/markus/cvs/ssh/serverloop.c,v retrieving revision 1.82 diff -u -r1.82 serverloop.c --- serverloop.c 10 Oct 2001 22:18:47 -0000 1.82 +++ serverloop.c 11 Oct 2001 18:06:33 -0000 @@ -92,6 +92,45 @@ /* prototypes */ static void server_init_dispatch(void); +/* + * we write to this pipe if a SIGCHLD is caught in order to avoid + * the race between select() and child_terminated + */ +static int notify_pipe[2]; +static void +notify_setup(void) +{ + if (pipe(notify_pipe) < 0) { + error("pipe(notify_pipe) failed %s", strerror(errno)); + notify_pipe[0] = -1; /* read end */ + notify_pipe[1] = -1; /* write end */ + } else { + set_nonblock(notify_pipe[0]); + set_nonblock(notify_pipe[1]); + } +} +static void +notify_parent(void) +{ + if (notify_pipe[1] != -1) + write(notify_pipe[1], "", 1); +} +static void +notify_prepare(fd_set *readset) +{ + if (notify_pipe[0] != -1) + FD_SET(notify_pipe[0], readset); +} +static void +notify_done(fd_set *readset) +{ + char c; + + if (notify_pipe[0] != -1 && FD_ISSET(notify_pipe[0], readset)) + while (read(notify_pipe[0], &c, 1) != -1) + debug2("notify_done: reading"); +} + static void sigchld_handler(int sig) { @@ -99,6 +138,7 @@ debug("Received SIGCHLD."); child_terminated = 1; signal(SIGCHLD, sigchld_handler); + notify_parent(); errno = save_errno; } @@ -242,6 +282,7 @@ if (fdin != -1 && buffer_len(&stdin_buffer) > 0) FD_SET(fdin, *writesetp); } + notify_prepare(*readsetp); /* * If we have buffered packet data going to the client, mark that @@ -278,6 +319,8 @@ error("select: %.100s", strerror(errno)); } else if (ret == 0 && client_alive_scheduled) client_alive_check(); + + notify_done(*readsetp); } /* @@ -467,6 +510,8 @@ connection_in = packet_get_connection_in(); connection_out = packet_get_connection_out(); + notify_setup(); + previous_stdout_buffer_bytes = 0; /* Set approximate I/O buffer size. */ @@ -572,6 +617,7 @@ max_fd = MAX(max_fd, fdin); max_fd = MAX(max_fd, fdout); max_fd = MAX(max_fd, fderr); + max_fd = MAX(max_fd, notify_pipe[0]); /* Sleep in select() until we can do something. */ wait_until_can_do_something(&readset, &writeset, &max_fd, @@ -696,7 +742,11 @@ connection_in = packet_get_connection_in(); connection_out = packet_get_connection_out(); + notify_setup(); + max_fd = MAX(connection_in, connection_out); + max_fd = MAX(max_fd, notify_pipe[0]); + xxx_authctxt = authctxt; server_init_dispatch(); From Nicolas.Williams at ubsw.com Thu Nov 1 05:33:38 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 31 Oct 2001 13:33:38 -0500 Subject: suggested fix for the sigchld race In-Reply-To: <20011031174201.A5564@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Oct 31, 2001 at 05:42:01PM +0100 References: <20011031174201.A5564@faui02.informatik.uni-erlangen.de> Message-ID: <20011031133337.R5739@sm2p1386swk.wdr.com> Does this make it unnecessary to block SIGCHLD around where child_terminated is manipulated? At first glance I'd say yes... Your patch is rather elegant and simple. The extra file descriptors needed should not be a problem, I don't think. Why did you list that as a disadvantage? Below is a patch to misc.h/misc.c/config.h.in to deal with signal blocking. And sigprocmask and sigblock need to be added to the configure.in list of function checks. And the code in serverloop2() that manipulates child_terminated needs to be bracketed with calls to block_sigchld()/unblock_sigchld(). I'm not recommending this patch, mind you. I'll test yours... Nico On Wed, Oct 31, 2001 at 05:42:01PM +0100, Markus Friedl wrote: > comments? > > alternatives: sigsetjmp(ugly) and pselect(not portable, available) > drawback: additional filedescriptors. > Index: 2_9_p2_w_gss_krb5_named_keys.15/config.h.in --- 2_9_p2_w_gss_krb5_named_keys.15/config.h.in Tue, 26 Jun 2001 16:27:13 -0400 (OpenSSH/f/45_config.h.i 1.3 644) +++ 2_9_p2_w_gss_krb5_named_keys.16(w)/config.h.in Tue, 30 Oct 2001 15:55:15 -0500 (OpenSSH/f/45_config.h.i 1.4 644) @@ -542,6 +542,12 @@ /* Define if you have the sigvec function. */ #undef HAVE_SIGVEC +/* Define if you have the sigprocmask function. */ +#undef HAVE_SIGPROCMASK + +/* Define if you have the sigblock function. */ +#undef HAVE_SIGBLOCK + /* Define if you have the snprintf function. */ #undef HAVE_SNPRINTF Index: 2_9_p2_w_gss_krb5_named_keys.15/misc.h --- 2_9_p2_w_gss_krb5_named_keys.15/misc.h Thu, 03 May 2001 16:12:13 -0400 (OpenSSH/i/45_misc.h 1.1 644) +++ 2_9_p2_w_gss_krb5_named_keys.16(w)/misc.h Tue, 30 Oct 2001 14:33:44 -0500 (OpenSSH/i/45_misc.h 1.2 644) @@ -32,3 +32,6 @@ /* wrapper for signal interface */ typedef void (*mysig_t)(int); mysig_t mysignal(int sig, mysig_t act); + +void block_sigchld(); +void unblock_sigchld(); Index: 2_9_p2_w_gss_krb5_named_keys.15/misc.c --- 2_9_p2_w_gss_krb5_named_keys.15/misc.c Fri, 22 Jun 2001 15:59:54 -0400 (OpenSSH/i/46_misc.c 1.2 644) +++ 2_9_p2_w_gss_krb5_named_keys.16(w)/misc.c Tue, 30 Oct 2001 16:22:43 -0500 (OpenSSH/i/46_misc.c 1.3 644) @@ -156,3 +156,34 @@ return (signal(sig, act)); #endif } + +#ifdef HAVE_SIGPROCMASK +static sigset_t osigset; +#elif HAVE_SIGBLOCK +static int osigmask; +#endif + +void +block_sigchld() +{ +#ifdef HAVE_SIGPROCMASK + sigset_t sigchld_set; + (void) sigemptyset(&sigchld_set); + (void) sigaddset(&sigchld_set, SIGCHLD); + if (sigprocmask(SIG_BLOCK, &sigchld_set, &osigset) < 0) + debug("block_sigchld: sigprocmask() returned error %s", strerror(errno)); +#elif HAVE_SIGBLOCK + osigmask = sigblock(sigmask(SIGCHLD)); +#endif +} + +void +unblock_sigchld() +{ +#ifdef HAVE_SIGPROCMASK + if (sigprocmask(SIG_UNBLOCK, &osigset, NULL) < 0) + debug("block_sigchld: sigprocmask() returned error %s", strerror(errno)); +#elif HAVE_SIGBLOCK + (void) sigsetmask(osigmask); +#endif +} Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Thu Nov 1 06:16:26 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 31 Oct 2001 20:16:26 +0100 Subject: suggested fix for the sigchld race In-Reply-To: <20011031133337.R5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Oct 31, 2001 at 01:33:38PM -0500 References: <20011031174201.A5564@faui02.informatik.uni-erlangen.de> <20011031133337.R5739@sm2p1386swk.wdr.com> Message-ID: <20011031201626.C11971@faui02.informatik.uni-erlangen.de> On Wed, Oct 31, 2001 at 01:33:38PM -0500, Nicolas Williams wrote: > Does this make it unnecessary to block SIGCHLD around where > child_terminated is manipulated? At first glance I'd say yes... currently, collect_children() blocks signals: static void collect_children(void) { pid_t pid; sigset_t oset, nset; int status; /* block SIGCHLD while we check for dead children */ sigemptyset(&nset); sigaddset(&nset, SIGCHLD); sigprocmask(SIG_BLOCK, &nset, &oset); if (child_terminated) { while ((pid = waitpid(-1, &status, WNOHANG)) > 0) session_close_by_pid(pid, status); child_terminated = 0; } sigprocmask(SIG_SETMASK, &oset, NULL); } From markus at openbsd.org Thu Nov 1 06:18:19 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 31 Oct 2001 20:18:19 +0100 Subject: suggested fix for the sigchld race In-Reply-To: <20011031133337.R5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Oct 31, 2001 at 01:33:38PM -0500 References: <20011031174201.A5564@faui02.informatik.uni-erlangen.de> <20011031133337.R5739@sm2p1386swk.wdr.com> Message-ID: <20011031201819.A20625@folly> On Wed, Oct 31, 2001 at 01:33:38PM -0500, Nicolas Williams wrote: > The extra file descriptors needed should not be a problem, I don't > think. Why did you list that as a disadvantage? if you have 1000 running sshds on your system you need additional 2000 filedescriptos in your kernel. -m From djast at cs.toronto.edu Thu Nov 1 06:23:00 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 31 Oct 2001 14:23:00 -0500 Subject: suggested fix for the sigchld race In-Reply-To: Your message of "Wed, 31 Oct 2001 13:33:38 EST." <20011031133337.R5739@sm2p1386swk.wdr.com> Message-ID: <01Oct31.142304edt.453144-11303@jane.cs.toronto.edu> On Wed, 31 Oct 2001 13:33:38 EST, Nicolas Williams writes: > Does this make it unnecessary to block SIGCHLD around where > child_terminated is manipulated? At first glance I'd say yes... It might be cleaner to eliminate child_terminated altogether in favour of the new mechanism for polling for terminated children. If child_terminated is still necessary, then the blocking in collect_children() shouldn't be removed. Otherwise, a SIGCHLD that arrives during collect_children() might not set child_terminated correctly. In general, I'd like to see SIGCHLD and other signals blocked more of the time, not less: the arrival of a signal can cause system calls to be interrupted, among other possible mischief and complication. (Note that SA_RESTART doesn't work around that problem effectively: that flag affects some, but not all, system calls. In Pine under Solaris 8, I've seen SIGALRM cause the unlink() of lock files over NFS to fail, for example.) IMHO, the safest and simplest approach in general is often to keep the signal blocked at all times, except when we know we're prepared to handle it; e.g., unblock it before any calls which we expect may block for a lengthy time--such as select()--and be prepared for those calls to fail with EINTR. FWIW, I'm not fond of the debug() call inside sigchld_handler(); it can cause async-unsafe operations to occur. (BTW, I'm guessing that we already know that grace_alarm_handler() in ssh.c does async-unsafe operations, hence the comment "/* XXX no idea how fix this signal handler */" :-) ) -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From Nicolas.Williams at ubsw.com Thu Nov 1 06:32:22 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 31 Oct 2001 14:32:22 -0500 Subject: suggested fix for the sigchld race In-Reply-To: <20011031201819.A20625@folly>; from markus@openbsd.org on Wed, Oct 31, 2001 at 08:18:19PM +0100 References: <20011031174201.A5564@faui02.informatik.uni-erlangen.de> <20011031133337.R5739@sm2p1386swk.wdr.com> <20011031201819.A20625@folly> Message-ID: <20011031143221.S5739@sm2p1386swk.wdr.com> Right. I'm on Solaris. I don't care :) On Solaris I have to live with the 256 fildes limit in stdio (32-bit) and the artificial 1024 fildes limit in select(3c). Nico On Wed, Oct 31, 2001 at 08:18:19PM +0100, Markus Friedl wrote: > On Wed, Oct 31, 2001 at 01:33:38PM -0500, Nicolas Williams wrote: > > The extra file descriptors needed should not be a problem, I don't > > think. Why did you list that as a disadvantage? > > if you have 1000 running sshds on your system you need > additional 2000 filedescriptos in your kernel. > > -m -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Thu Nov 1 06:38:24 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 31 Oct 2001 14:38:24 -0500 Subject: OpenStep (NeXT) and TTY modes Message-ID: <20011031143823.T5739@sm2p1386swk.wdr.com> OpenStep, apparently, does not initialize new pty/tty modes to a sane default. I'm thinking this code snippet, added to tty_parse_modes() before the for(;;) loop should suffice: #ifdef HAVE_NEXT tio.c_oflag |= ONLCR; tio.c_lflag |= ECHO; #endif /* HAVE_NEXT */ Also, I've noticed that "ssh -t next_host stty" gives different output than an interactive session to the same NeXT... I suspect that this means that the SSH client is sending a different set of tty modes to the sshd on the NeXT... Is that so? Does that make sense? Cheers, Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From imorgan at nas.nasa.gov Thu Nov 1 07:16:36 2001 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 31 Oct 2001 12:16:36 -0800 (PST) Subject: REQ: Minor change ton handling of without-password In-Reply-To: from "imorgan" at Oct 31, 2001 12:04:29 PM Message-ID: <200110312016.MAA169208@nopython.nas.nasa.gov> Hi, OpenSSH 2.9p2 behaves differently with 'PermitRootLogin without-password' than does SSH 2.2.27 with 'PermitRootLogin nopwd': nopython.imorgan 153> ssh root at sun523 root at sun523's password: ROOT LOGIN REFUSED FROM nopython.nas.nasa.gov nopython.imorgan 154> ssh root at sun566 root at sun566's password: Permission denied. In the case of OpenSSH, you simply get 'Permission denied' which may lead some to incorrectly assume that the issue is a mistyped password. -- Iain Morgan NAS Desktop Support Group From stevesk at pobox.com Thu Nov 1 07:40:03 2001 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 31 Oct 2001 12:40:03 -0800 (PST) Subject: OpenStep (NeXT) and TTY modes In-Reply-To: <20011031143823.T5739@sm2p1386swk.wdr.com> Message-ID: On Wed, 31 Oct 2001, Nicolas Williams wrote: :OpenStep, apparently, does not initialize new pty/tty modes to a sane :default. : :I'm thinking this code snippet, added to tty_parse_modes() before the :for(;;) loop should suffice: : :#ifdef HAVE_NEXT : tio.c_oflag |= ONLCR; : tio.c_lflag |= ECHO; :#endif /* HAVE_NEXT */ : :Also, I've noticed that "ssh -t next_host stty" gives different output :than an interactive session to the same NeXT... I suspect that this :means that the SSH client is sending a different set of tty modes to the :sshd on the NeXT... Is that so? Does that make sense? i don't know. is in the same for protocol 1 and 2? you can debug with ssh/-vvv sshd/-ddd for tty_make_modes() and tty_parse_modes(). From Nicolas.Williams at ubsw.com Thu Nov 1 07:40:24 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 31 Oct 2001 15:40:24 -0500 Subject: OpenStep (NeXT) and TTY modes In-Reply-To: <20011031143823.T5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Oct 31, 2001 at 02:38:24PM -0500 References: <20011031143823.T5739@sm2p1386swk.wdr.com> Message-ID: <20011031154023.U5739@sm2p1386swk.wdr.com> Ok, the correct modes to add, before parsing the client-sent tty modes, are: #ifdef HAVE_NEXT tio.c_oflag |= ONLCR; tio.c_lflag |= ECHO; tio.c_iflag |= ICRNL; #endif /* HAVE_NEXT */ We've tested this change and find that it fixes the problem with tty modes on OpenStep. Nico On Wed, Oct 31, 2001 at 02:38:24PM -0500, Nicolas Williams wrote: > OpenStep, apparently, does not initialize new pty/tty modes to a sane > default. > > I'm thinking this code snippet, added to tty_parse_modes() before the > for(;;) loop should suffice: > > #ifdef HAVE_NEXT > tio.c_oflag |= ONLCR; > tio.c_lflag |= ECHO; > #endif /* HAVE_NEXT */ > > Also, I've noticed that "ssh -t next_host stty" gives different output > than an interactive session to the same NeXT... I suspect that this > means that the SSH client is sending a different set of tty modes to the > sshd on the NeXT... Is that so? Does that make sense? > > Cheers, > > Nico > -- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Thu Nov 1 07:51:44 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 31 Oct 2001 15:51:44 -0500 Subject: OpenStep (NeXT) and TTY modes In-Reply-To: ; from Kevin Steves on Wed, Oct 31, 2001 at 12:40:03PM -0800 References: <20011031143823.T5739@sm2p1386swk.wdr.com> Message-ID: <20011031155144.T26615@wdr.com> On Wed, Oct 31, 2001 at 12:40:03PM -0800, Kevin Steves wrote: > On Wed, 31 Oct 2001, Nicolas Williams wrote: > :OpenStep, apparently, does not initialize new pty/tty modes to a sane > :default. > : > :I'm thinking this code snippet, added to tty_parse_modes() before the > :for(;;) loop should suffice: > : > :#ifdef HAVE_NEXT > : tio.c_oflag |= ONLCR; > : tio.c_lflag |= ECHO; > :#endif /* HAVE_NEXT */ > : > :Also, I've noticed that "ssh -t next_host stty" gives different output > :than an interactive session to the same NeXT... I suspect that this > :means that the SSH client is sending a different set of tty modes to the > :sshd on the NeXT... Is that so? Does that make sense? > > i don't know. is in the same for protocol 1 and 2? you can debug with > ssh/-vvv sshd/-ddd for tty_make_modes() and tty_parse_modes(). I just did ssh -vvv -- I saw no difference in what the client sends... Go figure... I can't see why the sshd would not apply both the same way. But mind you, the client is OpenSSH 2.9p2 on Solaris, and the server is OpenSSH 2.9p2 on OpenStep. No big deal. The patch to add tio.c_iflag |= INLCR, tio.c_oflag |= ONLCR and tio.c_lflag |= ECHO suffices for me. We've tested with OpenSSH clients and PUTTY. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ed at UDel.Edu Thu Nov 1 08:03:09 2001 From: ed at UDel.Edu (Ed Phillips) Date: Wed, 31 Oct 2001 16:03:09 -0500 (EST) Subject: Problem compiling 2.9.9p2 on Sol 2.6 Message-ID: It appears that "fixpaths" has "/usr/bin/perl" hard-coded in. This causes make to fail immediately after running configure. Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From ed at UDel.Edu Thu Nov 1 08:09:01 2001 From: ed at UDel.Edu (Ed Phillips) Date: Wed, 31 Oct 2001 16:09:01 -0500 (EST) Subject: Problem compiling 2.9.9p2 on Sol 2.6 In-Reply-To: Message-ID: Also, for some reason, mdoc2man.pl was mode 0644 (and couldn't be executed) after running configure on Solaris 2.6. On Wed, 31 Oct 2001, Ed Phillips wrote: > Date: Wed, 31 Oct 2001 16:03:09 -0500 (EST) > From: Ed Phillips > To: OpenSSH Development > Subject: Problem compiling 2.9.9p2 on Sol 2.6 > > It appears that "fixpaths" has "/usr/bin/perl" hard-coded in. This causes > make to fail immediately after running configure. > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Darren.Moffat at eng.sun.com Thu Nov 1 09:16:21 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 31 Oct 2001 14:16:21 -0800 (PST) Subject: REQ: Minor change ton handling of without-password Message-ID: <200110312216.f9VMGLSI462222@jurassic.eng.sun.com> >OpenSSH 2.9p2 behaves differently with 'PermitRootLogin without-password' >than does SSH 2.2.27 with 'PermitRootLogin nopwd': > >nopython.imorgan 153> ssh root at sun523 >root at sun523's password: >ROOT LOGIN REFUSED FROM nopython.nas.nasa.gov > >nopython.imorgan 154> ssh root at sun566 >root at sun566's password: >Permission denied. > >In the case of OpenSSH, you simply get 'Permission denied' which may lead >some to incorrectly assume that the issue is a mistyped password. OpenSSH is more secure in its behaviour since it didn't tell you that the password was correct so it can't be used as a method to test possible root passwords and then go and use the root password to get into the host by another means (eg on the console). I guess it could be a config option to say how much information is given out when a login is refused. If you care write the patch to make it configurable and ask for it to be included. -- Darren J Moffat From djm at mindrot.org Thu Nov 1 09:33:53 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Nov 2001 09:33:53 +1100 (EST) Subject: Open SSL connection to HTTPS? In-Reply-To: <3BE018FE.8245CF71@netcelo.com> Message-ID: On Wed, 31 Oct 2001, Ciaran Deignan wrote: > > > Hi All, > > I just tried to test my web server with telnet. The only problem > was that my web server refuses non-encrypted connections (duh!). > > I know that SSL and SSH are *entirely* different, but ssh is > the only commonly-available encryption-enabled command-line tool > around. It would be greate to have an SSL-emulation mode in > OpenSSH.... No - they are _completely_ different. If you have OpenSSL installed (which you probably have if you have OpenSSH installed), you can use "openssl s_client" to do what you ask. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Thu Nov 1 09:36:58 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Nov 2001 09:36:58 +1100 (EST) Subject: REQ: Minor change ton handling of without-password In-Reply-To: <200110312016.MAA169208@nopython.nas.nasa.gov> Message-ID: On Wed, 31 Oct 2001, Iain Morgan wrote: > nopython.imorgan 154> ssh root at sun566 > root at sun566's password: > Permission denied. > > In the case of OpenSSH, you simply get 'Permission denied' which may lead > some to incorrectly assume that the issue is a mistyped password. We do not want to expose the reason why access is denied - we go to some trouble to ensure this. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Thu Nov 1 09:37:56 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Nov 2001 09:37:56 +1100 (EST) Subject: Problem compiling 2.9.9p2 on Sol 2.6 In-Reply-To: Message-ID: On Wed, 31 Oct 2001, Ed Phillips wrote: > It appears that "fixpaths" has "/usr/bin/perl" hard-coded in. This causes > make to fail immediately after running configure. Huh? how is fixpaths run from the Makefile? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From celinn at mtu.edu Thu Nov 1 10:03:48 2001 From: celinn at mtu.edu (Christopher Linn) Date: Wed, 31 Oct 2001 18:03:48 -0500 Subject: Problem compiling 2.9.9p2 on Sol 2.6 In-Reply-To: ; from djm@mindrot.org on Thu, Nov 01, 2001 at 09:37:56AM +1100 References: Message-ID: <20011031180347.A31099@mtu.edu> On Thu, Nov 01, 2001 at 09:37:56AM +1100, Damien Miller wrote: > On Wed, 31 Oct 2001, Ed Phillips wrote: > > > It appears that "fixpaths" has "/usr/bin/perl" hard-coded in. This causes > > make to fail immediately after running configure. > > Huh? how is fixpaths run from the Makefile? > > -d yeah, i'm building it with perl in a non-std place, and no fixpaths problems at all. from the transcript of my build, fixpaths is called via /path/to/perl ./fixpaths ... and it just works. sol 2.6, openssh-2.9.9p2, perl 5.005_03, /usr/ccs/bin/make, and i tweek paths my fixpaths gets used.. chris -- Christopher Linn, | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From wally.winzer at ChampUSA.COM Thu Nov 1 10:01:14 2001 From: wally.winzer at ChampUSA.COM (Auteria Wally Winzer Jr.) Date: Wed, 31 Oct 2001 15:01:14 -0800 Subject: 2.9.9p2 and Solaris-2.8 PAM: Cannot delete credentials[7]: Permission denied Message-ID: <3BE082BA.F0D034BC@ChampUSA.COM> The 2 errors: pam_setcred: error Permission denied Cannot delete credentials[7]: Permission denied Looks to be a major bug in the PAM module for Solaris-2.8/2.7/2.6. Has anyone from the list (developers of OpenSSH, endusers, hackers, etc.) came up w/ a solution? Even a temporary one? When authenticating yourself on the same system that worked, but when authenticating to another system failed. I even tried to placed entries within /etc/pam.conf w/ no success. If there's no viable solution (even with key authentication) then I'll have to revert back to SSH-3.0.1/SSH-1.2.31. Thanks. - Wally Winzer Jr. P.S. Pls send all replies to wally.winzer at ChampUSA.COM for I don't belong to this list as of yet. Thx. From djm at mindrot.org Thu Nov 1 12:40:36 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Nov 2001 12:40:36 +1100 (EST) Subject: 2.9.9p2 and Solaris-2.8 PAM: Cannot delete credentials[7]: Permission denied In-Reply-To: <3BE082BA.F0D034BC@ChampUSA.COM> Message-ID: On Wed, 31 Oct 2001, Auteria Wally Winzer Jr. wrote: > The 2 errors: > > pam_setcred: error Permission denied > Cannot delete credentials[7]: Permission denied This hasn't caused visible problems in the past - what are you seeing? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From vsync at quadium.net Thu Nov 1 10:20:28 2001 From: vsync at quadium.net (vsync) Date: Wed, 31 Oct 2001 16:20:28 -0700 Subject: Default X11 forwarding behavior Message-ID: <2.1-3001316-268-B-OEWW@feynman.hurstdog.org> Ed Phillips wrote: > Are there any good reasons why not to sshd allow X11 forwarding > to occur? Bandwidth usage, perhaps? -- vsync http://quadium.net/ Sent using Eudora for PalmOS on a Visor Platinum with VisorPhone. Yay for tech! From tim at multitalents.net Thu Nov 1 14:18:04 2001 From: tim at multitalents.net (Tim Rice) Date: Wed, 31 Oct 2001 19:18:04 -0800 (PST) Subject: Problem compiling 2.9.9p2 on Sol 2.6 In-Reply-To: Message-ID: And so does fixprogs. But it doesn't really matter. It works fine on systems that have no /usr/bin/perl. You need to find out what went wrong with configure. What does 'grep "^PERL=" Makefile' say? On Wed, 31 Oct 2001, Ed Phillips wrote: > Also, for some reason, mdoc2man.pl was mode 0644 (and couldn't be > executed) after running configure on Solaris 2.6. > > On Wed, 31 Oct 2001, Ed Phillips wrote: > > > Date: Wed, 31 Oct 2001 16:03:09 -0500 (EST) > > From: Ed Phillips > > To: OpenSSH Development > > Subject: Problem compiling 2.9.9p2 on Sol 2.6 > > > > It appears that "fixpaths" has "/usr/bin/perl" hard-coded in. This causes > > make to fail immediately after running configure. > > > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From ed at UDel.Edu Fri Nov 2 01:22:58 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 1 Nov 2001 09:22:58 -0500 (EST) Subject: Problem compiling 2.9.9p2 on Sol 2.6 In-Reply-To: Message-ID: On Thu, 1 Nov 2001, Damien Miller wrote: > Date: Thu, 1 Nov 2001 09:37:56 +1100 (EST) > From: Damien Miller > To: Ed Phillips > Cc: OpenSSH Development > Subject: Re: Problem compiling 2.9.9p2 on Sol 2.6 > > On Wed, 31 Oct 2001, Ed Phillips wrote: > > > It appears that "fixpaths" has "/usr/bin/perl" hard-coded in. This causes > > make to fail immediately after running configure. > > Huh? how is fixpaths run from the Makefile? Look for FIXPATHSCMD in the Makefile and you can see where it is run. Anyway, it looks like the problem is actually got something to do with the fact that "PERL" didn't get set when I ran configure (even though you can't even run configure without it). Could it be that PERL is not getting set correctly if it's not in /usr/bin/perl? Thanks, Ed > > -d > > -- > | By convention there is color, \\ Damien Miller > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > | But in reality there are atoms and space - Democritus (c. 400 BCE) > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From ed at UDel.Edu Fri Nov 2 01:30:37 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 1 Nov 2001 09:30:37 -0500 (EST) Subject: 2.9.9p2 and Solaris-2.8 PAM: Cannot delete credentials[7]: Permission denied In-Reply-To: <3BE082BA.F0D034BC@ChampUSA.COM> Message-ID: On Wed, 31 Oct 2001, Auteria Wally Winzer Jr. wrote: > Date: Wed, 31 Oct 2001 15:01:14 -0800 > From: Auteria Wally Winzer Jr. > To: openssh-unix-dev at mindrot.org > Subject: 2.9.9p2 and Solaris-2.8 PAM: Cannot delete credentials[7]: > Permission denied > > The 2 errors: > > pam_setcred: error Permission denied > Cannot delete credentials[7]: Permission denied > > Looks to be a major bug in the PAM module for Solaris-2.8/2.7/2.6. > Has anyone from the list (developers of OpenSSH, endusers, hackers, etc.) > came up w/ a solution? Even a temporary one? > When authenticating yourself on the same system that worked, but when > authenticating to another system failed. I even tried to placed entries > within /etc/pam.conf w/ no success. If there's no viable solution (even with > key authentication) then I'll have to revert back to SSH-3.0.1/SSH-1.2.31. I reported this problem recently too... the result is that "keylogout" (destroy Secure RPC credentials) is not run for the user when the user logs out. Other than that, it really has no impact except for the error message (if you have logging turned up to that level). The only solution I see (in lieu of Sun fixing it - which is what people on the list have suggested is the "right thing") - is to change do_pam_cleanup_proc() in auth-pam.c to do a seteuid() with the user's uid before calling pam_setcred(), and then, I guess, call seteuid(0) afterwards to make the rest of the cleanup code run as uid 0 like it used to. This should at least get keylogout to work for the user. Darren, can you tell us why Sun decided to implement pam_sm_setcred(PAM_DELETE_CRED) the way they did in pam_unix.so? Shouldn't keylogout be run for PAM_USER and not the euid of the caller? Hope this helps! Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From deniz at intellect.com.tr Fri Nov 2 01:38:00 2001 From: deniz at intellect.com.tr (Deniz CEVIK) Date: Thu, 1 Nov 2001 16:38:00 +0200 Subject: Authentication Problem In-Reply-To: Message-ID: Hi, Recently, I have upgraded ssh to version 2.2.9p2 on redhat 6.2. After the installation, I started to couldn't connect server via ssh. I am getting password incorrect messages although password is correct. How can I solve this problem. Thanks. debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for root debug2: input_userauth_request: try method none Failed none for ROOT from x.x.x.x port 1240 ssh2 debug1: userauth-request for user root service ssh-connection method password debug1: attempt 1 failures 1 debug2: input_userauth_request: try method password From mouring at etoh.eviladmin.org Fri Nov 2 02:25:06 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 1 Nov 2001 09:25:06 -0600 (CST) Subject: OpenStep (NeXT) and TTY modes In-Reply-To: <20011031154023.U5739@sm2p1386swk.wdr.com> Message-ID: I have to ask since I did the core NeXT work.. What issues are you seeing that adding the below 3 lines fix? I've been using the NeXT (OpenStep 4.2 and NeXTStep 3.3 on Black hardware) for about a year now without noticing any abnormal issues. - Ben On Wed, 31 Oct 2001, Nicolas Williams wrote: > Ok, the correct modes to add, before parsing the client-sent tty modes, > are: > > #ifdef HAVE_NEXT > tio.c_oflag |= ONLCR; > tio.c_lflag |= ECHO; > tio.c_iflag |= ICRNL; > #endif /* HAVE_NEXT */ > > We've tested this change and find that it fixes the problem with tty > modes on OpenStep. > > Nico > > > On Wed, Oct 31, 2001 at 02:38:24PM -0500, Nicolas Williams wrote: > > OpenStep, apparently, does not initialize new pty/tty modes to a sane > > default. > > > > I'm thinking this code snippet, added to tty_parse_modes() before the > > for(;;) loop should suffice: > > > > #ifdef HAVE_NEXT > > tio.c_oflag |= ONLCR; > > tio.c_lflag |= ECHO; > > #endif /* HAVE_NEXT */ > > > > Also, I've noticed that "ssh -t next_host stty" gives different output > > than an interactive session to the same NeXT... I suspect that this > > means that the SSH client is sending a different set of tty modes to the > > sshd on the NeXT... Is that so? Does that make sense? > > > > Cheers, > > > > Nico > > -- > > > > Visit our website at http://www.ubswarburg.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately by e-mail if you have received this > > e-mail by mistake and delete this e-mail from your system. > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. The sender therefore > > does not accept liability for any errors or omissions in the contents > > of this message which arise as a result of e-mail transmission. If > > verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any securities or > > related financial instruments. > -- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > From roth+openssh at feep.net Fri Nov 2 02:45:32 2001 From: roth+openssh at feep.net (Mark D. Roth) Date: Thu, 1 Nov 2001 09:45:32 -0600 Subject: OpenSSH-3.0p1-pre-CVS: configure.ac checks for login in -lutil and -lbsd? In-Reply-To: ; from tim@multitalents.net on Tue, Oct 30, 2001 at 08:10:31PM -0800 References: Message-ID: <20011101094532.A3579@yorktown.isdn.uiuc.edu> On Tue Oct 30 20:10 2001 -0800, Tim Rice wrote: > @@ -619,7 +616,13 @@ > AC_CHECK_FUNCS(gettimeofday time) > dnl Checks for libutil functions > AC_CHECK_HEADERS(libutil.h) > -AC_CHECK_FUNCS(login logout updwtmp logwtmp) > +AC_CHECK_FUNC(login, > + [AC_DEFINE(HAVE_LOGIN)], > + [AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LOGIN) LIBS="$LIBS -lutil", > + [AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])] > + )] > +) > +AC_CHECK_FUNCS(logout updwtmp logwtmp) > dnl Checks for utmp functions > AC_CHECK_FUNCS(endutent getutent getutid getutline pututline setutent) > AC_CHECK_FUNCS(utmpname) Just a minor stylistic comment: Wouldn't it be a bit cleaner to just use this? AC_SEARCH_LIBS(login, util bsd, [AC_DEFINE(HAVE_LOGIN)]) Of course, if I'm missing something, feel free to flog me with a large trout... ;) -- Mark D. Roth http://www.feep.net/~roth/ From Nicolas.Williams at ubsw.com Fri Nov 2 03:25:41 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 1 Nov 2001 11:25:41 -0500 Subject: OpenStep (NeXT) and TTY modes In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Nov 01, 2001 at 09:25:06AM -0600 References: <20011031154023.U5739@sm2p1386swk.wdr.com> Message-ID: <20011101112540.V5739@sm2p1386swk.wdr.com> Without those flags being set we get: a) no echo, b) no CR. The command that fixes the problem is "stty -nl echo". Perhaps there's something different about your OpenStep systems and ours? (apart from the hw -- we use x86 hw). Nico On Thu, Nov 01, 2001 at 09:25:06AM -0600, mouring at etoh.eviladmin.org wrote: > > I have to ask since I did the core NeXT work.. What issues are you seeing > that adding the below 3 lines fix? > > I've been using the NeXT (OpenStep 4.2 and NeXTStep 3.3 on Black hardware) > for about a year now without noticing any abnormal issues. > > - Ben > > On Wed, 31 Oct 2001, Nicolas Williams wrote: > > > Ok, the correct modes to add, before parsing the client-sent tty modes, > > are: > > > > #ifdef HAVE_NEXT > > tio.c_oflag |= ONLCR; > > tio.c_lflag |= ECHO; > > tio.c_iflag |= ICRNL; > > #endif /* HAVE_NEXT */ > > > > We've tested this change and find that it fixes the problem with tty > > modes on OpenStep. > > > > Nico > > > > > > On Wed, Oct 31, 2001 at 02:38:24PM -0500, Nicolas Williams wrote: > > > OpenStep, apparently, does not initialize new pty/tty modes to a sane > > > default. > > > > > > I'm thinking this code snippet, added to tty_parse_modes() before the > > > for(;;) loop should suffice: > > > > > > #ifdef HAVE_NEXT > > > tio.c_oflag |= ONLCR; > > > tio.c_lflag |= ECHO; > > > #endif /* HAVE_NEXT */ > > > > > > Also, I've noticed that "ssh -t next_host stty" gives different output > > > than an interactive session to the same NeXT... I suspect that this > > > means that the SSH client is sending a different set of tty modes to the > > > sshd on the NeXT... Is that so? Does that make sense? > > > > > > Cheers, > > > > > > Nico > > > -- > > > > > > Visit our website at http://www.ubswarburg.com > > > > > > This message contains confidential information and is intended only > > > for the individual named. If you are not the named addressee you > > > should not disseminate, distribute or copy this e-mail. Please > > > notify the sender immediately by e-mail if you have received this > > > e-mail by mistake and delete this e-mail from your system. > > > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > > as information could be intercepted, corrupted, lost, destroyed, > > > arrive late or incomplete, or contain viruses. The sender therefore > > > does not accept liability for any errors or omissions in the contents > > > of this message which arise as a result of e-mail transmission. If > > > verification is required please request a hard-copy version. This > > > message is provided for informational purposes and should not be > > > construed as a solicitation or offer to buy or sell any securities or > > > related financial instruments. > > -- > > > > Visit our website at http://www.ubswarburg.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately by e-mail if you have received this > > e-mail by mistake and delete this e-mail from your system. > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. The sender therefore > > does not accept liability for any errors or omissions in the contents > > of this message which arise as a result of e-mail transmission. If > > verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any securities or > > related financial instruments. > > > > -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From mouring at etoh.eviladmin.org Fri Nov 2 03:37:20 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 1 Nov 2001 10:37:20 -0600 (CST) Subject: OpenStep (NeXT) and TTY modes In-Reply-To: <20011101112540.V5739@sm2p1386swk.wdr.com> Message-ID: Hmm.. Baseline OpenStep 4.2 on NeXT Black Slab with the meger y2k patches put out before it transformed into Mac OS X. I've not touched an OpenStep 4.2 White box in almost 4 years. Still seems odd that they would react so differently, and yet no one else I've talked to running NeXT 3.x to OpenStep 4.x from x86 to Sparc has complained in over a year. Can I get a few other people in the NeXT world that are still hanging around to give comments on this please? Mainly those with x86, but anyone with HP, Sparc, or m68k comment if this causes any odd effects (check 'su' and 'telnet' of the box.. it has been an issue in the past before we moved to readpassphrase() on some NeXT versions). I'm still about a month out until I can put my Slab back into working order. - Ben On Thu, 1 Nov 2001, Nicolas Williams wrote: > Without those flags being set we get: a) no echo, b) no CR. > > The command that fixes the problem is "stty -nl echo". > > Perhaps there's something different about your OpenStep systems and > ours? (apart from the hw -- we use x86 hw). > > Nico > > > On Thu, Nov 01, 2001 at 09:25:06AM -0600, mouring at etoh.eviladmin.org wrote: > > > > I have to ask since I did the core NeXT work.. What issues are you seeing > > that adding the below 3 lines fix? > > > > I've been using the NeXT (OpenStep 4.2 and NeXTStep 3.3 on Black hardware) > > for about a year now without noticing any abnormal issues. > > > > - Ben > > > > On Wed, 31 Oct 2001, Nicolas Williams wrote: > > > > > Ok, the correct modes to add, before parsing the client-sent tty modes, > > > are: > > > > > > #ifdef HAVE_NEXT > > > tio.c_oflag |= ONLCR; > > > tio.c_lflag |= ECHO; > > > tio.c_iflag |= ICRNL; > > > #endif /* HAVE_NEXT */ > > > > > > We've tested this change and find that it fixes the problem with tty > > > modes on OpenStep. > > > > > > Nico > > > > > > > > > On Wed, Oct 31, 2001 at 02:38:24PM -0500, Nicolas Williams wrote: > > > > OpenStep, apparently, does not initialize new pty/tty modes to a sane > > > > default. > > > > > > > > I'm thinking this code snippet, added to tty_parse_modes() before the > > > > for(;;) loop should suffice: > > > > > > > > #ifdef HAVE_NEXT > > > > tio.c_oflag |= ONLCR; > > > > tio.c_lflag |= ECHO; > > > > #endif /* HAVE_NEXT */ > > > > > > > > Also, I've noticed that "ssh -t next_host stty" gives different output > > > > than an interactive session to the same NeXT... I suspect that this > > > > means that the SSH client is sending a different set of tty modes to the > > > > sshd on the NeXT... Is that so? Does that make sense? > > > > > > > > Cheers, > > > > > > > > Nico > > > > -- > > > > > > > > Visit our website at http://www.ubswarburg.com > > > > > > > > This message contains confidential information and is intended only > > > > for the individual named. If you are not the named addressee you > > > > should not disseminate, distribute or copy this e-mail. Please > > > > notify the sender immediately by e-mail if you have received this > > > > e-mail by mistake and delete this e-mail from your system. > > > > > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > > > as information could be intercepted, corrupted, lost, destroyed, > > > > arrive late or incomplete, or contain viruses. The sender therefore > > > > does not accept liability for any errors or omissions in the contents > > > > of this message which arise as a result of e-mail transmission. If > > > > verification is required please request a hard-copy version. This > > > > message is provided for informational purposes and should not be > > > > construed as a solicitation or offer to buy or sell any securities or > > > > related financial instruments. > > > -- > > > > > > Visit our website at http://www.ubswarburg.com > > > > > > This message contains confidential information and is intended only > > > for the individual named. If you are not the named addressee you > > > should not disseminate, distribute or copy this e-mail. Please > > > notify the sender immediately by e-mail if you have received this > > > e-mail by mistake and delete this e-mail from your system. > > > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > > as information could be intercepted, corrupted, lost, destroyed, > > > arrive late or incomplete, or contain viruses. The sender therefore > > > does not accept liability for any errors or omissions in the contents > > > of this message which arise as a result of e-mail transmission. If > > > verification is required please request a hard-copy version. This > > > message is provided for informational purposes and should not be > > > construed as a solicitation or offer to buy or sell any securities or > > > related financial instruments. > > > > > > > -- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > From tim at multitalents.net Fri Nov 2 04:33:22 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 1 Nov 2001 09:33:22 -0800 (PST) Subject: OpenSSH-3.0p1-pre-CVS: configure.ac checks for login in -lutil and -lbsd? In-Reply-To: <20011101094532.A3579@yorktown.isdn.uiuc.edu> Message-ID: On Thu, 1 Nov 2001, Mark D. Roth wrote: > On Tue Oct 30 20:10 2001 -0800, Tim Rice wrote: > > @@ -619,7 +616,13 @@ > > AC_CHECK_FUNCS(gettimeofday time) > > dnl Checks for libutil functions > > AC_CHECK_HEADERS(libutil.h) > > -AC_CHECK_FUNCS(login logout updwtmp logwtmp) > > +AC_CHECK_FUNC(login, > > + [AC_DEFINE(HAVE_LOGIN)], > > + [AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LOGIN) LIBS="$LIBS -lutil", > > + [AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])] > > + )] > > +) > > +AC_CHECK_FUNCS(logout updwtmp logwtmp) > > dnl Checks for utmp functions > > AC_CHECK_FUNCS(endutent getutent getutid getutline pututline setutent) > > AC_CHECK_FUNCS(utmpname) > > Just a minor stylistic comment: Wouldn't it be a bit cleaner to just > use this? > > AC_SEARCH_LIBS(login, util bsd, [AC_DEFINE(HAVE_LOGIN)]) Yes it would be cleaner. Thanks. (Maybe it's time to post a list of macros on the wall) :-) I'll commit these changes this weekend unless I hear it breaks somewhere. > > Of course, if I'm missing something, feel free to flog me with a large > trout... ;) > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From Nicolas.Williams at ubsw.com Fri Nov 2 04:58:48 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 1 Nov 2001 12:58:48 -0500 Subject: OpenStep (NeXT) and TTY modes In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Nov 01, 2001 at 10:37:20AM -0600 References: <20011101112540.V5739@sm2p1386swk.wdr.com> Message-ID: <20011101125847.W5739@sm2p1386swk.wdr.com> For what it's worth. People first noticed this problem here a while ago, about a year even. We found another problem with OpenSSH and OpenStep, more recently, which we've reported to Apple: when running sshd standalone (not from inetd), machines panic and then hang on reboot. Go figure. We don't know what causes it. The workaround is to kill sshd before rebooting or run sshd out of inetd. Again, this is white NeXT we're talking about (OS 4.2, w/ y2k patches, on x86 hw). Nico On Thu, Nov 01, 2001 at 10:37:20AM -0600, mouring at etoh.eviladmin.org wrote: > > Hmm.. Baseline OpenStep 4.2 on NeXT Black Slab with the meger y2k patches > put out before it transformed into Mac OS X. > > I've not touched an OpenStep 4.2 White box in almost 4 years. > > Still seems odd that they would react so differently, and yet no one else > I've talked to running NeXT 3.x to OpenStep 4.x from x86 to Sparc has > complained in over a year. > > Can I get a few other people in the NeXT world that are still hanging > around to give comments on this please? Mainly those with x86, but anyone > with HP, Sparc, or m68k comment if this causes any odd effects (check 'su' > and 'telnet' of the box.. it has been an issue in the past before we moved > to readpassphrase() on some NeXT versions). > > I'm still about a month out until I can put my Slab back into working > order. > > - Ben > > On Thu, 1 Nov 2001, Nicolas Williams wrote: > > > Without those flags being set we get: a) no echo, b) no CR. > > > > The command that fixes the problem is "stty -nl echo". > > > > Perhaps there's something different about your OpenStep systems and > > ours? (apart from the hw -- we use x86 hw). > > > > Nico > > > > > > On Thu, Nov 01, 2001 at 09:25:06AM -0600, mouring at etoh.eviladmin.org wrote: > > > > > > I have to ask since I did the core NeXT work.. What issues are you seeing > > > that adding the below 3 lines fix? > > > > > > I've been using the NeXT (OpenStep 4.2 and NeXTStep 3.3 on Black hardware) > > > for about a year now without noticing any abnormal issues. > > > > > > - Ben > > > > > > On Wed, 31 Oct 2001, Nicolas Williams wrote: > > > > > > > Ok, the correct modes to add, before parsing the client-sent tty modes, > > > > are: > > > > > > > > #ifdef HAVE_NEXT > > > > tio.c_oflag |= ONLCR; > > > > tio.c_lflag |= ECHO; > > > > tio.c_iflag |= ICRNL; > > > > #endif /* HAVE_NEXT */ > > > > > > > > We've tested this change and find that it fixes the problem with tty > > > > modes on OpenStep. > > > > > > > > Nico > > > > > > > > > > > > On Wed, Oct 31, 2001 at 02:38:24PM -0500, Nicolas Williams wrote: > > > > > OpenStep, apparently, does not initialize new pty/tty modes to a sane > > > > > default. > > > > > > > > > > I'm thinking this code snippet, added to tty_parse_modes() before the > > > > > for(;;) loop should suffice: > > > > > > > > > > #ifdef HAVE_NEXT > > > > > tio.c_oflag |= ONLCR; > > > > > tio.c_lflag |= ECHO; > > > > > #endif /* HAVE_NEXT */ > > > > > > > > > > Also, I've noticed that "ssh -t next_host stty" gives different output > > > > > than an interactive session to the same NeXT... I suspect that this > > > > > means that the SSH client is sending a different set of tty modes to the > > > > > sshd on the NeXT... Is that so? Does that make sense? > > > > > > > > > > Cheers, > > > > > > > > > > Nico > > > > > -- > > > > > > > > > > Visit our website at http://www.ubswarburg.com > > > > > > > > > > This message contains confidential information and is intended only > > > > > for the individual named. If you are not the named addressee you > > > > > should not disseminate, distribute or copy this e-mail. Please > > > > > notify the sender immediately by e-mail if you have received this > > > > > e-mail by mistake and delete this e-mail from your system. > > > > > > > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > > > > as information could be intercepted, corrupted, lost, destroyed, > > > > > arrive late or incomplete, or contain viruses. The sender therefore > > > > > does not accept liability for any errors or omissions in the contents > > > > > of this message which arise as a result of e-mail transmission. If > > > > > verification is required please request a hard-copy version. This > > > > > message is provided for informational purposes and should not be > > > > > construed as a solicitation or offer to buy or sell any securities or > > > > > related financial instruments. > > > > -- > > > > > > > > Visit our website at http://www.ubswarburg.com > > > > > > > > This message contains confidential information and is intended only > > > > for the individual named. If you are not the named addressee you > > > > should not disseminate, distribute or copy this e-mail. Please > > > > notify the sender immediately by e-mail if you have received this > > > > e-mail by mistake and delete this e-mail from your system. > > > > > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > > > as information could be intercepted, corrupted, lost, destroyed, > > > > arrive late or incomplete, or contain viruses. The sender therefore > > > > does not accept liability for any errors or omissions in the contents > > > > of this message which arise as a result of e-mail transmission. If > > > > verification is required please request a hard-copy version. This > > > > message is provided for informational purposes and should not be > > > > construed as a solicitation or offer to buy or sell any securities or > > > > related financial instruments. > > > > > > > > > > -- > > > > Visit our website at http://www.ubswarburg.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately by e-mail if you have received this > > e-mail by mistake and delete this e-mail from your system. > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. The sender therefore > > does not accept liability for any errors or omissions in the contents > > of this message which arise as a result of e-mail transmission. If > > verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any securities or > > related financial instruments. > > > > -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From tim at multitalents.net Fri Nov 2 05:08:31 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 1 Nov 2001 10:08:31 -0800 (PST) Subject: OpenSSH-3.0p1-pre-CVS: configure.ac checks for login in -lutil and -lbsd? In-Reply-To: Message-ID: On Thu, 1 Nov 2001, Tim Rice wrote: > On Thu, 1 Nov 2001, Mark D. Roth wrote: > > > Just a minor stylistic comment: Wouldn't it be a bit cleaner to just > > use this? > > > > AC_SEARCH_LIBS(login, util bsd, [AC_DEFINE(HAVE_LOGIN)]) > > Yes it would be cleaner. Thanks. > (Maybe it's time to post a list of macros on the wall) :-) > > I'll commit these changes this weekend unless I hear it breaks somewhere. > Looking deeper I see that my patch broke the openpty test. Moving the login stuff up a bit fixes this. ------------------< cut >----------------- --- configure.ac.orig Sat Oct 27 10:45:37 2001 +++ configure.ac Thu Nov 1 09:58:22 2001 @@ -370,9 +370,6 @@ AC_CHECK_FUNC(getspnam, , AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen")) -AC_CHECK_FUNC(login, , - AC_CHECK_LIB(util, login, - AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil")) dnl zlib is required AC_ARG_WITH(zlib, @@ -426,6 +423,11 @@ [], [ AC_CHECK_LIB(c89, utimes, LIBS="$LIBS -lc89") ] ) +dnl Checks for libutil functions +AC_CHECK_HEADERS(libutil.h) +AC_SEARCH_LIBS(login, util bsd, [AC_DEFINE(HAVE_LOGIN)]) +AC_CHECK_FUNCS(logout updwtmp logwtmp) + AC_FUNC_STRFTIME # Checks for header files. @@ -617,9 +619,6 @@ dnl Checks for time functions AC_CHECK_FUNCS(gettimeofday time) -dnl Checks for libutil functions -AC_CHECK_HEADERS(libutil.h) -AC_CHECK_FUNCS(login logout updwtmp logwtmp) dnl Checks for utmp functions AC_CHECK_FUNCS(endutent getutent getutid getutline pututline setutent) AC_CHECK_FUNCS(utmpname) @@ -632,11 +631,6 @@ [AC_CHECK_LIB(s, getuserattr, [LIBS="$LIBS -ls"; AC_DEFINE(HAVE_GETUSERATTR)])] ) -AC_CHECK_FUNC(login, - [AC_DEFINE(HAVE_LOGIN)], - [AC_CHECK_LIB(bsd, login, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_LOGIN)])] -) - AC_CHECK_FUNC(daemon, [AC_DEFINE(HAVE_DAEMON)], [AC_CHECK_LIB(bsd, daemon, [LIBS="$LIBS -lbsd"; AC_DEFINE(HAVE_DAEMON)])] ------------------< end cut >----------------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Fri Nov 2 05:16:27 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 1 Nov 2001 10:16:27 -0800 (PST) Subject: Authentication Problem In-Reply-To: Message-ID: On Thu, 1 Nov 2001, Deniz CEVIK wrote: > Hi, > > Recently, I have upgraded ssh to version 2.2.9p2 on redhat 6.2. After the > installation, I started to couldn't connect server via ssh. I am getting > password incorrect messages although password is correct. How can I solve > this problem. What configure options did you use? Did you enable pam? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From Darren.Moffat at eng.sun.com Fri Nov 2 06:54:56 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Thu, 1 Nov 2001 11:54:56 -0800 (PST) Subject: 2.9.9p2 and Solaris-2.8 PAM: Cannot delete credentials[7]: Permission denied Message-ID: <200111011954.fA1JsuSI619243@jurassic.eng.sun.com> >Darren, can you tell us why Sun decided to implement >pam_sm_setcred(PAM_DELETE_CRED) the way they did in pam_unix.so? >Shouldn't keylogout be run for PAM_USER and not the euid of the caller? This was because of a limitation in the internal API between libnsl and keyserv at the time pam_unix was written, this limitation has only recenly gone away. This will probably be fixed in the next release of Solaris but it is not easy for us to backport it as a patch at this time (due to the nature of the changes). -- Darren J Moffat From djm at mindrot.org Fri Nov 2 08:34:16 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 2 Nov 2001 08:34:16 +1100 (EST) Subject: Problem compiling 2.9.9p2 on Sol 2.6 In-Reply-To: Message-ID: On Thu, 1 Nov 2001, Ed Phillips wrote: > Look for FIXPATHSCMD in the Makefile and you can see where it is run. > > Anyway, it looks like the problem is actually got something to do with the > fact that "PERL" didn't get set when I ran configure (even though you > can't even run configure without it). Could it be that PERL is not > getting set correctly if it's not in /usr/bin/perl? It won?t get found it is isn?t in your $PATH. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From bbense at networking.stanford.edu Fri Nov 2 09:26:31 2001 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Thu, 1 Nov 2001 14:26:31 -0800 (PST) Subject: Patch to auth-krb4.c In-Reply-To: Message-ID: - In the MIT k4 emulation libraries that come with version 1.2.* of the MIT src code there is an internal check that the owner of a tkt and the owner of a process must match in order for the library calls to succeed. This is a change from older versions of the code and the kth libraries. -Basically what happens is that auth_krb4_password does the chown on the credentials before it is through with them. In order for the MIT k4 emulation libraries to work correctly, this chown[1] must be delayed until after the tkt is verified against the local srvtab. I'm not sure why the chown is where it is anyway. Unless the verification succeeds, the tkt is destroyed. So, this patch won't change any behaviour with current kerberos libraries and will make the code compatible with the MIT K5 src code. - While the current version of openssl and MIT K5 are incompatible out of the box, this won't be true with openssl.0.9.7. To make this work locally, I've hacked the MIT des425 libraries. - Booker C. Bense [1]- Login.krb5 in the new k5 src tree goes to great lengths to avoid chowning tkt files. There is some subtle race condition here that I don't understand well enough to know whether sshd is vulnerable. -------------- next part -------------- Index: auth-krb4.c =================================================================== RCS file: /afs/ir/dev/cvs/kerberos/openssh/auth-krb4.c,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- auth-krb4.c 2001/10/01 18:18:44 1.1.1.1 +++ auth-krb4.c 2001/11/01 22:01:51 1.3 @@ -122,12 +122,18 @@ r = krb_get_pw_in_tkt((char *) pw->pw_name, "", realm, "krbtgt", realm, DEFAULT_TKT_LIFE, (char *)password); if (r != INTK_OK) { - debug("Kerberos v4 password authentication for %s " - "failed: %s", pw->pw_name, krb_err_txt[r]); + debug("Kerberos v4 password authentication for %s@%s " + "failed: %s", pw->pw_name, realm, krb_err_txt[r]); goto failure; } + + /* In the MIT K5 k4 emulation libraries, the uid of the process + must match the uid of the owner of the tkt file or the library + calls will fail. This is a change from both kth and the older + cygnus code. This means the chown must happen after any verfication. + */ /* Successful authentication. */ - chown(tkt_string(), pw->pw_uid, pw->pw_gid); + /* chown(tkt_string(), pw->pw_uid, pw->pw_gid); */ /* * Now that we have a TGT, try to get a local @@ -182,6 +188,7 @@ goto failure; } /* Authentication succeeded. */ + chown(tkt_string(), pw->pw_uid, pw->pw_gid); return (1); } else /* Logging in as root or no local Kerberos realm. */ From deniz at intellect.com.tr Fri Nov 2 18:50:44 2001 From: deniz at intellect.com.tr (Deniz CEVIK) Date: Fri, 2 Nov 2001 09:50:44 +0200 Subject: Authentication Problem In-Reply-To: Message-ID: Hi, Configuration file like below. I also copied sshd.pam.generic file to pam.d directory as /etc/pam.d/sshd. Where can I enable pam authentication. Thanks. # $OpenBSD: sshd_config,v 1.42 2001/09/20 20:57:51 mouring Exp $ # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin # This is the sshd server system-wide configuration file. See sshd(8) # for more information. Port 22 #Protocol 2,1 #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 HostKey /usr/local/etc/ssh_host_key # HostKeys for protocol version 2 HostKey /usr/local/etc/ssh_host_rsa_key HostKey /usr/local/etc/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key KeyRegenerationInterval 3600 ServerKeyBits 768 # Logging SyslogFacility AUTH LogLevel INFO #obsoletes QuietMode and FascistLogging # Authentication: LoginGraceTime 600 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # rhosts authentication should not be used RhostsAuthentication no # Don't read the user's ~/.rhosts and ~/.shosts files IgnoreRhosts yes # For this to work you will also need host keys in /usr/local/etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication #IgnoreUserKnownHosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes PermitEmptyPasswords no # Uncomment to disable s/key passwords #ChallengeResponseAuthentication no # Uncomment to enable PAM keyboard-interactive authentication # Warning: enabling this may bypass the setting of 'PasswordAuthentication' #PAMAuthenticationViaKbdInt yes # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes X11Forwarding no X11DisplayOffset 10 PrintMotd yes #PrintLastLog no KeepAlive yes UseLogin yes #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp /usr/local/libexec/sftp-server -----Original Message----- From: Tim Rice [mailto:tim at multitalents.net] Sent: 01 Kasym 2001 Per?embe 20:16 To: Deniz CEVIK Cc: OpenSSH Development Subject: Re: Authentication Problem On Thu, 1 Nov 2001, Deniz CEVIK wrote: > Hi, > > Recently, I have upgraded ssh to version 2.2.9p2 on redhat 6.2. After the > installation, I started to couldn't connect server via ssh. I am getting > password incorrect messages although password is correct. How can I solve > this problem. What configure options did you use? Did you enable pam? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From jochen at remote.org Fri Nov 2 22:29:34 2001 From: jochen at remote.org (Jochen Topf) Date: Fri, 2 Nov 2001 12:29:34 +0100 Subject: su/sudo using ssh auth Message-ID: <20011102122934.A9120@eldorado.remote.org> To the openssh and sudo developer mailing lists: Ssh has a key agent allowing authentication to remote hosts without entering your password/passphrase again and again, which is very convenient. I think the 'su', 'sudo', and similiar commands could benefit from this idea and mechanism. I don't have the necessary expertise in cryptology to do this myself so I just want to throw this into the diskussion. If programs like 'su' und 'sudo' could be extended to use the ssh-agent a 'su-authorized-keys' file in the homedir of root would be enough to become root or any other user with any key in that file. For 'sudo' a similar mechanism could be used. With existing ssh software I can, of course, put my key into root's authorized_keys file and ssh to 'root at localhost', but this is an unnecessary roundabout route, conflicts with policies disallowing remote root logins and doesn't give me access to other accounts (like 'news' or user accounts) I want to 'su' to. Any ideas how this could be accomplished? Jochen -- Jochen Topf - jochen at remote.org - http://www.remote.org/jochen/ From tim at multitalents.net Sat Nov 3 02:11:33 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 2 Nov 2001 07:11:33 -0800 (PST) Subject: Authentication Problem In-Reply-To: Message-ID: On Fri, 2 Nov 2001, Deniz CEVIK wrote: > Hi, > > Configuration file like below. I also copied sshd.pam.generic file to pam.d > directory as /etc/pam.d/sshd. > Where can I enable pam authentication. > When you ran configure, did you use the --with-pam option? [snip] > On Thu, 1 Nov 2001, Deniz CEVIK wrote: > > > Hi, > > > > Recently, I have upgraded ssh to version 2.2.9p2 on redhat 6.2. After the > > installation, I started to couldn't connect server via ssh. I am getting > > password incorrect messages although password is correct. How can I solve > > this problem. > > What configure options did you use? > Did you enable pam? > > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From LKoehntop at dakcl.com Sat Nov 3 02:32:31 2001 From: LKoehntop at dakcl.com (Koehntop, Lucas) Date: Fri, 2 Nov 2001 09:32:31 -0600 Subject: su/sudo using ssh auth Message-ID: You could also try using the Kerberos auth methods as well. This would let you do what you want. Lucas Koehntop -----Original Message----- From: sudo-workers-admin at courtesan.com [mailto:sudo-workers-admin at courtesan.com] On Behalf Of Jochen Topf Sent: Friday, November 02, 2001 5:30 AM To: sudo-workers at courtesan.com; openssh-unix-dev at mindrot.org Subject: su/sudo using ssh auth To the openssh and sudo developer mailing lists: Ssh has a key agent allowing authentication to remote hosts without entering your password/passphrase again and again, which is very convenient. I think the 'su', 'sudo', and similiar commands could benefit from this idea and mechanism. I don't have the necessary expertise in cryptology to do this myself so I just want to throw this into the diskussion. If programs like 'su' und 'sudo' could be extended to use the ssh-agent a 'su-authorized-keys' file in the homedir of root would be enough to become root or any other user with any key in that file. For 'sudo' a similar mechanism could be used. With existing ssh software I can, of course, put my key into root's authorized_keys file and ssh to 'root at localhost', but this is an unnecessary roundabout route, conflicts with policies disallowing remote root logins and doesn't give me access to other accounts (like 'news' or user accounts) I want to 'su' to. Any ideas how this could be accomplished? Jochen -- Jochen Topf - jochen at remote.org - http://www.remote.org/jochen/ ____________________________________________________________ sudo-workers mailing list For list information, options, or to unsubscribe, visit: http://www.courtesan.com/mailman/listinfo/sudo-workers From jhein at timing.com Sat Nov 3 02:44:52 2001 From: jhein at timing.com (John E Hein) Date: Fri, 2 Nov 2001 08:44:52 -0700 Subject: su/sudo using ssh auth In-Reply-To: <20011102122934.A9120@eldorado.remote.org> References: <20011102122934.A9120@eldorado.remote.org> Message-ID: <15330.49012.312477.96560@brain.timing.com> Jochen Topf wrote at 12:29 +0100 on Nov 2: > To the openssh and sudo developer mailing lists: > > Ssh has a key agent allowing authentication to remote hosts without > entering your password/passphrase again and again, which is very > convenient. I think the 'su', 'sudo', and similiar commands could benefit > from this idea and mechanism. I don't have the necessary expertise in > cryptology to do this myself so I just want to throw this into the > diskussion. If programs like 'su' und 'sudo' could be extended to use > the ssh-agent a 'su-authorized-keys' file in the homedir of root would > be enough to become root or any other user with any key in that file. > For 'sudo' a similar mechanism could be used. > > With existing ssh software I can, of course, put my key into root's > authorized_keys file and ssh to 'root at localhost', but this is an > unnecessary roundabout route, conflicts with policies disallowing remote > root logins and doesn't give me access to other accounts (like 'news' > or user accounts) I want to 'su' to. > > Any ideas how this could be accomplished? I, too, would like this feature. I emailed the sudo-workers list back in June (see Subject: sudo-agent). Some day, I'll get around to writing sudo-agent. From Todd.Miller at courtesan.com Sat Nov 3 04:55:43 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Fri, 02 Nov 2001 10:55:43 -0700 Subject: su/sudo using ssh auth In-Reply-To: Your message of "Fri, 02 Nov 2001 12:29:34 +0100." <20011102122934.A9120@eldorado.remote.org> References: <20011102122934.A9120@eldorado.remote.org> Message-ID: <200111021755.fA2HthS2024471@xerxes.courtesan.com> I have resisted doing this because I really think it is pointless. The only reason sudo authenticates at all is to guard against a lack of physical security. Using the ssh agent would not protect against thins since the passphrase is only entered once. If you don't want to enter a password in sudo, just turn off authentication and rely on whatever method was used to login. - todd From jhein at timing.com Sat Nov 3 06:00:41 2001 From: jhein at timing.com (John E Hein) Date: Fri, 2 Nov 2001 12:00:41 -0700 Subject: su/sudo using ssh auth In-Reply-To: <200111021755.fA2HthS2024471@xerxes.courtesan.com> References: <20011102122934.A9120@eldorado.remote.org> <200111021755.fA2HthS2024471@xerxes.courtesan.com> Message-ID: <15330.60761.648539.59452@brain.timing.com> Todd C. Miller wrote at 10:55 -0700 on Nov 2: > I have resisted doing this because I really think it is pointless. > > The only reason sudo authenticates at all is to guard against a > lack of physical security. Using the ssh agent would not protect > against thins since the passphrase is only entered once. If you > don't want to enter a password in sudo, just turn off authentication > and rely on whatever method was used to login. But I do want to have to enter a password, for instance, at the start of a long running build script that needs to occasionally have root privs at a number of strategic points in the script to do some building in a chroot or mount a flash device. When the script ends (successfully or otherwise), the sudo credential for the script and its children would go away. Without such a feature (and without turning off sudo authentication), one would have to periodically revisit the script and re-enter one's password. I hope this example illustrates the utility of a sudo-agent type of feature. An authentication more fine grained than login level authentication is desired. As someone suggested, Kerberos tickets might be a good way to go - I've never used them. From Todd.Miller at courtesan.com Sat Nov 3 06:28:36 2001 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Fri, 02 Nov 2001 12:28:36 -0700 Subject: su/sudo using ssh auth In-Reply-To: Your message of "Fri, 02 Nov 2001 12:00:41 MST." <15330.60761.648539.59452@brain.timing.com> References: <20011102122934.A9120@eldorado.remote.org> <200111021755.fA2HthS2024471@xerxes.courtesan.com> <15330.60761.648539.59452@brain.timing.com> Message-ID: <200111021928.fA2JSaS2019567@xerxes.courtesan.com> Sorry, I still don't see the point and have no plans to add support for this. - todd From rwp at hprwp.fc.hp.com Sat Nov 3 07:17:08 2001 From: rwp at hprwp.fc.hp.com (Bob Proulx) Date: Fri, 2 Nov 2001 13:17:08 -0700 (MST) Subject: su/sudo using ssh auth In-Reply-To: <15330.60761.648539.59452@brain.timing.com> References: <20011102122934.A9120@eldorado.remote.org> <200111021755.fA2HthS2024471@xerxes.courtesan.com> <15330.60761.648539.59452@brain.timing.com> Message-ID: <15330.65348.462485.900524@hprwp.fc.hp.com> > But I do want to have to enter a password, for instance, at the start of > a long running build script that needs to occasionally have root > privs at a number of strategic points in the script to do some > building in a chroot or mount a flash device. How long is long running? You could always increase the time for remembering that a password was entered to be long enough to cover the needed time interval. What commands are you running? You could always specify an interface of okayed commands in sudoers where no password is ever required. If those commands are okay to run then they are okay to run. Mounting and unmounting are prime examples. Bob From ed at UDel.Edu Sat Nov 3 07:19:45 2001 From: ed at UDel.Edu (Ed Phillips) Date: Fri, 2 Nov 2001 15:19:45 -0500 (EST) Subject: Entropy and DSA keys Message-ID: I remember a discussion to the effect that using DSA keys in sshd increases the requirement for random bits available on the system... and that this requirement (was it a 128 bit random number per connection?) presents security problems on systems that don't have a decent source of entropy? Am I misinterpreting those discussions? We are having a problem deploying sshd (no prngd) where sshd refuses to start because it says theres not enough available entropy. Would disabling DSA in sshd prevent the system from becoming "entropy starved"? If I'm missing the point of the latest discussions, someone please correct me.... what was the real meaning of those discussions about using DSA keys in sshd? Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From jhein at timing.com Sat Nov 3 08:08:02 2001 From: jhein at timing.com (John E Hein) Date: Fri, 2 Nov 2001 14:08:02 -0700 Subject: su/sudo using ssh auth In-Reply-To: <15330.65348.462485.900524@hprwp.fc.hp.com> References: <20011102122934.A9120@eldorado.remote.org> <200111021755.fA2HthS2024471@xerxes.courtesan.com> <15330.60761.648539.59452@brain.timing.com> <15330.65348.462485.900524@hprwp.fc.hp.com> Message-ID: <15331.2866.389206.483485@brain.timing.com> Bob Proulx wrote at 13:17 -0700 on Nov 2: > > But I do want to have to enter a password, for instance, at the start of > > a long running build script that needs to occasionally have root > > privs at a number of strategic points in the script to do some > > building in a chroot or mount a flash device. > > How long is long running? You could always increase the time for > remembering that a password was entered to be long enough to cover the > needed time interval. Could be 1, could be 12, could be more hours; could be much less if it dies early. The timeout you mention is compiled in. > What commands are you running? You could always specify an interface > of okayed commands in sudoers where no password is ever required. If > those commands are okay to run then they are okay to run. Mounting > and unmounting are prime examples. rm, mount, cpio, etc., etc. I want these to be authenticated once for the parent process, then children who invoke sudo need not enter a password. I don't want carte blanche NOPASSWD in sudoers (which applies to the anyone running a sudo that uses that sudoers - usually per machine). Nor do I want to have to edit sudoers each time I add a command I want to run with sudo to this or some other script. This equates to a setuid program (except you need to get authenticated to run it) where the elevated effective uid is relinquished when it's not needed. There are some conceptual parallels to ssh-agent, but it's not quite the same thing (nor, as has been mentioned, should it be). From djm at mindrot.org Sat Nov 3 09:46:51 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 3 Nov 2001 09:46:51 +1100 (EST) Subject: Entropy and DSA key In-Reply-To: Message-ID: On Fri, 2 Nov 2001, Ed Phillips wrote: > I remember a discussion to the effect that using DSA keys in sshd > increases the requirement for random bits available on the system... and > that this requirement (was it a 128 bit random number per connection?) > presents security problems on systems that don't have a decent source of > entropy? Am I misinterpreting those discussions? > > We are having a problem deploying sshd (no prngd) where sshd refuses to > start because it says theres not enough available entropy. Would > disabling DSA in sshd prevent the system from becoming "entropy starved"? No, you should adjust ssh_prng_cmds to gather more entropy or pester your OS vendor for /dev/random. > If I'm missing the point of the latest discussions, someone please correct > me.... what was the real meaning of those discussions about using DSA keys > in sshd? Read WARNING.RNG -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From jochen at remote.org Sat Nov 3 18:41:07 2001 From: jochen at remote.org (Jochen Topf) Date: Sat, 3 Nov 2001 08:41:07 +0100 Subject: su/sudo using ssh auth In-Reply-To: <200111021755.fA2HthS2024471@xerxes.courtesan.com>; from "Todd C. Miller" on Fri, Nov 02, 2001 at 10:55:43AM -0700 References: <20011102122934.A9120@eldorado.remote.org> <200111021755.fA2HthS2024471@xerxes.courtesan.com> Message-ID: <20011103084107.A15920@eldorado.remote.org> Ok, first to make one point clear that maybe didn't come around in my first posting: I want *one* key-agent to work for 'ssh', 'su', and 'sudo' and similar programs. Thats the whole point. Having one authentication method would make things easier. Of course this is more complicated to do then just put something into 'su' or 'sudo', but thats why I send this to the ssh developers list, too. On Fri, Nov 02, 2001 at 10:55:43AM -0700, Todd C. Miller wrote: > I have resisted doing this because I really think it is pointless. > > The only reason sudo authenticates at all is to guard against a > lack of physical security. Using the ssh agent would not protect > against thins since the passphrase is only entered once. If you > don't want to enter a password in sudo, just turn off authentication > and rely on whatever method was used to login. Of course adding ssh-agent support to 'su' would be more helpful then for 'sudo', because 'sudo' already does this password caching thing. And I myself would be happy to have it for 'su' only, because I don't use 'sudo' all that much. But I think it still would be useful for 'sudo'. Two reasons: 1) I don't have a password any more on several accounts. I just log in through ssh with a key. The machines are far away anyways so I never log in at the console. The same thing applies to many accounts used for use by administrative scripts only. 2) If I want to automate a script that runs through several machines, using several accounts on each machine for different parts of the job this would be very handy. The whole idea is more of a convenience thing then something I absolutely need. Of course I can always use other methods. But this would allow me to get rid of the whole UNIX password stuff and only use ssh keys for authentication. Jochen -- Jochen Topf - jochen at remote.org - http://www.remote.org/jochen/ From lewis.muhlenkamp at motorola.com Sun Nov 4 03:37:21 2001 From: lewis.muhlenkamp at motorola.com (Lewis Muhlenkamp) Date: Sat, 03 Nov 2001 10:37:21 -0600 Subject: su/sudo using ssh auth References: <20011102122934.A9120@eldorado.remote.org> <200111021755.fA2HthS2024471@xerxes.courtesan.com> <20011103084107.A15920@eldorado.remote.org> Message-ID: <3BE41D41.177C7777@motorola.com> In a slightly more generic sense, I think what is being asked is for ssh, su, sudo, etc. to support Pluggable Authentication Modules (PAM). Does that make sense? I could see ssh-agent being made into a PAM module. I could see the above three use the ssh-agent PAM module, plus LDAP, NIS, etc. PAM modules for authentication. I think that would be a very good thing to have. On the flip side though, there would be a need to configure these tools appropriately. You would still probably want timeouts on commands run via sudo. That may now reside in the sudoers file, or in the pam.conf file. I think sudo already supports PAM. sudo authentication is done in the same fashion as a telnet. Thus, I do not think anything needs to be changed on sudo's side. I think turning ssh-agent into a PAM module, or at least providing the ssh server that capability, is what is really being asked here. Just my $0.02. Jochen Topf wrote: > > Ok, first to make one point clear that maybe didn't come around in my > first posting: I want *one* key-agent to work for 'ssh', 'su', and 'sudo' > and similar programs. Thats the whole point. Having one authentication > method would make things easier. Of course this is more complicated to > do then just put something into 'su' or 'sudo', but thats why I send this > to the ssh developers list, too. > > On Fri, Nov 02, 2001 at 10:55:43AM -0700, Todd C. Miller wrote: > > I have resisted doing this because I really think it is pointless. > > > > The only reason sudo authenticates at all is to guard against a > > lack of physical security. Using the ssh agent would not protect > > against thins since the passphrase is only entered once. If you > > don't want to enter a password in sudo, just turn off authentication > > and rely on whatever method was used to login. > > Of course adding ssh-agent support to 'su' would be more helpful then for > 'sudo', because 'sudo' already does this password caching thing. And I > myself would be happy to have it for 'su' only, because I don't use 'sudo' > all that much. But I think it still would be useful for 'sudo'. Two reasons: > > 1) I don't have a password any more on several accounts. I just log in > through ssh with a key. The machines are far away anyways so I never > log in at the console. The same thing applies to many accounts used > for use by administrative scripts only. > > 2) If I want to automate a script that runs through several machines, > using several accounts on each machine for different parts of the job > this would be very handy. > > The whole idea is more of a convenience thing then something I absolutely > need. Of course I can always use other methods. But this would allow me > to get rid of the whole UNIX password stuff and only use ssh keys for > authentication. -- ---------------------------------------------------------------------------- | Lewis Muhlenkamp | Network Systems Administrator | | Motorola, Inc. | phone: 847-538-4670 | | 1301 E. Algonquin Rd. | fax: 847-538-3630 | | Mailstop: IL02/2624 | email: lewis.muhlenkamp at motorola.com | | Schaumburg, IL 60196 | | ---------------------------------------------------------------------------- From jurgen at botz.org Sun Nov 4 06:08:51 2001 From: jurgen at botz.org (Jurgen Botz) Date: Sat, 03 Nov 2001 11:08:51 -0800 Subject: askpass for passwords? Message-ID: <7084.1004814531@nova.botz.org> Is there a particular reason the client can't use SSH_ASKPASS for passwords when using password authentication? This would seem to be useful when using ssh in scripted commands against servers that only allow password authentication. :j -- J?rgen Botz | While differing widely in the various jurgen at botz.org | little bits we know, in our infinite | ignorance we are all equal. -Karl Popper From wichert at wiggy.net Sun Nov 4 12:49:38 2001 From: wichert at wiggy.net (Wichert Akkerman) Date: Sun, 4 Nov 2001 02:49:38 +0100 Subject: OPIE patch for current CVS Message-ID: <20011104024938.A28279@wiggy.net> I redid my previous OPIE patch for the current ssh tree. It seems to work fine here, and I'ld love to see it merged before the 3.0 release. Wichert. diff -x CVS -wNur ../cvs/other/openssh_cvs/Makefile.in openssh_cvs/Makefile.in --- ../cvs/other/openssh_cvs/Makefile.in Mon Oct 22 02:53:59 2001 +++ openssh_cvs/Makefile.in Sun Nov 4 01:18:19 2001 @@ -50,7 +50,7 @@ SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o +SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o auth-opie.o MANPAGES = scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out MANPAGES_IN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 diff -x CVS -wNur ../cvs/other/openssh_cvs/acconfig.h openssh_cvs/acconfig.h --- ../cvs/other/openssh_cvs/acconfig.h Mon Oct 22 02:53:59 2001 +++ openssh_cvs/acconfig.h Sun Nov 4 01:34:28 2001 @@ -196,6 +196,9 @@ /* Define if you want S/Key support */ #undef SKEY +/* Define if you want OPIE support */ +#undef OPIE + /* Define if you want TCP Wrappers support */ #undef LIBWRAP diff -x CVS -wNur ../cvs/other/openssh_cvs/auth-opie.c openssh_cvs/auth-opie.c --- ../cvs/other/openssh_cvs/auth-opie.c Thu Jan 1 01:00:00 1970 +++ openssh_cvs/auth-opie.c Sun Nov 4 02:42:50 2001 @@ -0,0 +1,106 @@ +/* + * Copyright (c) 2001 Wichert Akkerman. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ +#include "includes.h" +RCSID("$Id"); + +#ifdef OPIE + +#include + +#include "xmalloc.h" +#include "auth.h" + +static void * +opie_init_ctx(Authctxt *authctxt) +{ + return authctxt; +} + +#define PROMPT "\nOPIE Password: " + +static int +opie_query(void *ctx, char **name, char **infotxt, + u_int* numprompts, char ***prompts, u_int **echo_on) +{ + Authctxt *authctxt = ctx; + char challenge[OPIE_CHALLENGE_MAX+64], *p; + int len; + struct opie opie; + + if (opiechallenge(&opie, authctxt->user, challenge) != 0) + return -1; + + opieverify(&opie, ""); /* Zap lock again */ + + *name = xstrdup(""); + *infotxt = xstrdup(""); + *numprompts = 1; + *prompts = xmalloc(*numprompts * sizeof(char*)); + *echo_on = xmalloc(*numprompts * sizeof(u_int)); + (*echo_on)[0] = 0; + + len = strlen(challenge) + strlen(PROMPT) + 1; + p = xmalloc(len); + p[0] = '\0'; + strlcat(p, challenge, len); + strlcat(p, PROMPT, len); + (*prompts)[0] = p; + + return 0; +} + +static int +opie_respond(void *ctx, u_int numresponses, char **responses) +{ + struct opie opie; + char challenge[OPIE_CHALLENGE_MAX]; + Authctxt *authctxt = ctx; + + if (opiechallenge(&opie, authctxt->user, challenge) != 0) + return -1; + + if (authctxt->valid && + numresponses == 1 && + opieverify(&opie, responses[0]) == 0) + return 0; + else + opieverify(&opie, ""); /* Always need to verify to keep locks + in sync */ + return -1; +} + +static void +opie_free_ctx(void *ctx) +{ + /* we don't have a special context */ +} + +KbdintDevice opie_device = { + "opie", + opie_init_ctx, + opie_query, + opie_respond, + opie_free_ctx +}; +#endif /* OPIE */ diff -x CVS -wNur ../cvs/other/openssh_cvs/auth2-chall.c openssh_cvs/auth2-chall.c --- ../cvs/other/openssh_cvs/auth2-chall.c Wed Oct 3 19:12:44 2001 +++ openssh_cvs/auth2-chall.c Sun Nov 4 01:25:57 2001 @@ -42,6 +42,10 @@ #else #ifdef SKEY extern KbdintDevice skey_device; +#else +#ifdef OPIE +extern KbdintDevice opie_device; +#endif #endif #endif @@ -51,6 +55,10 @@ #else #ifdef SKEY &skey_device, +#else +#ifdef OPIE + &opie_device, +#endif #endif #endif NULL diff -x CVS -wNur ../cvs/other/openssh_cvs/configure.ac openssh_cvs/configure.ac --- ../cvs/other/openssh_cvs/configure.ac Sat Oct 27 19:45:37 2001 +++ openssh_cvs/configure.ac Sun Nov 4 01:32:17 2001 @@ -514,6 +514,32 @@ ] ) +# Check whether user wants OPIE support +OPIE_MSG="no" +AC_ARG_WITH(opie, + [ --with-opie[[=PATH]] Enable OPIE support + (optionally in PATH)], + [ + if test "x$withval" != "xno" ; then + + if test "x$withval" != "xyes" ; then + CPPFLAGS="$CPPFLAGS -I${withval}/include" + LDFLAGS="$LDFLAGS -L${withval}/lib" + fi + + AC_DEFINE(OPIE) + LIBS="-lopie $LIBS" + OPIE_MSG="yes" + + AC_CHECK_FUNC(opiechallenge, + [], + [ + AC_MSG_ERROR([** Incomplete or missing OPIE libraries.]) + ]) + fi + ] +) + # Check whether user wants TCP wrappers support TCPW_MSG="no" AC_ARG_WITH(tcp-wrappers, @@ -2211,6 +2237,7 @@ echo " Smartcard support: $SCARD_MSG" echo " AFS support: $AFS_MSG" echo " S/KEY support: $SKEY_MSG" +echo " OPIE support: $OPIE_MSG" echo " TCP Wrappers support: $TCPW_MSG" echo " MD5 password support: $MD5_MSG" echo " IP address in \$DISPLAY hack: $DISPLAY_HACK_MSG" diff -x CVS -wNur ../cvs/other/openssh_cvs/readconf.c openssh_cvs/readconf.c --- ../cvs/other/openssh_cvs/readconf.c Wed Oct 3 19:39:39 2001 +++ openssh_cvs/readconf.c Sun Nov 4 01:44:19 2001 @@ -141,6 +141,7 @@ { "challengeresponseauthentication", oChallengeResponseAuthentication }, { "skeyauthentication", oChallengeResponseAuthentication }, /* alias */ { "tisauthentication", oChallengeResponseAuthentication }, /* alias */ + { "opieauthentication", oChallengeResponseAuthentication }, /* alias */ #if defined(KRB4) || defined(KRB5) { "kerberosauthentication", oKerberosAuthentication }, #endif diff -x CVS -wNur ../cvs/other/openssh_cvs/servconf.c openssh_cvs/servconf.c --- ../cvs/other/openssh_cvs/servconf.c Wed Sep 12 18:32:15 2001 +++ openssh_cvs/servconf.c Sun Nov 4 01:44:27 2001 @@ -286,6 +286,7 @@ { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, { "challengeresponseauthentication", sChallengeResponseAuthentication }, { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ + { "opieauthentication", sChallengeResponseAuthentication }, /* alias */ { "checkmail", sDeprecated }, { "listenaddress", sListenAddress }, { "printmotd", sPrintMotd }, -- _________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | wichert at wiggy.net http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From mouring at etoh.eviladmin.org Sun Nov 4 16:25:09 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 3 Nov 2001 23:25:09 -0600 (CST) Subject: OPIE patch for current CVS In-Reply-To: <20011104024938.A28279@wiggy.net> Message-ID: Sorry 3.0 feature set occured when OpenBSD 3.0 went to cd pressing. Sorry - Ben On Sun, 4 Nov 2001, Wichert Akkerman wrote: > > I redid my previous OPIE patch for the current ssh tree. It seems > to work fine here, and I'ld love to see it merged before the 3.0 > release. > > Wichert. > > > diff -x CVS -wNur ../cvs/other/openssh_cvs/Makefile.in openssh_cvs/Makefile.in > --- ../cvs/other/openssh_cvs/Makefile.in Mon Oct 22 02:53:59 2001 > +++ openssh_cvs/Makefile.in Sun Nov 4 01:18:19 2001 > @@ -50,7 +50,7 @@ > > SSHOBJS= ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o > > -SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o > +SSHDOBJS= sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o auth-opie.o > > MANPAGES = scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out > MANPAGES_IN = scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 > diff -x CVS -wNur ../cvs/other/openssh_cvs/acconfig.h openssh_cvs/acconfig.h > --- ../cvs/other/openssh_cvs/acconfig.h Mon Oct 22 02:53:59 2001 > +++ openssh_cvs/acconfig.h Sun Nov 4 01:34:28 2001 > @@ -196,6 +196,9 @@ > /* Define if you want S/Key support */ > #undef SKEY > > +/* Define if you want OPIE support */ > +#undef OPIE > + > /* Define if you want TCP Wrappers support */ > #undef LIBWRAP > > diff -x CVS -wNur ../cvs/other/openssh_cvs/auth-opie.c openssh_cvs/auth-opie.c > --- ../cvs/other/openssh_cvs/auth-opie.c Thu Jan 1 01:00:00 1970 > +++ openssh_cvs/auth-opie.c Sun Nov 4 02:42:50 2001 > @@ -0,0 +1,106 @@ > +/* > + * Copyright (c) 2001 Wichert Akkerman. All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in the > + * documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR > + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES > + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. > + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > +#include "includes.h" > +RCSID("$Id"); > + > +#ifdef OPIE > + > +#include > + > +#include "xmalloc.h" > +#include "auth.h" > + > +static void * > +opie_init_ctx(Authctxt *authctxt) > +{ > + return authctxt; > +} > + > +#define PROMPT "\nOPIE Password: " > + > +static int > +opie_query(void *ctx, char **name, char **infotxt, > + u_int* numprompts, char ***prompts, u_int **echo_on) > +{ > + Authctxt *authctxt = ctx; > + char challenge[OPIE_CHALLENGE_MAX+64], *p; > + int len; > + struct opie opie; > + > + if (opiechallenge(&opie, authctxt->user, challenge) != 0) > + return -1; > + > + opieverify(&opie, ""); /* Zap lock again */ > + > + *name = xstrdup(""); > + *infotxt = xstrdup(""); > + *numprompts = 1; > + *prompts = xmalloc(*numprompts * sizeof(char*)); > + *echo_on = xmalloc(*numprompts * sizeof(u_int)); > + (*echo_on)[0] = 0; > + > + len = strlen(challenge) + strlen(PROMPT) + 1; > + p = xmalloc(len); > + p[0] = '\0'; > + strlcat(p, challenge, len); > + strlcat(p, PROMPT, len); > + (*prompts)[0] = p; > + > + return 0; > +} > + > +static int > +opie_respond(void *ctx, u_int numresponses, char **responses) > +{ > + struct opie opie; > + char challenge[OPIE_CHALLENGE_MAX]; > + Authctxt *authctxt = ctx; > + > + if (opiechallenge(&opie, authctxt->user, challenge) != 0) > + return -1; > + > + if (authctxt->valid && > + numresponses == 1 && > + opieverify(&opie, responses[0]) == 0) > + return 0; > + else > + opieverify(&opie, ""); /* Always need to verify to keep locks > + in sync */ > + return -1; > +} > + > +static void > +opie_free_ctx(void *ctx) > +{ > + /* we don't have a special context */ > +} > + > +KbdintDevice opie_device = { > + "opie", > + opie_init_ctx, > + opie_query, > + opie_respond, > + opie_free_ctx > +}; > +#endif /* OPIE */ > diff -x CVS -wNur ../cvs/other/openssh_cvs/auth2-chall.c openssh_cvs/auth2-chall.c > --- ../cvs/other/openssh_cvs/auth2-chall.c Wed Oct 3 19:12:44 2001 > +++ openssh_cvs/auth2-chall.c Sun Nov 4 01:25:57 2001 > @@ -42,6 +42,10 @@ > #else > #ifdef SKEY > extern KbdintDevice skey_device; > +#else > +#ifdef OPIE > +extern KbdintDevice opie_device; > +#endif > #endif > #endif > > @@ -51,6 +55,10 @@ > #else > #ifdef SKEY > &skey_device, > +#else > +#ifdef OPIE > + &opie_device, > +#endif > #endif > #endif > NULL > diff -x CVS -wNur ../cvs/other/openssh_cvs/configure.ac openssh_cvs/configure.ac > --- ../cvs/other/openssh_cvs/configure.ac Sat Oct 27 19:45:37 2001 > +++ openssh_cvs/configure.ac Sun Nov 4 01:32:17 2001 > @@ -514,6 +514,32 @@ > ] > ) > > +# Check whether user wants OPIE support > +OPIE_MSG="no" > +AC_ARG_WITH(opie, > + [ --with-opie[[=PATH]] Enable OPIE support > + (optionally in PATH)], > + [ > + if test "x$withval" != "xno" ; then > + > + if test "x$withval" != "xyes" ; then > + CPPFLAGS="$CPPFLAGS -I${withval}/include" > + LDFLAGS="$LDFLAGS -L${withval}/lib" > + fi > + > + AC_DEFINE(OPIE) > + LIBS="-lopie $LIBS" > + OPIE_MSG="yes" > + > + AC_CHECK_FUNC(opiechallenge, > + [], > + [ > + AC_MSG_ERROR([** Incomplete or missing OPIE libraries.]) > + ]) > + fi > + ] > +) > + > # Check whether user wants TCP wrappers support > TCPW_MSG="no" > AC_ARG_WITH(tcp-wrappers, > @@ -2211,6 +2237,7 @@ > echo " Smartcard support: $SCARD_MSG" > echo " AFS support: $AFS_MSG" > echo " S/KEY support: $SKEY_MSG" > +echo " OPIE support: $OPIE_MSG" > echo " TCP Wrappers support: $TCPW_MSG" > echo " MD5 password support: $MD5_MSG" > echo " IP address in \$DISPLAY hack: $DISPLAY_HACK_MSG" > diff -x CVS -wNur ../cvs/other/openssh_cvs/readconf.c openssh_cvs/readconf.c > --- ../cvs/other/openssh_cvs/readconf.c Wed Oct 3 19:39:39 2001 > +++ openssh_cvs/readconf.c Sun Nov 4 01:44:19 2001 > @@ -141,6 +141,7 @@ > { "challengeresponseauthentication", oChallengeResponseAuthentication }, > { "skeyauthentication", oChallengeResponseAuthentication }, /* alias */ > { "tisauthentication", oChallengeResponseAuthentication }, /* alias */ > + { "opieauthentication", oChallengeResponseAuthentication }, /* alias */ > #if defined(KRB4) || defined(KRB5) > { "kerberosauthentication", oKerberosAuthentication }, > #endif > diff -x CVS -wNur ../cvs/other/openssh_cvs/servconf.c openssh_cvs/servconf.c > --- ../cvs/other/openssh_cvs/servconf.c Wed Sep 12 18:32:15 2001 > +++ openssh_cvs/servconf.c Sun Nov 4 01:44:27 2001 > @@ -286,6 +286,7 @@ > { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, > { "challengeresponseauthentication", sChallengeResponseAuthentication }, > { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ > + { "opieauthentication", sChallengeResponseAuthentication }, /* alias */ > { "checkmail", sDeprecated }, > { "listenaddress", sListenAddress }, > { "printmotd", sPrintMotd }, > > -- > _________________________________________________________________ > / Nothing is fool-proof to a sufficiently talented fool \ > | wichert at wiggy.net http://www.liacs.nl/~wichert/ | > | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | > From Robert.Dahlem at siemens.com Mon Nov 5 01:18:00 2001 From: Robert.Dahlem at siemens.com (Robert Dahlem) Date: Sun, 04 Nov 2001 15:18:00 +0100 Subject: Slow connection performance with ssh2 Message-ID: <200111041420.fA4EKvt15290@mail1.siemens.de> Hi, since I switched from SSH 1 to OpenSSH 2.9p2/2.9.9p2/3.0p1 Snapshot I suffer from awfully slow connection performance. Once the connection is established, performance is perfectly ok. Client Server (protocol 2 only) # time ssh -p 22222 xx id # time sshd -d -p 22222 real 0m13.340s real 0m13.900s user 0m7.860s user 0m7.530s sys 0m0.170s sys 0m0.240s Well, this is not the coolest hardware around and the problem is not really existent betweeen other machines with 4 SPARC III 64bit at 300 MHz. :-) The line between the machines operates at 2MBit/s and was nearly idle while testing. Its the same when both machines are on 100BaseT, so it seems to have to do with CPU consumption while doing the initial key exchange. I wrote myself a little program sniffing on the debug output and timestamping each line with the time difference to the previous line. I attached both and also tried to format the output. Here is the outcome: Client Server ============================================================================= Connecting to xx [x.x.x.x] port 22222. Allocated local port 994. Connection from y.y.y.y port 994 Client protocol version 2.0 ********* 4.430 seconds Client software version OpenSSH_3.0p1 Remote protocol version 1.99 remote software version OpenSSH_3.0p1 SSH2_MSG_KEXINIT sent SSH2_MSG_KEXINIT sent SSH2_MSG_KEXINIT received SSH2_MSG_KEXINIT received SSH2_MSG_KEX_DH_GEX_REQUEST sent SSH2_MSG_KEX_DH_GEX_REQUEST received expecting SSH2_MSG_KEX_DH_GEX_GROUP SSH2_MSG_KEX_DH_GEX_GROUP sent ********* 3.330 seconds ********* 3.39 seconds dh_gen_key: priv key bits set: 134/256 dh_gen_key: priv_key bits set: 126/256 bits set: 1573/3191 bits_set: 1582/3191 SSH2_MSG_KEX_DH_GEX_INIT sent expecting SSH2_MSG_KEX_DH_GEX_INIT expecting SSH2_MSG_KEX_DH_GEX_REPLY bits set: 1573/3191 ********* 4.260 seconds ********* 4.730 seconds SSH2_MSG_KEX_DH_GEX_REPLY sent check_host_in_hostfile kex_derive_keys Host 'xx' is known and matches RSA key newkeys: mode 1 bits set: 1582/3191 SSH2_MSG_NEWKEYS sent ********* 3.910 waiting for SSH2_MSG_NEWKEYS ssh_rsa_verify: signature correct kex_derive_keys newkeys: mode 1 SSH2_MSG_NEWKEYS sent waiting for SSH2_MSG_NEWKEYS ********* 4.110 newkeys: mode 0 newkeys: mode 0 SSH2_MSG_NEWKEYS received SSH2_MSG_NEWKEYS received done: ssh_kex2. KEX done I also tried apptrace: There is a total of 13248 library calls on the client side of which are 6641 to libcrypto.so.0.9.6:BN_is_bit_set() and 1905 to libc.so.1:malloc(). I'm pretty sure all this user time spent for generating and checking keys on the server and the client add together to the total real time, so client and server are nearly always waiting for the other end to finish its calculations. Is there any way to reduce the CPU cost of key generation and checking in the connection phase without sacrificing security? TIA for any hint (except those attempting to sell me some decent hardware :-). Regards, Robert -- Robert.Dahlem at siemens.com Siemens Business Services - FS GF KORDOBA-Outsourcing Tel: +49-69-797-6530 Fax: +49-69-797-6599 ---------------------------------------------------------------------- Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email software; far better than Outlook. Try it sometime. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 12742 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011104/2ea7f35f/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 8099 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011104/2ea7f35f/attachment-0001.obj From gert at greenie.muc.de Mon Nov 5 04:00:02 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 4 Nov 2001 18:00:02 +0100 Subject: Slow connection performance with ssh2 In-Reply-To: <200111041420.fA4EKvt15290@mail1.siemens.de>; from Robert Dahlem on Sun, Nov 04, 2001 at 03:18:00PM +0100 References: <200111041420.fA4EKvt15290@mail1.siemens.de> Message-ID: <20011104180002.A12040@greenie.muc.de> Hi, On Sun, Nov 04, 2001 at 03:18:00PM +0100, Robert Dahlem wrote: > SSH2_MSG_KEX_DH_GEX_REQUEST sent SSH2_MSG_KEX_DH_GEX_REQUEST received > expecting SSH2_MSG_KEX_DH_GEX_GROUP SSH2_MSG_KEX_DH_GEX_GROUP sent > ********* 3.330 seconds ********* 3.39 seconds > dh_gen_key: priv key bits set: 134/256 dh_gen_key: priv_key bits set: 126/256 I have noticed the same - it hangs at these points for a while: debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. debug: bits set: 1008/2049 debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. <2nd pause, shorter> debug: Got SSH2_MSG_KEXDH_REPLY. As my hardware is slower (Sparc LX, NetBSD, 50 MHz CPU) it takes more than 2 minutes (!!), which are spent on CPU cycles in ssh and sshd - running with 95% CPU... - the overall CPU time used by sshd for a successful connect is about 2:50 minutes ssh protocol 1 connects take about 5 seconds or so. Now my question to the experts: is this unavoidable? Or maybe a miscompilation of one of the algorithms used on the Sparc hardware? The openssh version I use is "SSH-1.99-OpenSSH_2.5.1 NetBSD_Secure_Shell-20010614" (which comes with NetBSD 1.5.2). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From gleblanc at linuxweasel.com Mon Nov 5 01:05:19 2001 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: 04 Nov 2001 09:05:19 -0500 Subject: Slow connection performance with ssh2 In-Reply-To: <20011104180002.A12040@greenie.muc.de> References: <200111041420.fA4EKvt15290@mail1.siemens.de> <20011104180002.A12040@greenie.muc.de> Message-ID: <1004882719.1723.20.camel@peecee> On Sun, 2001-11-04 at 12:00, Gert Doering wrote: > Hi, > > On Sun, Nov 04, 2001 at 03:18:00PM +0100, Robert Dahlem wrote: > > SSH2_MSG_KEX_DH_GEX_REQUEST sent SSH2_MSG_KEX_DH_GEX_REQUEST received > > expecting SSH2_MSG_KEX_DH_GEX_GROUP SSH2_MSG_KEX_DH_GEX_GROUP sent > > ********* 3.330 seconds ********* 3.39 seconds > > dh_gen_key: priv key bits set: 134/256 dh_gen_key: priv_key bits set: 126/256 > > I have noticed the same - it hangs at these points for a while: > > debug: Sending SSH2_MSG_KEX_DH_GEX_REQUEST. > debug: Wait SSH2_MSG_KEX_DH_GEX_GROUP. > debug: Got SSH2_MSG_KEX_DH_GEX_GROUP. > > debug: bits set: 1008/2049 > debug: Sending SSH2_MSG_KEX_DH_GEX_INIT. > debug: Wait SSH2_MSG_KEX_DH_GEX_REPLY. > <2nd pause, shorter> > debug: Got SSH2_MSG_KEXDH_REPLY. > > As my hardware is slower (Sparc LX, NetBSD, 50 MHz CPU) it takes more > than 2 minutes (!!), which are spent on CPU cycles in ssh and sshd - running > with 95% CPU... - the overall CPU time used by sshd for a successful > connect is about 2:50 minutes Older SPARCs in general are bloody slow at encryption operations. Try upgrading to 2.9.9p2, and make sure that you're -not- using DSA, as that's REALLY REALLY slow. Greg From gert at greenie.muc.de Mon Nov 5 05:29:55 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 4 Nov 2001 19:29:55 +0100 Subject: Slow connection performance with ssh2 In-Reply-To: <1004882719.1723.20.camel@peecee>; from Gregory Leblanc on Sun, Nov 04, 2001 at 09:05:19AM -0500 References: <200111041420.fA4EKvt15290@mail1.siemens.de> <20011104180002.A12040@greenie.muc.de> <1004882719.1723.20.camel@peecee> Message-ID: <20011104192955.A16077@greenie.muc.de> Hi, On Sun, Nov 04, 2001 at 09:05:19AM -0500, Gregory Leblanc wrote: > > As my hardware is slower (Sparc LX, NetBSD, 50 MHz CPU) it takes more > > than 2 minutes (!!), which are spent on CPU cycles in ssh and sshd - running > > with 95% CPU... - the overall CPU time used by sshd for a successful > > connect is about 2:50 minutes > > Older SPARCs in general are bloody slow at encryption operations. I know that :-) (still: ssh protocol 1 connects in less than 5 seconds). > Try upgrading to 2.9.9p2, and make sure that you're -not- using DSA, as > that's REALLY REALLY slow. I did disable DSA already (I removed the DSA host key (and restarted sshd), which should be sufficient, no?). Will try 2.9.9p2... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From datqtruong at yahoo.com Mon Nov 5 05:48:55 2001 From: datqtruong at yahoo.com (dat truong) Date: Sun, 4 Nov 2001 10:48:55 -0800 (PST) Subject: openssh-2.9.9p2 and kerberos 5 In-Reply-To: <7084.1004814531@nova.botz.org> Message-ID: <20011104184855.48728.qmail@web14509.mail.yahoo.com> does anyone know if openssh 2.9.9p2 works with kerberos 5? Pls let me know. thanks. -Dat __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com From mouring at etoh.eviladmin.org Mon Nov 5 08:16:04 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 4 Nov 2001 15:16:04 -0600 (CST) Subject: Slow connection performance with ssh2 In-Reply-To: <20011104192955.A16077@greenie.muc.de> Message-ID: If one read the SSH v2 specs they would realize more crypto work is being done in v2 upfront using D/H. Markus and others did improved it. A SS20 150mhz box connects at about 25 seconds. But when compared to my dual 533mhz it is slow (which is almost instant). I have a U10 over here which I'll be testing sometime this month, but there is not much one can do. Even v2 on NeXT Black slab (68k-25mhz) is slow. It would be intersting to benchmark SSH Corp and vshell on slow boxes to see where we stand, but I suspect they will be the same or we will be slightly faster. (We do have the best crypto people in OpenBSD, right Theo? =) - Ben On Sun, 4 Nov 2001, Gert Doering wrote: > Hi, > > On Sun, Nov 04, 2001 at 09:05:19AM -0500, Gregory Leblanc wrote: > > > As my hardware is slower (Sparc LX, NetBSD, 50 MHz CPU) it takes more > > > than 2 minutes (!!), which are spent on CPU cycles in ssh and sshd - running > > > with 95% CPU... - the overall CPU time used by sshd for a successful > > > connect is about 2:50 minutes > > > > Older SPARCs in general are bloody slow at encryption operations. > > I know that :-) (still: ssh protocol 1 connects in less than 5 seconds). > > > Try upgrading to 2.9.9p2, and make sure that you're -not- using DSA, as > > that's REALLY REALLY slow. > > I did disable DSA already (I removed the DSA host key (and restarted > sshd), which should be sufficient, no?). Will try 2.9.9p2... > > gert > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de > From djm at mindrot.org Mon Nov 5 08:49:45 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 5 Nov 2001 08:49:45 +1100 (EST) Subject: Slow connection performance with ssh2 In-Reply-To: Message-ID: On Sun, 4 Nov 2001 mouring at etoh.eviladmin.org wrote: > It would be intersting to benchmark SSH Corp and vshell on slow boxes to > see where we stand, but I suspect they will be the same or we will be > slightly faster. (We do have the best crypto people in OpenBSD, right > Theo? =) We will be slower than some other implementations because we support draft-ietf-secsh-dh-group-exchange-01.txt, which requires a fair bit of computation. You can trade connect speed for security by disabling this - delete or rename $sysconfdir/{primes,moduli} Using RSA keys for SSH2 authentication helps too. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From markus at openbsd.org Mon Nov 5 08:52:51 2001 From: markus at openbsd.org (Markus Friedl) Date: Sun, 4 Nov 2001 22:52:51 +0100 Subject: OPIE patch for current CVS In-Reply-To: <20011104024938.A28279@wiggy.net>; from wichert@wiggy.net on Sun, Nov 04, 2001 at 02:49:38AM +0100 References: <20011104024938.A28279@wiggy.net> Message-ID: <20011104225251.A24533@folly> On Sun, Nov 04, 2001 at 02:49:38AM +0100, Wichert Akkerman wrote: > > I redid my previous OPIE patch for the current ssh tree. It seems > to work fine here, and I'ld love to see it merged before the 3.0 > release. how different is this from skey? isn't this just a s/skey/opie/g ? From markus at openbsd.org Mon Nov 5 08:55:49 2001 From: markus at openbsd.org (Markus Friedl) Date: Sun, 4 Nov 2001 22:55:49 +0100 Subject: Slow connection performance with ssh2 In-Reply-To: <20011104192955.A16077@greenie.muc.de>; from gert@greenie.muc.de on Sun, Nov 04, 2001 at 07:29:55PM +0100 References: <200111041420.fA4EKvt15290@mail1.siemens.de> <20011104180002.A12040@greenie.muc.de> <1004882719.1723.20.camel@peecee> <20011104192955.A16077@greenie.muc.de> Message-ID: <20011104225549.B24533@folly> On Sun, Nov 04, 2001 at 07:29:55PM +0100, Gert Doering wrote: > Hi, > > On Sun, Nov 04, 2001 at 09:05:19AM -0500, Gregory Leblanc wrote: > > > As my hardware is slower (Sparc LX, NetBSD, 50 MHz CPU) it takes more > > > than 2 minutes (!!), which are spent on CPU cycles in ssh and sshd - running > > > with 95% CPU... - the overall CPU time used by sshd for a successful > > > connect is about 2:50 minutes > > > > Older SPARCs in general are bloody slow at encryption operations. > > I know that :-) (still: ssh protocol 1 connects in less than 5 seconds). so DH is probably slow on your machine. doing RSA twice seems faster. you could try to run $ openssl speed -m From markus at openbsd.org Mon Nov 5 08:56:41 2001 From: markus at openbsd.org (Markus Friedl) Date: Sun, 4 Nov 2001 22:56:41 +0100 Subject: askpass for passwords? In-Reply-To: <7084.1004814531@nova.botz.org>; from jurgen@botz.org on Sat, Nov 03, 2001 at 11:08:51AM -0800 References: <7084.1004814531@nova.botz.org> Message-ID: <20011104225641.C24533@folly> On Sat, Nov 03, 2001 at 11:08:51AM -0800, Jurgen Botz wrote: > Is there a particular reason the client can't use SSH_ASKPASS for > passwords when using password authentication? i assume you are using 2.9.9. it does use SSH_ASKPASS. From wichert at wiggy.net Mon Nov 5 09:01:42 2001 From: wichert at wiggy.net (Wichert Akkerman) Date: Sun, 4 Nov 2001 23:01:42 +0100 Subject: OPIE patch for current CVS In-Reply-To: <20011104225251.A24533@folly> References: <20011104024938.A28279@wiggy.net> <20011104225251.A24533@folly> Message-ID: <20011104230142.U28279@wiggy.net> Previously Markus Friedl wrote: > how different is this from skey? > isn't this just a s/skey/opie/g ? Not quite, there are a few different requirements with respect to generating the challenge and doing the verification. The code is quite similar though. s/key might actually have the same problem, but since I don't have it here and afaik it's unmaintained these days I haven't bothered to look into it. Wichert. -- _________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | wichert at wiggy.net http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | From sxw at dcs.ed.ac.uk Mon Nov 5 09:43:10 2001 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Sun, 4 Nov 2001 22:43:10 GMT Subject: openssh-2.9.9p2 and kerberos 5 In-Reply-To: dat truong's message of Sun, 4 Nov 2001 10:48:55 -0800 (PST) Message-ID: <200111042243.WAA07513@canna.dcs.ed.ac.uk> > does anyone know if openssh 2.9.9p2 works > with kerberos 5? Pls let me know. There is code in 2.9.9p2 to do Kerberos v5 over the version 1 protocol. This code doesn't compile by default on the portable version, and is Heimdal specific. I've got a set of patches (now completed, and being tested locally) which add a --with-kerberos5 option to ./configure to set this up for portable compliation, and include changes to support both MIT Kerberos and Heimdal. I hope to make these available shortly. In addition, my patches to add GSSAPI (and hence Kerberos v5) support to protocol version 2 should be updated to 2.9.9p2 at around the same point. (Probably just in time for the 3.0p1 release, knowing my luck) Cheers, Simon. From gert at greenie.muc.de Mon Nov 5 19:11:29 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 5 Nov 2001 09:11:29 +0100 Subject: Slow connection performance with ssh2 In-Reply-To: <20011104225549.B24533@folly>; from Markus Friedl on Sun, Nov 04, 2001 at 10:55:49PM +0100 References: <200111041420.fA4EKvt15290@mail1.siemens.de> <20011104180002.A12040@greenie.muc.de> <1004882719.1723.20.camel@peecee> <20011104192955.A16077@greenie.muc.de> <20011104225549.B24533@folly> Message-ID: <20011105091129.B5302@greenie.muc.de> Hi, On Sun, Nov 04, 2001 at 10:55:49PM +0100, Markus Friedl wrote: > > [ssh protocol 1: 5 s, protocol 2: over 2 minutes ] > > so DH is probably slow on your machine. doing RSA twice > seems faster. you could try to run > $ openssl speed OK, here we go (I reduced the lengthy output to those that seemed "the necessary ones", if I missed some, plese tell me)... Doing 512 bit private rsa's for 10s: 22 512 bit private RSA's in 10.30s Doing 512 bit public rsa's for 10s: 180 512 bit public RSA's in 9.90s Doing 1024 bit private rsa's for 10s: 4 1024 bit private RSA's in 12.45s Doing 1024 bit public rsa's for 10s: 51 1024 bit public RSA's in 9.92s Doing 2048 bit private rsa's for 10s: 1 2048 bit private RSA's in 21.92s Doing 2048 bit public rsa's for 10s: 14 2048 bit public RSA's in 10.70s Doing 512 bit sign dsa's for 10s: 19 512 bit DSA signs in 10.13s Doing 512 bit verify dsa's for 10s: 12 512 bit DSA verify in 8.60s Doing 1024 bit sign dsa's for 10s: 6 1024 bit DSA signs in 10.96s Doing 1024 bit verify dsa's for 10s: 5 1024 bit DSA verify in 11.14s Doing 2048 bit sign dsa's for 10s: 2 2048 bit DSA signs in 13.26s Doing 2048 bit verify dsa's for 10s: 2 2048 bit DSA verify in 16.57s OpenSSL 0.9.5a 1 Apr 2000 built on: Sun Aug 19 19:35:28 CST 2001 options:bn(32,32) md2(int) rc4(ptr,int) des(idx,cisc,4,long) blowfish(idx) compiler: cc -O2 -Werror The 'numbers' are in 1000s of bytes per second processed. type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 17.11k 47.11k 62.41k 69.65k 72.05k mdc2 38.91k 39.57k 39.38k 39.73k 39.77k md5 213.45k 620.71k 1557.61k 2461.04k 2867.20k hmac(md5) 69.79k 359.11k 1074.42k 2079.17k 2829.71k sha1 66.56k 266.33k 431.62k 517.19k 542.48k rmd160 61.47k 270.02k 448.86k 537.17k 567.14k rc4 864.00k 1229.81k 1271.96k 1252.09k 1284.53k des cbc 241.98k 274.42k 275.09k 275.46k 278.53k des ede3 77.82k 87.54k 88.83k 90.20k 89.04k idea cbc 0.00 0.00 0.00 0.00 0.00 rc2 cbc 325.26k 388.52k 398.02k 413.24k 401.15k rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00 blowfish cbc 399.95k 480.22k 497.46k 502.59k 514.77k cast cbc 421.64k 425.26k 434.34k 436.68k 436.91k sign verify sign/s verify/s rsa 512 bits 0.4682s 0.0550s 2.1 18.2 rsa 1024 bits 3.1125s 0.1945s 0.3 5.1 rsa 2048 bits 21.9200s 0.7193s 0.0 1.4 sign verify sign/s verify/s dsa 512 bits 0.5332s 0.6717s 1.9 1.5 dsa 1024 bits 1.8267s 2.2280s 0.5 0.4 dsa 2048 bits 6.6300s 8.2850s 0.2 0.1 -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From papier at sdv.fr Mon Nov 5 20:15:39 2001 From: papier at sdv.fr (Laurent Papier) Date: Mon, 5 Nov 2001 10:15:39 +0100 Subject: Entropy and DSA key In-Reply-To: References: Message-ID: <200111050848.fA58mET19754@factorix.sdv.fr> On Sat, 3 Nov 2001 09:46:51 +1100 (EST) Damien Miller wrote: > On Fri, 2 Nov 2001, Ed Phillips wrote: > > We are having a problem deploying sshd (no prngd) where sshd refuses to > > start because it says theres not enough available entropy. Would > > disabling DSA in sshd prevent the system from becoming "entropy starved"? > > No, you should adjust ssh_prng_cmds to gather more entropy or pester your > OS vendor for /dev/random. We have the exact same problem here on AIX 3.x. We now use prngd and this completly solve the problem. -- Laurent Papier - Admin. systeme Sdv Plurimedia - From Robert.Dahlem at siemens.com Mon Nov 5 21:47:33 2001 From: Robert.Dahlem at siemens.com (Robert Dahlem) Date: Mon, 05 Nov 2001 11:47:33 +0100 Subject: Slow connection performance with ssh2 In-Reply-To: Message-ID: <200111051050.fA5AoUJ21993764@mail3.siemens.de> Damien, On Mon, 5 Nov 2001 08:49:45 +1100 (EST), Damien Miller wrote: >You can trade connect speed for security by disabling this - delete >or rename $sysconfdir/{primes,moduli} Could you please give an explanation or a pointer to some reading what this trade means? >Using RSA keys for SSH2 authentication helps too. No big deal here (MIPS R4400/250 MHz). I already had RSA, tried to switch to DSA: not worse compared to RSA (RSA is bad enough :-) . Regards, Robert -- Robert.Dahlem at siemens.com Siemens Business Services - FS GF KORDOBA-Outsourcing Tel: +49-69-797-6530 Fax: +49-69-797-6599 ---------------------------------------------------------------------- Sent using PMMail (http://www.pmmail2000.com) - fast, decent, email software; far better than Outlook. Try it sometime. From djm at mindrot.org Mon Nov 5 23:58:03 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 5 Nov 2001 23:58:03 +1100 (EST) Subject: Slow connection performance with ssh2 In-Reply-To: <200111051050.fA5AoUJ21993764@mail3.siemens.de> Message-ID: On Mon, 5 Nov 2001, Robert Dahlem wrote: > Damien, > > On Mon, 5 Nov 2001 08:49:45 +1100 (EST), Damien Miller wrote: > > >You can trade connect speed for security by disabling this - delete > >or rename $sysconfdir/{primes,moduli} > > Could you please give an explanation or a pointer to some reading what > this trade means? The aforementioned draft is probably the best place to start. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Tue Nov 6 00:01:48 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Nov 2001 00:01:48 +1100 (EST) Subject: Entropy and DSA key In-Reply-To: <200111050848.fA58mET19754@factorix.sdv.fr> Message-ID: On Mon, 5 Nov 2001, Laurent Papier wrote: > > No, you should adjust ssh_prng_cmds to gather more entropy or pester your > > OS vendor for /dev/random. > > We have the exact same problem here on AIX 3.x. We now use prngd and this > completly solve the problem. Short of pursuading your OS vendor to give you a /dev/random, using PRNGd is the best approach. IMO the built-in entropy code should really be a last resort. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From markus at openbsd.org Tue Nov 6 00:03:46 2001 From: markus at openbsd.org (Markus Friedl) Date: Mon, 5 Nov 2001 14:03:46 +0100 Subject: Slow connection performance with ssh2 In-Reply-To: ; from djm@mindrot.org on Mon, Nov 05, 2001 at 08:49:45AM +1100 References: Message-ID: <20011105140346.A19060@faui02.informatik.uni-erlangen.de> On Mon, Nov 05, 2001 at 08:49:45AM +1100, Damien Miller wrote: > On Sun, 4 Nov 2001 mouring at etoh.eviladmin.org wrote: > > > It would be intersting to benchmark SSH Corp and vshell on slow boxes to > > see where we stand, but I suspect they will be the same or we will be > > slightly faster. (We do have the best crypto people in OpenBSD, right > > Theo? =) > > We will be slower than some other implementations because we support > draft-ietf-secsh-dh-group-exchange-01.txt, which requires a fair bit > of computation. > > You can trade connect speed for security by disabling this - delete > or rename $sysconfdir/{primes,moduli} i don't think dh-group-exchange causes more computation. it adds one additional round-trip. hm, ok, if a larger group is chosen, the computation time increases. -m From mark.pitt at ch.ibm.com Tue Nov 6 01:12:10 2001 From: mark.pitt at ch.ibm.com (Mark Pitt) Date: Mon, 5 Nov 2001 15:12:10 +0100 Subject: Security - ssh allows unintended access on AIX Message-ID: Under AIX there are three security settings: expires = a fixed date at which an account is no longer valid maxage= weeks before a password expires maxexpires=max weeks during which a password can be changed by a user after expiration AFTER WHICH ACCESS IS NOT ALLOWED Beauty of maxage with expires is, that no manual intervention is required to block inactive users. With maxage=5 and expires=1 an inactive user will be locked out after 6 weeks, even if he knows the password, also you can avoid "smoking joes" or inactive accounts. loginrestrictions in auth.c checks everything EXCEPT this. Security problem is, this allows access when access should be denied. Default for expires is -1, which means a password will expire as in maxage, but the user can change his password at anytime, however once set, access should be denied. Being a simple soul, I have added a routine passwdexpires ( AIX Lib ) directly after loginrestrictions with the same code. I think this should be urgently added to the code - hope this helps. auth.c /* mpi change expiresmsg */ #ifdef WITH_AIXAUTHENTICATE char *loginmsg; char *expiresmsg; int passexpcode; #endif /* WITH_AIXAUTHENTICATE */ #ifdef WITH_AIXAUTHENTICATE auth.c /* mpi change passwdexpires hinein */ if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) { if (loginmsg && *loginmsg) { char *p; for (p = loginmsg; *p; p++) { if (*p == '\n') *p = ' '; } *--p = '\0'; log("Login restricted for %s: %.100s", pw->pw_name, loginmsg); } return 0; } passexpcode=passwdexpired(pw->pw_name, &expiresmsg); if ( passexpcode > 0 ) { if (expiresmsg && *expiresmsg) { char *e; for (e = expiresmsg; *e; e++) { if (*e == '\n') *e = ' '; } *--e = '\0'; if ( passexpcode == 1 ) { log("Password expired %s: %.100s", pw->pw_name, expiresmsg); } else { log("Password expired too long or system failure %s: %.100s", pw->pw_name, expir esmsg); return 0; } } } #endif /* WITH_AIXAUTHENTICATE */ * expires Defines the expiration time for the user account. * Possible values: a valid date in the form MMDDHHMMYY or 0. * If 0 the account does not expire. If 0101000070 the account * is disabled. The range for YY is: * 00 - 38 years 2000 thru 2038 * 39 - 99 years 1939 thru 1999 * histexpire Defines the period of time in weeks that a user * will not be able to reuse a password. * Possible values: an integer value between 0 and 260. * 26 (approximately 6 months) is the recommended value. * * maxexpired Defines the maximum number of weeks after maxage that an expired * password can be changed by a user. The default is -1, which * is equivalent to unlimited. Range: -1 to 52. maxage must * be greater than 0 for maxexpired to be enforced. (root is * exempt from maxexpired.) * ------------------------------------------------------------------------------- Base Operating System and Extensions Technical Reference, Volume 1 ------------------------------------------------------------------------------- passwdexpired Subroutine Purpose Checks the user's password to determine if it has expired. Syntax passwdexpired (UserName, Message) char *UserName; char **Message; Description The passwdexpired subroutine checks a user's password to determine if it has : The passwdexpired subroutine checks a user's password to determine if it has expired. The subroutine checks the registry variable in the /etc/security/user file to ascertain where the user is administered. If the registry variable is not defined, the passwdexpired subroutine checks the local, NIS, and DCE databases for the user definition and expiration time. The passwdexpired subroutine may pass back informational messages, such as how many days remain until password expiration. Parameters UserName Specifies the user's name whose password is to be checked. Message Points to a pointer that the passwdexpired subroutine allocates memory for and fills in. This string is suitable for printing and issues messages, suchas in how many days the password will expire. Return Values Upon successful completion, the passwdexpired subroutine returns a value of 0. If this subroutine fails, it returns one of the following values: 1 Indicates that the password is expired, and the user must change it. : 2 Indicates that the password is expired, and only a system administrator may change it. -1 Indicates that an internal error has occurred, such as a memory allocation (malloc) failure or database corruption. Error Codes The passwdexpired subroutine fails if one or more of the following values is true: ENOENT Indicates that the user could not be found. EPERM Indicates that the user did not have permission to check password expiration. ENOMEM Indicates that memory allocation (malloc) failed. EINVAL Indicates that the parameters are not valid. Implementation Specifics ENOENT Indicates that the user could not be found. EPERM Indicates that the user did not have permission to check password expiration. ENOMEM Indicates that memory allocation (malloc) failed. EINVAL Indicates that the parameters are not valid. Implementation Specifics This subroutine is part of Base Operating System (BOS) Runtime. Related Information The authenticate subroutine. The login command. ------------------------------------------------------------------------------- Mark Pitt SP Administrator IBM, Campus Winterthur 058-333-1542 From michael.mai at db.com Tue Nov 6 02:23:36 2001 From: michael.mai at db.com (Michael Mai) Date: Mon, 5 Nov 2001 16:23:36 +0100 Subject: OpenSSH 2.3 Message-ID: Dear Gentlemen: a couple of months ago we ported OpenSSH 2.3 to an IBM OS/390 Mainframe machine: It ran very well until we tried to connect to an SSH server using SSH2 protocol. On the OS/390 (which is the client) it comes up with the following error messages: >ssh -v -2 somehost . . . debug: bits set: 504/1024 debug: len 55 datafellows 0 debug: dsa_verify: signature incorrect dsa_verify failed for server_host_key debug: Calling cleanup 0x1cf36d18(0x0) and it ends. I also tried a different key : -c "blowfish-cbc" but the problem remains the same. Can anybody help ?? Gruss/ regards Michael Mai Deutsche Bank PCAM-GT CTO Platform Mainframe MVS Applications Application Enabling Technology email: michael.mai at db.com -- Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From strube at physik3.gwdg.de Tue Nov 6 02:57:00 2001 From: strube at physik3.gwdg.de (Hans Werner Strube) Date: Mon, 5 Nov 2001 16:57:00 +0100 (MET) Subject: Slow connection performance with ssh2 Message-ID: <200111051557.QAA01196@marc.physik3.gwdg.de> Gregory Leblanc wrote: > > As my hardware is slower (Sparc LX, NetBSD, 50 MHz CPU) it takes more > > than 2 minutes (!!), which are spent on CPU cycles in ssh and sshd - running > > with 95% CPU... - the overall CPU time used by sshd for a successful > > connect is about 2:50 minutes > > Older SPARCs in general are bloody slow at encryption operations. Try > upgrading to 2.9.9p2, and make sure that you're -not- using DSA, as > that's REALLY REALLY slow. It is important to use a matching instruction set. My openssl libcrypto was compiled for sparcv8 (with Sun Workshop 5.0, -xO3). When using ssh (client) on old sun4c (sparcv7) machines like IPX or SS2, ssh login took almost 2 minutes. When a libcrypto was built specially for sparcv7, this was reduced to 17 seconds -- of course, still much too slow. A Sparc LX has about the same speed as an IPX but is sparcv8a (almost v8); but if your libcrypto happens to be compiled for UltraSPARC (v8plus), you may have a similar effect as I had. AFAIK, gcc uses sparcv8 by default. From mouring at etoh.eviladmin.org Tue Nov 6 02:59:30 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 5 Nov 2001 09:59:30 -0600 (CST) Subject: Entropy and DSA key In-Reply-To: Message-ID: Maybe we should have set internal entropy to --with-internal-entropy at the 3.0 instead of having it default. (Thus having ./configure failure if it does not find entropy) I think most people will ignore messages if ./configure success. - Ben On Tue, 6 Nov 2001, Damien Miller wrote: > On Mon, 5 Nov 2001, Laurent Papier wrote: > > > > No, you should adjust ssh_prng_cmds to gather more entropy or pester your > > > OS vendor for /dev/random. > > > > We have the exact same problem here on AIX 3.x. We now use prngd and this > > completly solve the problem. > > Short of pursuading your OS vendor to give you a /dev/random, using > PRNGd is the best approach. IMO the built-in entropy code should > really be a last resort. > > -d > > -- > | By convention there is color, \\ Damien Miller > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > | But in reality there are atoms and space - Democritus (c. 400 BCE) > > From mouring at etoh.eviladmin.org Tue Nov 6 03:00:58 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 5 Nov 2001 10:00:58 -0600 (CST) Subject: Security - ssh allows unintended access on AIX In-Reply-To: Message-ID: If you wish us to consider a patch.. PLEASE provide it in unified diff format. - Ben On Mon, 5 Nov 2001, Mark Pitt wrote: > > Under AIX there are three security settings: > > expires = a fixed date at which an account is no longer valid > maxage= weeks before a password expires > maxexpires=max weeks during which a password can be changed by a user after > expiration AFTER WHICH ACCESS IS NOT ALLOWED > > Beauty of maxage with expires is, that no manual intervention is required > to block inactive users. > With maxage=5 and expires=1 an inactive user will be locked out after 6 > weeks, even if he knows the password, also you can avoid "smoking joes" or > inactive accounts. > > loginrestrictions in auth.c checks everything EXCEPT this. > > Security problem is, this allows access when access should be denied. > Default for expires is -1, which means a password will expire as in maxage, > but the user can change his password at anytime, however once set, access > should be denied. > > Being a simple soul, I have added a routine passwdexpires ( AIX Lib ) > directly after loginrestrictions with the same code. I think this should > be urgently added to the code - hope this helps. > > auth.c > > /* mpi change expiresmsg */ > #ifdef WITH_AIXAUTHENTICATE > char *loginmsg; > char *expiresmsg; > int passexpcode; > #endif /* WITH_AIXAUTHENTICATE */ > > > #ifdef WITH_AIXAUTHENTICATE > > auth.c > > /* mpi change passwdexpires hinein */ > > if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != > 0) { > > if (loginmsg && *loginmsg) { > char *p; > for (p = loginmsg; *p; p++) { > if (*p == '\n') > *p = ' '; > } > *--p = '\0'; > log("Login restricted for %s: %.100s", pw->pw_name, > loginmsg); > } > return 0; > } > > passexpcode=passwdexpired(pw->pw_name, &expiresmsg); > > if ( passexpcode > 0 ) { > > if (expiresmsg && *expiresmsg) { > char *e; > for (e = expiresmsg; *e; e++) { > if (*e == '\n') > *e = ' '; > } > *--e = '\0'; > > if ( passexpcode == 1 ) { > log("Password expired %s: %.100s", pw->pw_name, > expiresmsg); > } > else { > log("Password expired too long or system failure > %s: %.100s", pw->pw_name, expir > esmsg); > return 0; > } > } > > } > > #endif /* WITH_AIXAUTHENTICATE */ > > > * expires Defines the expiration time for the user account. > * Possible values: a valid date in the form MMDDHHMMYY or 0. > * If 0 the account does not expire. If 0101000070 the > account > * is disabled. The range for YY is: > * 00 - 38 years 2000 thru 2038 > * 39 - 99 years 1939 thru 1999 > > * histexpire Defines the period of time in weeks that a user > * will not be able to reuse a password. > * Possible values: an integer value between 0 and 260. > * 26 (approximately 6 months) is the recommended value. > * > * maxexpired Defines the maximum number of weeks after maxage that an > expired > * password can be changed by a user. The default is -1, > which > * is equivalent to unlimited. Range: -1 to 52. maxage must > * be greater than 0 for maxexpired to be enforced. (root is > * exempt from maxexpired.) > * > ------------------------------------------------------------------------------- > Base Operating System and Extensions Technical Reference, Volume 1 > ------------------------------------------------------------------------------- > > passwdexpired Subroutine > > Purpose > > Checks the user's password to determine if it has expired. > > Syntax > > passwdexpired (UserName, Message) > > char *UserName; > > char **Message; > > Description > > The passwdexpired subroutine checks a user's password to determine if it > has > : > The passwdexpired subroutine checks a user's password to determine if it > has > expired. The subroutine checks the registry variable in the > /etc/security/user > file to ascertain where the user is administered. If the registry variable > is > not defined, the passwdexpired subroutine checks the local, NIS, and DCE > databases for the user definition and expiration time. > > The passwdexpired subroutine may pass back informational messages, such as > how > many days remain until password expiration. > > Parameters > > UserName Specifies the user's name whose password is to be checked. > > Message Points to a pointer that the passwdexpired subroutine allocates > memory > for and fills in. This string is suitable for printing and issues messages, > suchas in how many days the password will expire. > > Return Values > > Upon successful completion, the passwdexpired subroutine returns a value of > 0. > If this subroutine fails, it returns one of the following values: > > 1 Indicates that the password is expired, and the user must change it. > : > > 2 Indicates that the password is expired, and only a system administrator > may > change it. > > -1 Indicates that an internal error has occurred, such as a memory > allocation > (malloc) failure or database corruption. > > Error Codes > > The passwdexpired subroutine fails if one or more of the following values > is > true: > > ENOENT Indicates that the user could not be found. > > EPERM Indicates that the user did not have permission to check password > expiration. > > ENOMEM Indicates that memory allocation (malloc) failed. > > EINVAL Indicates that the parameters are not valid. > > Implementation Specifics > > ENOENT Indicates that the user could not be found. > > EPERM Indicates that the user did not have permission to check password > expiration. > > ENOMEM Indicates that memory allocation (malloc) failed. > > EINVAL Indicates that the parameters are not valid. > > Implementation Specifics > > This subroutine is part of Base Operating System (BOS) Runtime. > > Related Information > > The authenticate subroutine. > > The login command. > ------------------------------------------------------------------------------- > > > Mark Pitt > SP Administrator > IBM, Campus Winterthur > 058-333-1542 > > > From ed at UDel.Edu Tue Nov 6 03:23:51 2001 From: ed at UDel.Edu (Ed Phillips) Date: Mon, 5 Nov 2001 11:23:51 -0500 (EST) Subject: Entropy and DSA key In-Reply-To: Message-ID: Is there any way to compile openssh so that it will use prngd, but if it's not answering, use the compiled-in prng-like routines? Thanks, Ed On Mon, 5 Nov 2001 mouring at etoh.eviladmin.org wrote: > Date: Mon, 5 Nov 2001 09:59:30 -0600 (CST) > From: mouring at etoh.eviladmin.org > To: Damien Miller > Cc: Laurent Papier , openssh-unix-dev at mindrot.org, ed at UDel.Edu > Subject: Re: Entropy and DSA key > > > Maybe we should have set internal entropy to --with-internal-entropy at > the 3.0 instead of having it default. (Thus having ./configure failure > if it does not find entropy) > > I think most people will ignore messages if ./configure success. > > - Ben > > On Tue, 6 Nov 2001, Damien Miller wrote: > > > On Mon, 5 Nov 2001, Laurent Papier wrote: > > > > > > No, you should adjust ssh_prng_cmds to gather more entropy or pester your > > > > OS vendor for /dev/random. > > > > > > We have the exact same problem here on AIX 3.x. We now use prngd and this > > > completly solve the problem. > > > > Short of pursuading your OS vendor to give you a /dev/random, using > > PRNGd is the best approach. IMO the built-in entropy code should > > really be a last resort. > > > > -d > > > > -- > > | By convention there is color, \\ Damien Miller > > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > > | But in reality there are atoms and space - Democritus (c. 400 BCE) > > > > > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From mouring at etoh.eviladmin.org Tue Nov 6 03:40:27 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 5 Nov 2001 10:40:27 -0600 (CST) Subject: Entropy and DSA key In-Reply-To: Message-ID: This has been talked about between Damien and myself, but the more I think about it. The more I don't like the idea. I'd rather sometime down the road make a clean break of our internal entropy system (Yes, Damien, I'm changing my tune.. ). If anything work to allow for a libprng.a which could be compiled into OpenSSH if someone so wants internal entropy. Yes (as some will argue) it adds another dependancy for those OSes without /dev/random, but I think it would be best for everyone in the end. Before someone jumps up and starts screaming. I'm not proposing we suddenly drop it. The proposal is this (not set in stone mind you): 3.1 - Make internal entropy --with-* option and not enabled by default. Provide warnings at that screen and provide locations to PRNGd. Warn about how it will be removed in a future release. 3.5 - ? Provide ability to link with a libprngd.a instead of compiling w/ our internal entropy. 4.0 - ? Remove internal entropy code. Out of interest does ANYONE use egd.pl any more?! - Ben On Mon, 5 Nov 2001, Ed Phillips wrote: > Is there any way to compile openssh so that it will use prngd, but if it's > not answering, use the compiled-in prng-like routines? > > Thanks, > > Ed > > On Mon, 5 Nov 2001 mouring at etoh.eviladmin.org wrote: > > > Date: Mon, 5 Nov 2001 09:59:30 -0600 (CST) > > From: mouring at etoh.eviladmin.org > > To: Damien Miller > > Cc: Laurent Papier , openssh-unix-dev at mindrot.org, ed at UDel.Edu > > Subject: Re: Entropy and DSA key > > > > > > Maybe we should have set internal entropy to --with-internal-entropy at > > the 3.0 instead of having it default. (Thus having ./configure failure > > if it does not find entropy) > > > > I think most people will ignore messages if ./configure success. > > > > - Ben > > > > On Tue, 6 Nov 2001, Damien Miller wrote: > > > > > On Mon, 5 Nov 2001, Laurent Papier wrote: > > > > > > > > No, you should adjust ssh_prng_cmds to gather more entropy or pester your > > > > > OS vendor for /dev/random. > > > > > > > > We have the exact same problem here on AIX 3.x. We now use prngd and this > > > > completly solve the problem. > > > > > > Short of pursuading your OS vendor to give you a /dev/random, using > > > PRNGd is the best approach. IMO the built-in entropy code should > > > really be a last resort. > > > > > > -d > > > > > > -- > > > | By convention there is color, \\ Damien Miller > > > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > > > | But in reality there are atoms and space - Democritus (c. 400 BCE) > > > > > > > > > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > > From gert at greenie.muc.de Tue Nov 6 03:48:12 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 5 Nov 2001 17:48:12 +0100 Subject: Entropy and DSA key In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Nov 05, 2001 at 10:40:27AM -0600 References: Message-ID: <20011105174812.B15435@greenie.muc.de> hi, On Mon, Nov 05, 2001 at 10:40:27AM -0600, mouring at etoh.eviladmin.org wrote: > Out of interest does ANYONE use egd.pl any more?! I have a few hosts that are "never thouch a running system" candidates, and they still run egd.pl - but new installations always get prngd. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From djast at cs.toronto.edu Tue Nov 6 03:57:00 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Mon, 5 Nov 2001 11:57:00 -0500 Subject: Entropy and DSA key In-Reply-To: Your message of "Mon, 05 Nov 2001 11:23:51 EST." Message-ID: <01Nov5.115711edt.453149-15184@jane.cs.toronto.edu> On Mon, 05 Nov 2001 11:23:51 EST, Ed Phillips writes: > Is there any way to compile openssh so that it will use prngd, but if it's > not answering, use the compiled-in prng-like routines? No supported way, and no way that doesn't involve modifying the source. I recently asked here whether that feature would be accepted if I wrote a patch to implement it; the consensus was, for reasons I won't rehash, that the feature was not desired. However, assuming you're using OpenSSL 0.9.5 or later, and using Unix sockets for PRNGD rather than a TCP port, it can be done fairly easily, by calling OpenSSL's EGD hooks from the internal entropy code instead of compiling in OpenSSH's PRNGD code. - In entropy.c, make the following change to the _second_ definition of seed_rng() (the version which is used by the internal entropy code): ======================================================================== if (!prng_initialised) fatal("RNG not initialised"); + + #define EGD_SOCKET "/path/to/prngd/socket" + if (!RAND_status()) { + RAND_egd(EGD_SOCKET); + } + if (RAND_status()) { + return; + } /* Make sure some other sigchld handler doesn't reap our entropy */ /* commands */ ======================================================================== - Configure openssh *without* PRNGD support. Use at your own risk. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From peterw at usa.net Tue Nov 6 04:05:40 2001 From: peterw at usa.net (Peter W) Date: Mon, 5 Nov 2001 12:05:40 -0500 Subject: phasing out internal entropy code? In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Nov 05, 2001 at 10:40:27AM -0600 References: Message-ID: <20011105120540.A25770@usa.net> On Mon, Nov 05, 2001 at 10:40:27AM -0600, mouring at etoh.eviladmin.org wrote: > I'd rather sometime down the > road make a clean break of our internal entropy system (Yes, Damien, I'm > changing my tune.. ). If anything work to allow for a libprng.a > which could be compiled into OpenSSH if someone so wants internal entropy. > > Yes (as some will argue) it adds another dependancy for those OSes without > /dev/random, but I think it would be best for everyone in the end. Anything that helps convince lazy vendors (cough! [Sun] cough cough) to get off their tails and provide things like /dev/random and /dev/urandom is a good thing, IMO. prngd: do you mean this? http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html -Peter From mouring at etoh.eviladmin.org Tue Nov 6 04:14:59 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 5 Nov 2001 11:14:59 -0600 (CST) Subject: phasing out internal entropy code? In-Reply-To: <20011105120540.A25770@usa.net> Message-ID: On Mon, 5 Nov 2001, Peter W wrote: > On Mon, Nov 05, 2001 at 10:40:27AM -0600, mouring at etoh.eviladmin.org wrote: > > > I'd rather sometime down the > > road make a clean break of our internal entropy system (Yes, Damien, I'm > > changing my tune.. ). If anything work to allow for a libprng.a > > which could be compiled into OpenSSH if someone so wants internal entropy. > > > > Yes (as some will argue) it adds another dependancy for those OSes without > > /dev/random, but I think it would be best for everyone in the end. > > Anything that helps convince lazy vendors (cough! [Sun] cough cough) to get > off their tails and provide things like /dev/random and /dev/urandom is a > good thing, IMO. > Don't be hard on Sun. Rumor in the grape vine says that Solaris 9 will have such a beast. > prngd: do you mean this? > http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html > It is unresolvable (more than likely do to the crappy network I'm on), but yes that is the right person. - Ben From manoj at ranchnetworks.com Tue Nov 6 05:35:22 2001 From: manoj at ranchnetworks.com (Manoj Jaitly) Date: Mon, 5 Nov 2001 13:35:22 -0500 Subject: 2.9.9p2 In-Reply-To: Message-ID: Hi Can anyone help me in finiding the following functions in openssh2.9.9p2, I did not find these functions any where BN_num_bits BN_bn2bin BN_init Infact all the BN_ related functions. Also the MD5_ related functions Thanks Manoj From wendyp at cray.com Tue Nov 6 05:38:36 2001 From: wendyp at cray.com (Wendy Palm) Date: Mon, 05 Nov 2001 12:38:36 -0600 Subject: 2.9.9p2 References: Message-ID: <3BE6DCAC.3053C111@cray.com> these are in openssl. Manoj Jaitly wrote: > > Hi > > Can anyone help me in finiding the following functions in openssh2.9.9p2, I > did not find these functions any where > > BN_num_bits > BN_bn2bin > BN_init > > Infact all the BN_ related functions. > > Also the MD5_ related functions > > Thanks > Manoj -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From simon at sxw.org.uk Tue Nov 6 06:23:30 2001 From: simon at sxw.org.uk (Simon Wilkinson) Date: Mon, 5 Nov 2001 19:23:30 +0000 Subject: [PATCH] Kerberos v5 support for protocol v1 Message-ID: <01110519233009.16364@loki.dcs.ed.ac.uk> The following patch *) Adds a configure option to turn on the existing Kerberos v5 support in the portable version *) Extends the code to support MIT Kerberos in addition to Heimdal The patch is against the current CVS tree. I've tested it against MIT Keberos 1.2.2, I'd appreciate it if someone could confirm that Heimdal works with the portable configuration stuff. Coming RSN - patches to 2.9.9p2 containing this, and the GSSAPI stuff for protocol v2. Cheers, Simon. -- Simon Wilkinson http://www.sxw.org.uk -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cvs.diffs Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011105/342824e9/attachment.ksh From markus at openbsd.org Tue Nov 6 07:43:02 2001 From: markus at openbsd.org (Markus Friedl) Date: Mon, 5 Nov 2001 21:43:02 +0100 Subject: OpenSSH 2.3 In-Reply-To: ; from michael.mai@db.com on Mon, Nov 05, 2001 at 04:23:36PM +0100 References: Message-ID: <20011105214302.A6026@folly> On Mon, Nov 05, 2001 at 04:23:36PM +0100, Michael Mai wrote: > debug: bits set: 504/1024 > debug: len 55 datafellows 0 > debug: dsa_verify: signature incorrect > dsa_verify failed for server_host_key > debug: Calling cleanup 0x1cf36d18(0x0) does openssl work on this machine? e.g. openssl speed dsa ? -m From scott.burch at camberwind.com Tue Nov 6 10:03:20 2001 From: scott.burch at camberwind.com (Scott Burch) Date: Mon, 5 Nov 2001 17:03:20 -0600 Subject: FYI dsa_lib.c and dh_lib.c in openssl-0.9.6b and latest snapshot Message-ID: <00bd01c1664e$10a33c20$f24318ac@ent.core.medtronic.com> Hello, I am writing to comment on problems I have seen in the past that are currently still problems with compiling OpenSSH with the Sun Forte Compiler version 6 update 2 and gcc on Solaris 8 (not suprising since the problems are actually in the openssl code). I used the snapshot from 11/4 for this test on a brand new system I built from the July release of Solaris 8. I have the latest linker patches, C, C++ library patches, etc. If you want to see the ouput of showrev, etc I can provide this. People in the past suggested that I apply the latest linker patch in the past to fix the problem, however that is not true. The only way I can compile openssh and have it work is to do the following suggest from people on this list. Others should be able to replicate my problems easily. I am reporting back now, because I finally got a chance to rejump my Ultra10 that I used to do the compile. If nobody else has these problems then something else must be wrong on my machine, but I don't see what. I built the following from source with Sun Forte 6 update 2: zlib 1.1.3 openssl 0.9.6b tcp_wrappers skey libraries prngd0.9.23 (Oh and skey does not work...it fails checking for skey_keyinfo... no config error missing s/key libraries...I was able to compile and install skey without problems as long as I used gnu-make...but openssh snapshot from 11/4 can not find the libraries...so I think something is wrong there as well.) The compilation options I used for various code are documented in the Sun Blueprint "Building and Deploying OpenSSH for the Solaris Operating Environment" The source changes I made are below for openssl (suggested by several here): Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from static DSA_METHOD *default_DSA_method; to static DSA_METHOD *default_DSA_method = NULL; I just found another of these beasts in crypto/dh/dh_lib.c. Change static const DH_METHOD *default_DH_method; to static const DH_METHOD *default_DH_method = NULL; -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011105/20304e18/attachment.html From djm at mindrot.org Tue Nov 6 10:34:06 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Nov 2001 10:34:06 +1100 (EST) Subject: Entropy and DSA key In-Reply-To: Message-ID: On Mon, 5 Nov 2001 mouring at etoh.eviladmin.org wrote: > > Maybe we should have set internal entropy to --with-internal-entropy at > the 3.0 instead of having it default. (Thus having ./configure failure > if it does not find entropy) I really like the idea, but its too late for 3.0. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Tue Nov 6 10:51:01 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Nov 2001 10:51:01 +1100 (EST) Subject: Slow connection performance with ssh2 In-Reply-To: <20011105140346.A19060@faui02.informatik.uni-erlangen.de> Message-ID: On Mon, 5 Nov 2001, Markus Friedl wrote: > i don't think dh-group-exchange causes more computation. > it adds one additional round-trip. hm, ok, if a larger group > is chosen, the computation time increases. one extra modexp on the client, two on the server and a bit of hashing at each end. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Tue Nov 6 10:52:46 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Nov 2001 10:52:46 +1100 (EST) Subject: Security - ssh allows unintended access on AIX In-Reply-To: Message-ID: On Mon, 5 Nov 2001, Mark Pitt wrote: > Being a simple soul, I have added a routine passwdexpires ( AIX Lib ) > directly after loginrestrictions with the same code. I think this should > be urgently added to the code - hope this helps. Could you send this as a unified diff ?diff -u?, it makes it much easier to review and merge. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Tue Nov 6 10:54:26 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Nov 2001 10:54:26 +1100 (EST) Subject: 2.9.9p2 In-Reply-To: Message-ID: On Mon, 5 Nov 2001, Manoj Jaitly wrote: > Hi > > Can anyone help me in finiding the following functions in openssh2.9.9p2, I > did not find these functions any where > > BN_num_bits > BN_bn2bin > BN_init > > Infact all the BN_ related functions. > > Also the MD5_ related functions OpenSSL?s libcrypto -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From mjt at tls.msk.ru Tue Nov 6 11:40:38 2001 From: mjt at tls.msk.ru (Michael Tokarev) Date: Tue, 06 Nov 2001 03:40:38 +0300 Subject: FYI dsa_lib.c and dh_lib.c in openssl-0.9.6b and latest snapshot References: <00bd01c1664e$10a33c20$f24318ac@ent.core.medtronic.com> Message-ID: <3BE73186.2D1ED495@tls.msk.ru> > Scott Burch wrote: [] > The source changes I made are below for openssl (suggested by several here): > > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > static DSA_METHOD *default_DSA_method; > to > static DSA_METHOD *default_DSA_method = NULL; Hmmm... Such variables should be initialized by a compiler/linker/whatether. Interesting to see if this is in some C specs or not. Gcc with GNU ld will definitely initialize the variable in question to zero (NULL = 0, isn't it?). Note for example numerous flame wars on linux-kernel when Linus rejected a patch that contains initializations like this -- due to resulting executable growth. That is, without initializer, code works just like with it, but an initializer makes resulting executable bigger. I almost shure this is a bug in compiler or linker and NOT in the code, but I don't know specs that says so. Well, those static variables can be initialized explicitly as a work around buggy compiling environment... Regards, Michael. From scott.burch at camberwind.com Tue Nov 6 15:08:42 2001 From: scott.burch at camberwind.com (Scott Burch) Date: 05 Nov 2001 23:08:42 -0500 Subject: FYI dsa_lib.c and dh_lib.c in openssl-0.9.6b and latest snapshot In-Reply-To: <3BE73186.2D1ED495@tls.msk.ru> References: <00bd01c1664e$10a33c20$f24318ac@ent.core.medtronic.com> <3BE73186.2D1ED495@tls.msk.ru> Message-ID: <1005019723.466.14.camel@glacier> Yeah, Perhaps there is a bug, but I had these same problems with gcc on Solaris. However I just checked and there are 2 patches for the Forte compiler 6 update 2 available as of October 1: They are: 111685-02 C++ 5.3: Patch for Forte Developer 6 Update 2 C++ compiler and 111678-04 Compiler Common 6.2: Patch Forte Developer 6 Update 2, C++ F77 F95. I have already applied the very latest libc and C++ library patches as well as the latest linker patches...but maybe with the additional compiler patches these changes won't have to be made. I suppose it is possible that the linker and library patches might have fixed issues with gcc but not Forte? I'll try the additional patches tomorrow and see how they work. If there is a fix beyond changing source in openssl then I will report this. If anyone already knows the answer then please report it to the list. If Jason Reid or Keith Watson are monitoring this list perhaps they can comment. I will try with gcc tomorrow and see how that works...I know I had problems before on the January 2001 release of Solaris. Jason and Keith used the April 2001 release of Solaris 8, 5/98 Solaris 2.6, Solaris 7 11/9 with Forte C 6 Update 1 and gcc 2.95.2. I'll keep quite unless I find something useful. -Scott On Mon, 2001-11-05 at 19:40, Michael Tokarev wrote: > > Scott Burch wrote: > [] > > The source changes I made are below for openssl (suggested by several here): > > > > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > > static DSA_METHOD *default_DSA_method; > > to > > static DSA_METHOD *default_DSA_method = NULL; > > Hmmm... > Such variables should be initialized by a compiler/linker/whatether. > Interesting to see if this is in some C specs or not. Gcc with > GNU ld will definitely initialize the variable in question to > zero (NULL = 0, isn't it?). Note for example numerous flame wars > on linux-kernel when Linus rejected a patch that contains > initializations like this -- due to resulting executable growth. > That is, without initializer, code works just like with it, but > an initializer makes resulting executable bigger. I almost shure > this is a bug in compiler or linker and NOT in the code, but I > don't know specs that says so. Well, those static variables can > be initialized explicitly as a work around buggy compiling > environment... > > Regards, > Michael. > -- Scott Burch http://www.camberwind.com/ From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Nov 6 22:11:19 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 6 Nov 2001 12:11:19 +0100 Subject: FYI dsa_lib.c and dh_lib.c in openssl-0.9.6b and latest snapshot In-Reply-To: <3BE73186.2D1ED495@tls.msk.ru> References: <00bd01c1664e$10a33c20$f24318ac@ent.core.medtronic.com> <3BE73186.2D1ED495@tls.msk.ru> Message-ID: <20011106121119.A27950@serv01.aet.tu-cottbus.de> On Tue, Nov 06, 2001 at 03:40:38AM +0300, Michael Tokarev wrote: > > Scott Burch wrote: > [] > > The source changes I made are below for openssl (suggested by several here): > > > > Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from > > static DSA_METHOD *default_DSA_method; > > to > > static DSA_METHOD *default_DSA_method = NULL; > > Hmmm... > Such variables should be initialized by a compiler/linker/whatether. > Interesting to see if this is in some C specs or not. Gcc with > GNU ld will definitely initialize the variable in question to > zero (NULL = 0, isn't it?). Note for example numerous flame wars > on linux-kernel when Linus rejected a patch that contains > initializations like this -- due to resulting executable growth. > That is, without initializer, code works just like with it, but > an initializer makes resulting executable bigger. I almost shure > this is a bug in compiler or linker and NOT in the code, but I > don't know specs that says so. Well, those static variables can > be initialized explicitly as a work around buggy compiling > environment... We had this topic quite some time ago. According to the C standard, static variables like the ones discussed here must be initialized to 0/NULL/... Unfortunately there seems to be a bug in the runtime routines responsible to initialize the locations, it could be reproduced for both Sun's compiler and gcc. I tracked this problem down and committed the fix mentioned above to the OpenSSL source tree, but it won't be available before 0.9.6c (the code was restructured after 0.9.5, so the problem appears with 0.9.6, 0.9.6a, 0.9.6b). A workaround would be to call DSA_set_default_method(NULL); and DH_set_default_method(NULL); before first calling DSA_new() and DH_new() respectively. This workaround may be wrapped by a OpenSSL version specific #ifdef construct. (I don't know, whether the default method may ever be something different than NULL at this point, but it may well be possible that with support for some crypto hardware stuff things may change...) If you find such a contruct ugly: you are wright, but please remember that this is a bug in Solaris, that is only triggered by OpenSSL, we are not responsible for this problem... (We may be responsible for enough other problems, but at least not for this one :-) Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From dwd at bell-labs.com Wed Nov 7 02:54:12 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 09:54:12 -0600 Subject: Entropy and DSA key In-Reply-To: ; from mouring@etoh.eviladmin.org on Mon, Nov 05, 2001 at 10:40:27AM -0600 References: Message-ID: <20011106095412.A1298@lucent.com> On Mon, Nov 05, 2001 at 10:40:27AM -0600, mouring at etoh.eviladmin.org wrote: > On Mon, 5 Nov 2001, Ed Phillips wrote: > > > Is there any way to compile openssh so that it will use prngd, but if it's > > not answering, use the compiled-in prng-like routines? In addition to Dan Astoorian's suggestion, you could try my patch which is in the mailing list archive in a thread beginning at http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99193668118573&w=2 It allows you to select any of /dev/random, prngd, or internal entropy sources and if it can't find one it will go on to the next. > This has been talked about between Damien and myself, but the more I think > about it. The more I don't like the idea. I'd rather sometime down the > road make a clean break of our internal entropy system (Yes, Damien, I'm > changing my tune.. ). If anything work to allow for a libprng.a > which could be compiled into OpenSSH if someone so wants internal entropy. > > Yes (as some will argue) it adds another dependancy for those OSes without > /dev/random, but I think it would be best for everyone in the end. > > Before someone jumps up and starts screaming. I'm not proposing we > suddenly drop it. The proposal is this (not set in stone mind you): > > 3.1 - Make internal entropy --with-* option and not enabled by default. > Provide warnings at that screen and provide locations to PRNGd. Warn > about how it will be removed in a future release. I don't mind a configure option. > 3.5 - ? Provide ability to link with a libprngd.a instead of compiling w/ > our internal entropy. No problem. I assume libprngd.a would be part of the prngd package then, not the OpenSSH package, and since you wouldn't have to maintain it, it would make your life easier. > 4.0 - ? Remove internal entropy code. Are you saying you would continue support of libprngd.a? If so, why not take out the internal entropy code at the same time you switch to libprngd.a in 3.5? I have a very strong need to be able to run openssh binaries on systems without /dev/random and without system administration privileges. I distribute 6 Unix types widely throughout my company using an unprivileged user id. I need to compile on the oldest operating system release still in use for each type (for example, on Solaris it's 2.5.1) and rely on upward compatibility to allow the same binaries to run everywhere. On a subset of the systems the system administrator re-installs the binaries into a privileged directory, and on those I use prngd, but otherwise my only recourse is to use the internal entropy collector. If a /dev/random exists, I'll use that instead, but I have no way of getting all the literally thousands of Solaris systems to install the optional package from Sun. In fact, the current internal entropy collection code is just barely usable because it runs a whole lot of programs every time ssh is started. This is currently the worst thing about OpenSSH for me. SSH 1.2.27 does not have this problem: it only runs the long slow programs the first time, and from then on it uses the entropy saved in the seed file and adds a small amount of randomness each time. I've asked more than once on this mailing list if there's any crypto reason why OpenSSH does not do that, and nobody has given any so I assume it's just a matter of not having gotten around to it and not wanting to have to support more code. I've never seen any security warnings about what SSH 1.2.27 does so I presume it is fine. Dan Astoorian sent me a private email about a month ago saying that he had communicated with Lutz Janiecke, the author of PRNGD and an OpenSSL developer, about having a one-shot mode on PRNGD where it can collect all the entropy and return the random number to stdout and then exit rather than be long running. That sounds like a great idea because the code would then not need to be duplicated in OpenSSH. The extra fork/exec overhead would not be noticed compared with all the other programs PRNGD runs, especially if it only needs to be run the first time you run ssh as I think it ought. Even better, what would make the most sense is for OpenSSL to support the one-shot PRNGD as well as the long running PRNGD. Then entropy collection could be completely removed from OpenSSH, there'd be no need for libprngd.a, and everybody would be happy. Surely other applications that use OpenSSL have this exact same problem, and OpenSSL already has support for PRNGD. Lutz, can you comment? - Dave Dykstra From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Nov 7 03:23:36 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 6 Nov 2001 17:23:36 +0100 Subject: Entropy and DSA key In-Reply-To: <20011106095412.A1298@lucent.com> References: <20011106095412.A1298@lucent.com> Message-ID: <20011106172336.A4527@serv01.aet.tu-cottbus.de> On Tue, Nov 06, 2001 at 09:54:12AM -0600, Dave Dykstra wrote: > > This has been talked about between Damien and myself, but the more I think > > about it. The more I don't like the idea. I'd rather sometime down the > > road make a clean break of our internal entropy system (Yes, Damien, I'm > > changing my tune.. ). If anything work to allow for a libprng.a > > which could be compiled into OpenSSH if someone so wants internal entropy. > > > > Yes (as some will argue) it adds another dependancy for those OSes without > > /dev/random, but I think it would be best for everyone in the end. > > > > Before someone jumps up and starts screaming. I'm not proposing we > > suddenly drop it. The proposal is this (not set in stone mind you): > > > > 3.1 - Make internal entropy --with-* option and not enabled by default. > > Provide warnings at that screen and provide locations to PRNGd. Warn > > about how it will be removed in a future release. > > I don't mind a configure option. > > > 3.5 - ? Provide ability to link with a libprngd.a instead of compiling w/ > > our internal entropy. > > No problem. I assume libprngd.a would be part of the prngd package then, > not the OpenSSH package, and since you wouldn't have to maintain it, it > would make your life easier. I am not sure about the impacts of this proposal :-) I assume that "libprngd.a" would contains the configuration of the entropy gathering commands and the call of the gatherer processes itself!? At least by now the scheduling is interlinked with the code responsible to serve the communication socket... In a certain sense the work to do is offloaded from the OpenSSH portable team (OpenSSH/OpenBSD has /dev/urandom) to me... At this point I have to state that my term at the university is over and I am looking for a new job, which is not that easy these days (provided that for personal reasons I am somewhat bound to Berlin/Germany and that with 37 I am already a really old guy...). I therefore cannot make any promise about the time I can spend on the PRNGd project in the future. (I do take my security work very seriously and rather do not promise anything than promise something I cannot hold.) And I already have quite some backlog of submissions for PRNGd, but it seems that the nice sunny whether is over anyway :-) > Dan Astoorian sent me a private email about a month ago saying that he had > communicated with Lutz Janiecke, the author of PRNGD and an OpenSSL > developer, about having a one-shot mode on PRNGD where it can collect all > the entropy and return the random number to stdout and then exit rather > than be long running. That sounds like a great idea because the code would > then not need to be duplicated in OpenSSH. The extra fork/exec overhead > would not be noticed compared with all the other programs PRNGD runs, > especially if it only needs to be run the first time you run ssh as I think > it ought. > > Even better, what would make the most sense is for OpenSSL to support the > one-shot PRNGD as well as the long running PRNGD. Then entropy collection > could be completely removed from OpenSSH, there'd be no need for libprngd.a, > and everybody would be happy. Surely other applications that use OpenSSL > have this exact same problem, and OpenSSL already has support for PRNGD. I don't see yet, in how far a "one shot" prngd would be different from the internal entropy collection code. It does cause a delay until enough entropy was gathered. Granted, it would allow for a cleaner implementation than having the code built-in, but for understandable reasons collecting entropy requires the effort to collect the entropy :-) Using a seed-save file helps, but somebody could steal it, so that calling external gatherers at the time the cryptographic routines are started up is an important issue. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From dwd at bell-labs.com Wed Nov 7 03:39:37 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 10:39:37 -0600 Subject: Entropy and DSA key In-Reply-To: <20011106172336.A4527@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Nov 06, 2001 at 05:23:36PM +0100 References: <20011106095412.A1298@lucent.com> <20011106172336.A4527@serv01.aet.tu-cottbus.de> Message-ID: <20011106103937.C2288@lucent.com> On Tue, Nov 06, 2001 at 05:23:36PM +0100, Lutz Jaenicke wrote: > I don't see yet, in how far a "one shot" prngd would be different from > the internal entropy collection code. It would be the virtually the same but the advantage is it would only have to be maintained in one place. > It does cause a delay until enough > entropy was gathered. Granted, it would allow for a cleaner implementation > than having the code built-in, but for understandable reasons collecting > entropy requires the effort to collect the entropy :-) > Using a seed-save file helps, but somebody could steal it, so that calling > external gatherers at the time the cryptographic routines are started up > is an important issue. I don't buy that argument. If somebody has the ability to steal your seed-save file, that means your system has already been compromised so I don't see the point of trying to secure it further, certainly not at such a high cost of time spent on every ssh client startup. I think the only thing to worry about is an external attacker. - Dave Dykstra From ed at UDel.Edu Wed Nov 7 04:18:52 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 12:18:52 -0500 (EST) Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <20011106172336.A4527@serv01.aet.tu-cottbus.de> Message-ID: What I don't understand about the internal entropy collection is why can't sshd just run the commands periodically just like prngd, and keep a running, stirred pool of random numbers to use when a client connects? Why does sshd have to run every command and start, basically, from scratch every time a client connects? It seems like it'd be trivial for sshd just have this feature built-in, with all the caveats documented like "This is NOT actually PRNGD, but it may be good enough for your system that doesn't have /dev/[u]random or if you can't run PRNGD or whatever." Like Dave said, sshd from ssh-1.2.27 just fired off the commands at startup, then add to that a little at a time, on the fly. On a system where there's not a lot of activity (for example, an NFS server), 90% of the commands are returning the same bytes over and over again, so it really doesn't matter whether you run them once at startup, then periodically while sshd is not doing anything (sshd is not actually doing anything on our departmental systems 99.99% of the time - it could be running prng-like commands occasionally while waiting for a connection), or whether you run them every single time a client connects. The drawbacks listed in WARNING.RNG are, IMHO, a direct result of the implementation choices made for the internal entropy collection. I don't know a lot about the code for sshd, but it's seems a simple thing to change (in theory) - having a constantly updated pool of random bytes kept in the parent sshd process (which gets updated by running prng-like commands periodically), and passing that pool off to each spawned sshd child with a little system-call stirring after forking (getpid(), gettimeofday(), etc. in the child before it needs to grab some random bytes). How many random bytes are required to process a client connection on the server side? We could make the pool big enough to allow for whatever the maximum requirement is, right? IMHO, it would be a "good thing" to make OpenSSH require fewer third-party packages (don't get me wrong, PRNGD, /dev/random, etc. are nice). OpenSSL is already a pretty severe requirement in terms of compile time - and you can't get rid of that. And sure, supporting a list of prng commands for every platform is not something anyone really wants to do, but why can't we just borrow the latest set from PRNGD for the next OpenSSH release... and let the user know that it really needs to be customized for THEIR systems, just like with PRNGD itself. Ah... I'm rambling... Thanks for reading. Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Nov 7 04:33:21 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 6 Nov 2001 18:33:21 +0100 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: References: <20011106172336.A4527@serv01.aet.tu-cottbus.de> Message-ID: <20011106183321.A5662@serv01.aet.tu-cottbus.de> On Tue, Nov 06, 2001 at 12:18:52PM -0500, Ed Phillips wrote: > What I don't understand about the internal entropy collection is why can't > sshd just run the commands periodically just like prngd, and keep a > running, stirred pool of random numbers to use when a client connects? [more text removed] The problem is not sshd. sshd startup only happens once and it does not matter whether it takes 0.5 seconds or 5 seconds; the server will be up for hours/days/weeks anyway. (Re-seeding should happen over time.) The problem is with the client!!! ssh client processes are called by the user to log into the server and the response time is an important issue here! Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From david-bronder at uiowa.edu Wed Nov 7 04:33:31 2001 From: david-bronder at uiowa.edu (David Bronder) Date: Tue, 6 Nov 2001 11:33:31 -0600 (CST) Subject: [openssh-unix-dev] Re: AIX lastlog change? In-Reply-To: from "Damien Miller" at Sep 28, 2001 10:48:44 AM Message-ID: <200111061733.fA6HXVq59266@fire.its.uiowa.edu> In playing with this some, it seems like the right place for the AIX loginsuccess() call would be with the rest of the lastlog stuff, but it looked to me like it'd be ugly to make that happen. So I'm looking at two alternatives; but since I'm not that familiar with the intended extent of purpose of the functions below, I'm not sure which is the better choice. 1) Take the loginsuccess() out of do_authentication() in auth1.c and add it to do_authenticated() in session.c to provide for both protocol versions (as described below). 2) Take the loginsuccess() out of do_authentication() in auth1.c and add it to auth_log() in auth.c with appropriate conditional based on the "authenticated" argument. I'm leaning toward the second one at the moment, in part because I'd also like to move the loginfailed() call currently in do_authloop() in auth1.c into auth_log() as well. In the current location, it not only doesn't cover protocol 2, but it never seems to get called since the connection is closed before enough login failures occur. If it's in auth_log(), the right AIX call can be made regardless of what kind of authentication or protocol is used. Can anyone offer some insight for me? Thanks, =Dave Damien Miller wrote: > > On Thu, 27 Sep 2001, David Bronder wrote: > > > Somewhere between 2.9p1 and 2.9.9p2 there was a change to auth2.c that > > removed the userauth_reply() function. There were a few lines of code > > in that function, #ifdef'd with WITH_AIXAUTHENTICATE, that handled the > > AIX method of lastlog type stuff (specifically, a loginsuccess() call). > > There is a similar call in auth1.c, down in do_authentication(), which > > is still there in 2.9.9p2. > > > > So with 2.9.9p2, the lastlog stuff is handled properly if you connect > > with protocol version 1, but not with protocol version 2. Looking at > > the code a little, maybe this can be moved into do_authenticated() in > > session.c covering both the protocol versions. There's already other > > WITH_AIXAUTHENTICATE code in there, too. Not being familiar with the > > "proper" place for various steps, I don't know if this is the correct > > place, though. > > > > If that would be considered the right place for it, I can throw out a > > quick patch, I guess. > > Yes please :) > > -d > > -- > | Damien Miller \ ``E-mail attachments are the poor man's > | http://www.mindrot.org / distributed filesystem'' - Dan Geer > -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Nov 7 04:39:35 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 6 Nov 2001 18:39:35 +0100 Subject: Entropy and DSA key In-Reply-To: <20011106103937.C2288@lucent.com> References: <20011106095412.A1298@lucent.com> <20011106172336.A4527@serv01.aet.tu-cottbus.de> <20011106103937.C2288@lucent.com> Message-ID: <20011106183935.B5662@serv01.aet.tu-cottbus.de> On Tue, Nov 06, 2001 at 10:39:37AM -0600, Dave Dykstra wrote: > On Tue, Nov 06, 2001 at 05:23:36PM +0100, Lutz Jaenicke wrote: > > It does cause a delay until enough > > entropy was gathered. Granted, it would allow for a cleaner implementation > > than having the code built-in, but for understandable reasons collecting > > entropy requires the effort to collect the entropy :-) > > > Using a seed-save file helps, but somebody could steal it, so that calling > > external gatherers at the time the cryptographic routines are started up > > is an important issue. > > I don't buy that argument. If somebody has the ability to steal your > seed-save file, that means your system has already been compromised so I > don't see the point of trying to secure it further, certainly not at such a > high cost of time spent on every ssh client startup. I think the only > thing to worry about is an external attacker. With home directories on NFS protecting the seed file is difficult and accessing the seed file does not necessarily require compromising the system. The private keys are protected by a passphrase, so while I still would not like people stealing the key files, there exists an additional line of defense. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From ed at UDel.Edu Wed Nov 7 04:44:48 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 12:44:48 -0500 (EST) Subject: Entropy and DSA key In-Reply-To: <20011106103937.C2288@lucent.com> Message-ID: On Tue, 6 Nov 2001, Dave Dykstra wrote: > Date: Tue, 6 Nov 2001 10:39:37 -0600 > From: Dave Dykstra > To: Lutz.Jaenicke at aet.TU-Cottbus.DE > Cc: openssh-unix-dev at mindrot.org, mouring at etoh.eviladmin.org, > Ed Phillips , Dan Astoorian > Subject: Re: Entropy and DSA key > > On Tue, Nov 06, 2001 at 05:23:36PM +0100, Lutz Jaenicke wrote: > > I don't see yet, in how far a "one shot" prngd would be different from > > the internal entropy collection code. > > It would be the virtually the same but the advantage is it would only have > to be maintained in one place. > > > It does cause a delay until enough > > entropy was gathered. Granted, it would allow for a cleaner implementation > > than having the code built-in, but for understandable reasons collecting > > entropy requires the effort to collect the entropy :-) > > > Using a seed-save file helps, but somebody could steal it, so that calling > > external gatherers at the time the cryptographic routines are started up > > is an important issue. > > I don't buy that argument. If somebody has the ability to steal your > seed-save file, that means your system has already been compromised so I > don't see the point of trying to secure it further, certainly not at such a > high cost of time spent on every ssh client startup. I think the only > thing to worry about is an external attacker. Well put. I agree. Sometimes, in all the security "hub-bub" I think people fail to realize some of these simple things. For anyone who has slower, older systems to support (we only have approximately 100 Suns ranging from SS1+ to 6800), the fact that ssh takes 2 minutes instead of 5 seconds has immense system administrative ramifications. For example, if you want to change the root password on every system - get ready to spend the whole weekend... It seem like most of the resistance to the whole internal entropy collection thing is mainly the lack of interest in continuing support for it... as opposed to any real deficiency (that wasn't designed in). It could be better. Then, OpenSSH wouldn't rely on yet another 3rd party package - for such a basic "you can't even get started without dealing with this" need. Sure, it makes supporting OpenSSH harder (more code = more work = more user questions, etc.), but it makes it easier for the user who doesn't have to go track down the other software, get it working on their system, figure out how to make ssh use it... and then still question the OpenSSH list about its use with OpenSSH specifically. And that in turn creates more "work", not "code" work, but still support work nonetheless for those wonderful people that try to support OpenSSH. For anyone who's used ssh-1.2.x, OpenSSH is nicer, but it's also worse in this particular respect - the darn thing is unusable until you get over the stupid entropy "hurdle", which never had to be dealt with in ssh-1.2.x. Dave mentioned in a previous email that he hasn't been able to find any information stating that ssh-1.2.x was deficient due to it's entropy collection scheme - which doesn't involve running 50 commands for every client that connects. Does anyone have hard evidence stating that the ssh-1.2.x scheme is in fact, scientifically, deficient? Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Darren.Moffat at Sun.COM Wed Nov 7 04:50:37 2001 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Tue, 06 Nov 2001 09:50:37 -0800 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) References: <20011106172336.A4527@serv01.aet.tu-cottbus.de> <20011106183321.A5662@serv01.aet.tu-cottbus.de> Message-ID: <3BE822ED.2040304@Sun.COM> Lutz Jaenicke wrote: > The problem is not sshd. sshd startup only happens once and it does not > matter whether it takes 0.5 seconds or 5 seconds; the server will be up > for hours/days/weeks anyway. (Re-seeding should happen over time.) Startup time is important, both for the master listening daemon and for the children it forks to handle connections. It might not matter to you but on servers that have uptime guarantees specified in the fractions of a percent very little second on a reboot counts. 5 seconds on a test machine could translate into 30 on a production machine or older hardware. I'm infavour of removing all entropy gathering code from OpenSSH, including the use of arc4random and the private pool it keeps. I would much rather see /dev/urandom used directly each time. I have profiled this on Solaris and there wasn't a noticable difference in performance for time spent reading /dev/urandom verses using arc4random. What I did was open /dev/urandom the first time it was needed and leave it open for the duration but just read the requested number of bytes from it each time. Doing this has the side effect that rc4 can be removed from the list of required crypto algorithms. -- Darren J Moffat From ed at UDel.Edu Wed Nov 7 04:48:53 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 12:48:53 -0500 (EST) Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <20011106183321.A5662@serv01.aet.tu-cottbus.de> Message-ID: On Tue, 6 Nov 2001, Lutz Jaenicke wrote: > Date: Tue, 6 Nov 2001 18:33:21 +0100 > From: Lutz Jaenicke > To: OpenSSH Development > Subject: Re: Entropy collection in sshd (was Re: Entropy and DSA key) > > On Tue, Nov 06, 2001 at 12:18:52PM -0500, Ed Phillips wrote: > > What I don't understand about the internal entropy collection is why can't > > sshd just run the commands periodically just like prngd, and keep a > > running, stirred pool of random numbers to use when a client connects? > [more text removed] > > The problem is not sshd. sshd startup only happens once and it does not > matter whether it takes 0.5 seconds or 5 seconds; the server will be up > for hours/days/weeks anyway. (Re-seeding should happen over time.) > > The problem is with the client!!! ssh client processes are called by the > user to log into the server and the response time is an important issue > here! I'm not following you... the problem of "it takes 2 freakin minutes to get logged into my SS1+" is a direct result of entropy collection performed by sshd. "ssh -v -v -v" show a very long pause, while truss of sshd shows it running the prng commands. On really slow systems, the commands take longer that 200 milliseconds to run, so that get timed-out, and that cause less entropy to be collected, and more commands to be run in sshd. I'm talking about sshd with the "internal" prng commands - not with PRNGD... Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From martyn.a.roberts at bt.com Wed Nov 7 04:58:54 2001 From: martyn.a.roberts at bt.com (martyn.a.roberts at bt.com) Date: Tue, 6 Nov 2001 17:58:54 -0000 Subject: Solaris 7 changing password via PAM Message-ID: Hi, I am having a problem with the issue of changing the password for an expired user (passed -f ). The version of Openssh is 2.9.9p3 compiled with gcc 2.95.3, configured --with-pam. The user can login fine when the password is not expired. Once the password is expired the user is connected and told the password has expired and is asked to change it. The user is prompted for the old password, this is then entered (without echoing, - the RP_ALLOW_STDIN code change has been applied) as soon as carriage-return is hit the used it disconnected. The error appears to be with the chauthtok function call. Building the same code functions correctly on Solaris 8. I have had to return the box to work (albeit with a non expiry changing Openssh) so will take a little while if I have to get hold of lots of debug logs. Am hoping that someone has already seen this? (fingers crossed ;-) Martyn Roberts NoMartyn.a.SpamRoberts at bt.reallynospam.com (Guess you can work the above out) From djast at cs.toronto.edu Wed Nov 7 05:08:43 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 6 Nov 2001 13:08:43 -0500 Subject: Entropy and DSA key In-Reply-To: Your message of "Tue, 06 Nov 2001 11:23:36 EST." <20011106172336.A4527@serv01.aet.tu-cottbus.de> Message-ID: <01Nov6.130846edt.453149-15184@jane.cs.toronto.edu> On Tue, 06 Nov 2001 11:23:36 EST, Lutz Jaenicke writes: > > I don't see yet, in how far a "one shot" prngd would be different from > the internal entropy collection code. It does cause a delay until enough > entropy was gathered. Granted, it would allow for a cleaner implementation > than having the code built-in, but for understandable reasons collecting > entropy requires the effort to collect the entropy :-) A cleaner implementation is a worthwhile goal. There should be a method of gathering entropy available which will, to the degree that it's possible, always work. OpenSSH's (or OpenSSL's) interface to that method should be as clean as possible; a command which produces the entropy on stdout would seem to be the most obvious and flexible implementation for such a method. I think the ideal would be to see the problem addressed in OpenSSL rather than in OpenSSH. It already uses /dev/random if it's available, and the next version will look for an EGD/PRNGD socket in a number of "standard" locations. It might make sense if OpenSSL could run a command as a last resort. A huge advantage of a "one-shot" invocation of prngd would be that such a command would have all of the same sources of entropy available as prngd itself (including such resources as seed files, which should be stirred regularly during prngd's normal course of operation). It adds robustness, at the cost of efficiency but not the cost of substantially poorer entropy. Moreover, OpenSSH would no longer have to keep its own seed file--and this circumvents the NFS issue, among others. In summary, the way I'd like to see things is: - OpenSSH: doesn't need to do *anything* explicit to seed OpenSSL's PRNG - OpenSSL: tries, in order: a) /dev/[u]random b) connecting to PRNGD c) running an entropy-gathering program--let's call it "entropy-client" - PRNGD: operates much as it does now (but rewrites its seed file more often) - entropy-client: if PRNGD isn't running, runs the same programs PRNGD would to get its entropy (albeit less efficiently), mixes in and perturbs the same seed file. Note that "entropy-client" would have to be a privileged program, since the seed file is sensitive. Managing the seed file is important: you don't want to have a situation where the method you fall back to does not have good entropy because that method is seldom used, and this is why I think PRNGD and the one-shot command should be working together. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From dwd at bell-labs.com Wed Nov 7 05:08:51 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 12:08:51 -0600 Subject: Entropy and DSA key In-Reply-To: <20011106183935.B5662@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Nov 06, 2001 at 06:39:35PM +0100 References: <20011106095412.A1298@lucent.com> <20011106172336.A4527@serv01.aet.tu-cottbus.de> <20011106103937.C2288@lucent.com> <20011106183935.B5662@serv01.aet.tu-cottbus.de> Message-ID: <20011106120851.B3818@lucent.com> On Tue, Nov 06, 2001 at 06:39:35PM +0100, Lutz Jaenicke wrote: > On Tue, Nov 06, 2001 at 10:39:37AM -0600, Dave Dykstra wrote: > > On Tue, Nov 06, 2001 at 05:23:36PM +0100, Lutz Jaenicke wrote: ... > > > Using a seed-save file helps, but somebody could steal it, so that calling > > > external gatherers at the time the cryptographic routines are started up > > > is an important issue. > > > > I don't buy that argument. If somebody has the ability to steal your > > seed-save file, that means your system has already been compromised so I > > don't see the point of trying to secure it further, certainly not at such a > > high cost of time spent on every ssh client startup. I think the only > > thing to worry about is an external attacker. > > With home directories on NFS protecting the seed file is difficult and > accessing the seed file does not necessarily require compromising the > system. The private keys are protected by a passphrase, so while I still > would not like people stealing the key files, there exists an additional > line of defense. I have never seen a NFS cluster where home directories aren't exported read-write. Perhaps in obscure cases they might also be exported read-only to some more servers, but that's hardly relevant. If they are exported read-write, and assuming they are using a traditional non-kerberized NFS, then anybody who can get physical access to one of the workstations or anybody can spoof one in the DNS (which is trivial) can easily get write access to all users' home directories. The attacker can do absolutely anything including modifying the user's .profile, .ssh/authorized_keys or .rhosts, and from there log on and do anything they want. In that case, who cares about somebody having read access to a seed file? It makes no difference to overall security. Right? There's no point worrying about people who use non-kerberized NFS, and kerberized NFS doesn't have a problem. - Dave Dykstra From dwd at bell-labs.com Wed Nov 7 05:21:02 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 12:21:02 -0600 Subject: Entropy and DSA key In-Reply-To: <01Nov6.130846edt.453149-15184@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Tue, Nov 06, 2001 at 01:08:43PM -0500 References: <20011106172336.A4527@serv01.aet.tu-cottbus.de> <01Nov6.130846edt.453149-15184@jane.cs.toronto.edu> Message-ID: <20011106122102.B5276@lucent.com> On Tue, Nov 06, 2001 at 01:08:43PM -0500, Dan Astoorian wrote: ... > - entropy-client: if PRNGD isn't running, runs the same programs > PRNGD would to get its entropy (albeit less efficiently), mixes in > and perturbs the same seed file. > > Note that "entropy-client" would have to be a privileged program, since > the seed file is sensitive. Managing the seed file is important: you > don't want to have a situation where the method you fall back to does > not have good entropy because that method is seldom used, and this is > why I think PRNGD and the one-shot command should be working together. I was with you until that point. It's essential for me that the seed file be able to be kept per user because I have no way of installing a privileged program on most of the computers in my distribution. This is the way ssh 1.2.27 did it. - Dave Dykstra From ed at UDel.Edu Wed Nov 7 05:23:38 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 13:23:38 -0500 (EST) Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <3BE822ED.2040304@Sun.COM> Message-ID: On Tue, 6 Nov 2001, Darren J Moffat wrote: > Date: Tue, 06 Nov 2001 09:50:37 -0800 > From: Darren J Moffat > To: Lutz Jaenicke > Cc: OpenSSH Development > Subject: Re: Entropy collection in sshd (was Re: Entropy and DSA key) > > > > Lutz Jaenicke wrote: > > > The problem is not sshd. sshd startup only happens once and it does not > > matter whether it takes 0.5 seconds or 5 seconds; the server will be up > > for hours/days/weeks anyway. (Re-seeding should happen over time.) > > > Startup time is important, both for the master listening daemon and > for the children it forks to handle connections. > > It might not matter to you but on servers that have uptime guarantees > specified in the fractions of a percent very little second on a reboot > counts. > > 5 seconds on a test machine could translate into 30 on a production > machine or older hardware. > > I'm infavour of removing all entropy gathering code from OpenSSH, > including the use of arc4random and the private pool it keeps. I would > much rather see /dev/urandom used directly each time. I have > profiled this on Solaris and there wasn't a noticable difference in > performance for time spent reading /dev/urandom verses using arc4random. > What I did was open /dev/urandom the first time it was needed and leave > it open for the duration but just read the requested number of bytes > from it each time. Doing this has the side effect that rc4 can be > removed from the list of required crypto algorithms. No difference? Between "internal" entropy collection and /dev/urandom? I'm not following... By the way, can you direct me to distributions of /dev/urandom for Sol2.3, Sol2.5, Sol2.5.1, Sol2.6, Sol7 and Sol8? I'd gladly switch to /dev/urandom if all of our Sun systems could run it... especially the Sol2.3 IPCs that we still have hanging around in production... ;-) Thanks! Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Wed Nov 7 05:33:40 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 6 Nov 2001 13:33:40 -0500 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <3BE822ED.2040304@Sun.COM>; from Darren.Moffat@Sun.COM on Tue, Nov 06, 2001 at 09:50:37AM -0800 References: <20011106172336.A4527@serv01.aet.tu-cottbus.de> <20011106183321.A5662@serv01.aet.tu-cottbus.de> <3BE822ED.2040304@Sun.COM> Message-ID: <20011106133339.X5739@sm2p1386swk.wdr.com> On Tue, Nov 06, 2001 at 09:50:37AM -0800, Darren J Moffat wrote: > Lutz Jaenicke wrote: > > The problem is not sshd. sshd startup only happens once and it does not > > matter whether it takes 0.5 seconds or 5 seconds; the server will be up > > for hours/days/weeks anyway. (Re-seeding should happen over time.) > > Startup time is important, both for the master listening daemon and > for the children it forks to handle connections. > > It might not matter to you but on servers that have uptime guarantees > specified in the fractions of a percent very little second on a reboot > counts. > > 5 seconds on a test machine could translate into 30 on a production > machine or older hardware. Agreed. For example, the Sun cryptorand daemon takes longer to start up on machines with lots of RAM, and you may have to wait minutes before you can login to a rebooted server, even though it's up already. > I'm infavour of removing all entropy gathering code from OpenSSH, > including the use of arc4random and the private pool it keeps. I would > much rather see /dev/urandom used directly each time. I have > profiled this on Solaris and there wasn't a noticable difference in > performance for time spent reading /dev/urandom verses using arc4random. > What I did was open /dev/urandom the first time it was needed and leave > it open for the duration but just read the requested number of bytes > from it each time. Doing this has the side effect that rc4 can be > removed from the list of required crypto algorithms. Darren, Does this mean that Sun will put out a /dev/urandom? For any OS version earlier than Solaris 9? My current thoughts on handling /dev/[u]random on Solaris 26, 7 and 8 in the absence of something concret from Sun are: - use ANDIrand for /dev/urandom -- it's non-blocking - use Sun's cryptorand for /dev/random -- it's blocking - at boot time seed /dev/urandom with a root-read-only seed file - periodically re-seed /dev/urandom with data from /dev/random - periodically re-create the boot-time seed file from output of /dev/random Ideally there'd be a /dev/urandom non-blocking driver that knows how to gather entropy; ANDIrand is very weak in that area. > -- > Darren J Moffat Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ed at UDel.Edu Wed Nov 7 05:37:48 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 13:37:48 -0500 (EST) Subject: Solaris 7 changing password via PAM In-Reply-To: Message-ID: On Tue, 6 Nov 2001 martyn.a.roberts at bt.com wrote: > Date: Tue, 6 Nov 2001 17:58:54 -0000 > From: martyn.a.roberts at bt.com > To: openssh-unix-dev at mindrot.org > Subject: Solaris 7 changing password via PAM > > Hi, > > I am having a problem with the issue of changing the password for an expired > user (passed -f ). > The version of Openssh is 2.9.9p3 compiled with gcc 2.95.3, configured > --with-pam. > > The user can login fine when the password is not expired. Once the password > is expired the user is connected and told the password has expired and is > asked to change it. The user is prompted for the old password, this is then > entered (without echoing, - the RP_ALLOW_STDIN code change has been applied) > as soon as carriage-return is hit the used it disconnected. > The error appears to be with the chauthtok function call. Does sshd dump core? What's the stack trace? That'd help a lot - knowing what the calling routine was (before it got into PAM-land)... > Building the same code functions correctly on Solaris 8. > I have had to return the box to work (albeit with a non expiry changing > Openssh) so will take a little while if I have to get hold of lots of debug > logs. Am hoping that someone has already seen this? (fingers crossed ;-) Oh... well can you sneak in and run adb on the core? Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Darren.Moffat at eng.sun.com Wed Nov 7 05:43:23 2001 From: Darren.Moffat at eng.sun.com (Darren J Moffat) Date: Tue, 06 Nov 2001 10:43:23 -0800 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) References: Message-ID: <3BE82F4B.5000807@Eng.Sun.COM> Ed Phillips wrote: > > No difference? Between "internal" entropy collection and /dev/urandom? > I'm not following... What I meant was that there was no performance difference when using /dev/urandom directly verses via arc4random. NOT internal gathering verses /dev/urandom. I was trying to saying that the pool held by arc4random didn't seem to by me anything. > By the way, can you direct me to distributions of /dev/urandom for Sol2.3, > Sol2.5, Sol2.5.1, Sol2.6, Sol7 and Sol8? I can't point you to a Sun supported Solution but there is: http://www.cosy.sbg.ac.at/~andi/ > I'd gladly switch to /dev/urandom if all of our Sun systems could run > it... especially the Sol2.3 IPCs that we still have hanging around in > production... ;-) You do realise that there will never be security patches for 2.3 so I strongly suggest you upgrade if you care about securtiy on those machines. -- Darren J Moffat From martyn.a.roberts at bt.com Wed Nov 7 05:55:03 2001 From: martyn.a.roberts at bt.com (martyn.a.roberts at bt.com) Date: Tue, 6 Nov 2001 18:55:03 -0000 Subject: Solaris 7 changing password via PAM reply Message-ID: Hi, Sorry no core dumps, the sshd programme is perfectly happy just fails to consider changing the password. Cheers, Martyn -----Original Message----- From: Ed Phillips [mailto:ed at UDel.Edu] Sent: 06 November 2001 18:38 To: Roberts,M,Martyn,IVLH4 C Cc: openssh-unix-dev Subject: Re: Solaris 7 changing password via PAM On Tue, 6 Nov 2001 martyn.a.roberts at bt.com wrote: > Date: Tue, 6 Nov 2001 17:58:54 -0000 > From: martyn.a.roberts at bt.com > To: openssh-unix-dev at mindrot.org > Subject: Solaris 7 changing password via PAM > > Hi, > > I am having a problem with the issue of changing the password for an expired > user (passed -f ). > The version of Openssh is 2.9.9p3 compiled with gcc 2.95.3, configured > --with-pam. > > The user can login fine when the password is not expired. Once the password > is expired the user is connected and told the password has expired and is > asked to change it. The user is prompted for the old password, this is then > entered (without echoing, - the RP_ALLOW_STDIN code change has been applied) > as soon as carriage-return is hit the used it disconnected. > The error appears to be with the chauthtok function call. Does sshd dump core? What's the stack trace? That'd help a lot - knowing what the calling routine was (before it got into PAM-land)... > Building the same code functions correctly on Solaris 8. > I have had to return the box to work (albeit with a non expiry changing > Openssh) so will take a little while if I have to get hold of lots of debug > logs. Am hoping that someone has already seen this? (fingers crossed ;-) Oh... well can you sneak in and run adb on the core? Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From djast at cs.toronto.edu Wed Nov 7 06:06:41 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 6 Nov 2001 14:06:41 -0500 Subject: Entropy and DSA key In-Reply-To: Your message of "Tue, 06 Nov 2001 13:21:02 EST." <20011106122102.B5276@lucent.com> Message-ID: <01Nov6.140642edt.453142-15184@jane.cs.toronto.edu> On Tue, 06 Nov 2001 13:21:02 EST, Dave Dykstra writes: > On Tue, Nov 06, 2001 at 01:08:43PM -0500, Dan Astoorian wrote: > > Note that "entropy-client" would have to be a privileged program, since > > the seed file is sensitive. Managing the seed file is important: you > > don't want to have a situation where the method you fall back to does > > not have good entropy because that method is seldom used, and this is > > why I think PRNGD and the one-shot command should be working together. > > I was with you until that point. It's essential for me that the seed file > be able to be kept per user because I have no way of installing a > privileged program on most of the computers in my distribution. This is the > way ssh 1.2.27 did it. That's not the situation for most users. I don't know many people who can install sshd without at least some administrative privileges. BTW, "privileged program" need not imply "setuid-root"; the seed file could belong to a dedicated non-root user, and the program setuid to that user. There are pros and cons to having PRNGD run as root, which I won't get into; suffice it to say I've suggested to Lutz in the past that it would be a useful feature if PRNGD could be configured to rescind root privileges after binding to its socket, and he says it's on his to-do list for PRNGD. For the general case, I stand behind my proposed design. Cases such as Dave's would require compromises, such as an entropy-client which could run unprivileged, and an OpenSSL that was configured to look in a non-standard location for the PRNGD socket (since an unprivileged PRNGD couldn't bind to /var/run/entropy or the other standard locations), etc. Such tweaks aren't a big deal. My questions are whether my proposed design as a whole is sound, practical, and implementable, whether anyone can suggest improvements to it, and whether any of the developers for all of the projects involved (OpenSSL, OpenSSH, and PRNGD) like these ideas enough to get together and implement any of them. :-) -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From dwd at bell-labs.com Wed Nov 7 06:16:06 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 13:16:06 -0600 Subject: Entropy and DSA key In-Reply-To: <01Nov6.140642edt.453142-15184@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Tue, Nov 06, 2001 at 02:06:41PM -0500 References: <20011106122102.B5276@lucent.com> <01Nov6.140642edt.453142-15184@jane.cs.toronto.edu> Message-ID: <20011106131606.E5772@lucent.com> On Tue, Nov 06, 2001 at 02:06:41PM -0500, Dan Astoorian wrote: > On Tue, 06 Nov 2001 13:21:02 EST, Dave Dykstra writes: > > I was with you until that point. It's essential for me that the seed file > > be able to be kept per user because I have no way of installing a > > privileged program on most of the computers in my distribution. This is the > > way ssh 1.2.27 did it. > > That's not the situation for most users. I don't know many people who > can install sshd without at least some administrative privileges. Right, but I have a lot of users of the ssh client that don't have sshd installed on their systems. - Dave Dykstra From tim at mcgarry.ch Wed Nov 7 06:14:26 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 6 Nov 2001 20:14:26 +0100 Subject: Unkerberized NFS References: <20011106095412.A1298@lucent.com> <20011106172336.A4527@serv01.aet.tu-cottbus.de> <20011106103937.C2288@lucent.com> <20011106183935.B5662@serv01.aet.tu-cottbus.de> <20011106120851.B3818@lucent.com> Message-ID: <002401c166f7$44ce2380$c802a8c0@cablecom.ch> I disagree, about NFS, obviously any smart organisation will ensure that NFS is secured with kerberos BEFORE they allow RSA authentication. But those who dont know better shouldn't find that installing OpenSSH actually reduces the system security. This issue of NFS security comes up quite often and the response is usually "secure your NFS", isn't it time that sshd_config an flag something like ISYOURNFSSECURE=yes|no If the answer is no, it's very easy to modify auth2.c etc with a few calls to fstatvfs to avoid trusting files from an unsafe location. yes I know AuthorizedKeysFile can avoid this problem, but it wasn't available in the portable version till 299, and even after that I'm sure it's not as widely used as it should be. Tim McGarry ----- Original Message ----- From: "Dave Dykstra" To: Cc: ; ; "Ed Phillips" ; "Dan Astoorian" Sent: Tuesday, November 06, 2001 7:08 PM Subject: Re: Entropy and DSA key > On Tue, Nov 06, 2001 at 06:39:35PM +0100, Lutz Jaenicke wrote: > > On Tue, Nov 06, 2001 at 10:39:37AM -0600, Dave Dykstra wrote: > > > On Tue, Nov 06, 2001 at 05:23:36PM +0100, Lutz Jaenicke wrote: > ... > > > > Using a seed-save file helps, but somebody could steal it, so that calling > > > > external gatherers at the time the cryptographic routines are started up > > > > is an important issue. > > > > > > I don't buy that argument. If somebody has the ability to steal your > > > seed-save file, that means your system has already been compromised so I > > > don't see the point of trying to secure it further, certainly not at such a > > > high cost of time spent on every ssh client startup. I think the only > > > thing to worry about is an external attacker. > > > > With home directories on NFS protecting the seed file is difficult and > > accessing the seed file does not necessarily require compromising the > > system. The private keys are protected by a passphrase, so while I still > > would not like people stealing the key files, there exists an additional > > line of defense. > > > I have never seen a NFS cluster where home directories aren't exported > read-write. Perhaps in obscure cases they might also be exported read-only > to some more servers, but that's hardly relevant. If they are exported > read-write, and assuming they are using a traditional non-kerberized NFS, > then anybody who can get physical access to one of the workstations or > anybody can spoof one in the DNS (which is trivial) can easily get write > access to all users' home directories. The attacker can do absolutely > anything including modifying the user's .profile, .ssh/authorized_keys or > .rhosts, and from there log on and do anything they want. In that case, > who cares about somebody having read access to a seed file? It makes no > difference to overall security. Right? There's no point worrying about > people who use non-kerberized NFS, and kerberized NFS doesn't have a > problem. > > - Dave Dykstra > From djast at cs.toronto.edu Wed Nov 7 06:29:35 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 6 Nov 2001 14:29:35 -0500 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: Your message of "Tue, 06 Nov 2001 13:33:40 EST." <20011106133339.X5739@sm2p1386swk.wdr.com> Message-ID: <01Nov6.142937edt.453142-15184@jane.cs.toronto.edu> On Tue, 06 Nov 2001 13:33:40 EST, Nicolas Williams writes: > > Does this mean that Sun will put out a /dev/urandom? For any OS version > earlier than Solaris 9? Sun addresses that question in Symptoms and Resolutions Database article 27606: http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=fsrdb%2F27606 (Executive summary: Solaris 2.6 and later have the unbundled SUNWski package available; other releases can be accommodated with public domain packages like ANDIrand.) -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From dwd at bell-labs.com Wed Nov 7 06:30:17 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 13:30:17 -0600 Subject: Unkerberized NFS In-Reply-To: <002401c166f7$44ce2380$c802a8c0@cablecom.ch>; from tim@mcgarry.ch on Tue, Nov 06, 2001 at 08:14:26PM +0100 References: <20011106095412.A1298@lucent.com> <20011106172336.A4527@serv01.aet.tu-cottbus.de> <20011106103937.C2288@lucent.com> <20011106183935.B5662@serv01.aet.tu-cottbus.de> <20011106120851.B3818@lucent.com> <002401c166f7$44ce2380$c802a8c0@cablecom.ch> Message-ID: <20011106133017.G5772@lucent.com> On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > I disagree, about NFS, obviously any smart organisation will ensure that NFS > is secured with kerberos BEFORE they allow RSA authentication. > But those who dont know better shouldn't find that installing OpenSSH > actually reduces the system security. It does not reduce system security. If you are exporting a filesystem with unkerberized NFS read-write, anybody can read and write any (usually non-root) file, including many things the user executes such as .profile so even without .rhosts or .ssh/authorized_keys it is totally wide open. Having SSH worry about unkerberized NFS is like trying to put a slightly stronger lock on the door of a safe that has a whole wall missing. - Dave Dykstra From tim at mcgarry.ch Wed Nov 7 06:32:20 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 6 Nov 2001 20:32:20 +0100 Subject: Unkerberized NFS References: <20011106095412.A1298@lucent.com> <20011106172336.A4527@serv01.aet.tu-cottbus.de> <20011106103937.C2288@lucent.com> <20011106183935.B5662@serv01.aet.tu-cottbus.de> <20011106120851.B3818@lucent.com> <002401c166f7$44ce2380$c802a8c0@cablecom.ch> <20011106133017.G5772@lucent.com> Message-ID: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> I suppose your right, but if you edit someones .profile, you can easily compromise the boxes they log into. If you edit authorized_keys, access to every box in the organisation could be possible Tim McGarry ----- Original Message ----- From: "Dave Dykstra" To: "Tim McGarry" Cc: Sent: Tuesday, November 06, 2001 8:30 PM Subject: Re: Unkerberized NFS > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > I disagree, about NFS, obviously any smart organisation will ensure that NFS > > is secured with kerberos BEFORE they allow RSA authentication. > > But those who dont know better shouldn't find that installing OpenSSH > > actually reduces the system security. > > It does not reduce system security. If you are exporting a filesystem with > unkerberized NFS read-write, anybody can read and write any (usually non-root) > file, including many things the user executes such as .profile so even > without .rhosts or .ssh/authorized_keys it is totally wide open. Having > SSH worry about unkerberized NFS is like trying to put a slightly stronger > lock on the door of a safe that has a whole wall missing. > > - Dave Dykstra > From mouring at etoh.eviladmin.org Wed Nov 7 06:38:40 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Nov 2001 13:38:40 -0600 (CST) Subject: Entropy and DSA key In-Reply-To: <01Nov6.130846edt.453149-15184@jane.cs.toronto.edu> Message-ID: On Tue, 6 Nov 2001, Dan Astoorian wrote: [..] > In summary, the way I'd like to see things is: > - OpenSSH: doesn't need to do *anything* explicit to seed OpenSSL's > PRNG > - OpenSSL: tries, in order: > a) /dev/[u]random > b) connecting to PRNGD The following two things could be done today minus support for PRNGD sockets. Until that feature is supported it will not simplify the code very much (from what I can see). > c) running an entropy-gathering program--let's call it > "entropy-client" > - PRNGD: operates much as it does now (but rewrites its seed file > more often) > - entropy-client: if PRNGD isn't running, runs the same programs > PRNGD would to get its entropy (albeit less efficiently), mixes in > and perturbs the same seed file. > In general the idea is fine.. Assuming.. a) You get people to upgrade OpenSSL to the 'lastest'. Which is a hard sell in some cases. (RAND_egd() has existed since 0.9.5) b) For older installs you still need some 'fall back'. Or pretty much your saying 'upgrade or leave'. c) How does this support OpenSSL staticly compiled into OpenSSH (something I would not support, but others may be required for multiple location support). d) a 'One shot' PRNGd may be another way to look at it, but it is no better/worse than linking to a libprngd.a or libegd.a or what-not. I would perfer OpenSSL handle all the entropy behind the scenes. It would make our life easier in the portable group. However it only removes around 1000 lines of code in a 55,000 line project (I'm refering to portable. OpenBSD's ssh tree is 45,000 lines.). No matter the way you cut it. Not everyone will be happy until /dev/{u}random suddenly appears on every box in the world. I do have servers that lack /dev/{u}random so I am also affecting myself. As I told someone from IBM, I'm looking at a 2 - 3 year phase over. Not something that will happen in 3.1 in 6 months or so. Yanking out functionality that people know and depend on is always a *BAD* thing without phasing in a new feature to replace it. - Ben From ed at UDel.Edu Wed Nov 7 06:43:04 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 14:43:04 -0500 (EST) Subject: Solaris 7 changing password via PAM reply In-Reply-To: Message-ID: Maybe Darren can reproduce this? On Tue, 6 Nov 2001 martyn.a.roberts at bt.com wrote: > Date: Tue, 6 Nov 2001 18:55:03 -0000 > From: martyn.a.roberts at bt.com > To: openssh-unix-dev at mindrot.org > Subject: RE: Solaris 7 changing password via PAM reply > > Hi, > > Sorry no core dumps, the sshd programme is perfectly happy just fails to > consider changing the password. > > Cheers, > Martyn > > -----Original Message----- > From: Ed Phillips [mailto:ed at UDel.Edu] > Sent: 06 November 2001 18:38 > To: Roberts,M,Martyn,IVLH4 C > Cc: openssh-unix-dev > Subject: Re: Solaris 7 changing password via PAM > > > On Tue, 6 Nov 2001 martyn.a.roberts at bt.com wrote: > > > Date: Tue, 6 Nov 2001 17:58:54 -0000 > > From: martyn.a.roberts at bt.com > > To: openssh-unix-dev at mindrot.org > > Subject: Solaris 7 changing password via PAM > > > > Hi, > > > > I am having a problem with the issue of changing the password for an > expired > > user (passed -f ). > > The version of Openssh is 2.9.9p3 compiled with gcc 2.95.3, configured > > --with-pam. > > > > The user can login fine when the password is not expired. Once the > password > > is expired the user is connected and told the password has expired and is > > asked to change it. The user is prompted for the old password, this is > then > > entered (without echoing, - the RP_ALLOW_STDIN code change has been > applied) > > as soon as carriage-return is hit the used it disconnected. > > The error appears to be with the chauthtok function call. > > Does sshd dump core? What's the stack trace? That'd help a lot - knowing > what the calling routine was (before it got into PAM-land)... > > > Building the same code functions correctly on Solaris 8. > > I have had to return the box to work (albeit with a non expiry changing > > Openssh) so will take a little while if I have to get hold of lots of > debug > > logs. Am hoping that someone has already seen this? (fingers crossed ;-) > > Oh... well can you sneak in and run adb on the core? > > Thanks, > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From mouring at etoh.eviladmin.org Wed Nov 7 06:44:55 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Nov 2001 13:44:55 -0600 (CST) Subject: Entropy and DSA key In-Reply-To: <20011106095412.A1298@lucent.com> Message-ID: On Tue, 6 Nov 2001, Dave Dykstra wrote: > > Before someone jumps up and starts screaming. I'm not proposing we > > suddenly drop it. The proposal is this (not set in stone mind you): > > > > 3.1 - Make internal entropy --with-* option and not enabled by default. > > Provide warnings at that screen and provide locations to PRNGd. Warn > > about how it will be removed in a future release. > > I don't mind a configure option. > So can we at least agree that Internal Entropy should *NOT* be enabled unless someone enables it via a ./configure option? At least starting in 3.1 and later? > > 3.5 - ? Provide ability to link with a libprngd.a instead of compiling w/ > > our internal entropy. > > No problem. I assume libprngd.a would be part of the prngd package then, > not the OpenSSH package, and since you wouldn't have to maintain it, it > would make your life easier. > That was my initial idea yes. > > 4.0 - ? Remove internal entropy code. > > Are you saying you would continue support of libprngd.a? If so, why not > take out the internal entropy code at the same time you switch to libprngd.a > in 3.5? > No. In my world view there needs to be an overlap. A few releases of 'warning' that the internal entropy code is being removed before it actually occurs. This should be reserved for major release numbers. - Ben From mouring at etoh.eviladmin.org Wed Nov 7 06:46:35 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Nov 2001 13:46:35 -0600 (CST) Subject: Unkerberized NFS In-Reply-To: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> Message-ID: seed files on NFS.. My only concern is packet sniffing. How may NFS connetions are encryped now days? - Ben On Tue, 6 Nov 2001, Tim McGarry wrote: > I suppose your right, but if you edit someones .profile, you can easily > compromise the boxes they log into. If you edit authorized_keys, access to > every box in the organisation could be possible > > Tim McGarry > > ----- Original Message ----- > From: "Dave Dykstra" > To: "Tim McGarry" > Cc: > Sent: Tuesday, November 06, 2001 8:30 PM > Subject: Re: Unkerberized NFS > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > > I disagree, about NFS, obviously any smart organisation will ensure that > NFS > > > is secured with kerberos BEFORE they allow RSA authentication. > > > But those who dont know better shouldn't find that installing OpenSSH > > > actually reduces the system security. > > > > It does not reduce system security. If you are exporting a filesystem > with > > unkerberized NFS read-write, anybody can read and write any (usually > non-root) > > file, including many things the user executes such as .profile so even > > without .rhosts or .ssh/authorized_keys it is totally wide open. Having > > SSH worry about unkerberized NFS is like trying to put a slightly stronger > > lock on the door of a safe that has a whole wall missing. > > > > - Dave Dykstra > > > > From jean.bouchard at courriel.polymtl.ca Wed Nov 7 04:19:19 2001 From: jean.bouchard at courriel.polymtl.ca (Jean Bouchard) Date: Tue, 6 Nov 2001 12:19:19 -0500 Subject: problem compiling on a SParc4 Sun4m Solaris2.6 Message-ID: I am working with Solaris 2.6 and with the version of openssh 2.9.9-p2 I was able to compile for a UltraSpar 5 Sun4u with no problem. But fot a Sparc4 Sun4m i'm getting this message: ./ssh : Exec format error. Wrong Architechture. Do you have a hit why it's not working, is there and option i have to set? thank you for your help jean ============================================ Jean Bouchard Technicien en Informatique au d?partement de G?nie ?lectrique,laboratoire de (VLSI et T?L?COMM). ?cole Polytechnique de Montr?al 2900 Edouard Monpetit Montr?al, Qu?bec H3T 1J4 Local D-5234 T?l: (514) 340-4711 poste 4808 Fax: (514) 340-4147 Courriel: jean.bouchard at polymtl.ca ============================================ From gert at greenie.muc.de Wed Nov 7 06:57:01 2001 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 6 Nov 2001 20:57:01 +0100 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: ; from Ed Phillips on Tue, Nov 06, 2001 at 12:48:53PM -0500 References: <20011106183321.A5662@serv01.aet.tu-cottbus.de> Message-ID: <20011106205701.A22645@greenie.muc.de> Hi, On Tue, Nov 06, 2001 at 12:48:53PM -0500, Ed Phillips wrote: > I'm not following you... the problem of "it takes 2 freakin minutes to get > logged into my SS1+" is a direct result of entropy collection performed by > sshd. No, it's not. I use NetBSD on a Sparc LX with /dev/random, and ssh takes still 2 minutes - the delay is NOT caused by the random number generation but by slow crypto on ancient Sparc hardware. ssh protocol 1 is much quicker (and also needs random). See the thread on slow connections that happened here about three days ago. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From ed at UDel.Edu Wed Nov 7 07:03:10 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 15:03:10 -0500 (EST) Subject: Entropy and DSA key Message-ID: On Tue, 6 Nov 2001, Dan Astoorian wrote: > Date: Tue, 6 Nov 2001 13:23:58 -0500 > From: Dan Astoorian > To: Dave Dykstra > Cc: Ed Phillips > Subject: Re: Entropy and DSA key > > On Tue, 06 Nov 2001 10:54:12 EST, Dave Dykstra writes: > > > On Mon, 5 Nov 2001, Ed Phillips wrote: > > > > > > > Is there any way to compile openssh so that it will use prngd, but if it' > > s > > > > not answering, use the compiled-in prng-like routines? > > > > In addition to Dan Astoorian's suggestion, you could try my patch which is > > in the mailing list archive in a thread beginning at > > > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99193668118573&w=2 > > > > It allows you to select any of /dev/random, prngd, or internal entropy > > sources and if it can't find one it will go on to the next. > > (Removed openssh-unix-dev and others from recipients--it's getting noisy > in here.) > > Correct me if I'm wrong, Dave, but my recollection is that your patch > goes on to the next method if it finds that prngd is not _configured_ > (i.e., if the socket doesn't exist), as distinct from if it's "not > answering." If PRNGD has died, your patch doesn't use internal entropy > sources. Mine does fall back in that case, but is a bit less efficient > in the general case (because it always writes a seed file even when > connecting to PRNGD, for example). > > It's not clear to me which problem Ed was looking to solve, but I > thought this was worth pointing out. I was hoping that OpenSSH could be compile (with some configure options that already exist) to try the PRNGD socket first, then if it's not there or not answering, run the "internal" entropy collection code. Then we wandered into a discussion about whether or not OpenSSH should even have the ssh_prng_cmds, run them from sshd, maintain all that extra code, etc. I've seen some good arguments for and against it. My preference is close to what Dan has suggested for the order of where sshd should look when trying to get some random bits: 1) Try /dev/[u]random. 2) Try PRNGD. 3) Try an improved "internal entropy collection" method that doesn't involving running commands for each client connection. I don't know exactly how /dev/urandom or PRNGD work, so I don't know if it's possible to tell whether they're running and listening, or out of entropy, or just not answering... in a timely enough manner to decide to "punt" and run some commands. Sure, we can sit back and say: "Pester Sun for a /dev/[u]random!"... but there are way too many Sun/Solaris boxes out there in production, and Sun is not making a /dev/[u]random for Solaris 2.x < Sol9 - that seems pretty clear. Maybe some day when we have upgraded all the production boxes to Sol10 (Solaris 8+ doesn't run on older machines tho'), THEN we can just use /dev/[u]random for OpenSSH. Until then, the ANDIrand solution doesn't run on just ANY version of Solaris, and that IMO is worse than a stock Solaris ssh_prng_cmds file. PRNGD is a nice tool and a "good" solution for Solaris - but you still have to worry about making it run the right set of commands, just like in the ssh_prng_cmds file with the internal entropy collection of OpenSSH. It'd be nice to improve the internal routines... for those who don't have the luxury of upgrading to the latest OS version or ditching the old hardware or whose vendor won't backport /dev/[u]random to it's older OS versions... Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Wed Nov 7 07:08:19 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 6 Nov 2001 15:08:19 -0500 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <01Nov6.142937edt.453142-15184@jane.cs.toronto.edu>; from Dan Astoorian on Tue, Nov 06, 2001 at 02:29:35PM -0500 References: <20011106133339.X5739@sm2p1386swk.wdr.com> <01Nov6.142937edt.453142-15184@jane.cs.toronto.edu> Message-ID: <20011106150819.U26615@wdr.com> On Tue, Nov 06, 2001 at 02:29:35PM -0500, Dan Astoorian wrote: > On Tue, 06 Nov 2001 13:33:40 EST, Nicolas Williams writes: > > > > Does this mean that Sun will put out a /dev/urandom? For any OS version > > earlier than Solaris 9? > > Sun addresses that question in Symptoms and Resolutions Database article > 27606: > > http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=fsrdb%2F27606 > > (Executive summary: Solaris 2.6 and later have the unbundled SUNWski > package available; other releases can be accommodated with public domain > packages like ANDIrand.) SUNWski == cryptorand cryptorand -> blocking /dev/random I'd like a non-blocking /dev/urandom, thank you very much. ANDIrand provides that. > -- > Dan Astoorian People shouldn't think that it's better to have > Sysadmin, CSLab loved and lost than never loved at all. It's > djast at cs.toronto.edu not, it's better to have loved and won. All > www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Wed Nov 7 07:16:11 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 6 Nov 2001 15:16:11 -0500 Subject: Unkerberized NFS In-Reply-To: ; from mouring@etoh.eviladmin.org on Tue, Nov 06, 2001 at 01:46:35PM -0600 References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> Message-ID: <20011106151609.Y5739@sm2p1386swk.wdr.com> Can't these user-specific seed files be stored in {/var}/tmp/ssh-seed-$user/? On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org wrote: > > seed files on NFS.. My only concern is packet sniffing. How may NFS > connetions are encryped now days? > > - Ben > > On Tue, 6 Nov 2001, Tim McGarry wrote: > > > I suppose your right, but if you edit someones .profile, you can easily > > compromise the boxes they log into. If you edit authorized_keys, access to > > every box in the organisation could be possible > > > > Tim McGarry > > > > ----- Original Message ----- > > From: "Dave Dykstra" > > To: "Tim McGarry" > > Cc: > > Sent: Tuesday, November 06, 2001 8:30 PM > > Subject: Re: Unkerberized NFS > > > > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > > > I disagree, about NFS, obviously any smart organisation will ensure that > > NFS > > > > is secured with kerberos BEFORE they allow RSA authentication. > > > > But those who dont know better shouldn't find that installing OpenSSH > > > > actually reduces the system security. > > > > > > It does not reduce system security. If you are exporting a filesystem > > with > > > unkerberized NFS read-write, anybody can read and write any (usually > > non-root) > > > file, including many things the user executes such as .profile so even > > > without .rhosts or .ssh/authorized_keys it is totally wide open. Having > > > SSH worry about unkerberized NFS is like trying to put a slightly stronger > > > lock on the door of a safe that has a whole wall missing. > > > > > > - Dave Dykstra > > > > > > > -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From tim at mcgarry.ch Wed Nov 7 07:20:16 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 6 Nov 2001 21:20:16 +0100 Subject: Unkerberized NFS References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> <20011106151609.Y5739@sm2p1386swk.wdr.com> Message-ID: <004001c16700$731c9b00$c802a8c0@cablecom.ch> Sound's good what about authorized_keys though, doesn't stop hacks with rsa, at least with Nicos kerberos principals extension, you'll know who it was who compromised the system (unless of course they undo the changes done to authorizeds_keys really quick. after gaining access) ----- Original Message ----- From: "Nicolas Williams" To: Cc: "Tim McGarry" ; "Dave Dykstra" ; Sent: Tuesday, November 06, 2001 9:16 PM Subject: Re: Unkerberized NFS > Can't these user-specific seed files be stored in {/var}/tmp/ssh-seed-$user/? > > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org wrote: > > > > seed files on NFS.. My only concern is packet sniffing. How may NFS > > connetions are encryped now days? > > > > - Ben > > > > On Tue, 6 Nov 2001, Tim McGarry wrote: > > > > > I suppose your right, but if you edit someones .profile, you can easily > > > compromise the boxes they log into. If you edit authorized_keys, access to > > > every box in the organisation could be possible > > > > > > Tim McGarry > > > > > > ----- Original Message ----- > > > From: "Dave Dykstra" > > > To: "Tim McGarry" > > > Cc: > > > Sent: Tuesday, November 06, 2001 8:30 PM > > > Subject: Re: Unkerberized NFS > > > > > > > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > > > > I disagree, about NFS, obviously any smart organisation will ensure that > > > NFS > > > > > is secured with kerberos BEFORE they allow RSA authentication. > > > > > But those who dont know better shouldn't find that installing OpenSSH > > > > > actually reduces the system security. > > > > > > > > It does not reduce system security. If you are exporting a filesystem > > > with > > > > unkerberized NFS read-write, anybody can read and write any (usually > > > non-root) > > > > file, including many things the user executes such as .profile so even > > > > without .rhosts or .ssh/authorized_keys it is totally wide open. Having > > > > SSH worry about unkerberized NFS is like trying to put a slightly stronger > > > > lock on the door of a safe that has a whole wall missing. > > > > > > > > - Dave Dykstra > > > > > > > > > > > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > From ed at UDel.Edu Wed Nov 7 07:26:24 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 15:26:24 -0500 (EST) Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <20011106205701.A22645@greenie.muc.de> Message-ID: On Tue, 6 Nov 2001, Gert Doering wrote: > Date: Tue, 6 Nov 2001 20:57:01 +0100 > From: Gert Doering > To: Ed Phillips , > Lutz Jaenicke > Cc: OpenSSH Development > Subject: Re: Entropy collection in sshd (was Re: Entropy and DSA key) > > Hi, > > On Tue, Nov 06, 2001 at 12:48:53PM -0500, Ed Phillips wrote: > > I'm not following you... the problem of "it takes 2 freakin minutes to get > > logged into my SS1+" is a direct result of entropy collection performed by > > sshd. > > No, it's not. I use NetBSD on a Sparc LX with /dev/random, and ssh takes > still 2 minutes - the delay is NOT caused by the random number generation > but by slow crypto on ancient Sparc hardware. ssh protocol 1 is much > quicker (and also needs random). > > See the thread on slow connections that happened here about three days > ago. Later in my message that you quoted - you can see my detailed explanation about how if you truss sshd (or what the syslog in DEBUG mode), you can actually see it running prng commands, which takes a long time (waiting for the commands to gather up enough bytes of entropy). In my case, this is further confounded by the fact that individual commands were taking longer than the default timeout of 200 millisec. I agree, the ancient Sparc hardware isn't really up to the crypto, but my guess is that in our case it would still be able to provide a shell in under 30 seconds if it didn't have to run a bunch of commands (does it actually stop running commands if it gets enough entropy - or does it run the whole set each time it needs entropy?). Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Wed Nov 7 07:29:57 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 6 Nov 2001 15:29:57 -0500 Subject: Unkerberized NFS In-Reply-To: <004001c16700$731c9b00$c802a8c0@cablecom.ch>; from Tim McGarry on Tue, Nov 06, 2001 at 09:20:16PM +0100 References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> <20011106151609.Y5739@sm2p1386swk.wdr.com> <004001c16700$731c9b00$c802a8c0@cablecom.ch> Message-ID: <20011106152957.X26615@wdr.com> I was referring merely to the packet sniffing attack. That was a reference to the fact that you can run kerberized NFS without encrypting the NFS traffic. Clearly, using authorized_keys on non-secure NFS home directories is not good. It might be nice, however, to have an option to place authorized_keys or alternate authorized_keys files in secure directories, much like sendmail has an option to place .forward files in places other than users' homedirs. But even this wouldn't help much with non-secure NFS -- as long as you store useful or sensitive data on non-secure NFS you lose. Nico On Tue, Nov 06, 2001 at 09:20:16PM +0100, Tim McGarry wrote: > Sound's good > > what about authorized_keys though, doesn't stop hacks with rsa, at least > with Nicos kerberos principals extension, you'll know who it was who > compromised the system (unless of course they undo the changes done to > authorizeds_keys really quick. after gaining access) > > ----- Original Message ----- > From: "Nicolas Williams" > To: > Cc: "Tim McGarry" ; "Dave Dykstra" ; > > Sent: Tuesday, November 06, 2001 9:16 PM > Subject: Re: Unkerberized NFS > > > > Can't these user-specific seed files be stored in > {/var}/tmp/ssh-seed-$user/? > > > > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org > wrote: > > > > > > seed files on NFS.. My only concern is packet sniffing. How may NFS > > > connetions are encryped now days? > > > > > > - Ben > > > > > > On Tue, 6 Nov 2001, Tim McGarry wrote: > > > > > > > I suppose your right, but if you edit someones .profile, you can > easily > > > > compromise the boxes they log into. If you edit authorized_keys, > access to > > > > every box in the organisation could be possible > > > > > > > > Tim McGarry > > > > > > > > ----- Original Message ----- > > > > From: "Dave Dykstra" > > > > To: "Tim McGarry" > > > > Cc: > > > > Sent: Tuesday, November 06, 2001 8:30 PM > > > > Subject: Re: Unkerberized NFS > > > > > > > > > > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > > > > > I disagree, about NFS, obviously any smart organisation will > ensure that > > > > NFS > > > > > > is secured with kerberos BEFORE they allow RSA authentication. > > > > > > But those who dont know better shouldn't find that installing > OpenSSH > > > > > > actually reduces the system security. > > > > > > > > > > It does not reduce system security. If you are exporting a > filesystem > > > > with > > > > > unkerberized NFS read-write, anybody can read and write any (usually > > > > non-root) > > > > > file, including many things the user executes such as .profile so > even > > > > > without .rhosts or .ssh/authorized_keys it is totally wide open. > Having > > > > > SSH worry about unkerberized NFS is like trying to put a slightly > stronger > > > > > lock on the door of a safe that has a whole wall missing. > > > > > > > > > > - Dave Dykstra > > > > > > > > > > > > > > > -- > > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > > -to a public e-mail mailing list I hereby grant permission to distribute- > > -and copy this message.- > > > > Visit our website at http://www.ubswarburg.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately by e-mail if you have received this > > e-mail by mistake and delete this e-mail from your system. > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. The sender therefore > > does not accept liability for any errors or omissions in the contents > > of this message which arise as a result of e-mail transmission. If > > verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any securities or > > related financial instruments. > > -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From tim at mcgarry.ch Wed Nov 7 07:30:48 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 6 Nov 2001 21:30:48 +0100 Subject: Unkerberized NFS References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> <20011106151609.Y5739@sm2p1386swk.wdr.com> <004001c16700$731c9b00$c802a8c0@cablecom.ch> <20011106152957.X26615@wdr.com> Message-ID: <00e601c16701$ebbaca40$c802a8c0@cablecom.ch> thats what the AuthorizedKeysFile does isn't it? ----- Original Message ----- From: "Nicolas Williams" To: "Tim McGarry" ; Cc: "Dave Dykstra" ; Sent: Tuesday, November 06, 2001 9:29 PM Subject: Re: Unkerberized NFS > I was referring merely to the packet sniffing attack. That was a > reference to the fact that you can run kerberized NFS without encrypting > the NFS traffic. > > Clearly, using authorized_keys on non-secure NFS home directories is not > good. > > It might be nice, however, to have an option to place authorized_keys > or alternate authorized_keys files in secure directories, much like > sendmail has an option to place .forward files in places other than > users' homedirs. But even this wouldn't help much with non-secure NFS -- > as long as you store useful or sensitive data on non-secure NFS you > lose. > > Nico > > > On Tue, Nov 06, 2001 at 09:20:16PM +0100, Tim McGarry wrote: > > Sound's good > > > > what about authorized_keys though, doesn't stop hacks with rsa, at least > > with Nicos kerberos principals extension, you'll know who it was who > > compromised the system (unless of course they undo the changes done to > > authorizeds_keys really quick. after gaining access) > > > > ----- Original Message ----- > > From: "Nicolas Williams" > > To: > > Cc: "Tim McGarry" ; "Dave Dykstra" ; > > > > Sent: Tuesday, November 06, 2001 9:16 PM > > Subject: Re: Unkerberized NFS > > > > > > > Can't these user-specific seed files be stored in > > {/var}/tmp/ssh-seed-$user/? > > > > > > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org > > wrote: > > > > > > > > seed files on NFS.. My only concern is packet sniffing. How may NFS > > > > connetions are encryped now days? > > > > > > > > - Ben > > > > > > > > On Tue, 6 Nov 2001, Tim McGarry wrote: > > > > > > > > > I suppose your right, but if you edit someones .profile, you can > > easily > > > > > compromise the boxes they log into. If you edit authorized_keys, > > access to > > > > > every box in the organisation could be possible > > > > > > > > > > Tim McGarry > > > > > > > > > > ----- Original Message ----- > > > > > From: "Dave Dykstra" > > > > > To: "Tim McGarry" > > > > > Cc: > > > > > Sent: Tuesday, November 06, 2001 8:30 PM > > > > > Subject: Re: Unkerberized NFS > > > > > > > > > > > > > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > > > > > > I disagree, about NFS, obviously any smart organisation will > > ensure that > > > > > NFS > > > > > > > is secured with kerberos BEFORE they allow RSA authentication. > > > > > > > But those who dont know better shouldn't find that installing > > OpenSSH > > > > > > > actually reduces the system security. > > > > > > > > > > > > It does not reduce system security. If you are exporting a > > filesystem > > > > > with > > > > > > unkerberized NFS read-write, anybody can read and write any (usually > > > > > non-root) > > > > > > file, including many things the user executes such as .profile so > > even > > > > > > without .rhosts or .ssh/authorized_keys it is totally wide open. > > Having > > > > > > SSH worry about unkerberized NFS is like trying to put a slightly > > stronger > > > > > > lock on the door of a safe that has a whole wall missing. > > > > > > > > > > > > - Dave Dykstra > > > > > > > > > > > > > > > > > > > -- > > > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > > > -to a public e-mail mailing list I hereby grant permission to distribute- > > > -and copy this message.- > > > > > > Visit our website at http://www.ubswarburg.com > > > > > > This message contains confidential information and is intended only > > > for the individual named. If you are not the named addressee you > > > should not disseminate, distribute or copy this e-mail. Please > > > notify the sender immediately by e-mail if you have received this > > > e-mail by mistake and delete this e-mail from your system. > > > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > > as information could be intercepted, corrupted, lost, destroyed, > > > arrive late or incomplete, or contain viruses. The sender therefore > > > does not accept liability for any errors or omissions in the contents > > > of this message which arise as a result of e-mail transmission. If > > > verification is required please request a hard-copy version. This > > > message is provided for informational purposes and should not be > > > construed as a solicitation or offer to buy or sell any securities or > > > related financial instruments. > > > > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Nov 7 07:44:41 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 6 Nov 2001 21:44:41 +0100 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <20011106205701.A22645@greenie.muc.de> References: <20011106183321.A5662@serv01.aet.tu-cottbus.de> <20011106205701.A22645@greenie.muc.de> Message-ID: <20011106214441.A8619@serv01.aet.tu-cottbus.de> On Tue, Nov 06, 2001 at 08:57:01PM +0100, Gert Doering wrote: > On Tue, Nov 06, 2001 at 12:48:53PM -0500, Ed Phillips wrote: > > I'm not following you... the problem of "it takes 2 freakin minutes to get > > logged into my SS1+" is a direct result of entropy collection performed by > > sshd. > > No, it's not. I use NetBSD on a Sparc LX with /dev/random, and ssh takes > still 2 minutes - the delay is NOT caused by the random number generation > but by slow crypto on ancient Sparc hardware. ssh protocol 1 is much > quicker (and also needs random). I is hard to comment about a platform I don't know in detail, but I tend to sit in front of a good old HP 9000/710 (1991?), 50MHz. It took me some tries, but by tuning OpenSSL's flags I could gain a great deal of performance. Have a look into the BN_LLONG and company flags. Two minutes seems to be really slow to me. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From mouring at etoh.eviladmin.org Wed Nov 7 07:45:25 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Nov 2001 14:45:25 -0600 (CST) Subject: Unkerberized NFS In-Reply-To: <20011106151609.Y5739@sm2p1386swk.wdr.com> Message-ID: Great, =) So you going to write the code to handle that mess of race conditions? I won't touch /tmp in any program unless I am required. That includes all the CGI code I write. Remember, we just X cookies from /tmp due to race conditions and security issues. - Ben On Tue, 6 Nov 2001, Nicolas Williams wrote: > Can't these user-specific seed files be stored in {/var}/tmp/ssh-seed-$user/? > > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org wrote: > > > > seed files on NFS.. My only concern is packet sniffing. How may NFS > > connetions are encryped now days? > > > > - Ben > > > > On Tue, 6 Nov 2001, Tim McGarry wrote: > > > > > I suppose your right, but if you edit someones .profile, you can easily > > > compromise the boxes they log into. If you edit authorized_keys, access to > > > every box in the organisation could be possible > > > > > > Tim McGarry > > > > > > ----- Original Message ----- > > > From: "Dave Dykstra" > > > To: "Tim McGarry" > > > Cc: > > > Sent: Tuesday, November 06, 2001 8:30 PM > > > Subject: Re: Unkerberized NFS > > > > > > > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > > > > I disagree, about NFS, obviously any smart organisation will ensure that > > > NFS > > > > > is secured with kerberos BEFORE they allow RSA authentication. > > > > > But those who dont know better shouldn't find that installing OpenSSH > > > > > actually reduces the system security. > > > > > > > > It does not reduce system security. If you are exporting a filesystem > > > with > > > > unkerberized NFS read-write, anybody can read and write any (usually > > > non-root) > > > > file, including many things the user executes such as .profile so even > > > > without .rhosts or .ssh/authorized_keys it is totally wide open. Having > > > > SSH worry about unkerberized NFS is like trying to put a slightly stronger > > > > lock on the door of a safe that has a whole wall missing. > > > > > > > > - Dave Dykstra > > > > > > > > > > > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > From ed at UDel.Edu Wed Nov 7 07:51:12 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 15:51:12 -0500 (EST) Subject: Entropy and DSA key In-Reply-To: Message-ID: On Tue, 6 Nov 2001 mouring at etoh.eviladmin.org wrote: > Date: Tue, 6 Nov 2001 13:44:55 -0600 (CST) > From: mouring at etoh.eviladmin.org > To: Dave Dykstra > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Entropy and DSA key > > > > On Tue, 6 Nov 2001, Dave Dykstra wrote: > > > > Before someone jumps up and starts screaming. I'm not proposing we > > > suddenly drop it. The proposal is this (not set in stone mind you): > > > > > > 3.1 - Make internal entropy --with-* option and not enabled by default. > > > Provide warnings at that screen and provide locations to PRNGd. Warn > > > about how it will be removed in a future release. > > > > I don't mind a configure option. > > > > So can we at least agree that Internal Entropy should *NOT* be enabled > unless someone enables it via a ./configure option? At least starting in > 3.1 and later? > > > > 3.5 - ? Provide ability to link with a libprngd.a instead of compiling w/ > > > our internal entropy. > > > > No problem. I assume libprngd.a would be part of the prngd package then, > > not the OpenSSH package, and since you wouldn't have to maintain it, it > > would make your life easier. > > > That was my initial idea yes. > > > > 4.0 - ? Remove internal entropy code. > > > > Are you saying you would continue support of libprngd.a? If so, why not > > take out the internal entropy code at the same time you switch to libprngd.a > > in 3.5? > > > No. In my world view there needs to be an overlap. A few releases of > 'warning' that the internal entropy code is being removed before it > actually occurs. This should be reserved for major release numbers. If the internal entropy collection is not going to be "fixed up" then I say just nix it right now with 3.0. If the code needs to hang around until version 4.0 anyway, then why not fix it up to be the best it can be? What amazing new features are going to require so much development time that there just no time to fix it up over the next year or however long it takes to get to another major release? Also, someone mentioned that we should ditch it because OpenSSL should be the one to worry about getting good random bits. Does the OpenSSL API require an application to supply the random bits as arguments to the API routines, or does the API need a callback set by the app to get random bits, or something else? The SSH v1/v2 protocol doesn't require any random bits itself? Maybe we should all go out and get a random number device that we can plug into the serial port on our SS1s and IPCs and LXs and enhance OpenSSH to just read random numbers from the serial port at 2400 bps... ;-P Heck, how many random bits do you actually need for sshd to receive a single client connection? I could bang in more bits faster on the keyboard than my SS1+ can get from running all the ssh_prng_cmds... I know... "Put a sock in it Ed!" Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Nov 7 07:51:35 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 6 Nov 2001 21:51:35 +0100 Subject: Entropy and DSA key In-Reply-To: References: <01Nov6.130846edt.453149-15184@jane.cs.toronto.edu> Message-ID: <20011106215135.B8619@serv01.aet.tu-cottbus.de> On Tue, Nov 06, 2001 at 01:38:40PM -0600, mouring at etoh.eviladmin.org wrote: > I would perfer OpenSSL handle all the entropy behind the scenes. It would > make our life easier in the portable group. However it only removes > around 1000 lines of code in a 55,000 line project (I'm refering to > portable. OpenBSD's ssh tree is 45,000 lines.). I would not expect this to happen. OpenSSL is used by a lot of security relevant applications, many of them running with root permission. The OpenSSL library does contact the hardcoded /dev/[u]random location and will query some hardcoded locations for a PRNGd/EGD socket. I don't think a library should do things beyond this level. I really don't want a library to try and run commands (maybe with root permission) behind my back. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 From ed at UDel.Edu Wed Nov 7 07:52:27 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 15:52:27 -0500 (EST) Subject: Unkerberized NFS In-Reply-To: <20011106151609.Y5739@sm2p1386swk.wdr.com> Message-ID: On Tue, 6 Nov 2001, Nicolas Williams wrote: > Date: Tue, 6 Nov 2001 15:16:11 -0500 > From: Nicolas Williams > To: mouring at etoh.eviladmin.org > Cc: Tim McGarry , Dave Dykstra , > openssh-unix-dev at mindrot.org > Subject: Re: Unkerberized NFS > > Can't these user-specific seed files be stored in {/var}/tmp/ssh-seed-$user/? That's what I was wondering... Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Wed Nov 7 08:01:03 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 6 Nov 2001 16:01:03 -0500 Subject: Unkerberized NFS In-Reply-To: ; from mouring@etoh.eviladmin.org on Tue, Nov 06, 2001 at 02:45:25PM -0600 References: <20011106151609.Y5739@sm2p1386swk.wdr.com> Message-ID: <20011106160103.A26615@wdr.com> Hey, I'm not asking for this. Dave Dykstra is. :) Personally, I'd like to have a good /dev/random solution. That's all. Nico On Tue, Nov 06, 2001 at 02:45:25PM -0600, mouring at etoh.eviladmin.org wrote: > > Great, =) So you going to write the code to handle that mess of > race conditions? I won't touch /tmp in any program unless I am > required. That includes all the CGI code I write. > > Remember, we just X cookies from /tmp due to race conditions and security > issues. > > - Ben > > > On Tue, 6 Nov 2001, Nicolas Williams wrote: > > > Can't these user-specific seed files be stored in {/var}/tmp/ssh-seed-$user/? > > > > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org wrote: > > > > > > seed files on NFS.. My only concern is packet sniffing. How may NFS > > > connetions are encryped now days? > > > > > > - Ben > > > > > > On Tue, 6 Nov 2001, Tim McGarry wrote: > > > > > > > I suppose your right, but if you edit someones .profile, you can easily > > > > compromise the boxes they log into. If you edit authorized_keys, access to > > > > every box in the organisation could be possible > > > > > > > > Tim McGarry > > > > > > > > ----- Original Message ----- > > > > From: "Dave Dykstra" > > > > To: "Tim McGarry" > > > > Cc: > > > > Sent: Tuesday, November 06, 2001 8:30 PM > > > > Subject: Re: Unkerberized NFS > > > > > > > > > > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > > > > > I disagree, about NFS, obviously any smart organisation will ensure that > > > > NFS > > > > > > is secured with kerberos BEFORE they allow RSA authentication. > > > > > > But those who dont know better shouldn't find that installing OpenSSH > > > > > > actually reduces the system security. > > > > > > > > > > It does not reduce system security. If you are exporting a filesystem > > > > with > > > > > unkerberized NFS read-write, anybody can read and write any (usually > > > > non-root) > > > > > file, including many things the user executes such as .profile so even > > > > > without .rhosts or .ssh/authorized_keys it is totally wide open. Having > > > > > SSH worry about unkerberized NFS is like trying to put a slightly stronger > > > > > lock on the door of a safe that has a whole wall missing. > > > > > > > > > > - Dave Dykstra > > > > > > > > > > > > > > > -- > > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > > -to a public e-mail mailing list I hereby grant permission to distribute- > > -and copy this message.- > > > > Visit our website at http://www.ubswarburg.com > > > > This message contains confidential information and is intended only > > for the individual named. If you are not the named addressee you > > should not disseminate, distribute or copy this e-mail. Please > > notify the sender immediately by e-mail if you have received this > > e-mail by mistake and delete this e-mail from your system. > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. The sender therefore > > does not accept liability for any errors or omissions in the contents > > of this message which arise as a result of e-mail transmission. If > > verification is required please request a hard-copy version. This > > message is provided for informational purposes and should not be > > construed as a solicitation or offer to buy or sell any securities or > > related financial instruments. > > > > > -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ed at UDel.Edu Wed Nov 7 08:20:06 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 16:20:06 -0500 (EST) Subject: Unkerberized NFS In-Reply-To: <20011106152957.X26615@wdr.com> Message-ID: How common is the /etc/publickey in various OSes? I was thinking that for our site, it might be nice to access public keys using PAM/LDAP. On Solaris, theoretically, sshd could call getpublickey(). It puts another constraint on login (the LDAP server has to be available), but chances are, if you're using LDAP, and the LDAP server is down, the Solaris system can get at /etc/passwd, et. al., stuff either through LDAP, so you'd get a cached version if available in nscd. Just a thought... Ed On Tue, 6 Nov 2001, Nicolas Williams wrote: > Date: Tue, 6 Nov 2001 15:29:57 -0500 > From: Nicolas Williams > To: Tim McGarry , mouring at etoh.eviladmin.org > Cc: Dave Dykstra , openssh-unix-dev at mindrot.org > Subject: Re: Unkerberized NFS > > I was referring merely to the packet sniffing attack. That was a > reference to the fact that you can run kerberized NFS without encrypting > the NFS traffic. > > Clearly, using authorized_keys on non-secure NFS home directories is not > good. > > It might be nice, however, to have an option to place authorized_keys > or alternate authorized_keys files in secure directories, much like > sendmail has an option to place .forward files in places other than > users' homedirs. But even this wouldn't help much with non-secure NFS -- > as long as you store useful or sensitive data on non-secure NFS you > lose. > > Nico > > > On Tue, Nov 06, 2001 at 09:20:16PM +0100, Tim McGarry wrote: > > Sound's good > > > > what about authorized_keys though, doesn't stop hacks with rsa, at least > > with Nicos kerberos principals extension, you'll know who it was who > > compromised the system (unless of course they undo the changes done to > > authorizeds_keys really quick. after gaining access) > > > > ----- Original Message ----- > > From: "Nicolas Williams" > > To: > > Cc: "Tim McGarry" ; "Dave Dykstra" ; > > > > Sent: Tuesday, November 06, 2001 9:16 PM > > Subject: Re: Unkerberized NFS > > > > > > > Can't these user-specific seed files be stored in > > {/var}/tmp/ssh-seed-$user/? > > > > > > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org > > wrote: > > > > > > > > seed files on NFS.. My only concern is packet sniffing. How may NFS > > > > connetions are encryped now days? > > > > > > > > - Ben > > > > > > > > On Tue, 6 Nov 2001, Tim McGarry wrote: > > > > > > > > > I suppose your right, but if you edit someones .profile, you can > > easily > > > > > compromise the boxes they log into. If you edit authorized_keys, > > access to > > > > > every box in the organisation could be possible > > > > > > > > > > Tim McGarry > > > > > > > > > > ----- Original Message ----- > > > > > From: "Dave Dykstra" > > > > > To: "Tim McGarry" > > > > > Cc: > > > > > Sent: Tuesday, November 06, 2001 8:30 PM > > > > > Subject: Re: Unkerberized NFS > > > > > > > > > > > > > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote: > > > > > > > I disagree, about NFS, obviously any smart organisation will > > ensure that > > > > > NFS > > > > > > > is secured with kerberos BEFORE they allow RSA authentication. > > > > > > > But those who dont know better shouldn't find that installing > > OpenSSH > > > > > > > actually reduces the system security. > > > > > > > > > > > > It does not reduce system security. If you are exporting a > > filesystem > > > > > with > > > > > > unkerberized NFS read-write, anybody can read and write any (usually > > > > > non-root) > > > > > > file, including many things the user executes such as .profile so > > even > > > > > > without .rhosts or .ssh/authorized_keys it is totally wide open. > > Having > > > > > > SSH worry about unkerberized NFS is like trying to put a slightly > > stronger > > > > > > lock on the door of a safe that has a whole wall missing. > > > > > > > > > > > > - Dave Dykstra > > > > > > > > > > > > > > > > > > > -- > > > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > > > -to a public e-mail mailing list I hereby grant permission to distribute- > > > -and copy this message.- > > > > > > Visit our website at http://www.ubswarburg.com > > > > > > This message contains confidential information and is intended only > > > for the individual named. If you are not the named addressee you > > > should not disseminate, distribute or copy this e-mail. Please > > > notify the sender immediately by e-mail if you have received this > > > e-mail by mistake and delete this e-mail from your system. > > > > > > E-mail transmission cannot be guaranteed to be secure or error-free > > > as information could be intercepted, corrupted, lost, destroyed, > > > arrive late or incomplete, or contain viruses. The sender therefore > > > does not accept liability for any errors or omissions in the contents > > > of this message which arise as a result of e-mail transmission. If > > > verification is required please request a hard-copy version. This > > > message is provided for informational purposes and should not be > > > construed as a solicitation or offer to buy or sell any securities or > > > related financial instruments. > > > > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By posting- > -to a public e-mail mailing list I hereby grant permission to distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From mouring at etoh.eviladmin.org Wed Nov 7 08:24:49 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Nov 2001 15:24:49 -0600 (CST) Subject: Entropy and DSA key In-Reply-To: Message-ID: On Tue, 6 Nov 2001, Ed Phillips wrote: [..] > > If the internal entropy collection is not going to be "fixed up" then I > say just nix it right now with 3.0. If the code needs to hang around > until version 4.0 anyway, then why not fix it up to be the best it can be? > What amazing new features are going to require so much development time > that there just no time to fix it up over the next year or however long it > takes to get to another major release? > Respectly, Ed.. Don't put words in my mouth. I have not, nor have I ever since I started this thread talked about the current entropy system and about how we are 'not going to fix it'. My focus has been on finding a better place for it. Hopefully external from OpenSSH proper. Be it in the form of OpenSSL modification. Be it in the form of a 3rd party library. Be it in the form of a little black monkey that runs around shoving bananas up people rear-ends and collecting the sound to create entropy which it magicly shove it into OpenSSH. I really dislike when people do that. > Also, someone mentioned that we should ditch it because OpenSSL should be > the one to worry about getting good random bits. Does the OpenSSL API > require an application to supply the random bits as arguments to the API > routines, or does the API need a callback set by the app to get random > bits, or something else? The SSH v1/v2 protocol doesn't require any > random bits itself? > RAND_add() allows you to add entropy to the OpenSSL internal pool, and as far as I'm aware of arc4random or OpenSSL pools are used only. I'm only looking to see if people can agree that we can deal with entropy via OpenSSL or some other way and still have to be 'acceptable' to 99% of the world! I'm not looking for a 45 day discussion argument as to what is wrong with our current system. If I can get a tolerable feed back I can look at it in December when I regain my home network from the four corners of the earth. - Ben From dwd at bell-labs.com Wed Nov 7 08:28:10 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 15:28:10 -0600 Subject: Entropy and DSA key In-Reply-To: ; from mouring@etoh.eviladmin.org on Tue, Nov 06, 2001 at 01:44:55PM -0600 References: <20011106095412.A1298@lucent.com> Message-ID: <20011106152810.C9119@lucent.com> On Tue, Nov 06, 2001 at 01:44:55PM -0600, mouring at etoh.eviladmin.org wrote: > > > On Tue, 6 Nov 2001, Dave Dykstra wrote: > > > > Before someone jumps up and starts screaming. I'm not proposing we > > > suddenly drop it. The proposal is this (not set in stone mind you): > > > > > > 3.1 - Make internal entropy --with-* option and not enabled by default. > > > Provide warnings at that screen and provide locations to PRNGd. Warn > > > about how it will be removed in a future release. > > > > I don't mind a configure option. > > > > So can we at least agree that Internal Entropy should *NOT* be enabled > unless someone enables it via a ./configure option? At least starting in > 3.1 and later? It's OK with me although I imagine it may cause more questions from people. If configure bombs when it can't find prngd or /dev/random and tells people to enable the option then that should keep away most of the questions. It could be a good way to educate people to the disadvantages if the message explains that. > > > 3.5 - ? Provide ability to link with a libprngd.a instead of compiling w/ > > > our internal entropy. > > > > No problem. I assume libprngd.a would be part of the prngd package then, > > not the OpenSSH package, and since you wouldn't have to maintain it, it > > would make your life easier. > > > That was my initial idea yes. > > > > 4.0 - ? Remove internal entropy code. > > > > Are you saying you would continue support of libprngd.a? If so, why not > > take out the internal entropy code at the same time you switch to libprngd.a > > in 3.5? > > > No. In my world view there needs to be an overlap. A few releases of > 'warning' that the internal entropy code is being removed before it > actually occurs. This should be reserved for major release numbers. Oh, ok. The reasons for the temporary dual support would be in case people have problems with the new implementation or if they don't want to deal with the external dependency. Thanks for the clarification. Given Lutz's comments though the plan may need to be modified when the time comes. Hopefully OpenSSL will pick up more support. - Dave Dykstra From mouring at etoh.eviladmin.org Wed Nov 7 08:34:02 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Nov 2001 15:34:02 -0600 (CST) Subject: Entropy and DSA key In-Reply-To: <20011106152810.C9119@lucent.com> Message-ID: On Tue, 6 Nov 2001, Dave Dykstra wrote: > On Tue, Nov 06, 2001 at 01:44:55PM -0600, mouring at etoh.eviladmin.org wrote: > > > > > > On Tue, 6 Nov 2001, Dave Dykstra wrote: > > > > > > Before someone jumps up and starts screaming. I'm not proposing we > > > > suddenly drop it. The proposal is this (not set in stone mind you): > > > > > > > > 3.1 - Make internal entropy --with-* option and not enabled by default. > > > > Provide warnings at that screen and provide locations to PRNGd. Warn > > > > about how it will be removed in a future release. > > > > > > I don't mind a configure option. > > > > > > > So can we at least agree that Internal Entropy should *NOT* be enabled > > unless someone enables it via a ./configure option? At least starting in > > 3.1 and later? > > It's OK with me although I imagine it may cause more questions from > people. If configure bombs when it can't find prngd or /dev/random and > tells people to enable the option then that should keep away most of the > questions. It could be a good way to educate people to the disadvantages > if the message explains that. > That is my idea. People don't read the warning we have now. If a ./configure fails people are more apt to stop and think (not by much). [..] > > > > 4.0 - ? Remove internal entropy code. > > > > > > Are you saying you would continue support of libprngd.a? If so, why not > > > take out the internal entropy code at the same time you switch to libprngd.a > > > in 3.5? > > > > > No. In my world view there needs to be an overlap. A few releases of > > 'warning' that the internal entropy code is being removed before it > > actually occurs. This should be reserved for major release numbers. > > Oh, ok. The reasons for the temporary dual support would be in case people > have problems with the new implementation or if they don't want to deal with > the external dependency. > > Thanks for the clarification. Given Lutz's comments though the plan may > need to be modified when the time comes. Hopefully OpenSSL will pick up > more support. > Agreed.. I think it may be time to join OpenSSL list and have a chat with them for a while. But not until I have spent more time in the OpenSSL code and can provide a starting point. I hate whining about features without at least some form of 'proof of concept' hack. - Ben From markus at openbsd.org Wed Nov 7 08:34:56 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 6 Nov 2001 22:34:56 +0100 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <3BE822ED.2040304@Sun.COM>; from Darren.Moffat@Sun.COM on Tue, Nov 06, 2001 at 09:50:37AM -0800 References: <20011106172336.A4527@serv01.aet.tu-cottbus.de> <20011106183321.A5662@serv01.aet.tu-cottbus.de> <3BE822ED.2040304@Sun.COM> Message-ID: <20011106223456.A7141@folly> On Tue, Nov 06, 2001 at 09:50:37AM -0800, Darren J Moffat wrote: > I'm infavour of removing all entropy gathering code from OpenSSH, > including the use of arc4random and the private pool it keeps. I would arc4random(3) is used because it's in openbsd's libc and provides reasonable randomness (as opposed to rand(3)/random(3)) but that can be canged to something like get_random_bytes()... From tim at mcgarry.ch Wed Nov 7 08:33:37 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 6 Nov 2001 22:33:37 +0100 Subject: Entropy and DSA key References: Message-ID: <001a01c1670a$b2e0dee0$c802a8c0@cablecom.ch> Why don't we require less entropy on slower machines, who wants to break into a SS1 or IPX anyway. Tim ----- Original Message ----- From: "Ed Phillips" To: Cc: "Dave Dykstra" ; Sent: Tuesday, November 06, 2001 9:51 PM Subject: Re: Entropy and DSA key > On Tue, 6 Nov 2001 mouring at etoh.eviladmin.org wrote: > > > Date: Tue, 6 Nov 2001 13:44:55 -0600 (CST) > > From: mouring at etoh.eviladmin.org > > To: Dave Dykstra > > Cc: openssh-unix-dev at mindrot.org > > Subject: Re: Entropy and DSA key > > > > > > > > On Tue, 6 Nov 2001, Dave Dykstra wrote: > > > > > > Before someone jumps up and starts screaming. I'm not proposing we > > > > suddenly drop it. The proposal is this (not set in stone mind you): > > > > > > > > 3.1 - Make internal entropy --with-* option and not enabled by default. > > > > Provide warnings at that screen and provide locations to PRNGd. Warn > > > > about how it will be removed in a future release. > > > > > > I don't mind a configure option. > > > > > > > So can we at least agree that Internal Entropy should *NOT* be enabled > > unless someone enables it via a ./configure option? At least starting in > > 3.1 and later? > > > > > > 3.5 - ? Provide ability to link with a libprngd.a instead of compiling w/ > > > > our internal entropy. > > > > > > No problem. I assume libprngd.a would be part of the prngd package then, > > > not the OpenSSH package, and since you wouldn't have to maintain it, it > > > would make your life easier. > > > > > That was my initial idea yes. > > > > > > 4.0 - ? Remove internal entropy code. > > > > > > Are you saying you would continue support of libprngd.a? If so, why not > > > take out the internal entropy code at the same time you switch to libprngd.a > > > in 3.5? > > > > > No. In my world view there needs to be an overlap. A few releases of > > 'warning' that the internal entropy code is being removed before it > > actually occurs. This should be reserved for major release numbers. > > If the internal entropy collection is not going to be "fixed up" then I > say just nix it right now with 3.0. If the code needs to hang around > until version 4.0 anyway, then why not fix it up to be the best it can be? > What amazing new features are going to require so much development time > that there just no time to fix it up over the next year or however long it > takes to get to another major release? > > Also, someone mentioned that we should ditch it because OpenSSL should be > the one to worry about getting good random bits. Does the OpenSSL API > require an application to supply the random bits as arguments to the API > routines, or does the API need a callback set by the app to get random > bits, or something else? The SSH v1/v2 protocol doesn't require any > random bits itself? > > Maybe we should all go out and get a random number device that we can plug > into the serial port on our SS1s and IPCs and LXs and enhance OpenSSH to > just read random numbers from the serial port at 2400 bps... ;-P > > Heck, how many random bits do you actually need for sshd to receive a > single client connection? I could bang in more bits faster on the > keyboard than my SS1+ can get from running all the ssh_prng_cmds... > > I know... "Put a sock in it Ed!" > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > > From mouring at etoh.eviladmin.org Wed Nov 7 08:49:45 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Nov 2001 15:49:45 -0600 (CST) Subject: Entropy and DSA key In-Reply-To: <20011106215135.B8619@serv01.aet.tu-cottbus.de> Message-ID: On Tue, 6 Nov 2001, Lutz Jaenicke wrote: > On Tue, Nov 06, 2001 at 01:38:40PM -0600, mouring at etoh.eviladmin.org wrote: > > I would perfer OpenSSL handle all the entropy behind the scenes. It would > > make our life easier in the portable group. However it only removes > > around 1000 lines of code in a 55,000 line project (I'm refering to > > portable. OpenBSD's ssh tree is 45,000 lines.). > > I would not expect this to happen. OpenSSL is used by a lot of security > relevant applications, many of them running with root permission. > The OpenSSL library does contact the hardcoded /dev/[u]random location > and will query some hardcoded locations for a PRNGd/EGD socket. > I don't think a library should do things beyond this level. I really > don't want a library to try and run commands (maybe with root permission) > behind my back. > OpenSSL allows you to also state where PRNGd/EGD sockets are via RAND_egd(). It would be as easy to do RAND_cmd_list(), and require it to be setup before it was used by the application. It would be no less secure than PRNGd nor current internal solution. I agree that it should not try to build and run the stuff automaticly. Just like I don't believe OpenSSL should try PRNGd/EGD without being told to. - Ben From markus at openbsd.org Wed Nov 7 08:48:41 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 6 Nov 2001 22:48:41 +0100 Subject: OpenSSH 3.0 Message-ID: <20011106224841.A20613@folly> OpenSSH 3.0 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. This release contains many portability bug-fixes (listed in the ChangeLog) as well as several new features (listed below). We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== 1) SSH protocol v2 is now the default protocol version use the 'Protocol' option from ssh(1) and sshd(8) if you need to change this. 2) The files /etc/ssh_known_hosts2 ~/.ssh/known_hosts2 ~/.ssh/authorized_keys2 are now obsolete, you can use /etc/ssh_known_hosts ~/.ssh/known_hosts ~/.ssh/authorized_keys For backward compatibility ~/.ssh/authorized_keys2 will still used for authentication and hostkeys are still read from the known_hosts2. However, those deprecated files are considered 'readonly'. Future releases are likely not to read these files. 3) The CheckMail option in sshd_config is deprecated, as sshd(8) no longer checks for new mail. 4) X11 cookies are now stored in $HOME. New Features: ============= 1) Smartcard support in the ssh client and agent based on work by University of Michigan CITI (http://www.citi.umich.edu/projects/smartcard/). 2) support for Rekeying in protocol version 2 3) improved Kerberos support in protocol v1 (KerbIV and KerbV) 4) backward compatibility with older commercial SSH versions >= 2.0.10 5) getopt(3) is now used by all programs 6) dynamic forwarding (use ssh(1) as your socks server) 7) ClearAllForwardings in ssh(1) 8) ssh(1) now checks the hostkey for localhost (NoHostAuthenticationForLocalhost yes/no). 9) -F option in ssh(1) 10) ssh(1) now has a '-b bindaddress' option 11) scp(1) allows "scp /file localhost:/file" 12) The AuthorizedKeysFile option allows specification of alternative files that contain the public keys that can be used for user authentication (e.g. /etc/ssh_keys/%u, see sshd(8)) 13) extended AllowUsers user at host syntax in sshd(8) 14) improved challenge-response support (especially for systems supporting BSD_AUTH) 15) sshd(8) can specify time args as 1h, 2h30s etc. 16) sshd(8) transmits the correct exit status for remote execution with protocol version 2. 17) ssh-keygen(1) can import private RSA/DSA keys generated with the commercial version 18) ssh-keyscan(1) supports protocol version 2 OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From dwd at bell-labs.com Wed Nov 7 08:51:30 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 15:51:30 -0600 Subject: Unkerberized NFS In-Reply-To: ; from mouring@etoh.eviladmin.org on Tue, Nov 06, 2001 at 01:46:35PM -0600 References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> Message-ID: <20011106155130.A9779@lucent.com> On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org wrote: > > seed files on NFS.. My only concern is packet sniffing. How may NFS > connections are encryped now days? > > - Ben That's a good point I hadn't thought of, a potential problem even on Kerberized NFS. The only counter-argument I can think of is that if you're concerned enough to use encryption on ssh then you probably shouldn't be running unencrypted NFS unless it's behind a firewall that encloses only people you trust enough not to sniff. On Tue, Nov 06, 2001 at 03:16:11PM -0500, Nicolas Williams wrote: > Can't these user-specific seed files be stored in {/var}/tmp/ssh-seed-$user/? There's a possible solution. I recall that the XAUTHORITY file was in /tmp for some openssh releases and came back, and I'm not quite sure of the reasons, but I suspect they wouldn't be applicable to the seed file. Using /tmp for the seed file has a disadvantage that users may be surprised by why startup sometimes takes a lot longer whenever /tmp gets cleaned out (such as a reboot or a period of disuse). - Dave Dykstra From markus at openbsd.org Wed Nov 7 08:55:15 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 6 Nov 2001 22:55:15 +0100 Subject: Entropy and DSA key In-Reply-To: ; from ed@UDel.Edu on Tue, Nov 06, 2001 at 03:51:12PM -0500 References: Message-ID: <20011106225515.A5695@folly> On Tue, Nov 06, 2001 at 03:51:12PM -0500, Ed Phillips wrote: > The SSH v1/v2 protocol doesn't require any > random bits itself? yes, it does. for padding with random bytes, etc. From peterw at usa.net Wed Nov 7 08:57:10 2001 From: peterw at usa.net (Peter W) Date: Tue, 6 Nov 2001 16:57:10 -0500 Subject: Entropy gathering from multiple sources (redundancy) In-Reply-To: ; from ed@UDel.Edu on Tue, Nov 06, 2001 at 03:03:10PM -0500 References: Message-ID: <20011106165710.E8049@usa.net> On Tue, Nov 06, 2001 at 03:03:10PM -0500, Ed Phillips wrote: > My preference is close > to what Dan has suggested for the order of where sshd should look when > trying to get some random bits: > > 1) Try /dev/[u]random. > 2) Try PRNGD. > 3) Try an improved "internal entropy collection" method that doesn't > involving running commands for each client connection. What I like about this suggestion is the basic notion of *redundancy*. We've been using the internal commands for OpenSSH in part because that's the default config, and in part because the idea of relying on 'prngd' or 'egd.pl' to be up & running properly for a critical service like SSH is frightening (from a single point of failure to multiple points of failure). I'd like to be able to specify something like - try /dev/urandom if it exists - else try egd's pool - else fall back on prngd's pool - else fall back on ssh_prng_cmds Obviously this is mainly a problem with OSes like Solaris that do not provide kernel-based random data sources that we can rely on. It would be nice to specify different pools (or lists of pools) for sshd vs. the client applications, and it would be nice for users to be able to specify their own pools for their clients. Reasons being 1) I prefer that true entropy sources like /dev/random not be world-accessible 2) Some users may be granted access to such sources (e.g. wheel group) 3) On some system (e.g. shell accounts) users may want to use better entropy sources for their clients than the system admin has specified (e.g. /dev/urandom instead of ssh_prng_cmds) Thanks to all (especially those helping me off-list), -Peter From markus at openbsd.org Wed Nov 7 09:05:39 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 6 Nov 2001 23:05:39 +0100 Subject: Unkerberized NFS In-Reply-To: <20011106152957.X26615@wdr.com>; from Nicolas.Williams@ubsw.com on Tue, Nov 06, 2001 at 03:29:57PM -0500 References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> <20011106151609.Y5739@sm2p1386swk.wdr.com> <004001c16700$731c9b00$c802a8c0@cablecom.ch> <20011106152957.X26615@wdr.com> Message-ID: <20011106230539.A14927@faui02.informatik.uni-erlangen.de> On Tue, Nov 06, 2001 at 03:29:57PM -0500, Nicolas Williams wrote: > Clearly, using authorized_keys on non-secure NFS home directories is not > good. AuthorizedKeysFile /etc/ssh/%u From Darren.Moffat at Sun.COM Wed Nov 7 09:06:33 2001 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Tue, 06 Nov 2001 14:06:33 -0800 Subject: Unkerberized NFS References: Message-ID: <3BE85EE9.1040805@Sun.COM> Ed Phillips wrote: > How common is the /etc/publickey in various OSes? I was thinking that for > our site, it might be nice to access public keys using PAM/LDAP. On > Solaris, theoretically, sshd could call getpublickey(). It puts another > constraint on login (the LDAP server has to be available), but chances > are, if you're using LDAP, and the LDAP server is down, the Solaris system > can get at /etc/passwd, et. al., stuff either through LDAP, so you'd get a > cached version if available in nscd. PAM has nothing to do with this, you mean NSS (nsswitch.conf and the nss modules). Any system that has got ONC/ONC+ from Sun or has implemented NIS+ from scratch would have them. However I would strongly discourage you using getpublickey since it was not intended to store keys other than those for the AUTH_DH mechanisms of RPC. -- Darren J Moffat From tim at mcgarry.ch Wed Nov 7 09:05:34 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 6 Nov 2001 23:05:34 +0100 Subject: Unkerberized NFS References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> <20011106151609.Y5739@sm2p1386swk.wdr.com> <004001c16700$731c9b00$c802a8c0@cablecom.ch> <20011106152957.X26615@wdr.com> <20011106230539.A14927@faui02.informatik.uni-erlangen.de> Message-ID: <003901c1670f$28ea5220$c802a8c0@cablecom.ch> Yep The code works, all that's really needed is a comment in the default sshd_config warning admins of the perils of not setting AuthorizedKeysFile to something local. Tim ----- Original Message ----- From: "Markus Friedl" To: "Tim McGarry" ; ; "Dave Dykstra" ; Sent: Tuesday, November 06, 2001 11:05 PM Subject: Re: Unkerberized NFS > On Tue, Nov 06, 2001 at 03:29:57PM -0500, Nicolas Williams wrote: > > Clearly, using authorized_keys on non-secure NFS home directories is not > > good. > > AuthorizedKeysFile /etc/ssh/%u > From tim at mcgarry.ch Wed Nov 7 09:06:28 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 6 Nov 2001 23:06:28 +0100 Subject: Unkerberized NFS References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> <20011106155130.A9779@lucent.com> Message-ID: <003f01c1670f$48bb7660$c802a8c0@cablecom.ch> If you trust people enough not to sniff then why are you using ssh? ----- Original Message ----- From: "Dave Dykstra" To: Cc: "Tim McGarry" ; Sent: Tuesday, November 06, 2001 10:51 PM Subject: Re: Unkerberized NFS > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org wrote: > > > > seed files on NFS.. My only concern is packet sniffing. How may NFS > > connections are encryped now days? > > > > - Ben > > That's a good point I hadn't thought of, a potential problem even on > Kerberized NFS. The only counter-argument I can think of is that if you're > concerned enough to use encryption on ssh then you probably shouldn't be > running unencrypted NFS unless it's behind a firewall that encloses only > people you trust enough not to sniff. > > > On Tue, Nov 06, 2001 at 03:16:11PM -0500, Nicolas Williams wrote: > > Can't these user-specific seed files be stored in {/var}/tmp/ssh-seed-$user/? > > There's a possible solution. I recall that the XAUTHORITY file was in /tmp > for some openssh releases and came back, and I'm not quite sure of the > reasons, but I suspect they wouldn't be applicable to the seed file. Using > /tmp for the seed file has a disadvantage that users may be surprised by > why startup sometimes takes a lot longer whenever /tmp gets cleaned out > (such as a reboot or a period of disuse). > > - Dave Dykstra > From PAMIFER at terra.es Wed Nov 7 09:17:21 2001 From: PAMIFER at terra.es (ciph3r) Date: Tue, 6 Nov 2001 23:17:21 +0100 Subject: OpenSSH 3.0 References: <20011106224841.A20613@folly> Message-ID: <003b01c16710$cf042ea0$02001aac@bottom> Is it integrated in -current?? ----- Original Message ----- From: "Markus Friedl" To: ; Cc: ; ; ; Sent: Tuesday, November 06, 2001 10:48 PM Subject: OpenSSH 3.0 > OpenSSH 3.0 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 > implementation and includes sftp client and server support. > > This release contains many portability bug-fixes (listed in the > ChangeLog) as well as several new features (listed below). > > We would like to thank the OpenSSH community for their continued > support and encouragement. > > Important Changes: > ================== > > 1) SSH protocol v2 is now the default protocol version > > use the 'Protocol' option from ssh(1) and sshd(8) if > you need to change this. > > 2) The files > /etc/ssh_known_hosts2 > ~/.ssh/known_hosts2 > ~/.ssh/authorized_keys2 > are now obsolete, you can use > /etc/ssh_known_hosts > ~/.ssh/known_hosts > ~/.ssh/authorized_keys > For backward compatibility ~/.ssh/authorized_keys2 will still used for > authentication and hostkeys are still read from the known_hosts2. > However, those deprecated files are considered 'readonly'. Future > releases are likely not to read these files. > > 3) The CheckMail option in sshd_config is deprecated, as sshd(8) no longer > checks for new mail. > > 4) X11 cookies are now stored in $HOME. > > New Features: > ============= > > 1) Smartcard support in the ssh client and agent based on work by > University of Michigan CITI (http://www.citi.umich.edu/projects/smartcard/). > > 2) support for Rekeying in protocol version 2 > > 3) improved Kerberos support in protocol v1 (KerbIV and KerbV) > > 4) backward compatibility with older commercial SSH versions >= 2.0.10 > > 5) getopt(3) is now used by all programs > > 6) dynamic forwarding (use ssh(1) as your socks server) > > 7) ClearAllForwardings in ssh(1) > > 8) ssh(1) now checks the hostkey for localhost (NoHostAuthenticationForLocalhost yes/no). > > 9) -F option in ssh(1) > > 10) ssh(1) now has a '-b bindaddress' option > > 11) scp(1) allows "scp /file localhost:/file" > > 12) The AuthorizedKeysFile option allows specification of alternative > files that contain the public keys that can be used for user authentication > (e.g. /etc/ssh_keys/%u, see sshd(8)) > > 13) extended AllowUsers user at host syntax in sshd(8) > > 14) improved challenge-response support (especially for systems supporting BSD_AUTH) > > 15) sshd(8) can specify time args as 1h, 2h30s etc. > > 16) sshd(8) transmits the correct exit status for remote execution with protocol version 2. > > 17) ssh-keygen(1) can import private RSA/DSA keys generated with the commercial version > > 18) ssh-keyscan(1) supports protocol version 2 > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, > Kevin Steves, Damien Miller and Ben Lindstrom. > From djast at cs.toronto.edu Wed Nov 7 09:19:04 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Tue, 6 Nov 2001 17:19:04 -0500 Subject: Entropy and DSA key In-Reply-To: Your message of "Tue, 06 Nov 2001 15:51:35 EST." <20011106215135.B8619@serv01.aet.tu-cottbus.de> Message-ID: <01Nov6.171905edt.453142-15184@jane.cs.toronto.edu> On Tue, 06 Nov 2001 15:51:35 EST, Lutz Jaenicke writes: > On Tue, Nov 06, 2001 at 01:38:40PM -0600, mouring at etoh.eviladmin.org wrote: > > I would perfer OpenSSL handle all the entropy behind the scenes. It would > > make our life easier in the portable group. However it only removes > > around 1000 lines of code in a 55,000 line project (I'm refering to > > portable. OpenBSD's ssh tree is 45,000 lines.). > > I would not expect this to happen. OpenSSL is used by a lot of security > relevant applications, many of them running with root permission. > The OpenSSL library does contact the hardcoded /dev/[u]random location > and will query some hardcoded locations for a PRNGd/EGD socket. > I don't think a library should do things beyond this level. I really > don't want a library to try and run commands (maybe with root permission) > behind my back. The application needs to get the entropy from somewhere. If OpenSSL leaves it up to the application (and we're talking about the same app linked against OpenSSL, i.e., the one perhaps running with root permission) to find it, then some of those apps are likely to do the job badly, perhaps by supplying bad entropy or by taking insecure actions. That's why I don't think it's such a bad thing, _compared with the alternatives_, for the OpenSSL library, as a last resort, on systems without /dev/random, and where PRNGD is not operating, to run one hardcoded, well-audited command, which has the sense to give up its privileges as soon as possible. I'd certainly prefer that to the status quo, where OpenSSH's sshd runs dozens of commands as root. If you need a precedent for libraries running commands, look at /usr/lib/pt_chmod and /usr/lib/utmp_update under Solaris. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From ed at UDel.Edu Wed Nov 7 09:19:54 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 17:19:54 -0500 (EST) Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: <20011106214441.A8619@serv01.aet.tu-cottbus.de> Message-ID: On Tue, 6 Nov 2001, Lutz Jaenicke wrote: > Date: Tue, 6 Nov 2001 21:44:41 +0100 > From: Lutz Jaenicke > To: OpenSSH Development > Subject: Re: Entropy collection in sshd (was Re: Entropy and DSA key) > > On Tue, Nov 06, 2001 at 08:57:01PM +0100, Gert Doering wrote: > > On Tue, Nov 06, 2001 at 12:48:53PM -0500, Ed Phillips wrote: > > > I'm not following you... the problem of "it takes 2 freakin minutes to get > > > logged into my SS1+" is a direct result of entropy collection performed by > > > sshd. > > > > No, it's not. I use NetBSD on a Sparc LX with /dev/random, and ssh takes > > still 2 minutes - the delay is NOT caused by the random number generation > > but by slow crypto on ancient Sparc hardware. ssh protocol 1 is much > > quicker (and also needs random). > > I is hard to comment about a platform I don't know in detail, but I tend > to sit in front of a good old HP 9000/710 (1991?), 50MHz. It took me > some tries, but by tuning OpenSSL's flags I could gain a great deal > of performance. Have a look into the BN_LLONG and company flags. > Two minutes seems to be really slow to me. Okay, I start "ssh -v -v -v" and then it sits there for a long time at: ... debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY On the server side, the bulk of the time is spent as indicated in the DEBUG3 syslog messages below: Nov 6 16:59:42 ls1.nss.udel.edu sshd[1316]: debug2: kex_parse_kexinit: reserved 0 Nov 6 16:59:42 ls1.nss.udel.edu sshd[1316]: debug2: mac_init: found hmac-md5 Nov 6 16:59:42 ls1.nss.udel.edu sshd[1316]: debug1: kex: client->server aes128-cbc hmac-md5 none Nov 6 16:59:43 ls1.nss.udel.edu sshd[1316]: debug2: mac_init: found hmac-md5 Nov 6 16:59:43 ls1.nss.udel.edu sshd[1316]: debug1: kex: server->client aes128-cbc hmac-md5 none Nov 6 16:59:43 ls1.nss.udel.edu sshd[1316]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received Nov 6 16:59:44 ls1.nss.udel.edu sshd[1316]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent Nov 6 17:00:28 ls1.nss.udel.edu sshd[1316]: debug1: dh_gen_key: priv key bits set: 142/256 Nov 6 17:00:28 ls1.nss.udel.edu sshd[1316]: debug1: bits set: 1609/3191 Nov 6 17:00:28 ls1.nss.udel.edu sshd[1316]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT Nov 6 17:00:28 ls1.nss.udel.edu sshd[1316]: debug1: bits set: 1570/3191 Nov 6 17:01:27 ls1.nss.udel.edu sshd[1316]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent Nov 6 17:01:27 ls1.nss.udel.edu sshd[1316]: debug1: kex_derive_keys Nov 6 17:01:27 ls1.nss.udel.edu sshd[1316]: debug1: newkeys: mode 1 Nov 6 17:01:28 ls1.nss.udel.edu sshd[1316]: debug1: SSH2_MSG_NEWKEYS sent Nov 6 17:01:28 ls1.nss.udel.edu sshd[1316]: debug1: waiting for SSH2_MSG_NEWKEYS Okay... so now I'm confused. It would appear, that like you say, there is a long pause during computation in two spots in sshd. I just talk with my collegue who did the install and he tells me that the severe, long-running prng commands that timeout are during the startup of sshd. So all this time, I've been raving about sshd running the prng commands for every client connection... this doesn't actually occur? Oh sheesh... what a waste of typing... So the real problem is that compiling OpenSSL with solaris-sparcv7-cc just doesn't generate code that can crunch fast enough to allow login in less than 1.5 minutes? Oh well, I guess we can live with it. Hopefully in the next few months we'll replace any of our sun4c systems with at least a sun4m running Sol2.6 or higher (probably Sol8). Sorry for the wasted bandwidth guys... hasn't been the first time... probably won't be the last. ;-) So, why is ssh-1.2.27 almost instantaneous (5-10 seconds) compared to the above (give me a FAQ-smack if you feel the need)? Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From markus at openbsd.org Wed Nov 7 08:48:41 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 6 Nov 2001 16:48:41 -0500 Subject: OpenSSH 3.0 Message-ID: <20011106224841.A20613@folly> OpenSSH 3.0 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. This release contains many portability bug-fixes (listed in the ChangeLog) as well as several new features (listed below). We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== 1) SSH protocol v2 is now the default protocol version use the 'Protocol' option from ssh(1) and sshd(8) if you need to change this. 2) The files /etc/ssh_known_hosts2 ~/.ssh/known_hosts2 ~/.ssh/authorized_keys2 are now obsolete, you can use /etc/ssh_known_hosts ~/.ssh/known_hosts ~/.ssh/authorized_keys For backward compatibility ~/.ssh/authorized_keys2 will still used for authentication and hostkeys are still read from the known_hosts2. However, those deprecated files are considered 'readonly'. Future releases are likely not to read these files. 3) The CheckMail option in sshd_config is deprecated, as sshd(8) no longer checks for new mail. 4) X11 cookies are now stored in $HOME. New Features: ============= 1) Smartcard support in the ssh client and agent based on work by University of Michigan CITI (http://www.citi.umich.edu/projects/smartcard/). 2) support for Rekeying in protocol version 2 3) improved Kerberos support in protocol v1 (KerbIV and KerbV) 4) backward compatibility with older commercial SSH versions >= 2.0.10 5) getopt(3) is now used by all programs 6) dynamic forwarding (use ssh(1) as your socks server) 7) ClearAllForwardings in ssh(1) 8) ssh(1) now checks the hostkey for localhost (NoHostAuthenticationForLocalhost yes/no). 9) -F option in ssh(1) 10) ssh(1) now has a '-b bindaddress' option 11) scp(1) allows "scp /file localhost:/file" 12) The AuthorizedKeysFile option allows specification of alternative files that contain the public keys that can be used for user authentication (e.g. /etc/ssh_keys/%u, see sshd(8)) 13) extended AllowUsers user at host syntax in sshd(8) 14) improved challenge-response support (especially for systems supporting BSD_AUTH) 15) sshd(8) can specify time args as 1h, 2h30s etc. 16) sshd(8) transmits the correct exit status for remote execution with protocol version 2. 17) ssh-keygen(1) can import private RSA/DSA keys generated with the commercial version 18) ssh-keyscan(1) supports protocol version 2 OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From ed at UDel.Edu Wed Nov 7 09:23:20 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 17:23:20 -0500 (EST) Subject: Entropy and DSA key In-Reply-To: Message-ID: Sorry... I'm getty punchy from brain-fry over this stuff.. ;-) I need to go home and relax the wife and daughter or something... Ed On Tue, 6 Nov 2001 mouring at etoh.eviladmin.org wrote: > Date: Tue, 6 Nov 2001 15:24:49 -0600 (CST) > From: mouring at etoh.eviladmin.org > To: Ed Phillips > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Entropy and DSA key > > > > On Tue, 6 Nov 2001, Ed Phillips wrote: > [..] > > > > If the internal entropy collection is not going to be "fixed up" then I > > say just nix it right now with 3.0. If the code needs to hang around > > until version 4.0 anyway, then why not fix it up to be the best it can be? > > What amazing new features are going to require so much development time > > that there just no time to fix it up over the next year or however long it > > takes to get to another major release? > > > Respectly, Ed.. Don't put words in my mouth. I have not, nor have I > ever since I started this thread talked about the current entropy system > and about how we are 'not going to fix it'. My focus has been on finding > a better place for it. Hopefully external from OpenSSH proper. > > Be it in the form of OpenSSL modification. > Be it in the form of a 3rd party library. > Be it in the form of a little black monkey that runs around shoving > bananas up people rear-ends and collecting the sound to create entropy > which it magicly shove it into OpenSSH. > > I really dislike when people do that. > > > Also, someone mentioned that we should ditch it because OpenSSL should be > > the one to worry about getting good random bits. Does the OpenSSL API > > require an application to supply the random bits as arguments to the API > > routines, or does the API need a callback set by the app to get random > > bits, or something else? The SSH v1/v2 protocol doesn't require any > > random bits itself? > > > RAND_add() allows you to add entropy to the OpenSSL internal pool, and > as far as I'm aware of arc4random or OpenSSL pools are used only. > > > I'm only looking to see if people can agree that we can deal with entropy > via OpenSSL or some other way and still have to be 'acceptable' to > 99% of the world! I'm not looking for a 45 day discussion argument as to > what is wrong with our current system. If I can get a tolerable feed back > I can look at it in December when I regain my home network from the four > corners of the earth. > > - Ben > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From dwd at bell-labs.com Wed Nov 7 09:26:35 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 6 Nov 2001 16:26:35 -0600 Subject: Unkerberized NFS In-Reply-To: <003f01c1670f$48bb7660$c802a8c0@cablecom.ch>; from tim@mcgarry.ch on Tue, Nov 06, 2001 at 11:06:28PM +0100 References: <000801c166f9$c0833a40$c802a8c0@cablecom.ch> <20011106155130.A9779@lucent.com> <003f01c1670f$48bb7660$c802a8c0@cablecom.ch> Message-ID: <20011106162635.A10748@lucent.com> You could be using ssh through the firewall to a more hostile network. My point was that if you're using a hostile network for unencrypted though kerberized NFS you'd better not be storing any data on that filesystem you wouldn't want anybody to see. - Dave On Tue, Nov 06, 2001 at 11:06:28PM +0100, Tim McGarry wrote: > If you trust people enough not to sniff then why are you using ssh? > > ----- Original Message ----- > From: "Dave Dykstra" > To: > Cc: "Tim McGarry" ; > Sent: Tuesday, November 06, 2001 10:51 PM > Subject: Re: Unkerberized NFS > > > > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org > wrote: > > > > > > seed files on NFS.. My only concern is packet sniffing. How may NFS > > > connections are encryped now days? > > > > > > - Ben > > > > That's a good point I hadn't thought of, a potential problem even on > > Kerberized NFS. The only counter-argument I can think of is that if you're > > concerned enough to use encryption on ssh then you probably shouldn't be > > running unencrypted NFS unless it's behind a firewall that encloses only > > people you trust enough not to sniff. From ed at UDel.Edu Wed Nov 7 09:35:53 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 17:35:53 -0500 (EST) Subject: Unkerberized NFS In-Reply-To: <3BE85EE9.1040805@Sun.COM> Message-ID: On Tue, 6 Nov 2001, Darren J Moffat wrote: > Date: Tue, 06 Nov 2001 14:06:33 -0800 > From: Darren J Moffat > To: Ed Phillips > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Unkerberized NFS > > > > Ed Phillips wrote: > > > How common is the /etc/publickey in various OSes? I was thinking that for > > our site, it might be nice to access public keys using PAM/LDAP. On > > Solaris, theoretically, sshd could call getpublickey(). It puts another > > constraint on login (the LDAP server has to be available), but chances > > are, if you're using LDAP, and the LDAP server is down, the Solaris system > > can get at /etc/passwd, et. al., stuff either through LDAP, so you'd get a > > cached version if available in nscd. > > > PAM has nothing to do with this, you mean NSS (nsswitch.conf and the nss > modules). Okay... that makes sense. > Any system that has got ONC/ONC+ from Sun or has implemented NIS+ from > scratch would have them. What is ONC? > However I would strongly discourage you using getpublickey since it was > not intended to store keys other than those for the AUTH_DH mechanisms > of RPC. I was just wondering if getpublickey() was a "standard"-enough place to get a public key from sshd. What would be a "standard" way to have sshd lookup a public key that isn't in the normal ~/.ssh/authorized_keys2 place? Would it just have to be enhanced for this particular "look up public keys in LDAP" feature? Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From ed at UDel.Edu Wed Nov 7 09:41:51 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 6 Nov 2001 17:41:51 -0500 (EST) Subject: Okay... Message-ID: Who sent the Stalking Ninja after me.... I haven't been THAT bad today have I? ;-) Ed > Date: Tue, 06 Nov 2001 16:05:00 -0600 > From: NINJA-DISPATCH at bluesforbuddha.com > To: Ed Phillips > Subject: You are being stalked by an enemy ninja! > ... Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Darren.Moffat at Sun.COM Wed Nov 7 09:42:17 2001 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Tue, 06 Nov 2001 14:42:17 -0800 Subject: Entropy and DSA key References: <001a01c1670a$b2e0dee0$c802a8c0@cablecom.ch> Message-ID: <3BE86749.40007@Sun.COM> Tim McGarry wrote: > Why don't we require less entropy on slower machines, who wants to break > into a SS1 or IPX anyway. Why don't stupid people have less rights ? Just because a machine is old or slow doesn't imply anything about what it is used for or the sensitivity of the data held on it. I suspect a lot of older machines like this are used as firewalls for networks that don't have a huge bandwith requirement. An SS1 or IPX with 2 NICs would do just fine as a firewall for home. -- Darren J Moffat From Darren.Moffat at Sun.COM Wed Nov 7 09:47:38 2001 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Tue, 06 Nov 2001 14:47:38 -0800 Subject: Unkerberized NFS References: Message-ID: <3BE8688A.7010202@Sun.COM> Ed Phillips wrote: > What is ONC? Open Network Computing, basically it is the code for NIS, NIS+ and some RPC stuff. > What would be a "standard" way to have sshd lookup a public key that isn't > in the normal ~/.ssh/authorized_keys2 place? Would it just have to be > enhanced for this particular "look up public keys in LDAP" feature? I would actualy have thought of it more as an alternative to known_hosts not to authorized_keys. authorized_keys is a M:1 relationship, many keys giving access to a single account. I could see the possibility of storing this information in a nameservice table but the backend for getpublickey is not the place. -- Darren J Moffat From PAMIFER at terra.es Wed Nov 7 09:17:21 2001 From: PAMIFER at terra.es (ciph3r) Date: Tue, 6 Nov 2001 17:17:21 -0500 Subject: OpenSSH 3.0 References: <20011106224841.A20613@folly> Message-ID: <003b01c16710$cf042ea0$02001aac@bottom> Is it integrated in -current?? ----- Original Message ----- From: "Markus Friedl" To: ; Cc: ; ; ; Sent: Tuesday, November 06, 2001 10:48 PM Subject: OpenSSH 3.0 > OpenSSH 3.0 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 > implementation and includes sftp client and server support. > > This release contains many portability bug-fixes (listed in the > ChangeLog) as well as several new features (listed below). > > We would like to thank the OpenSSH community for their continued > support and encouragement. > > Important Changes: > ================== > > 1) SSH protocol v2 is now the default protocol version > > use the 'Protocol' option from ssh(1) and sshd(8) if > you need to change this. > > 2) The files > /etc/ssh_known_hosts2 > ~/.ssh/known_hosts2 > ~/.ssh/authorized_keys2 > are now obsolete, you can use > /etc/ssh_known_hosts > ~/.ssh/known_hosts > ~/.ssh/authorized_keys > For backward compatibility ~/.ssh/authorized_keys2 will still used for > authentication and hostkeys are still read from the known_hosts2. > However, those deprecated files are considered 'readonly'. Future > releases are likely not to read these files. > > 3) The CheckMail option in sshd_config is deprecated, as sshd(8) no longer > checks for new mail. > > 4) X11 cookies are now stored in $HOME. > > New Features: > ============= > > 1) Smartcard support in the ssh client and agent based on work by > University of Michigan CITI (http://www.citi.umich.edu/projects/smartcard/). > > 2) support for Rekeying in protocol version 2 > > 3) improved Kerberos support in protocol v1 (KerbIV and KerbV) > > 4) backward compatibility with older commercial SSH versions >= 2.0.10 > > 5) getopt(3) is now used by all programs > > 6) dynamic forwarding (use ssh(1) as your socks server) > > 7) ClearAllForwardings in ssh(1) > > 8) ssh(1) now checks the hostkey for localhost (NoHostAuthenticationForLocalhost yes/no). > > 9) -F option in ssh(1) > > 10) ssh(1) now has a '-b bindaddress' option > > 11) scp(1) allows "scp /file localhost:/file" > > 12) The AuthorizedKeysFile option allows specification of alternative > files that contain the public keys that can be used for user authentication > (e.g. /etc/ssh_keys/%u, see sshd(8)) > > 13) extended AllowUsers user at host syntax in sshd(8) > > 14) improved challenge-response support (especially for systems supporting BSD_AUTH) > > 15) sshd(8) can specify time args as 1h, 2h30s etc. > > 16) sshd(8) transmits the correct exit status for remote execution with protocol version 2. > > 17) ssh-keygen(1) can import private RSA/DSA keys generated with the commercial version > > 18) ssh-keyscan(1) supports protocol version 2 > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, > Kevin Steves, Damien Miller and Ben Lindstrom. From scott.burch at camberwind.com Wed Nov 7 10:15:54 2001 From: scott.burch at camberwind.com (Scott Burch) Date: Tue, 6 Nov 2001 17:15:54 -0600 Subject: Sun Forte 6 Update 2 Compiler Issues Resolved! Message-ID: <009c01c16718$fbf50760$f24318ac@ent.core.medtronic.com> Hello, If you are attempting to compile OpenSSH with the Sun Forte 6 Update 2 compiler on Solaris 8 (Solaris 8 7/01 s28s_u5wos_08 SPARC) then spare yourself the madness and make sure you have the following patches: 111685-02 C++ 5.3: Patch for Forte Developer 6 Update 2 C++ compiler and 111678-04 Compiler Common 6.2: Patch Forte Developer 6 Update 2, C++ F77 F95. I would also suggest the following patches (versions should be => versions listed below...these are current as of 2 days ago): 108434-03 32bit shared library patch for C++ 108435-03 64bit shared library patch for C++ 108528-11 Kernel Patch 108991-17 /usr/lib/libc.so.1 patch 109147-12 SunOS 5.8 Linker patch On Solaris 2.6 you should make sure you have the latest C/C++ library patches as well as the Forte patches mentioned above and 105591-12. I will be finding a 2.6 box I can patch tomorrow. I can't tell you exactly which patches you will need, but I suggest you at least apply all the latest C/C++ patches, linker patches, and Forte Patches. I believe the Forte patches resolve the problem since yesterday I applied all the C/C++, linker, and kernel patches and I was unable to compile and have things function without changing source for openssl. I hope somebody finds this useful. I will report back on Solaris 2.6. If you still can't get things to work then you can always do the following to the openssl code (this is for 0.9.6b): Please change line 69 in openssl-0.9.6b/crypto/dsa/dsa_lib.c from static DSA_METHOD *default_DSA_method; to static DSA_METHOD *default_DSA_method = NULL; I just found another of these beasts in crypto/dh/dh_lib.c. Change static const DH_METHOD *default_DH_method; to static const DH_METHOD *default_DH_method = NULL; -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011106/b8c32d29/attachment.html From doctor at doctor.nl2k.ab.ca Wed Nov 7 11:25:29 2001 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 6 Nov 2001 17:25:29 -0700 Subject: OpenSSH 3.0 In-Reply-To: <20011106224841.A20613@folly>; from markus@openbsd.org on Tue, Nov 06, 2001 at 04:48:41PM -0500 References: <20011106224841.A20613@folly> Message-ID: <20011106172529.A13661@doctor.nl2k.ab.ca> On Tue, Nov 06, 2001 at 04:48:41PM -0500, Markus Friedl wrote: > OpenSSH 3.0 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 > implementation and includes sftp client and server support. > > This release contains many portability bug-fixes (listed in the > ChangeLog) as well as several new features (listed below). > > We would like to thank the OpenSSH community for their continued > support and encouragement. > > Important Changes: > ================== > > 1) SSH protocol v2 is now the default protocol version > > use the 'Protocol' option from ssh(1) and sshd(8) if > you need to change this. > > 2) The files > /etc/ssh_known_hosts2 > ~/.ssh/known_hosts2 > ~/.ssh/authorized_keys2 > are now obsolete, you can use > /etc/ssh_known_hosts > ~/.ssh/known_hosts > ~/.ssh/authorized_keys > For backward compatibility ~/.ssh/authorized_keys2 will still used for > authentication and hostkeys are still read from the known_hosts2. > However, those deprecated files are considered 'readonly'. Future > releases are likely not to read these files. > > 3) The CheckMail option in sshd_config is deprecated, as sshd(8) no longer > checks for new mail. > > 4) X11 cookies are now stored in $HOME. > > New Features: > ============= > > 1) Smartcard support in the ssh client and agent based on work by > University of Michigan CITI (http://www.citi.umich.edu/projects/smartcard/). > > 2) support for Rekeying in protocol version 2 > > 3) improved Kerberos support in protocol v1 (KerbIV and KerbV) > > 4) backward compatibility with older commercial SSH versions >= 2.0.10 > > 5) getopt(3) is now used by all programs > > 6) dynamic forwarding (use ssh(1) as your socks server) > > 7) ClearAllForwardings in ssh(1) > > 8) ssh(1) now checks the hostkey for localhost (NoHostAuthenticationForLocalhost yes/no). > > 9) -F option in ssh(1) > > 10) ssh(1) now has a '-b bindaddress' option > > 11) scp(1) allows "scp /file localhost:/file" > > 12) The AuthorizedKeysFile option allows specification of alternative > files that contain the public keys that can be used for user authentication > (e.g. /etc/ssh_keys/%u, see sshd(8)) > > 13) extended AllowUsers user at host syntax in sshd(8) > > 14) improved challenge-response support (especially for systems supporting BSD_AUTH) > > 15) sshd(8) can specify time args as 1h, 2h30s etc. > > 16) sshd(8) transmits the correct exit status for remote execution with protocol version 2. > > 17) ssh-keygen(1) can import private RSA/DSA keys generated with the commercial version > > 18) ssh-keyscan(1) supports protocol version 2 > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, > Kevin Steves, Damien Miller and Ben Lindstrom. > Hate to do this but BSD/OS gives us: Script started on Tue Nov 6 17:23:15 2001 doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ make (cd openbsd-compat; make) gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib -lssh -lopenbsd-compat -lutil -lz -lcrypto gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib -lssh -lopenbsd-compat -lutil -lz -lcrypto auth.o: In function `allowed_user': /usr/source/openssh-3.0p1/auth.c:80: undefined reference to `getspnam' *** Error code 1 Stop. doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ gmake (cd openbsd-compat; gmake) gmake[1]: Entering directory `/usr/source/openssh-3.0p1/openbsd-compat' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/source/openssh-3.0p1/openbsd-compat' gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib -lssh -lopenbsd-compat -lutil -lz -lcrypto auth.o: In function `allowed_user': /usr/source/openssh-3.0p1/auth.c:80: undefined reference to `getspnam' gmake: *** [sshd] Error 1 doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ egrep getspnam /usr/include/*.h /usr/include/shadow.h:extern struct spwd *getspnam (__const char *__name) ; /usr/include/shadow.h:extern int getspnam_r (__const char *__name, struct spwd *__result_buf, doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ cat auth.c /* * Copyright (c) 2000 Markus Friedl. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #include "includes.h" RCSID("$OpenBSD: auth.c,v 1.28 2001/10/03 10:01:20 markus Exp $"); #ifdef HAVE_LOGIN_H #include #endif #include #ifdef HAVE_LIBGEN_H #include #endif #include "xmalloc.h" #include "match.h" #include "groupaccess.h" #include "log.h" #include "servconf.h" #include "auth.h" #include "auth-options.h" #include "canohost.h" #include "buffer.h" #include "bufaux.h" #include "uidswap.h" #include "tildexpand.h" /* import */ extern ServerOptions options; /* * Check if the user is allowed to log in via ssh. If user is listed * in DenyUsers or one of user's groups is listed in DenyGroups, false * will be returned. If AllowUsers isn't empty and user isn't listed * there, or if AllowGroups isn't empty and one of user's groups isn't * listed there, false will be returned. * If the user's shell is not executable, false will be returned. * Otherwise true is returned. */ int allowed_user(struct passwd * pw) { struct stat st; const char *hostname = NULL, *ipaddr = NULL; char *shell; int i; #ifdef WITH_AIXAUTHENTICATE char *loginmsg; #endif /* WITH_AIXAUTHENTICATE */ #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) struct spwd *spw; /* Shouldn't be called if pw is NULL, but better safe than sorry... */ if (!pw || !pw->pw_name) return 0; spw = getspnam(pw->pw_name); if (spw != NULL) { int days = time(NULL) / 86400; /* Check account expiry */ if ((spw->sp_expire >= 0) && (days > spw->sp_expire)) return 0; /* Check password expiry */ if ((spw->sp_lstchg >= 0) && (spw->sp_max >= 0) && (days > (spw->sp_lstchg + spw->sp_max))) return 0; } #else /* Shouldn't be called if pw is NULL, but better safe than sorry... */ if (!pw || !pw->pw_name) return 0; #endif /* * Get the shell from the password data. An empty shell field is * legal, and means /bin/sh. */ shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell; /* deny if shell does not exists or is not executable */ if (stat(shell, &st) != 0) return 0; if (!((st.st_mode & S_IFREG) && (st.st_mode & (S_IXOTH|S_IXUSR|S_IXGRP)))) return 0; if (options.num_deny_users > 0 || options.num_allow_users > 0) { hostname = get_canonical_hostname(options.reverse_mapping_check); ipaddr = get_remote_ipaddr(); } /* Return false if user is listed in DenyUsers */ if (options.num_deny_users > 0) { for (i = 0; i < options.num_deny_users; i++) if (match_user(pw->pw_name, hostname, ipaddr, options.deny_users[i])) return 0; } /* Return false if AllowUsers isn't empty and user isn't listed there */ if (options.num_allow_users > 0) { for (i = 0; i < options.num_allow_users; i++) if (match_user(pw->pw_name, hostname, ipaddr, options.allow_users[i])) break; /* i < options.num_allow_users iff we break for loop */ if (i >= options.num_allow_users) return 0; } if (options.num_deny_groups > 0 || options.num_allow_groups > 0) { /* Get the user's group access list (primary and supplementary) */ if (ga_init(pw->pw_name, pw->pw_gid) == 0) return 0; /* Return false if one of user's groups is listed in DenyGroups */ if (options.num_deny_groups > 0) if (ga_match(options.deny_groups, options.num_deny_groups)) { ga_free(); return 0; } /* * Return false if AllowGroups isn't empty and one of user's groups * isn't listed there */ if (options.num_allow_groups > 0) if (!ga_match(options.allow_groups, options.num_allow_groups)) { ga_free(); return 0; } ga_free(); } #ifdef WITH_AIXAUTHENTICATE if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) { if (loginmsg && *loginmsg) { /* Remove embedded newlines (if any) */ char *p; for (p = loginmsg; *p; p++) { if (*p == '\n') *p = ' '; } /* Remove trailing newline */ *--p = '\0'; log("Login restricted for %s: %.100s", pw->pw_name, loginmsg); } return 0; } #endif /* WITH_AIXAUTHENTICATE */ /* We found no reason not to let this user try to log on... */ return 1; } Authctxt * authctxt_new(void) { Authctxt *authctxt = xmalloc(sizeof(*authctxt)); memset(authctxt, 0, sizeof(*authctxt)); return authctxt; } void auth_log(Authctxt *authctxt, int authenticated, char *method, char *info) { void (*authlog) (const char *fmt,...) = verbose; char *authmsg; /* Raise logging level */ if (authenticated == 1 || !authctxt->valid || authctxt->failures >= AUTH_FAIL_LOG || strcmp(method, "password") == 0) authlog = log; if (authctxt->postponed) authmsg = "Postponed"; else authmsg = authenticated ? "Accepted" : "Failed"; authlog("%s %s for %s%.100s from %.200s port %d%s", authmsg, method, authctxt->valid ? "" : "illegal user ", authctxt->valid && authctxt->pw->pw_uid == 0 ? "ROOT" : authctxt->user, get_remote_ipaddr(), get_remote_port(), info); } /* * Check whether root logins are disallowed. */ int auth_root_allowed(char *method) { switch (options.permit_root_login) { case PERMIT_YES: return 1; break; case PERMIT_NO_PASSWD: if (strcmp(method, "password") != 0) return 1; break; case PERMIT_FORCED_ONLY: if (forced_command) { log("Root login accepted for forced command."); return 1; } break; } log("ROOT LOGIN REFUSED FROM %.200s", get_remote_ipaddr()); return 0; } /* * Given a template and a passwd structure, build a filename * by substituting % tokenised options. Currently, %% becomes '%', * %h becomes the home directory and %u the username. * * This returns a buffer allocated by xmalloc. */ char * expand_filename(const char *filename, struct passwd *pw) { Buffer buffer; char *file; const char *cp; /* * Build the filename string in the buffer by making the appropriate * substitutions to the given file name. */ buffer_init(&buffer); for (cp = filename; *cp; cp++) { if (cp[0] == '%' && cp[1] == '%') { buffer_append(&buffer, "%", 1); cp++; continue; } if (cp[0] == '%' && cp[1] == 'h') { buffer_append(&buffer, pw->pw_dir, strlen(pw->pw_dir)); cp++; continue; } if (cp[0] == '%' && cp[1] == 'u') { buffer_append(&buffer, pw->pw_name, strlen(pw->pw_name)); cp++; continue; } buffer_append(&buffer, cp, 1); } buffer_append(&buffer, "\0", 1); /* * Ensure that filename starts anchored. If not, be backward * compatible and prepend the '%h/' */ file = xmalloc(MAXPATHLEN); cp = buffer_ptr(&buffer); if (*cp != '/') snprintf(file, MAXPATHLEN, "%s/%s", pw->pw_dir, cp); else strlcpy(file, cp, MAXPATHLEN); buffer_free(&buffer); return file; } char * authorized_keys_file(struct passwd *pw) { return expand_filename(options.authorized_keys_file, pw); } char * authorized_keys_file2(struct passwd *pw) { return expand_filename(options.authorized_keys_file2, pw); } /* return ok if key exists in sysfile or userfile */ HostStatus check_key_in_hostfiles(struct passwd *pw, Key *key, const char *host, const char *sysfile, const char *userfile) { Key *found; char *user_hostfile; struct stat st; int host_status; /* Check if we know the host and its host key. */ found = key_new(key->type); host_status = check_host_in_hostfile(sysfile, host, key, found, NULL); if (host_status != HOST_OK && userfile != NULL) { user_hostfile = tilde_expand_filename(userfile, pw->pw_uid); if (options.strict_modes && (stat(user_hostfile, &st) == 0) && ((st.st_uid != 0 && st.st_uid != pw->pw_uid) || (st.st_mode & 022) != 0)) { log("Authentication refused for %.100s: " "bad owner or modes for %.200s", pw->pw_name, user_hostfile); } else { temporarily_use_uid(pw); host_status = check_host_in_hostfile(user_hostfile, host, key, found, NULL); restore_uid(); } xfree(user_hostfile); } key_free(found); debug2("check_key_in_hostfiles: key %s for %s", host_status == HOST_OK ? "ok" : "not found", host); return host_status; } /* * Check a given file for security. This is defined as all components * of the path to the file must either be owned by either the owner of * of the file or root and no directories must be group or world writable. * * XXX Should any specific check be done for sym links ? * * Takes an open file descriptor, the file name, a uid and and * error buffer plus max size as arguments. * * Returns 0 on success and -1 on failure */ int secure_filename(FILE *f, const char *file, struct passwd *pw, char *err, size_t errlen) { uid_t uid = pw->pw_uid; char buf[MAXPATHLEN], homedir[MAXPATHLEN]; char *cp; struct stat st; if (realpath(file, buf) == NULL) { snprintf(err, errlen, "realpath %s failed: %s", file, strerror(errno)); return -1; } if (realpath(pw->pw_dir, homedir) == NULL) { snprintf(err, errlen, "realpath %s failed: %s", pw->pw_dir, strerror(errno)); return -1; } /* check the open file to avoid races */ if (fstat(fileno(f), &st) < 0 || (st.st_uid != 0 && st.st_uid != uid) || (st.st_mode & 022) != 0) { snprintf(err, errlen, "bad ownership or modes for file %s", buf); return -1; } /* for each component of the canonical path, walking upwards */ for (;;) { if ((cp = dirname(buf)) == NULL) { snprintf(err, errlen, "dirname() failed"); return -1; } strlcpy(buf, cp, sizeof(buf)); debug3("secure_filename: checking '%s'", buf); if (stat(buf, &st) < 0 || (st.st_uid != 0 && st.st_uid != uid) || (st.st_mode & 022) != 0) { snprintf(err, errlen, "bad ownership or modes for directory %s", buf); return -1; } /* If are passed the homedir then we can stop */ if (strcmp(homedir, buf) == 0) { debug3("secure_filename: terminating check at '%s'", buf); break; } /* * dirname should always complete with a "/" path, * but we can be paranoid and check for "." too */ if ((strcmp("/", buf) == 0) || (strcmp(".", buf) == 0)) break; } return 0; } doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ exit exit Script done on Tue Nov 6 17:23:55 2001 -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca Society MUST be saved! Extremists must dissolve. Lest we forget on 11 Nov 2001 From djm at mindrot.org Wed Nov 7 11:50:03 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Nov 2001 11:50:03 +1100 (EST) Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: Message-ID: On Tue, 6 Nov 2001, Ed Phillips wrote: > What I don't understand about the internal entropy collection is why can't > sshd just run the commands periodically just like prngd, and keep a > running, stirred pool of random numbers to use when a client connects? Two reasons: 1. That is what PRNGd is for 2. Noone has ever contributed the code -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Wed Nov 7 11:51:45 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Nov 2001 11:51:45 +1100 (EST) Subject: Entropy and DSA key In-Reply-To: Message-ID: On Tue, 6 Nov 2001, Ed Phillips wrote: > > I don't buy that argument. If somebody has the ability to steal your > > seed-save file, that means your system has already been compromised so I > > don't see the point of trying to secure it further, certainly not at such a > > high cost of time spent on every ssh client startup. I think the only > > thing to worry about is an external attacker. > > Well put. I agree. Sometimes, in all the security "hub-bub" I think > people fail to realize some of these simple things. For anyone who has > slower, older systems to support (we only have approximately 100 Suns > ranging from SS1+ to 6800), the fact that ssh takes 2 minutes instead of 5 > seconds has immense system administrative ramifications. For example, if > you want to change the root password on every system - get ready to spend > the whole weekend... Crap - you can use PRNGd and not have any problem at all. That is why it is RECOMMENDED. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From doctor at doctor.nl2k.ab.ca Wed Nov 7 11:25:29 2001 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 6 Nov 2001 19:25:29 -0500 Subject: OpenSSH 3.0 In-Reply-To: <20011106224841.A20613@folly>; from markus@openbsd.org on Tue, Nov 06, 2001 at 04:48:41PM -0500 References: <20011106224841.A20613@folly> Message-ID: <20011106172529.A13661@doctor.nl2k.ab.ca> On Tue, Nov 06, 2001 at 04:48:41PM -0500, Markus Friedl wrote: > OpenSSH 3.0 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 > implementation and includes sftp client and server support. > > This release contains many portability bug-fixes (listed in the > ChangeLog) as well as several new features (listed below). > > We would like to thank the OpenSSH community for their continued > support and encouragement. > > Important Changes: > ================== > > 1) SSH protocol v2 is now the default protocol version > > use the 'Protocol' option from ssh(1) and sshd(8) if > you need to change this. > > 2) The files > /etc/ssh_known_hosts2 > ~/.ssh/known_hosts2 > ~/.ssh/authorized_keys2 > are now obsolete, you can use > /etc/ssh_known_hosts > ~/.ssh/known_hosts > ~/.ssh/authorized_keys > For backward compatibility ~/.ssh/authorized_keys2 will still used for > authentication and hostkeys are still read from the known_hosts2. > However, those deprecated files are considered 'readonly'. Future > releases are likely not to read these files. > > 3) The CheckMail option in sshd_config is deprecated, as sshd(8) no longer > checks for new mail. > > 4) X11 cookies are now stored in $HOME. > > New Features: > ============= > > 1) Smartcard support in the ssh client and agent based on work by > University of Michigan CITI (http://www.citi.umich.edu/projects/smartcard/). > > 2) support for Rekeying in protocol version 2 > > 3) improved Kerberos support in protocol v1 (KerbIV and KerbV) > > 4) backward compatibility with older commercial SSH versions >= 2.0.10 > > 5) getopt(3) is now used by all programs > > 6) dynamic forwarding (use ssh(1) as your socks server) > > 7) ClearAllForwardings in ssh(1) > > 8) ssh(1) now checks the hostkey for localhost (NoHostAuthenticationForLocalhost yes/no). > > 9) -F option in ssh(1) > > 10) ssh(1) now has a '-b bindaddress' option > > 11) scp(1) allows "scp /file localhost:/file" > > 12) The AuthorizedKeysFile option allows specification of alternative > files that contain the public keys that can be used for user authentication > (e.g. /etc/ssh_keys/%u, see sshd(8)) > > 13) extended AllowUsers user at host syntax in sshd(8) > > 14) improved challenge-response support (especially for systems supporting BSD_AUTH) > > 15) sshd(8) can specify time args as 1h, 2h30s etc. > > 16) sshd(8) transmits the correct exit status for remote execution with protocol version 2. > > 17) ssh-keygen(1) can import private RSA/DSA keys generated with the commercial version > > 18) ssh-keyscan(1) supports protocol version 2 > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, > Kevin Steves, Damien Miller and Ben Lindstrom. > Hate to do this but BSD/OS gives us: Script started on Tue Nov 6 17:23:15 2001 doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ make (cd openbsd-compat; make) gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib -lssh -lopenbsd-compat -lutil -lz -lcrypto gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib -lssh -lopenbsd-compat -lutil -lz -lcrypto auth.o: In function `allowed_user': /usr/source/openssh-3.0p1/auth.c:80: undefined reference to `getspnam' *** Error code 1 Stop. doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ gmake (cd openbsd-compat; gmake) gmake[1]: Entering directory `/usr/source/openssh-3.0p1/openbsd-compat' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/source/openssh-3.0p1/openbsd-compat' gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib -lssh -lopenbsd-compat -lutil -lz -lcrypto auth.o: In function `allowed_user': /usr/source/openssh-3.0p1/auth.c:80: undefined reference to `getspnam' gmake: *** [sshd] Error 1 doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ egrep getspnam /usr/include/*.h /usr/include/shadow.h:extern struct spwd *getspnam (__const char *__name) ; /usr/include/shadow.h:extern int getspnam_r (__const char *__name, struct spwd *__result_buf, doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ cat auth.c /* * Copyright (c) 2000 Markus Friedl. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #include "includes.h" RCSID("$OpenBSD: auth.c,v 1.28 2001/10/03 10:01:20 markus Exp $"); #ifdef HAVE_LOGIN_H #include #endif #include #ifdef HAVE_LIBGEN_H #include #endif #include "xmalloc.h" #include "match.h" #include "groupaccess.h" #include "log.h" #include "servconf.h" #include "auth.h" #include "auth-options.h" #include "canohost.h" #include "buffer.h" #include "bufaux.h" #include "uidswap.h" #include "tildexpand.h" /* import */ extern ServerOptions options; /* * Check if the user is allowed to log in via ssh. If user is listed * in DenyUsers or one of user's groups is listed in DenyGroups, false * will be returned. If AllowUsers isn't empty and user isn't listed * there, or if AllowGroups isn't empty and one of user's groups isn't * listed there, false will be returned. * If the user's shell is not executable, false will be returned. * Otherwise true is returned. */ int allowed_user(struct passwd * pw) { struct stat st; const char *hostname = NULL, *ipaddr = NULL; char *shell; int i; #ifdef WITH_AIXAUTHENTICATE char *loginmsg; #endif /* WITH_AIXAUTHENTICATE */ #if !defined(USE_PAM) && defined(HAVE_SHADOW_H) && \ !defined(DISABLE_SHADOW) && defined(HAS_SHADOW_EXPIRE) struct spwd *spw; /* Shouldn't be called if pw is NULL, but better safe than sorry... */ if (!pw || !pw->pw_name) return 0; spw = getspnam(pw->pw_name); if (spw != NULL) { int days = time(NULL) / 86400; /* Check account expiry */ if ((spw->sp_expire >= 0) && (days > spw->sp_expire)) return 0; /* Check password expiry */ if ((spw->sp_lstchg >= 0) && (spw->sp_max >= 0) && (days > (spw->sp_lstchg + spw->sp_max))) return 0; } #else /* Shouldn't be called if pw is NULL, but better safe than sorry... */ if (!pw || !pw->pw_name) return 0; #endif /* * Get the shell from the password data. An empty shell field is * legal, and means /bin/sh. */ shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell; /* deny if shell does not exists or is not executable */ if (stat(shell, &st) != 0) return 0; if (!((st.st_mode & S_IFREG) && (st.st_mode & (S_IXOTH|S_IXUSR|S_IXGRP)))) return 0; if (options.num_deny_users > 0 || options.num_allow_users > 0) { hostname = get_canonical_hostname(options.reverse_mapping_check); ipaddr = get_remote_ipaddr(); } /* Return false if user is listed in DenyUsers */ if (options.num_deny_users > 0) { for (i = 0; i < options.num_deny_users; i++) if (match_user(pw->pw_name, hostname, ipaddr, options.deny_users[i])) return 0; } /* Return false if AllowUsers isn't empty and user isn't listed there */ if (options.num_allow_users > 0) { for (i = 0; i < options.num_allow_users; i++) if (match_user(pw->pw_name, hostname, ipaddr, options.allow_users[i])) break; /* i < options.num_allow_users iff we break for loop */ if (i >= options.num_allow_users) return 0; } if (options.num_deny_groups > 0 || options.num_allow_groups > 0) { /* Get the user's group access list (primary and supplementary) */ if (ga_init(pw->pw_name, pw->pw_gid) == 0) return 0; /* Return false if one of user's groups is listed in DenyGroups */ if (options.num_deny_groups > 0) if (ga_match(options.deny_groups, options.num_deny_groups)) { ga_free(); return 0; } /* * Return false if AllowGroups isn't empty and one of user's groups * isn't listed there */ if (options.num_allow_groups > 0) if (!ga_match(options.allow_groups, options.num_allow_groups)) { ga_free(); return 0; } ga_free(); } #ifdef WITH_AIXAUTHENTICATE if (loginrestrictions(pw->pw_name, S_RLOGIN, NULL, &loginmsg) != 0) { if (loginmsg && *loginmsg) { /* Remove embedded newlines (if any) */ char *p; for (p = loginmsg; *p; p++) { if (*p == '\n') *p = ' '; } /* Remove trailing newline */ *--p = '\0'; log("Login restricted for %s: %.100s", pw->pw_name, loginmsg); } return 0; } #endif /* WITH_AIXAUTHENTICATE */ /* We found no reason not to let this user try to log on... */ return 1; } Authctxt * authctxt_new(void) { Authctxt *authctxt = xmalloc(sizeof(*authctxt)); memset(authctxt, 0, sizeof(*authctxt)); return authctxt; } void auth_log(Authctxt *authctxt, int authenticated, char *method, char *info) { void (*authlog) (const char *fmt,...) = verbose; char *authmsg; /* Raise logging level */ if (authenticated == 1 || !authctxt->valid || authctxt->failures >= AUTH_FAIL_LOG || strcmp(method, "password") == 0) authlog = log; if (authctxt->postponed) authmsg = "Postponed"; else authmsg = authenticated ? "Accepted" : "Failed"; authlog("%s %s for %s%.100s from %.200s port %d%s", authmsg, method, authctxt->valid ? "" : "illegal user ", authctxt->valid && authctxt->pw->pw_uid == 0 ? "ROOT" : authctxt->user, get_remote_ipaddr(), get_remote_port(), info); } /* * Check whether root logins are disallowed. */ int auth_root_allowed(char *method) { switch (options.permit_root_login) { case PERMIT_YES: return 1; break; case PERMIT_NO_PASSWD: if (strcmp(method, "password") != 0) return 1; break; case PERMIT_FORCED_ONLY: if (forced_command) { log("Root login accepted for forced command."); return 1; } break; } log("ROOT LOGIN REFUSED FROM %.200s", get_remote_ipaddr()); return 0; } /* * Given a template and a passwd structure, build a filename * by substituting % tokenised options. Currently, %% becomes '%', * %h becomes the home directory and %u the username. * * This returns a buffer allocated by xmalloc. */ char * expand_filename(const char *filename, struct passwd *pw) { Buffer buffer; char *file; const char *cp; /* * Build the filename string in the buffer by making the appropriate * substitutions to the given file name. */ buffer_init(&buffer); for (cp = filename; *cp; cp++) { if (cp[0] == '%' && cp[1] == '%') { buffer_append(&buffer, "%", 1); cp++; continue; } if (cp[0] == '%' && cp[1] == 'h') { buffer_append(&buffer, pw->pw_dir, strlen(pw->pw_dir)); cp++; continue; } if (cp[0] == '%' && cp[1] == 'u') { buffer_append(&buffer, pw->pw_name, strlen(pw->pw_name)); cp++; continue; } buffer_append(&buffer, cp, 1); } buffer_append(&buffer, "\0", 1); /* * Ensure that filename starts anchored. If not, be backward * compatible and prepend the '%h/' */ file = xmalloc(MAXPATHLEN); cp = buffer_ptr(&buffer); if (*cp != '/') snprintf(file, MAXPATHLEN, "%s/%s", pw->pw_dir, cp); else strlcpy(file, cp, MAXPATHLEN); buffer_free(&buffer); return file; } char * authorized_keys_file(struct passwd *pw) { return expand_filename(options.authorized_keys_file, pw); } char * authorized_keys_file2(struct passwd *pw) { return expand_filename(options.authorized_keys_file2, pw); } /* return ok if key exists in sysfile or userfile */ HostStatus check_key_in_hostfiles(struct passwd *pw, Key *key, const char *host, const char *sysfile, const char *userfile) { Key *found; char *user_hostfile; struct stat st; int host_status; /* Check if we know the host and its host key. */ found = key_new(key->type); host_status = check_host_in_hostfile(sysfile, host, key, found, NULL); if (host_status != HOST_OK && userfile != NULL) { user_hostfile = tilde_expand_filename(userfile, pw->pw_uid); if (options.strict_modes && (stat(user_hostfile, &st) == 0) && ((st.st_uid != 0 && st.st_uid != pw->pw_uid) || (st.st_mode & 022) != 0)) { log("Authentication refused for %.100s: " "bad owner or modes for %.200s", pw->pw_name, user_hostfile); } else { temporarily_use_uid(pw); host_status = check_host_in_hostfile(user_hostfile, host, key, found, NULL); restore_uid(); } xfree(user_hostfile); } key_free(found); debug2("check_key_in_hostfiles: key %s for %s", host_status == HOST_OK ? "ok" : "not found", host); return host_status; } /* * Check a given file for security. This is defined as all components * of the path to the file must either be owned by either the owner of * of the file or root and no directories must be group or world writable. * * XXX Should any specific check be done for sym links ? * * Takes an open file descriptor, the file name, a uid and and * error buffer plus max size as arguments. * * Returns 0 on success and -1 on failure */ int secure_filename(FILE *f, const char *file, struct passwd *pw, char *err, size_t errlen) { uid_t uid = pw->pw_uid; char buf[MAXPATHLEN], homedir[MAXPATHLEN]; char *cp; struct stat st; if (realpath(file, buf) == NULL) { snprintf(err, errlen, "realpath %s failed: %s", file, strerror(errno)); return -1; } if (realpath(pw->pw_dir, homedir) == NULL) { snprintf(err, errlen, "realpath %s failed: %s", pw->pw_dir, strerror(errno)); return -1; } /* check the open file to avoid races */ if (fstat(fileno(f), &st) < 0 || (st.st_uid != 0 && st.st_uid != uid) || (st.st_mode & 022) != 0) { snprintf(err, errlen, "bad ownership or modes for file %s", buf); return -1; } /* for each component of the canonical path, walking upwards */ for (;;) { if ((cp = dirname(buf)) == NULL) { snprintf(err, errlen, "dirname() failed"); return -1; } strlcpy(buf, cp, sizeof(buf)); debug3("secure_filename: checking '%s'", buf); if (stat(buf, &st) < 0 || (st.st_uid != 0 && st.st_uid != uid) || (st.st_mode & 022) != 0) { snprintf(err, errlen, "bad ownership or modes for directory %s", buf); return -1; } /* If are passed the homedir then we can stop */ if (strcmp(homedir, buf) == 0) { debug3("secure_filename: terminating check at '%s'", buf); break; } /* * dirname should always complete with a "/" path, * but we can be paranoid and check for "." too */ if ((strcmp("/", buf) == 0) || (strcmp(".", buf) == 0)) break; } return 0; } doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ exit exit Script done on Tue Nov 6 17:23:55 2001 -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca Society MUST be saved! Extremists must dissolve. Lest we forget on 11 Nov 2001 From djm at mindrot.org Wed Nov 7 13:50:17 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 7 Nov 2001 13:50:17 +1100 (EST) Subject: OpenSSH 3.0 In-Reply-To: <20011106172529.A13661@doctor.nl2k.ab.ca> Message-ID: On Tue, 6 Nov 2001, The Doctor wrote: [snip] Was it necessary to quote the entire release, cat the whole source file (like we don't have it?) AND CC everyone on the release notification list? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From doctor at doctor.nl2k.ab.ca Wed Nov 7 14:04:47 2001 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 6 Nov 2001 20:04:47 -0700 Subject: OpenSSH 3.0 In-Reply-To: ; from djm@mindrot.org on Wed, Nov 07, 2001 at 01:50:17PM +1100 References: <20011106172529.A13661@doctor.nl2k.ab.ca> Message-ID: <20011106200447.A28961@doctor.nl2k.ab.ca> Point of the matter is that we need to know who to report bugs to. On Wed, Nov 07, 2001 at 01:50:17PM +1100, Damien Miller wrote: > On Tue, 6 Nov 2001, The Doctor wrote: > > [snip] > > Was it necessary to quote the entire release, cat the whole source file > (like we don't have it?) AND CC everyone on the release notification > list? > > -d > > -- > | By convention there is color, \\ Damien Miller > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > | But in reality there are atoms and space - Democritus (c. 400 BCE) > -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca Society MUST be saved! Extremists must dissolve. Lest we forget on 11 Nov 2001 From gleblanc at linuxweasel.com Wed Nov 7 14:10:27 2001 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: 06 Nov 2001 19:10:27 -0800 Subject: OpenSSH 3.0 In-Reply-To: <20011106200447.A28961@doctor.nl2k.ab.ca> References: <20011106172529.A13661@doctor.nl2k.ab.ca> <20011106200447.A28961@doctor.nl2k.ab.ca> Message-ID: <1005102628.3564.15.camel@peecee> On Tue, 2001-11-06 at 19:04, The Doctor wrote: > Point of the matter is that we need to know who to report bugs to. Linked from www.openssh.org is http://www.openssh.org/report.html Greg From gotoh at taiyo.co.jp Wed Nov 7 14:47:48 2001 From: gotoh at taiyo.co.jp (Shun-ichi GOTO) Date: Wed, 07 Nov 2001 12:47:48 +0900 (JST) Subject: OpenSSH 3.0 In-Reply-To: <20011106224841.A20613@folly> References: <20011106224841.A20613@folly> Message-ID: <20011107.124748.92055508.gotoh@taiyo.co.jp> > OpenSSH 3.0 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. Following patch reported at 2001/10/09 is not applied in OpenSSH 3.0p1. Without this, ssh program cause acecss violation or memory overwrite problem if SSH_ASKPASS program returns too long string (greater than sizeof buf). And also treat '\r' character as line terminator like '\n' for safe. --- readpass.c 2001/10/09 05:42:49 1.1.1.1 +++ readpass.c 2001/10/09 08:06:38 @@ -45,7 +45,7 @@ { pid_t pid; size_t len; - char *nl, *pass; + char *pass; int p[2], status; char buf[1024]; @@ -71,16 +71,15 @@ fatal("ssh_askpass: exec(%s): %s", askpass, strerror(errno)); } close(p[1]); - len = read(p[0], buf, sizeof buf); + len = read(p[0], buf, sizeof buf -1); close(p[0]); while (waitpid(pid, &status, 0) < 0) if (errno != EINTR) break; if (len <= 1) return xstrdup(""); - nl = strchr(buf, '\n'); - if (nl) - *nl = '\0'; + buf[len] = '\0'; + buf[strcspn(buf, "\r\n")] = '\0'; pass = xstrdup(buf); memset(buf, 0, sizeof(buf)); return pass; --- Regards, Shun-ichi Goto R&D Group, TAIYO Corp., Tokyo, JAPAN From mouring at etoh.eviladmin.org Wed Nov 7 15:10:16 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 6 Nov 2001 22:10:16 -0600 (CST) Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: Message-ID: Ed, Did we not just get done talking about this in another topic. Did we not just discuss most of the time spent in SSH v2 protocol connections is in the D/YH key exchange? Did we not already establish that entropy gathering itself is very low overhead even on slower boxes? I REALLY WISH PEOPLE WOULD READ AND DO THEIR HOMEWORK. Delete your primes or moduli file and see how much it drops. As stated that will remove points where it does complex encryption. V2 was never designed w/ lowend boxes in mind. What is the performance of v1 on your SS1+? - Ben On Tue, 6 Nov 2001, Ed Phillips wrote: > On Tue, 6 Nov 2001, Lutz Jaenicke wrote: > > > Date: Tue, 6 Nov 2001 21:44:41 +0100 > > From: Lutz Jaenicke > > To: OpenSSH Development > > Subject: Re: Entropy collection in sshd (was Re: Entropy and DSA key) > > > > On Tue, Nov 06, 2001 at 08:57:01PM +0100, Gert Doering wrote: > > > On Tue, Nov 06, 2001 at 12:48:53PM -0500, Ed Phillips wrote: > > > > I'm not following you... the problem of "it takes 2 freakin minutes to get > > > > logged into my SS1+" is a direct result of entropy collection performed by > > > > sshd. > > > > > > No, it's not. I use NetBSD on a Sparc LX with /dev/random, and ssh takes > > > still 2 minutes - the delay is NOT caused by the random number generation > > > but by slow crypto on ancient Sparc hardware. ssh protocol 1 is much > > > quicker (and also needs random). > > > > I is hard to comment about a platform I don't know in detail, but I tend > > to sit in front of a good old HP 9000/710 (1991?), 50MHz. It took me > > some tries, but by tuning OpenSSL's flags I could gain a great deal > > of performance. Have a look into the BN_LLONG and company flags. > > Two minutes seems to be really slow to me. > > Okay, I start "ssh -v -v -v" and then it sits there for a long time at: > > ... > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > > On the server side, the bulk of the time is spent as indicated in the > DEBUG3 syslog messages below: > > Nov 6 16:59:42 ls1.nss.udel.edu sshd[1316]: debug2: kex_parse_kexinit: reserved 0 > Nov 6 16:59:42 ls1.nss.udel.edu sshd[1316]: debug2: mac_init: found hmac-md5 > Nov 6 16:59:42 ls1.nss.udel.edu sshd[1316]: debug1: kex: client->server aes128-cbc hmac-md5 none > Nov 6 16:59:43 ls1.nss.udel.edu sshd[1316]: debug2: mac_init: found hmac-md5 > Nov 6 16:59:43 ls1.nss.udel.edu sshd[1316]: debug1: kex: server->client aes128-cbc hmac-md5 none > Nov 6 16:59:43 ls1.nss.udel.edu sshd[1316]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received > Nov 6 16:59:44 ls1.nss.udel.edu sshd[1316]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > Nov 6 17:00:28 ls1.nss.udel.edu sshd[1316]: debug1: dh_gen_key: priv key bits set: 142/256 > Nov 6 17:00:28 ls1.nss.udel.edu sshd[1316]: debug1: bits set: 1609/3191 > Nov 6 17:00:28 ls1.nss.udel.edu sshd[1316]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > Nov 6 17:00:28 ls1.nss.udel.edu sshd[1316]: debug1: bits set: 1570/3191 > Nov 6 17:01:27 ls1.nss.udel.edu sshd[1316]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > Nov 6 17:01:27 ls1.nss.udel.edu sshd[1316]: debug1: kex_derive_keys > Nov 6 17:01:27 ls1.nss.udel.edu sshd[1316]: debug1: newkeys: mode 1 > Nov 6 17:01:28 ls1.nss.udel.edu sshd[1316]: debug1: SSH2_MSG_NEWKEYS sent > Nov 6 17:01:28 ls1.nss.udel.edu sshd[1316]: debug1: waiting for SSH2_MSG_NEWKEYS > > Okay... so now I'm confused. It would appear, that like you say, there is > a long pause during computation in two spots in sshd. > > I just talk with my collegue who did the install and he tells me that the > severe, long-running prng commands that timeout are during the startup of > sshd. So all this time, I've been raving about sshd running the prng > commands for every client connection... this doesn't actually occur? Oh > sheesh... what a waste of typing... > > So the real problem is that compiling OpenSSL with solaris-sparcv7-cc just > doesn't generate code that can crunch fast enough to allow login in less > than 1.5 minutes? Oh well, I guess we can live with it. Hopefully in the > next few months we'll replace any of our sun4c systems with at least a > sun4m running Sol2.6 or higher (probably Sol8). > > Sorry for the wasted bandwidth guys... hasn't been the first time... > probably won't be the last. ;-) > > So, why is ssh-1.2.27 almost instantaneous (5-10 seconds) compared to the > above (give me a FAQ-smack if you feel the need)? > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > > From gotoh at taiyo.co.jp Wed Nov 7 17:07:30 2001 From: gotoh at taiyo.co.jp (Shun-ichi GOTO) Date: Wed, 07 Nov 2001 15:07:30 +0900 (JST) Subject: OpenSSH 3.0 In-Reply-To: <20011106224841.A20613@folly> References: <20011106224841.A20613@folly> Message-ID: <20011107.150730.89922428.gotoh@taiyo.co.jp> Hi, >>>>> at Tue, 6 Nov 2001 16:48:41 -0500 >>>>> Markus Friedl said,> > OpenSSH 3.0 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. ...snip... > 6) dynamic forwarding (use ssh(1) as your socks server) This feature is interesting and userfull. However, it does not supports SOCKS4a hostname resolving extention. I made small patch to support this extension. --- Regards, Shun-ichi Goto R&D Group, TAIYO Corp., Tokyo, JAPAN -------------- next part -------------- Index: channels.c =================================================================== RCS file: /usr/home/gotoh/Repository/openssh/channels.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 channels.c --- channels.c 2001/11/07 01:18:29 1.1.1.2 +++ channels.c 2001/11/07 06:03:46 @@ -927,6 +927,27 @@ buffer_consume(&c->input, len); buffer_consume(&c->input, 1); /* trailing '\0' */ + if (memcmp(&s4_req.dest_addr, "\0\0\0", 3) == 0 && + memcmp(&s4_req.dest_addr, "\0\0\0\0", 4) != 0) { + /* SOCKS version 4a */ + struct hostent *he; + have = buffer_len(&c->input); + if (have < 2) + fatal("channel %d: decode socks4: hostname expected", c->self); + p = buffer_ptr(&c->input); + len = strlen(p); + debug2("channel %d: hostname: %s/%d", c->self, p, len); + if (len > have) + fatal("channel %d: decode socks4: len %d > have %d", + c->self, len, have); + he = gethostbyname(p); + if (he == NULL) + fatal("channel %d: decode socks4: Could not get IP address for" + " hostname %s", c->self, p); + memcpy(&s4_req.dest_addr, he->h_addr_list[0], sizeof(struct in_addr)); + buffer_consume(&c->input, len); + buffer_consume(&c->input, 1); /* trailing '\0' */ + } host = inet_ntoa(s4_req.dest_addr); strlcpy(c->path, host, sizeof(c->path)); c->host_port = ntohs(s4_req.dest_port); From markus at openbsd.org Wed Nov 7 20:28:12 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 10:28:12 +0100 Subject: OpenSSH 3.0 In-Reply-To: <20011107.150730.89922428.gotoh@taiyo.co.jp>; from gotoh@taiyo.co.jp on Wed, Nov 07, 2001 at 03:07:30PM +0900 References: <20011106224841.A20613@folly> <20011107.150730.89922428.gotoh@taiyo.co.jp> Message-ID: <20011107102812.A20066@faui02.informatik.uni-erlangen.de> On Wed, Nov 07, 2001 at 03:07:30PM +0900, Shun-ichi GOTO wrote: > + he = gethostbyname(p); 1) this blocks. 2) gethostbyname is obsolete From jayaraj at amritapuri.com Wed Nov 7 21:01:04 2001 From: jayaraj at amritapuri.com (jayaraj at amritapuri.com) Date: Wed, 7 Nov 2001 15:31:04 +0530 Subject: Flaw in empty password authentication in sshd Message-ID: <01110715310400.10838@chip.aero.iisc.ernet.in> The auth-pam.c of sshd server contains a small flaw that allows empty password logins even if "PermitEmptyPasswords" option in the sshd config file is set to "no". The scenario is as follows: Using ssh the user tries to logon to the machine using an account that has empty password. If the user presses enter on the password prompt (NULL password) access is disallowed. However upon entry of any random string the user is granted successful login. In "auth_pam_password" function (auth_pam.c) the lines: if(*password == '\0' && options.permit_empty_passwd == 0) return 0; disallows a login to an empty password account by providing empty password. However if the user provides a random non-empty password the user is able to login to an account that has empty password. This is because the "pam_authenticate" function which is called from "do_pam_authenticate" is always called with "flags" set to "0". If the system PAM authentication configuration is tightened this can be disallowed. However, since users rely on the SSH configuration this non-intuitive and buggy behaviour may be dangerous. >How-To-Repeat: The SSHD PAM configuration file must be the one that is shipped as a part of ssh install. In the source package this file is "contrib/redhat/sshd.pam-7.x". Since this file relies on system-auth file, a copy of the system-auth file in my system (standard Redhat 7.1) is pasted below: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so (Note that this has nullok configuration) Create an account that requires no password. Using ssh logon to the machine using the empty password account name. If the user presses enter on the password prompt (NULL password) access is disallowed. However upon entry of any random string the user is allowed to enter. >Fix: This problem can be overcome if "pam_authenticate" is called with "PAM_DISALLOW_NULL_AUTHTOK" flag if empty passwords are not permitted. A possible patch for the problem is given below: *** auth-pam.c Tue Apr 24 00:08:37 2001 --- auth-amrita.c Tue Nov 6 22:58:46 2001 *************** *** 203,208 **** --- 203,209 ---- { extern ServerOptions options; int pam_retval; + int flags=0; do_pam_set_conv(&conv); *************** *** 217,223 **** __pampasswd = password; pamstate = INITIAL_LOGIN; ! pam_retval = do_pam_authenticate(0); if (pam_retval == PAM_SUCCESS) { debug("PAM Password authentication accepted for " "user \"%.100s\"", pw->pw_name); --- 218,227 ---- __pampasswd = password; pamstate = INITIAL_LOGIN; ! if ( options.permit_empty_passwd == 0 ) ! flag = PAM_DISALLOW_NULL_AUTHTOK; ! ! pam_retval = do_pam_authenticate(flags); if (pam_retval == PAM_SUCCESS) { debug("PAM Password authentication accepted for " "user \"%.100s\"", pw->pw_name); --------------- Jayaraj Amrita Institute of Computer Technology, Amritapuri India From markus at openbsd.org Wed Nov 7 20:53:32 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 10:53:32 +0100 Subject: OpenSSH 3.0 In-Reply-To: <20011106172529.A13661@doctor.nl2k.ab.ca>; from doctor@doctor.nl2k.ab.ca on Tue, Nov 06, 2001 at 05:25:29PM -0700 References: <20011106224841.A20613@folly> <20011106172529.A13661@doctor.nl2k.ab.ca> Message-ID: <20011107105332.A22094@faui02.informatik.uni-erlangen.de> On Tue, Nov 06, 2001 at 05:25:29PM -0700, The Doctor wrote: > Hate to do this but BSD/OS gives us: thank you for abusing email. OpenSSH works fine for me on BSD/OS 4.2: $ sh configure --with-bsd-auth --with-ssl-dir=/usr/contrib From gotoh at taiyo.co.jp Wed Nov 7 21:01:30 2001 From: gotoh at taiyo.co.jp (Shun-ichi GOTO) Date: Wed, 07 Nov 2001 19:01:30 +0900 (JST) Subject: OpenSSH 3.0 In-Reply-To: <20011107102812.A20066@faui02.informatik.uni-erlangen.de> References: <20011106224841.A20613@folly> <20011107.150730.89922428.gotoh@taiyo.co.jp> <20011107102812.A20066@faui02.informatik.uni-erlangen.de> Message-ID: <20011107.190130.112872649.gotoh@taiyo.co.jp> >>>>> at Wed, 7 Nov 2001 10:28:12 +0100 >>>>> markus == Markus Friedl said, markus> On Wed, Nov 07, 2001 at 03:07:30PM +0900, Shun-ichi GOTO wrote: > + he = gethostbyname(p); markus> 1) this blocks. ouch! I have no plan for non-blocking way. I'll withdraw that patch. markus> 2) gethostbyname is obsolete In original source directory, I can get following result, so I use it. ## of corse, 2nd is by me. $ grep gethostbyname *.c auth-krb4.c: if ((hp = gethostbyname(localhost)) == NULL) { channels.c: he = gethostbyname(hostname); logintest.c: if (! (he = gethostbyname("localhost"))) { P.S. OpenSSH 3.0p1 works fine on BSD/OS 4.0.1. --- Regards, Shun-ichi Goto R&D Group, TAIYO Corp., Tokyo, JAPAN From markus at openbsd.org Wed Nov 7 21:13:29 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 11:13:29 +0100 Subject: OpenSSH 3.0 In-Reply-To: <20011107.190130.112872649.gotoh@taiyo.co.jp>; from gotoh@taiyo.co.jp on Wed, Nov 07, 2001 at 07:01:30PM +0900 References: <20011106224841.A20613@folly> <20011107.150730.89922428.gotoh@taiyo.co.jp> <20011107102812.A20066@faui02.informatik.uni-erlangen.de> <20011107.190130.112872649.gotoh@taiyo.co.jp> Message-ID: <20011107111329.A25748@faui02.informatik.uni-erlangen.de> On Wed, Nov 07, 2001 at 07:01:30PM +0900, Shun-ichi GOTO wrote: > > >>>>> at Wed, 7 Nov 2001 10:28:12 +0100 > >>>>> markus == Markus Friedl said, > markus> On Wed, Nov 07, 2001 at 03:07:30PM +0900, Shun-ichi GOTO wrote: > > + he = gethostbyname(p); > > markus> 1) this blocks. > > ouch! > I have no plan for non-blocking way. > I'll withdraw that patch. currently ssh blocks if you use hostnames when forwarding. i switched to non-blocking connects() but this does not help if DNS involved. > markus> 2) gethostbyname is obsolete > > In original source directory, I can get following result, so I use it. > ## of corse, 2nd is by me. yes, but kerberos does not seem to be ipv4 ready, and logintest.c seems to be a test. whenever possible we try to use getaddrinfo(). From matthew at debian.org Thu Nov 8 00:39:31 2001 From: matthew at debian.org (Matthew Vernon) Date: 07 Nov 2001 13:39:31 +0000 Subject: OpenSSH 3.0 In-Reply-To: Markus Friedl's message of Wed, 07 Nov 2001 10:32:01 GMT References: <20011106224841.A20613@folly> <20011107.150730.89922428.gotoh@taiyo.co.jp> <20011107102812.A20066@faui02.informatik.uni-erlangen.de> <20011107.190130.112872649.gotoh@taiyo.co.jp> <20011107.190130.112872649.gotoh@taiyo.co.jp> <20011107111329.A25748@faui02.informatik.uni-erlangen.de> Message-ID: <5bofmer97w.fsf@chiark.greenend.org.uk> Markus Friedl writes: > > On Wed, Nov 07, 2001 at 07:01:30PM +0900, Shun-ichi GOTO wrote: > > > > >>>>> at Wed, 7 Nov 2001 10:28:12 +0100 > > >>>>> markus == Markus Friedl said, > > markus> On Wed, Nov 07, 2001 at 03:07:30PM +0900, Shun-ichi GOTO wrote: > > > + he = gethostbyname(p); > > > > markus> 1) this blocks. > > > > ouch! > > I have no plan for non-blocking way. > > I'll withdraw that patch. > > currently ssh blocks if you use hostnames when forwarding. > > i switched to non-blocking connects() but this does not > help if DNS involved. Use ADNS? Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From markus at openbsd.org Thu Nov 8 00:46:47 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 14:46:47 +0100 Subject: OpenSSH 3.0 In-Reply-To: <5bofmer97w.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Wed, Nov 07, 2001 at 01:39:31PM +0000 References: <20011106224841.A20613@folly> <20011107.150730.89922428.gotoh@taiyo.co.jp> <20011107102812.A20066@faui02.informatik.uni-erlangen.de> <20011107.190130.112872649.gotoh@taiyo.co.jp> <20011107.190130.112872649.gotoh@taiyo.co.jp> <20011107111329.A25748@faui02.informatik.uni-erlangen.de> <5bofmer97w.fsf@chiark.greenend.org.uk> Message-ID: <20011107144647.A16751@faui02.informatik.uni-erlangen.de> On Wed, Nov 07, 2001 at 01:39:31PM +0000, Matthew Vernon wrote: > Use ADNS? GPL? bloat? portablility? From andreas at conectiva.com.br Thu Nov 8 00:59:06 2001 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Wed, 7 Nov 2001 11:59:06 -0200 Subject: what's the deal with openssh-3.0p1 and kerberos5? Message-ID: <20011107115906.M1324@conectiva.com.br> The openssh-3.0 announcement said: (...) 3) improved Kerberos support in protocol v1 (KerbIV and KerbV) (...) This seems to imply at least some krb5 support, but there is nothing new in ./configure --help about it. Grepping the source, I see many references to #ifdef KRB5. Trying to enable it manually (a #define in config.h) gives errors about a missing krb5_auth_con_setaddrs_from_fd, which I really can't find anywhere in the MIT sources, and many other missing functions. Yes, I know about the gssapi patch at http://www.sxw.org.uk/computing/patches/openssh.html, but it's only available for 2.9p2 so far and the poor guy has been repeatedly asking for it to be included in the mainstream version without success. So, is that planned? Krb5 in openssh? Or is there something wrong with the gssapi patches? I have openssh-3.0p1 and krb5-1.2.2 from MIT. From matthew at sel.cam.ac.uk Thu Nov 8 01:00:26 2001 From: matthew at sel.cam.ac.uk (Matthew Vernon) Date: Wed, 7 Nov 2001 14:00:26 +0000 (GMT) Subject: OpenSSH 3.0 In-Reply-To: <20011107144647.A16751@faui02.informatik.uni-erlangen.de> References: <20011106224841.A20613@folly> <20011107.150730.89922428.gotoh@taiyo.co.jp> <20011107102812.A20066@faui02.informatik.uni-erlangen.de> <20011107.190130.112872649.gotoh@taiyo.co.jp> <20011107111329.A25748@faui02.informatik.uni-erlangen.de> <5bofmer97w.fsf@chiark.greenend.org.uk> <20011107144647.A16751@faui02.informatik.uni-erlangen.de> Message-ID: <15337.15994.438022.179618@rapun.sel.cam.ac.uk> Markus Friedl writes: > On Wed, Nov 07, 2001 at 01:39:31PM +0000, Matthew Vernon wrote: > > Use ADNS? > > GPL? bloat? portablility? Ah. I had a memory that it was LGPL, but on checking discover I was incorrect. Matthew -- Rapun.sel - outermost outpost of the Pick Empire http://www.pick.ucam.org From markus at openbsd.org Thu Nov 8 01:04:54 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 15:04:54 +0100 Subject: OpenSSH 3.0 In-Reply-To: <15337.15994.438022.179618@rapun.sel.cam.ac.uk>; from matthew@sel.cam.ac.uk on Wed, Nov 07, 2001 at 02:00:26PM +0000 References: <20011106224841.A20613@folly> <20011107.150730.89922428.gotoh@taiyo.co.jp> <20011107102812.A20066@faui02.informatik.uni-erlangen.de> <20011107.190130.112872649.gotoh@taiyo.co.jp> <20011107111329.A25748@faui02.informatik.uni-erlangen.de> <5bofmer97w.fsf@chiark.greenend.org.uk> <20011107144647.A16751@faui02.informatik.uni-erlangen.de> <15337.15994.438022.179618@rapun.sel.cam.ac.uk> Message-ID: <20011107150453.B16751@faui02.informatik.uni-erlangen.de> On Wed, Nov 07, 2001 at 02:00:26PM +0000, Matthew Vernon wrote: > Markus Friedl writes: > > On Wed, Nov 07, 2001 at 01:39:31PM +0000, Matthew Vernon wrote: > > > Use ADNS? > > > > GPL? bloat? portablility? > > Ah. I had a memory that it was LGPL, but on checking discover I was > incorrect. apart from the GPL. it would require restructuring of big junks of code and this is not a top priority. not even if openssh gets rewritten. From ed at UDel.Edu Thu Nov 8 02:02:51 2001 From: ed at UDel.Edu (Ed Phillips) Date: Wed, 7 Nov 2001 10:02:51 -0500 (EST) Subject: Entropy collection in sshd (was Re: Entropy and DSA key) In-Reply-To: Message-ID: On Tue, 6 Nov 2001 mouring at etoh.eviladmin.org wrote: > What is the performance of v1 on your SS1+? Good... 14 seconds on the SS1+ for login with v1. Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From markus at openbsd.org Thu Nov 8 02:06:13 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 16:06:13 +0100 Subject: Entropy collection in sshd (was Re: Entropy and DSA key) Message-ID: <20011107160613.B27822@faui02.informatik.uni-erlangen.de> why don't you do some profiling instead of posting so many lines of email? From doctor at doctor.nl2k.ab.ca Thu Nov 8 02:15:49 2001 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 7 Nov 2001 08:15:49 -0700 Subject: OpenSSH 3.0 In-Reply-To: <1005102628.3564.15.camel@peecee>; from gleblanc@linuxweasel.com on Tue, Nov 06, 2001 at 07:10:27PM -0800 References: <20011106172529.A13661@doctor.nl2k.ab.ca> <20011106200447.A28961@doctor.nl2k.ab.ca> <1005102628.3564.15.camel@peecee> Message-ID: <20011107081549.E12993@doctor.nl2k.ab.ca> On Tue, Nov 06, 2001 at 07:10:27PM -0800, Gregory Leblanc wrote: > On Tue, 2001-11-06 at 19:04, The Doctor wrote: > > Point of the matter is that we need to know who to report bugs to. > > Linked from www.openssh.org is http://www.openssh.org/report.html > Greg > > Bugs go there. one for the FAQ/ -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca Society MUST be saved! Extremists must dissolve. Lest we forget on 11 Nov 2001 From doctor at doctor.nl2k.ab.ca Thu Nov 8 02:27:17 2001 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 7 Nov 2001 08:27:17 -0700 Subject: OpenSSH 3.0 In-Reply-To: <20011107105332.A22094@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Nov 07, 2001 at 10:53:32AM +0100 References: <20011106224841.A20613@folly> <20011106172529.A13661@doctor.nl2k.ab.ca> <20011107105332.A22094@faui02.informatik.uni-erlangen.de> Message-ID: <20011107082717.L12993@doctor.nl2k.ab.ca> On Wed, Nov 07, 2001 at 10:53:32AM +0100, Markus Friedl wrote: > On Tue, Nov 06, 2001 at 05:25:29PM -0700, The Doctor wrote: > > Hate to do this but BSD/OS gives us: > > thank you for abusing email. > > OpenSSH works fine for me on BSD/OS 4.2: > > $ sh configure --with-bsd-auth --with-ssl-dir=/usr/contrib apache also feels my wrath. Right, here is what I have been using since for a configuration file and was broken in 2.9.9 but works in 2.9 ./configure --prefix=/usr/contrib --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man --with-low-memory --with-elf --with-ncurses --with-openssl=/usr/contrib/openssl --with-ssl-dir=/usr/contrib/openssl --with-ssl=/usr/contrib/openssl --with-shadow --with-bsd-auth A note is that BSD systems havs their own shadow capability. DOES bsd-ish systems need --with-shadow. Note /usr/include/shadow.h is not part of BSD and is part of linux. -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca Society MUST be saved! Extremists must dissolve. Lest we forget on 11 Nov 2001 From mouring at etoh.eviladmin.org Thu Nov 8 02:30:30 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 7 Nov 2001 09:30:30 -0600 (CST) Subject: what's the deal with openssh-3.0p1 and kerberos5? In-Reply-To: <20011107115906.M1324@conectiva.com.br> Message-ID: OpenBSD's version of OpenSSH has KRB5 support ready for use. The portable group is still lagging a bit behind. I saw a set of Kerb5 enabling patches float by the list from Simon Wilkinson. I expect they will get merged in and it will be in a later 3.0pX release or in the next 3.x.x release. I could forward you the patch if you wish.. You need to have autoconf 2.52 or better to rebuild the ./configure script. Simon did (from what I can tell) a very good job of supporting MIT and HEIMDAL. Just too bad the two library developers can't standardize on an API. - Ben On Wed, 7 Nov 2001, Andreas Hasenack wrote: > The openssh-3.0 announcement said: > > (...) > 3) improved Kerberos support in protocol v1 (KerbIV and KerbV) > (...) > > This seems to imply at least some krb5 support, but there is nothing > new in ./configure --help about it. Grepping the source, I see many > references to #ifdef KRB5. Trying to enable it manually (a #define > in config.h) gives errors about a missing krb5_auth_con_setaddrs_from_fd, > which I really can't find anywhere in the MIT sources, and many > other missing functions. > > Yes, I know about the gssapi patch at > http://www.sxw.org.uk/computing/patches/openssh.html, but it's only > available for 2.9p2 so far and the poor guy has been repeatedly asking > for it to be included in the mainstream version without success. > So, is that planned? Krb5 in openssh? Or is there something wrong with > the gssapi patches? > > I have openssh-3.0p1 and krb5-1.2.2 from MIT. > > From markus at openbsd.org Thu Nov 8 02:35:05 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 16:35:05 +0100 Subject: OpenSSH 3.0 In-Reply-To: <20011107082717.L12993@doctor.nl2k.ab.ca>; from doctor@doctor.nl2k.ab.ca on Wed, Nov 07, 2001 at 08:27:17AM -0700 References: <20011106224841.A20613@folly> <20011106172529.A13661@doctor.nl2k.ab.ca> <20011107105332.A22094@faui02.informatik.uni-erlangen.de> <20011107082717.L12993@doctor.nl2k.ab.ca> Message-ID: <20011107163505.D866@faui02.informatik.uni-erlangen.de> On Wed, Nov 07, 2001 at 08:27:17AM -0700, The Doctor wrote: > On Wed, Nov 07, 2001 at 10:53:32AM +0100, Markus Friedl wrote: > > On Tue, Nov 06, 2001 at 05:25:29PM -0700, The Doctor wrote: > > > Hate to do this but BSD/OS gives us: > > > > thank you for abusing email. > > > > OpenSSH works fine for me on BSD/OS 4.2: > > > > $ sh configure --with-bsd-auth --with-ssl-dir=/usr/contrib > > apache also feels my wrath. > > Right, here is what I have been using since for a configuration file and > was broken in 2.9.9 but works in 2.9 > > > ./configure --prefix=/usr/contrib --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man --with-low-memory --with-elf --with-ncurses --with-openssl=/usr/contrib/openssl --with-ssl-dir=/usr/contrib/openssl --with-ssl=/usr/contrib/openssl --with-shadow --with-bsd-auth > > A note is that BSD systems havs their own shadow capability. if BSD/OS had getspnam(), then why would compiling fail on your machine? --with-shadow does not make sense if you have --with-bsd-auth From yasho at rambler.bg Thu Nov 8 03:35:26 2001 From: yasho at rambler.bg (Yavor G Georgiev) Date: Wed, 7 Nov 2001 17:35:26 +0100 Subject: No subject Message-ID: <8024670063.20011107173526@rambler.bg> Hello , OpenSSH gurus I am writing an SSH server but I have some problems when testing with your client - I do not recieve any window adjustments. The situation is something like this - I am exchanging data and sending window adjust after every packet, but do not get any window adjust packets. I tried to lookup the place in the source - OpenSSH-2.92p2 - but didn't find it. Can you help me - I just need to know what is going on , tell me where in the source I can find such place where window adjust is sent or under what circumstances this kind of packets are sent generally. Thanks in advance! -- Best regards, Yavor mailto:yasho at rambler.bg From markus at openbsd.org Thu Nov 8 02:52:25 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 16:52:25 +0100 Subject: your mail In-Reply-To: <8024670063.20011107173526@rambler.bg>; from yasho@rambler.bg on Wed, Nov 07, 2001 at 05:35:26PM +0100 References: <8024670063.20011107173526@rambler.bg> Message-ID: <20011107165225.C1689@faui02.informatik.uni-erlangen.de> grep packet_start.*SSH2_MSG_CHANNEL_WINDOW_ADJUST *.c is your source available, too? From doctor at doctor.nl2k.ab.ca Thu Nov 8 02:58:30 2001 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 7 Nov 2001 08:58:30 -0700 Subject: OpenSSH 3.0 In-Reply-To: <20011107163505.D866@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Nov 07, 2001 at 04:35:05PM +0100 References: <20011106224841.A20613@folly> <20011106172529.A13661@doctor.nl2k.ab.ca> <20011107105332.A22094@faui02.informatik.uni-erlangen.de> <20011107082717.L12993@doctor.nl2k.ab.ca> <20011107163505.D866@faui02.informatik.uni-erlangen.de> Message-ID: <20011107085830.A16474@doctor.nl2k.ab.ca> On Wed, Nov 07, 2001 at 04:35:05PM +0100, Markus Friedl wrote: > On Wed, Nov 07, 2001 at 08:27:17AM -0700, The Doctor wrote: > > On Wed, Nov 07, 2001 at 10:53:32AM +0100, Markus Friedl wrote: > > > On Tue, Nov 06, 2001 at 05:25:29PM -0700, The Doctor wrote: > > > > Hate to do this but BSD/OS gives us: > > > > > > thank you for abusing email. > > > > > > OpenSSH works fine for me on BSD/OS 4.2: > > > > > > $ sh configure --with-bsd-auth --with-ssl-dir=/usr/contrib > > > > apache also feels my wrath. > > > > Right, here is what I have been using since for a configuration file and > > was broken in 2.9.9 but works in 2.9 > > > > > > ./configure --prefix=/usr/contrib --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man --with-low-memory --with-elf --with-ncurses --with-openssl=/usr/contrib/openssl --with-ssl-dir=/usr/contrib/openssl --with-ssl=/usr/contrib/openssl --with-shadow --with-bsd-auth > > > > A note is that BSD systems havs their own shadow capability. > > if BSD/OS had getspnam(), then why would compiling fail on > your machine? > > --with-shadow does not make sense if you have --with-bsd-auth Let me try and see. -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca Society MUST be saved! Extremists must dissolve. Lest we forget on 11 Nov 2001 From doctor at doctor.nl2k.ab.ca Thu Nov 8 03:10:32 2001 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 7 Nov 2001 09:10:32 -0700 Subject: OpenSSH 3.0 In-Reply-To: <20011107085830.A16474@doctor.nl2k.ab.ca>; from doctor@doctor.nl2k.ab.ca on Wed, Nov 07, 2001 at 08:58:30AM -0700 References: <20011106224841.A20613@folly> <20011106172529.A13661@doctor.nl2k.ab.ca> <20011107105332.A22094@faui02.informatik.uni-erlangen.de> <20011107082717.L12993@doctor.nl2k.ab.ca> <20011107163505.D866@faui02.informatik.uni-erlangen.de> <20011107085830.A16474@doctor.nl2k.ab.ca> Message-ID: <20011107091032.A23375@doctor.nl2k.ab.ca> On Wed, Nov 07, 2001 at 08:58:30AM -0700, The Doctor wrote: > On Wed, Nov 07, 2001 at 04:35:05PM +0100, Markus Friedl wrote: > > On Wed, Nov 07, 2001 at 08:27:17AM -0700, The Doctor wrote: > > > On Wed, Nov 07, 2001 at 10:53:32AM +0100, Markus Friedl wrote: > > > > On Tue, Nov 06, 2001 at 05:25:29PM -0700, The Doctor wrote: > > > > > Hate to do this but BSD/OS gives us: > > > > > > > > thank you for abusing email. > > > > > > > > OpenSSH works fine for me on BSD/OS 4.2: > > > > > > > > $ sh configure --with-bsd-auth --with-ssl-dir=/usr/contrib > > > > > > apache also feels my wrath. > > > > > > Right, here is what I have been using since for a configuration file and > > > was broken in 2.9.9 but works in 2.9 > > > > > > > > > ./configure --prefix=/usr/contrib --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man --with-low-memory --with-elf --with-ncurses --with-openssl=/usr/contrib/openssl --with-ssl-dir=/usr/contrib/openssl --with-ssl=/usr/contrib/openssl --with-shadow --with-bsd-auth > > > > > > A note is that BSD systems havs their own shadow capability. > > > > if BSD/OS had getspnam(), then why would compiling fail on > > your machine? > > > > --with-shadow does not make sense if you have --with-bsd-auth > Let me try and see. > NOw we get: Script started on Wed Nov 7 09:08:31 2001 doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ cat /usr/contrib/bin/sshcsshosshnsshfsshisshgssh ./configure --prefix=/usr/contrib --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man --with-low-memory --with-elf --with-ncurses --with-openssl=/usr/contrib/openssl --with-ssl-dir=/usr/contrib/openssl --with-ssl=/usr/contrib/openssl --with-bsd-auth doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ make (cd openbsd-compat; make) /usr/bin/ar rv libopenbsd-compat.a bsd-arc4random.o bsd-cray.o bsd-cygwin_util.o bsd-misc.o bsd-nextstep.o bsd-snprintf.o bsd-waitpid.o fake-getaddrinfo.o fake-getnameinfo.o base64.o bindresvport.o daemon.o dirname.o getcwd.o getgrouplist.o getopt.o glob.o inet_aton.o inet_ntoa.o inet_ntop.o mktemp.o readpassphrase.o realpath.o rresvport.o setenv.o setproctitle.o sigact.o strlcat.o strlcpy.o strmode.o strsep.o r - bsd-arc4random.o r - bsd-cray.o r - bsd-cygwin_util.o r - bsd-misc.o r - bsd-nextstep.o r - bsd-snprintf.o r - bsd-waitpid.o r - fake-getaddrinfo.o r - fake-getnameinfo.o r - base64.o r - bindresvport.o r - daemon.o r - dirname.o r - getcwd.o r - getgrouplist.o r - getopt.o r - glob.o r - inet_aton.o r - inet_ntoa.o r - inet_ntop.o r - mktemp.o r - readpassphrase.o r - realpath.o r - rresvport.o r - setenv.o r - setproctitle.o r - sigact.o r - strlcat.o r - strlcpy.o r - strmode.o r - strsep.o ranlib libopenbsd-compat.a gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib -lssh -lopenbsd-compat -lutil -lz -lcrypto gcc -o sshd sshd.o auth.o auth1.o auth2.o auth-chall.o auth2-chall.o auth-rhosts.o auth-options.o auth-krb4.o auth-pam.o auth2-pam.o auth-passwd.o auth-rsa.o auth-rh-rsa.o auth-sia.o sshpty.o sshlogin.o loginrec.o servconf.o serverloop.o md5crypt.o session.o groupaccess.o auth-skey.o auth-bsdauth.o -L. -Lopenbsd-compat/ -L/usr/contrib/openssl/lib -lssh -lopenbsd-compat -lutil -lz -lcrypto auth.o: In function `allowed_user': /usr/source/openssh-3.0p1/auth.c:80: undefined reference to `getspnam' *** Error code 1 Stop. doctor.nl2k.ab.ca//usr/source/openssh-3.0p1$ exit exit Script done on Wed Nov 7 09:08:55 2001 Question: does bsd need getspnam? > -- > Member - Liberal International On 11 Sept 2001 the WORLD was violated. > This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca > Society MUST be saved! Extremists must dissolve. > Lest we forget on 11 Nov 2001 -- Member - Liberal International On 11 Sept 2001 the WORLD was violated. This is doctor at nl2k.ab.ca Ici doctor at nl2k.ab.ca Society MUST be saved! Extremists must dissolve. Lest we forget on 11 Nov 2001 From michael.mai at db.com Thu Nov 8 03:25:31 2001 From: michael.mai at db.com (Michael Mai) Date: Wed, 7 Nov 2001 17:25:31 +0100 Subject: OpenSSH 2.3 Message-ID: Hi, I recompiled and installed openssl. The libcrypto.a library has been rebuilt, but the problem remains unchanged: On Mon, Nov 05, 2001 at 04:23:36PM +0100, Michael Mai wrote: > debug: bits set: 504/1024 > debug: len 55 datafellows 0 > debug: dsa_verify: signature incorrect > dsa_verify failed for server_host_key > debug: Calling cleanup 0x1cf36d18(0x0) does openssl work on this machine? e.g. openssl speed dsa ? -m openssl does work now: >openssl speed dsa Doing 512 bit sign dsa's for 10s: 61 512 bit DSA signs in 3.45s Doing 512 bit verify dsa's for 10s: 57 512 bit DSA verify in 3.90s Doing 1024 bit sign dsa's for 10s: 18 1024 bit DSA signs in 3.62s Doing 1024 bit verify dsa's for 10s: 21 1024 bit DSA verify in 4.99s OpenSSL 0.9.6 24 Sep 2000 built on: Wed Nov 7 13:46:04 MEZ 2001 options:bn(32,32) md2(char) rc4(idx,char) des(ptr,cisc,16,long) idea(int) blowfi sh(ptr) compiler: c89 -g -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYSPARAM_H -D_ALL_SOURCE sign verify sign/s verify/s dsa 512 bits 0.0566s 0.0684s 17.7 14.6 dsa 1024 bits 0.2011s 0.2376s 5.0 4.2 but I still get the dsa_verify: signature incorrect message. Could you help again ?? Gruss/ regards Michael Mai email: michael.mai at db.com -- Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From markus at openbsd.org Thu Nov 8 04:03:22 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 7 Nov 2001 18:03:22 +0100 Subject: OpenSSH 3.0 In-Reply-To: <20011107091032.A23375@doctor.nl2k.ab.ca>; from doctor@doctor.nl2k.ab.ca on Wed, Nov 07, 2001 at 09:10:32AM -0700 References: <20011106224841.A20613@folly> <20011106172529.A13661@doctor.nl2k.ab.ca> <20011107105332.A22094@faui02.informatik.uni-erlangen.de> <20011107082717.L12993@doctor.nl2k.ab.ca> <20011107163505.D866@faui02.informatik.uni-erlangen.de> <20011107085830.A16474@doctor.nl2k.ab.ca> <20011107091032.A23375@doctor.nl2k.ab.ca> Message-ID: <20011107180322.A12807@faui02.informatik.uni-erlangen.de> make distclean before configure From bugzilla-daemon at mindrot.org Thu Nov 8 15:11:16 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Thu, 8 Nov 2001 15:11:16 +1100 (EST) Subject: [Bug 10] sshd sometimes clears too much memory when zeroing fd_sets Message-ID: <20011108041116.D9BAC2DF55@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=10 ------- Additional Comments From nalin at redhat.com 2001-11-08 15:11 ------- Created an attachment (id=2) Adapted version of patch originally by jlk at kamens.brookline.ma.us ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From yasho at rambler.bg Thu Nov 8 19:56:29 2001 From: yasho at rambler.bg (Yavor G Georgiev) Date: Thu, 8 Nov 2001 09:56:29 +0100 Subject: your mail Message-ID: <18183533304.20011108095629@rambler.bg> Hello Markus, Thanks for the reply :) I am afraid you didn't understand me right I saw the sending of this message - but as I can see it is send only at the start of the connection or after keyreexchange. I need to know if these packets are sent during the connection because my server waits for such packets and didn't recieved them. I am sure that such kind of packets are not sent during the connection I am also dumping the traffic with ssldump, but I want to know why. -- Best regards, Yavor mailto:yasho at rambler.bg From Alexander.Dost at drkw.com Thu Nov 8 20:04:53 2001 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Thu, 8 Nov 2001 10:04:53 +0100 Subject: OpenSSH3.0p1/PAM/Sol8 Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC3C@ibfftc0006.is.de.dresdnerkb.com> Hi there, I just tried out OpenSSH3.0p1 running on Solaris 8 with PAM (--with-PAM). The problem was mentioned some time ago and is still there :-( When a password is expired you are prompted to change it now, enter your login password and after doing so you are instantly disconnected. I think this is a problem with PAM and not SSH, but how can I get a solution on this ? sshd is running without problems, no core dump. In /var/adm/messages there is the following output: auth.crit fatal: PAM pam_chauthtok failed[-1]: Unknown error that's all. Is there a workaround (like using a different PAM library and not pam_unix.so) ? Alex From yasho at rambler.bg Thu Nov 8 22:41:09 2001 From: yasho at rambler.bg (Yavor G Georgiev) Date: Thu, 8 Nov 2001 12:41:09 +0100 Subject: your mail In-Reply-To: <20011108101028.C966@faui02.informatik.uni-erlangen.de> References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> Message-ID: <13393413040.20011108124109@rambler.bg> Hello Markus, Thanks again for the attention this time I was nuch more careful ;). I saw where is the problem. The OpenSSH sends window adjust when it consumes the half of the window and local_consumed is positive. But in the OpenSSH code you are decrementing the window size more slower than I in my server. When I am sending packet I a decrementing the window size with the data of the packet (including the size of the data as it is in string format) , I saw that the PuTTY client does it the same way. Why are you guys decrementing the window size with not with the data of the packet but with data without its len - is there any explanation in the drafts about this? Thanks again!!! Best regards, Yavor mailto:yasho at rambler.bg From markus at openbsd.org Thu Nov 8 22:25:19 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 8 Nov 2001 12:25:19 +0100 Subject: your mail In-Reply-To: <13393413040.20011108124109@rambler.bg>; from yasho@rambler.bg on Thu, Nov 08, 2001 at 12:41:09PM +0100 References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> Message-ID: <20011108122519.A17172@faui02.informatik.uni-erlangen.de> hi, if i understand you correctly your problem is that you and i disagree about what 'window size' means and what data/length is included in the 'window' if i send a byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data packet in OpenSSH, i count only the actual size of the data, and not the size of the complete packet as sent on the wire. draft-ietf-secsh-connect-11.txt says: "The window size is decremented by the amount of data sent." i don't think that the additional 1+4+4 bytes (byte,uint32,uint32) should be included in the window size counter. but i could be wrong. perhaps the draft is ambiguous about this. what do other implementations do? i think that only the size of the actual 'payload' data should be included in the window size, because you usually send SSH_MSG_CHANNEL_WINDOW_ADJUST messages if you have consumed the data (e.g. written the data to a socket). when forwarding/consuming the data received on a channel, OpenSSH does no longer know over how many packets this data was originally distributed. so only the length of the payload, the amount of data written to the 'consumer-socket' can be used to caculate the size for SSH_MSG_CHANNEL_WINDOW_ADJUST. -m From yasho at rambler.bg Thu Nov 8 23:34:43 2001 From: yasho at rambler.bg (Yavor G Georgiev) Date: Thu, 8 Nov 2001 13:34:43 +0100 Subject: your mail In-Reply-To: <20011108122519.A17172@faui02.informatik.uni-erlangen.de> References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> <20011108122519.A17172@faui02.informatik.uni-erlangen.de> Message-ID: <1496627312.20011108133443@rambler.bg> Hello Markus, Thursday, November 08, 2001, 12:25:19 PM, you wrote: MF> hi, MF> if i understand you correctly your problem is that you and i disagree MF> about what 'window size' means and what data/length is included in the MF> 'window' MF> if i send a MF> byte SSH_MSG_CHANNEL_DATA MF> uint32 recipient channel MF> string data MF> packet in OpenSSH, i count only the actual size of the data, MF> and not the size of the complete packet as sent on the wire. MF> draft-ietf-secsh-connect-11.txt says: MF> "The window size is decremented by the amount of data sent." MF> i don't think that the additional 1+4+4 bytes (byte,uint32,uint32) MF> should be included in the window size counter. but i could be wrong. MF> perhaps the draft is ambiguous about this. MF> what do other implementations do? MF> i think that only the size of the actual 'payload' data should be MF> included in the window size, because you usually send MF> SSH_MSG_CHANNEL_WINDOW_ADJUST messages if you have consumed the data MF> (e.g. written the data to a socket). MF> when forwarding/consuming the data received on a channel, OpenSSH does MF> no longer know over how many packets this data was originally MF> distributed. so only the length of the payload, the amount of data MF> written to the 'consumer-socket' can be used to caculate the size for MF> SSH_MSG_CHANNEL_WINDOW_ADJUST. MF> -m Yes you got me right. I assume the data to be the last part in the following example packet: byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data the one that is type string, which includes 4 more bytes for the length. You asked me about other implementations. I have made many tests with the PuTTY client. It sends window adjustment after every recieved packet. The value of the adjustment is calculated as the data field not the payload of the data. I am totally agreed with you that the draft is ambigious. Can we get some advice from the draft guys - what had they meant ? --- Best regards, Yavor mailto:yasho at rambler.bg From markus at openbsd.org Thu Nov 8 23:48:29 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 8 Nov 2001 13:48:29 +0100 Subject: your mail In-Reply-To: <1496627312.20011108133443@rambler.bg>; from yasho@rambler.bg on Thu, Nov 08, 2001 at 01:34:43PM +0100 References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> <20011108122519.A17172@faui02.informatik.uni-erlangen.de> <1496627312.20011108133443@rambler.bg> Message-ID: <20011108134829.A28973@faui02.informatik.uni-erlangen.de> On Thu, Nov 08, 2001 at 01:34:43PM +0100, Yavor G Georgiev wrote: > Yes you got me right. > I assume the data to be the last part in the following example packet: > byte SSH_MSG_CHANNEL_DATA > uint32 recipient channel > string data > the one that is type string, which includes 4 more bytes for the > length. i think the 4 string-len bytes should _not_ be included, since it should not matter for the window size whether a payload data of 10 bytes arrives in one or in 4 messages. if you include the 4 bytes in the window size then you count packets. -m From markus at openbsd.org Fri Nov 9 00:55:37 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 8 Nov 2001 14:55:37 +0100 Subject: logging of root logins In-Reply-To: ; from arthur@West.NL on Thu, Nov 08, 2001 at 01:59:25PM +0100 References: <20011108134946.B28973@faui02.informatik.uni-erlangen.de> Message-ID: <20011108145537.A8383@faui02.informatik.uni-erlangen.de> On Thu, Nov 08, 2001 at 01:59:25PM +0100, Arthur de Jong wrote: > root and warthur both have user id 0. Sorry, I should have made that > clearer. They both have different passwords and rsa keys and I would like > to be able to make the distinction in the logs. Currently ssh only logs > that a ROOT user has logged in, not which one. hm, i don't think uid sharing is a standard unix feature. however, i think that we should drop this: authlog("%s %s for %s%.100s from %.200s port %d%s", authmsg, method, authctxt->valid ? "" : "illegal user ", authctxt->valid && authctxt->pw->pw_uid == 0 ? "ROOT" : authctxt->user, get_remote_ipaddr(), get_remote_port(), info); and not print ROOT in caps: authlog("%s %s for %s%.100s from %.200s port %d%s", authmsg, method, authctxt->valid ? "" : "illegal user ", authctxt->user, get_remote_ipaddr(), get_remote_port(), info); do we really need backward compatibility for printing ROOT in upper case? -m From arthur at West.NL Fri Nov 9 02:02:05 2001 From: arthur at West.NL (Arthur de Jong) Date: Thu, 8 Nov 2001 16:02:05 +0100 (MET) Subject: logging of root logins In-Reply-To: <20011108145537.A8383@faui02.informatik.uni-erlangen.de> Message-ID: On Thu, 8 Nov 2001, Markus Friedl wrote: > hm, i don't think uid sharing is a standard unix feature. I agree that it's not a very nice thing to do but I know several organisations that use several ROOT accounts. It's nice to have several passwords to access ROOT priviliges. (I know sudo or similar is better but not as convenient). > however, i think that we should drop this: > > authlog("%s %s for %s%.100s from %.200s port %d%s", > authmsg, > method, > authctxt->valid ? "" : "illegal user ", > authctxt->valid && authctxt->pw->pw_uid == 0 ? "ROOT" : authctxt->user, > get_remote_ipaddr(), > get_remote_port(), > info); > > and not print ROOT in caps: > > authlog("%s %s for %s%.100s from %.200s port %d%s", > authmsg, > method, > authctxt->valid ? "" : "illegal user ", > authctxt->user, > get_remote_ipaddr(), > get_remote_port(), > info); > > do we really need backward compatibility for printing ROOT > in upper case? I personally like capatalized ROOT because it makes root logins stick out in the logs. Maybe something like: authlog("%s %s for %s%s%.100s from %.200s port %d%s", authmsg, method, authctxt->valid ? "" : "illegal user ", authctxt->valid && authctxt->pw->pw_uid == 0 ? "ROOT user " : "", authctxt->user, get_remote_ipaddr(), get_remote_port(), info); This would make it stand out and maybe keep it partially compatible with logfile checkers. Or even: authlog("%s %s for %s%.100s from %.200s port %d%s", ... authctxt->valid ? ( authctxt->pw->pw_uid == 0 ? "ROOT user " : "" ) : "illegal user ", ... -- arthur de jong - arthur at west.nl - west consulting b.v. -- From mouring at etoh.eviladmin.org Fri Nov 9 02:24:06 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Nov 2001 09:24:06 -0600 (CST) Subject: logging of root logins In-Reply-To: Message-ID: On Thu, 8 Nov 2001, Arthur de Jong wrote: > > On Thu, 8 Nov 2001, Markus Friedl wrote: > > hm, i don't think uid sharing is a standard unix feature. > > I agree that it's not a very nice thing to do but I know several > organisations that use several ROOT accounts. It's nice to have several > passwords to access ROOT priviliges. (I know sudo or similar is better but > not as convenient). > I hate the idea of multiple UID 0 accounts. I tolerate it one machine machine here because I could not get the backing of my manager to shut down the second account. [..] > > do we really need backward compatibility for printing ROOT > > in upper case? > > I personally like capatalized ROOT because it makes root logins stick out > in the logs. Maybe something like: > I think the patch you sent to the OpenSSH@ list is correct. I don't think is it required to have 'ROOT' in caps. - Ben From markus at openbsd.org Fri Nov 9 02:52:48 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 8 Nov 2001 16:52:48 +0100 Subject: logging of root logins In-Reply-To: ; from arthur@West.NL on Thu, Nov 08, 2001 at 04:02:05PM +0100 References: <20011108145537.A8383@faui02.informatik.uni-erlangen.de> Message-ID: <20011108165248.A27075@faui02.informatik.uni-erlangen.de> On Thu, Nov 08, 2001 at 04:02:05PM +0100, Arthur de Jong wrote: > authctxt->valid && authctxt->pw->pw_uid == 0 ? "ROOT user " : "", well this will print ROOT user root in 99.99999% of all cases. -m From arthur at West.NL Fri Nov 9 03:04:21 2001 From: arthur at West.NL (Arthur de Jong) Date: Thu, 8 Nov 2001 17:04:21 +0100 (MET) Subject: logging of root logins In-Reply-To: <20011108165248.A27075@faui02.informatik.uni-erlangen.de> Message-ID: On Thu, 8 Nov 2001, Markus Friedl wrote: > On Thu, Nov 08, 2001 at 04:02:05PM +0100, Arthur de Jong wrote: > > authctxt->valid && authctxt->pw->pw_uid == 0 ? "ROOT user " : "", > > well this will print > ROOT user root > in 99.99999% of all cases. True (though not on the system where i've noticed the problem). I don't know what the orriginal reason was to log 'ROOT' instead of 'root' in the first place but if it was a good reason it might still hold and 'ROOT user root' (or similar, old ssh did '...ROOT LOGIN as 'root'...) might make some sense. It was just an idea. -- arthur de jong - arthur at west.nl - west consulting b.v. -- From ed at UDel.Edu Fri Nov 9 03:06:13 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 8 Nov 2001 11:06:13 -0500 (EST) Subject: OpenSSH3.0p1/PAM/Sol8 In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC3C@ibfftc0006.is.de.dresdnerkb.com> Message-ID: On Thu, 8 Nov 2001, Dost, Alexander wrote: > Date: Thu, 8 Nov 2001 10:04:53 +0100 > From: "Dost, Alexander" > To: openssh-unix-dev at mindrot.org > Subject: OpenSSH3.0p1/PAM/Sol8 > > Hi there, > > I just tried out OpenSSH3.0p1 running on Solaris 8 with PAM (--with-PAM). > The problem was mentioned some time ago and is still there :-( > When a password is expired you are prompted to change it now, enter your > login password and after doing so you are instantly disconnected. I think > this is a problem with PAM and not SSH, but how can I get a solution on this > ? > sshd is running without problems, no core dump. In /var/adm/messages there > is the following output: > auth.crit fatal: PAM pam_chauthtok failed[-1]: Unknown error What does your /etc/pam.conf look like? Are you running sshd as root or some other uid? Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From info at ninosdepapel.org Fri Nov 9 03:14:47 2001 From: info at ninosdepapel.org (Niños de Papel) Date: Thu, 8 Nov 2001 11:14:47 -0500 Subject: Las Cosas de Papel, 3ra. Edición Message-ID: <20011108111431.SM00580@brulot> An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011108/f2c01e4f/attachment.html From Alexander.Dost at drkw.com Fri Nov 9 04:01:52 2001 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Thu, 8 Nov 2001 18:01:52 +0100 Subject: OpenSSH3.0p1/PAM/Sol8 Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC41@ibfftc0006.is.de.dresdnerkb.com> I imported the example from the contrib directory for generic unix. sshd is running as root. Alex pam.conf: # #ident "@(#)pam.conf 1.16 01/01/24 SMI" # # Copyright (c) 1996-2000 by Sun Microsystems, Inc. # All rights reserved. # # PAM configuration # # Authentication management # login auth required /usr/lib/security/$ISA/pam_unix.so.1 login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 sshd auth required /usr/lib/security/$ISA/pam_unix.so shadow nodelay # rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 # dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 # rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 other auth required /usr/lib/security/$ISA/pam_unix.so.1 # # Account management # login account requisite /usr/lib/security/$ISA/pam_roles.so.1 login account required /usr/lib/security/$ISA/pam_projects.so.1 login account required /usr/lib/security/$ISA/pam_unix.so.1 sshd account required /usr/lib/security/$ISA/pam_unix.so.1 # dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 dtlogin account required /usr/lib/security/$ISA/pam_projects.so.1 dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 # other account requisite /usr/lib/security/$ISA/pam_roles.so.1 other account required /usr/lib/security/$ISA/pam_projects.so.1 other account required /usr/lib/security/$ISA/pam_unix.so.1 # # Session management # sshd session required /usr/lib/security/$ISA/pam_unix.so.1 other session required /usr/lib/security/$ISA/pam_unix.so.1 # # Password management # sshd password required /usr/lib/security/$ISA/pam_unix.so shadow nullok use_authtok other password required /usr/lib/security/$ISA/pam_unix.so.1 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 # # Support for Kerberos V5 authentication (uncomment to use Kerberos) - snip > -----Original Message----- > From: Ed Phillips [SMTP:ed at UDel.Edu] > Sent: Thursday, November 08, 2001 17:06 > To: Dost, Alexander > Cc: openssh-unix-dev at mindrot.org > Subject: Re: OpenSSH3.0p1/PAM/Sol8 > > On Thu, 8 Nov 2001, Dost, Alexander wrote: > > > Date: Thu, 8 Nov 2001 10:04:53 +0100 > > From: "Dost, Alexander" > > To: openssh-unix-dev at mindrot.org > > Subject: OpenSSH3.0p1/PAM/Sol8 > > > > Hi there, > > > > I just tried out OpenSSH3.0p1 running on Solaris 8 with PAM > (--with-PAM). > > The problem was mentioned some time ago and is still there :-( > > When a password is expired you are prompted to change it now, enter your > > login password and after doing so you are instantly disconnected. I > think > > this is a problem with PAM and not SSH, but how can I get a solution on > this > > ? > > sshd is running without problems, no core dump. In /var/adm/messages > there > > is the following output: > > auth.crit fatal: PAM pam_chauthtok failed[-1]: Unknown error > > What does your /etc/pam.conf look like? Are you running sshd as root or > some other uid? > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key From nisse at lysator.liu.se Fri Nov 9 04:13:40 2001 From: nisse at lysator.liu.se (Niels Möller) Date: 08 Nov 2001 18:13:40 +0100 Subject: your mail In-Reply-To: Markus Friedl's message of "Thu, 8 Nov 2001 13:48:29 +0100" References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> <20011108122519.A17172@faui02.informatik.uni-erlangen.de> <1496627312.20011108133443@rambler.bg> <20011108134829.A28973@faui02.informatik.uni-erlangen.de> Message-ID: Markus Friedl writes: > On Thu, Nov 08, 2001 at 01:34:43PM +0100, Yavor G Georgiev wrote: > > Yes you got me right. > > I assume the data to be the last part in the following example packet: > > byte SSH_MSG_CHANNEL_DATA > > uint32 recipient channel > > string data > > the one that is type string, which includes 4 more bytes for the > > length. > > i think the 4 string-len bytes should _not_ be included, since > it should not matter for the window size whether a payload data > of 10 bytes arrives in one or in 4 messages. I agree with Markus. LSH and openssh have the same behaviour, I think. Regards, /Niels From galb-list at vandyke.com Fri Nov 9 04:24:42 2001 From: galb-list at vandyke.com (Joseph Galbraith) Date: Thu, 8 Nov 2001 10:24:42 -0700 Subject: your mail References: <8024670063.20011107173526@rambler.bg> <20011107165225.C1689@faui02.informatik.uni-erlangen.de> <4182487270.20011108093903@rambler.bg> <20011108101028.C966@faui02.informatik.uni-erlangen.de> <13393413040.20011108124109@rambler.bg> <20011108122519.A17172@faui02.informatik.uni-erlangen.de> <1496627312.20011108133443@rambler.bg> <20011108134829.A28973@faui02.informatik.uni-erlangen.de> Message-ID: <002a01c1687a$40ddc8a0$2800a8c0@test.vandyke.com> I believe VShell / SecureCRT also only bill the actual length of data against the window size. I do not think that the packet overhead should be included; I believe the current behavior is correct. - Joseph ----- Original Message ----- From: "Niels M?ller" To: "Markus Friedl" Cc: "Yavor G Georgiev" ; ; Sent: Thursday, November 08, 2001 10:13 Subject: Re: your mail > Markus Friedl writes: > > > On Thu, Nov 08, 2001 at 01:34:43PM +0100, Yavor G Georgiev wrote: > > > Yes you got me right. > > > I assume the data to be the last part in the following example packet: > > > byte SSH_MSG_CHANNEL_DATA > > > uint32 recipient channel > > > string data > > > the one that is type string, which includes 4 more bytes for the > > > length. > > > > i think the 4 string-len bytes should _not_ be included, since > > it should not matter for the window size whether a payload data > > of 10 bytes arrives in one or in 4 messages. > > I agree with Markus. LSH and openssh have the same behaviour, I think. > > Regards, > /Niels > From djast at cs.toronto.edu Fri Nov 9 04:27:16 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Thu, 8 Nov 2001 12:27:16 -0500 Subject: entropy.c patch to avoid unnecessary reading of /dev/urandom Message-ID: <01Nov8.122722edt.453139-15184@jane.cs.toronto.edu> This one-line patch prevents OpenSSH from depleting entropy unnecessarily from /dev/urandom when the OpenSSL library acquires its own entropy. Without this patch OpenSSH opens /dev/urandom and reads 32 bytes, and then OpenSSL opens it again and reads an additional 20. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/binary Size: 291 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011108/20374224/attachment.bin From ed at UDel.Edu Fri Nov 9 04:33:44 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 8 Nov 2001 12:33:44 -0500 (EST) Subject: OpenSSH3.0p1/PAM/Sol8 In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC41@ibfftc0006.is.de.dresdnerkb.com> Message-ID: On Thu, 8 Nov 2001, Dost, Alexander wrote: > Date: Thu, 8 Nov 2001 18:01:52 +0100 > From: "Dost, Alexander" > To: 'Ed Phillips' > Cc: openssh-unix-dev at mindrot.org > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > I imported the example from the contrib directory for generic unix. > sshd is running as root. > > Alex > > pam.conf: > # > #ident "@(#)pam.conf 1.16 01/01/24 SMI" > # > # Copyright (c) 1996-2000 by Sun Microsystems, Inc. > # All rights reserved. > # > # PAM configuration > # > # Authentication management > # > login auth required /usr/lib/security/$ISA/pam_unix.so.1 > login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 > sshd auth required /usr/lib/security/$ISA/pam_unix.so shadow nodelay Not that it matters, but "shadow" and "nodelay" are not arguments that are recognized by pam_unix.so.1 according to "man pam_unix". > # > rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > # > dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > # > rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > other auth required /usr/lib/security/$ISA/pam_unix.so.1 > # > # Account management > # > login account requisite /usr/lib/security/$ISA/pam_roles.so.1 > login account required /usr/lib/security/$ISA/pam_projects.so.1 > login account required /usr/lib/security/$ISA/pam_unix.so.1 > sshd account required /usr/lib/security/$ISA/pam_unix.so.1 Looks fine. > # > dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 > dtlogin account required /usr/lib/security/$ISA/pam_projects.so.1 > dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 > # > other account requisite /usr/lib/security/$ISA/pam_roles.so.1 > other account required /usr/lib/security/$ISA/pam_projects.so.1 > other account required /usr/lib/security/$ISA/pam_unix.so.1 > # > # Session management > # > sshd session required /usr/lib/security/$ISA/pam_unix.so.1 Looks fine. > other session required /usr/lib/security/$ISA/pam_unix.so.1 > # > # Password management > # > sshd password required /usr/lib/security/$ISA/pam_unix.so shadow > nullok use_authtok Again, these are not supported arguments according to "man pam_unix". However, they should just be ignored. You should get syslog messages to auth.err about these options though. Did you see any? > other password required /usr/lib/security/$ISA/pam_unix.so.1 > dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 > # > # Support for Kerberos V5 authentication (uncomment to use Kerberos) Hmmmm... what does your /etc/nsswitch.conf file look like? Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Alexander.Dost at drkw.com Fri Nov 9 04:47:01 2001 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Thu, 8 Nov 2001 18:47:01 +0100 Subject: OpenSSH3.0p1/PAM/Sol8 Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC43@ibfftc0006.is.de.dresdnerkb.com> Yes, I get the error messages (illegal option shadow/nodelay). I removed the entry and, as you said, they are just ignored, nothing changed. One additional piece of information: If I use NIS+ for password authentication/changing, all works fine. Alex # # /etc/nsswitch.files: # # An example file that could be copied over to /etc/nsswitch.conf; it # does not use any naming service. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. passwd: files group: files hosts: dns files ipnodes: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files # At present there isn't a 'files' backend for netgroup; the system will # figure it out pretty quickly, and won't use netgroups at all. netgroup: files automount: files aliases: files services: files sendmailvars: files printers: user files auth_attr: files prof_attr: files project: files > -----Original Message----- > From: Ed Phillips [SMTP:ed at UDel.Edu] > Sent: Thursday, November 08, 2001 18:34 > To: Dost, Alexander > Cc: openssh-unix-dev at mindrot.org > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > On Thu, 8 Nov 2001, Dost, Alexander wrote: > > > Date: Thu, 8 Nov 2001 18:01:52 +0100 > > From: "Dost, Alexander" > > To: 'Ed Phillips' > > Cc: openssh-unix-dev at mindrot.org > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > I imported the example from the contrib directory for generic unix. > > sshd is running as root. > > > > Alex > > > > pam.conf: > > # > > #ident "@(#)pam.conf 1.16 01/01/24 SMI" > > # > > # Copyright (c) 1996-2000 by Sun Microsystems, Inc. > > # All rights reserved. > > # > > # PAM configuration > > # > > # Authentication management > > # > > login auth required /usr/lib/security/$ISA/pam_unix.so.1 > > login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 > > sshd auth required /usr/lib/security/$ISA/pam_unix.so shadow > nodelay > > Not that it matters, but "shadow" and "nodelay" are not arguments that are > recognized by pam_unix.so.1 according to "man pam_unix". > > > # > > rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > > rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > > # > > dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > > # > > rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > > other auth required /usr/lib/security/$ISA/pam_unix.so.1 > > # > > # Account management > > # > > login account requisite > /usr/lib/security/$ISA/pam_roles.so.1 > > login account required > /usr/lib/security/$ISA/pam_projects.so.1 > > login account required /usr/lib/security/$ISA/pam_unix.so.1 > > sshd account required /usr/lib/security/$ISA/pam_unix.so.1 > > Looks fine. > > > # > > dtlogin account requisite > /usr/lib/security/$ISA/pam_roles.so.1 > > dtlogin account required > /usr/lib/security/$ISA/pam_projects.so.1 > > dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 > > # > > other account requisite > /usr/lib/security/$ISA/pam_roles.so.1 > > other account required > /usr/lib/security/$ISA/pam_projects.so.1 > > other account required /usr/lib/security/$ISA/pam_unix.so.1 > > # > > # Session management > > # > > sshd session required /usr/lib/security/$ISA/pam_unix.so.1 > > Looks fine. > > > other session required /usr/lib/security/$ISA/pam_unix.so.1 > > # > > # Password management > > # > > sshd password required /usr/lib/security/$ISA/pam_unix.so > shadow > > nullok use_authtok > > Again, these are not supported arguments according to "man pam_unix". > However, they should just be ignored. You should get syslog messages to > auth.err about these options though. Did you see any? > > > other password required /usr/lib/security/$ISA/pam_unix.so.1 > > dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 > > # > > # Support for Kerberos V5 authentication (uncomment to use Kerberos) > > Hmmmm... what does your /etc/nsswitch.conf file look like? > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. From Darren.Moffat at eng.sun.com Fri Nov 9 04:59:14 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Thu, 8 Nov 2001 09:59:14 -0800 (PST) Subject: OpenSSH3.0p1/PAM/Sol8 Message-ID: <200111081759.fA8HxEeB111610@jurassic.eng.sun.com> >sshd auth required /usr/lib/security/$ISA/pam_unix.so shadow nodelay These options do not exist for pam_unix on Solaris. Solaris always uses /etc/shadow and pam_unix doesn't actually know this (as it shouldn't). I don't even know what nodelay would mean it if did exist. -- Darren J Moffat From ed at UDel.Edu Fri Nov 9 05:16:53 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 8 Nov 2001 13:16:53 -0500 (EST) Subject: OpenSSH3.0p1/PAM/Sol8 In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC43@ibfftc0006.is.de.dresdnerkb.com> Message-ID: Can you try adding the "debug" option to the sshd lines in /etc/pam.conf? Also, make sure syslogd is gathering the messages for auth.err, auth.info, auth.debug, auth.alert, and auth.crit. Maybe something will show up in the logs to pinpoint where pam_sm_chauthtok() is failing. It's odd, because it should never return -1 - only valid PAM_XXXX error codes (which are >= 0), according to "man pam_sm_chauthtok". Strange... Ed On Thu, 8 Nov 2001, Dost, Alexander wrote: > Date: Thu, 8 Nov 2001 18:47:01 +0100 > From: "Dost, Alexander" > To: 'Ed Phillips' > Cc: openssh-unix-dev at mindrot.org > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > Yes, I get the error messages (illegal option shadow/nodelay). > I removed the entry and, as you said, they are just ignored, nothing > changed. > One additional piece of information: If I use NIS+ for password > authentication/changing, all works fine. > > Alex > > # > # /etc/nsswitch.files: > # > # An example file that could be copied over to /etc/nsswitch.conf; it > # does not use any naming service. > # > # "hosts:" and "services:" in this file are used only if the > # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. > > passwd: files > group: files > hosts: dns files > ipnodes: files > networks: files > protocols: files > rpc: files > ethers: files > netmasks: files > bootparams: files > publickey: files > # At present there isn't a 'files' backend for netgroup; the system will > # figure it out pretty quickly, and won't use netgroups at all. > netgroup: files > automount: files > aliases: files > services: files > sendmailvars: files > printers: user files > > auth_attr: files > prof_attr: files > project: files > > > -----Original Message----- > > From: Ed Phillips [SMTP:ed at UDel.Edu] > > Sent: Thursday, November 08, 2001 18:34 > > To: Dost, Alexander > > Cc: openssh-unix-dev at mindrot.org > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > On Thu, 8 Nov 2001, Dost, Alexander wrote: > > > > > Date: Thu, 8 Nov 2001 18:01:52 +0100 > > > From: "Dost, Alexander" > > > To: 'Ed Phillips' > > > Cc: openssh-unix-dev at mindrot.org > > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > > > I imported the example from the contrib directory for generic unix. > > > sshd is running as root. > > > > > > Alex > > > > > > pam.conf: > > > # > > > #ident "@(#)pam.conf 1.16 01/01/24 SMI" > > > # > > > # Copyright (c) 1996-2000 by Sun Microsystems, Inc. > > > # All rights reserved. > > > # > > > # PAM configuration > > > # > > > # Authentication management > > > # > > > login auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 > > > sshd auth required /usr/lib/security/$ISA/pam_unix.so shadow > > nodelay > > > > Not that it matters, but "shadow" and "nodelay" are not arguments that are > > recognized by pam_unix.so.1 according to "man pam_unix". > > > > > # > > > rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > > > rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > # > > > dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > # > > > rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > > > other auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > # > > > # Account management > > > # > > > login account requisite > > /usr/lib/security/$ISA/pam_roles.so.1 > > > login account required > > /usr/lib/security/$ISA/pam_projects.so.1 > > > login account required /usr/lib/security/$ISA/pam_unix.so.1 > > > sshd account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > Looks fine. > > > > > # > > > dtlogin account requisite > > /usr/lib/security/$ISA/pam_roles.so.1 > > > dtlogin account required > > /usr/lib/security/$ISA/pam_projects.so.1 > > > dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 > > > # > > > other account requisite > > /usr/lib/security/$ISA/pam_roles.so.1 > > > other account required > > /usr/lib/security/$ISA/pam_projects.so.1 > > > other account required /usr/lib/security/$ISA/pam_unix.so.1 > > > # > > > # Session management > > > # > > > sshd session required /usr/lib/security/$ISA/pam_unix.so.1 > > > > Looks fine. > > > > > other session required /usr/lib/security/$ISA/pam_unix.so.1 > > > # > > > # Password management > > > # > > > sshd password required /usr/lib/security/$ISA/pam_unix.so > > shadow > > > nullok use_authtok > > > > Again, these are not supported arguments according to "man pam_unix". > > However, they should just be ignored. You should get syslog messages to > > auth.err about these options though. Did you see any? > > > > > other password required /usr/lib/security/$ISA/pam_unix.so.1 > > > dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > # > > > # Support for Kerberos V5 authentication (uncomment to use Kerberos) > > > > Hmmmm... what does your /etc/nsswitch.conf file look like? > > > > Ed > > > > Ed Phillips University of Delaware (302) 831-6082 > > Systems Programmer III, Network and Systems Services > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to > http://www.drkw.com/disc/email/ or contact the sender. > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Alexander.Dost at drkw.com Fri Nov 9 05:35:25 2001 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Thu, 8 Nov 2001 19:35:25 +0100 Subject: OpenSSH3.0p1/PAM/Sol8 Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC44@ibfftc0006.is.de.dresdnerkb.com> Here is the output. First one successfull login, after that passwd -f and new try... Alex Nov 8 18:25:29 FFTUST2001 sshd[5618]: [ID 888916 auth.debug] unix pam_sm_authenticate(sshd f998505), flags = 0 Nov 8 18:25:29 FFTUST2001 sshd[5618]: [ID 800047 auth.info] Accepted password for f998505 from 130.21.163.43 port 38296 ssh2 Nov 8 18:25:35 FFTUST2001 sshd[5618]: [ID 833576 auth.debug] pam_setcred: error Permission denied --- Nov 8 18:26:07 FFTUST2001 sshd[5648]: [ID 888916 auth.debug] unix pam_sm_authenticate(sshd f998505), flags = 0 Nov 8 18:26:08 FFTUST2001 sshd[5648]: [ID 308033 auth.debug] pam_acct_mgmt: error Get new authentication token Nov 8 18:26:08 FFTUST2001 sshd[5648]: [ID 800047 auth.info] Accepted password for f998505 from 130.21.163.43 port 38299 ssh2 Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 618257 auth.debug] unix pam_sm_chauthtok(): prelim check Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 288048 auth.debug] pam_sm_chauthtok: System password aged Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 651162 auth.debug] unix_sm_chauthtok(): update passwords Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 801703 auth.debug] unix_sm_chauthtok: default Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 276273 auth.debug] unix_sm_chauthtok: uid = 0, euid = 0 Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 803388 auth.debug] number of services is 1 Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 240311 auth.debug] unix pam_sm_chauthtok(): repository: files after get_ns() Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 814557 auth.debug] ck_perm() called: repository=files Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 555593 auth.debug] PAM: verify_old_passwd: start: uid = 1590, privileged = 0 Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 319219 auth.debug] verify_old_passwd(): repository is files Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 485903 auth.debug] try_first_pass = 0, use_first_pass = 0 Nov 8 18:26:11 FFTUST2001 sshd[5651]: [ID 862941 auth.debug] turn: maxdate == -7, mindate == -1 Nov 8 18:26:11 FFTUST2001 sshd[5650]: [ID 125209 auth.debug] pam_chauthtok: error Unknown error Nov 8 18:26:11 FFTUST2001 sshd[5650]: [ID 800047 auth.crit] fatal: PAM pam_chauthtok failed[-1]: Unknown error Nov 8 18:26:11 FFTUST2001 sshd[5650]: [ID 833576 auth.debug] pam_setcred: error Permission denied Nov 8 18:26:11 FFTUST2001 sshd[5648]: [ID 833576 auth.debug] pam_setcred: error Permission denied > -----Original Message----- > From: Ed Phillips [SMTP:ed at UDel.Edu] > Sent: Thursday, November 08, 2001 19:17 > To: Dost, Alexander > Cc: openssh-unix-dev at mindrot.org > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > Can you try adding the "debug" option to the sshd lines in /etc/pam.conf? > Also, make sure syslogd is gathering the messages for auth.err, auth.info, > auth.debug, auth.alert, and auth.crit. Maybe something will show up in > the logs to pinpoint where pam_sm_chauthtok() is failing. It's odd, > because it should never return -1 - only valid PAM_XXXX error codes (which > are >= 0), according to "man pam_sm_chauthtok". Strange... > > Ed > > On Thu, 8 Nov 2001, Dost, Alexander wrote: > > > Date: Thu, 8 Nov 2001 18:47:01 +0100 > > From: "Dost, Alexander" > > To: 'Ed Phillips' > > Cc: openssh-unix-dev at mindrot.org > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > Yes, I get the error messages (illegal option shadow/nodelay). > > I removed the entry and, as you said, they are just ignored, nothing > > changed. > > One additional piece of information: If I use NIS+ for password > > authentication/changing, all works fine. > > > > Alex > > > > # > > # /etc/nsswitch.files: > > # > > # An example file that could be copied over to /etc/nsswitch.conf; it > > # does not use any naming service. > > # > > # "hosts:" and "services:" in this file are used only if the > > # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" > transports. > > > > passwd: files > > group: files > > hosts: dns files > > ipnodes: files > > networks: files > > protocols: files > > rpc: files > > ethers: files > > netmasks: files > > bootparams: files > > publickey: files > > # At present there isn't a 'files' backend for netgroup; the system > will > > # figure it out pretty quickly, and won't use netgroups at all. > > netgroup: files > > automount: files > > aliases: files > > services: files > > sendmailvars: files > > printers: user files > > > > auth_attr: files > > prof_attr: files > > project: files > > > > > -----Original Message----- > > > From: Ed Phillips [SMTP:ed at UDel.Edu] > > > Sent: Thursday, November 08, 2001 18:34 > > > To: Dost, Alexander > > > Cc: openssh-unix-dev at mindrot.org > > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > > > On Thu, 8 Nov 2001, Dost, Alexander wrote: > > > > > > > Date: Thu, 8 Nov 2001 18:01:52 +0100 > > > > From: "Dost, Alexander" > > > > To: 'Ed Phillips' > > > > Cc: openssh-unix-dev at mindrot.org > > > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > > > > > I imported the example from the contrib directory for generic unix. > > > > sshd is running as root. > > > > > > > > Alex > > > > > > > > pam.conf: > > > > # > > > > #ident "@(#)pam.conf 1.16 01/01/24 SMI" > > > > # > > > > # Copyright (c) 1996-2000 by Sun Microsystems, Inc. > > > > # All rights reserved. > > > > # > > > > # PAM configuration > > > > # > > > > # Authentication management > > > > # > > > > login auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 > > > > sshd auth required /usr/lib/security/$ISA/pam_unix.so shadow > > > nodelay > > > > > > Not that it matters, but "shadow" and "nodelay" are not arguments that > are > > > recognized by pam_unix.so.1 according to "man pam_unix". > > > > > > > # > > > > rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > > > > rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > # > > > > dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > # > > > > rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > > > > other auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > # > > > > # Account management > > > > # > > > > login account requisite > > > /usr/lib/security/$ISA/pam_roles.so.1 > > > > login account required > > > /usr/lib/security/$ISA/pam_projects.so.1 > > > > login account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > sshd account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > > Looks fine. > > > > > > > # > > > > dtlogin account requisite > > > /usr/lib/security/$ISA/pam_roles.so.1 > > > > dtlogin account required > > > /usr/lib/security/$ISA/pam_projects.so.1 > > > > dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > # > > > > other account requisite > > > /usr/lib/security/$ISA/pam_roles.so.1 > > > > other account required > > > /usr/lib/security/$ISA/pam_projects.so.1 > > > > other account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > # > > > > # Session management > > > > # > > > > sshd session required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > > Looks fine. > > > > > > > other session required /usr/lib/security/$ISA/pam_unix.so.1 > > > > # > > > > # Password management > > > > # > > > > sshd password required /usr/lib/security/$ISA/pam_unix.so > > > shadow > > > > nullok use_authtok > > > > > > Again, these are not supported arguments according to "man pam_unix". > > > However, they should just be ignored. You should get syslog messages > to > > > auth.err about these options though. Did you see any? > > > > > > > other password required /usr/lib/security/$ISA/pam_unix.so.1 > > > > dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > # > > > > # Support for Kerberos V5 authentication (uncomment to use Kerberos) > > > > > > Hmmmm... what does your /etc/nsswitch.conf file look like? > > > > > > Ed > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > > Systems Programmer III, Network and Systems Services > > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > If you have received this e-mail in error or wish to read our e-mail > disclaimer statement and monitoring policy, please refer to > > http://www.drkw.com/disc/email/ or contact the sender. > > > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key From adam-dated-1005677480.b73e07 at flounder.net Fri Nov 9 05:51:18 2001 From: adam-dated-1005677480.b73e07 at flounder.net (Adam McKenna) Date: Thu, 8 Nov 2001 10:51:18 -0800 Subject: logging of root logins In-Reply-To: References: <20011108145537.A8383@faui02.informatik.uni-erlangen.de> Message-ID: <20011108105118.G19266@flounder.net> On Thu, Nov 08, 2001 at 04:02:05PM +0100, Arthur de Jong wrote: > > On Thu, 8 Nov 2001, Markus Friedl wrote: > > hm, i don't think uid sharing is a standard unix feature. > > I agree that it's not a very nice thing to do but I know several > organisations that use several ROOT accounts. It's nice to have several > passwords to access ROOT priviliges. (I know sudo or similar is better but > not as convenient). How is sudo not convenient? It's four letters, and the person doesn't need to remember a separate root password, he just uses his own password. It's also vastly more configurable. --Adam From ed at UDel.Edu Fri Nov 9 06:16:13 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 8 Nov 2001 14:16:13 -0500 (EST) Subject: OpenSSH3.0p1/PAM/Sol8 In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC44@ibfftc0006.is.de.dresdnerkb.com> Message-ID: Does this system have the latest Recommended patches for Solaris 8? Ed On Thu, 8 Nov 2001, Dost, Alexander wrote: > Date: Thu, 8 Nov 2001 19:35:25 +0100 > From: "Dost, Alexander" > To: 'Ed Phillips' > Cc: openssh-unix-dev at mindrot.org > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > Here is the output. First one successfull login, after that passwd -f and > new try... > > Alex > > Nov 8 18:25:29 FFTUST2001 sshd[5618]: [ID 888916 auth.debug] unix > pam_sm_authenticate(sshd f998505), flags = 0 > Nov 8 18:25:29 FFTUST2001 sshd[5618]: [ID 800047 auth.info] Accepted > password for f998505 from 130.21.163.43 port 38296 ssh2 > Nov 8 18:25:35 FFTUST2001 sshd[5618]: [ID 833576 auth.debug] pam_setcred: > error Permission denied > --- > Nov 8 18:26:07 FFTUST2001 sshd[5648]: [ID 888916 auth.debug] unix > pam_sm_authenticate(sshd f998505), flags = 0 > Nov 8 18:26:08 FFTUST2001 sshd[5648]: [ID 308033 auth.debug] pam_acct_mgmt: > error Get new authentication token > Nov 8 18:26:08 FFTUST2001 sshd[5648]: [ID 800047 auth.info] Accepted > password for f998505 from 130.21.163.43 port 38299 ssh2 > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 618257 auth.debug] unix > pam_sm_chauthtok(): prelim check > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 288048 auth.debug] > pam_sm_chauthtok: System password aged > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 651162 auth.debug] > unix_sm_chauthtok(): update passwords > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 801703 auth.debug] > unix_sm_chauthtok: default > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 276273 auth.debug] > unix_sm_chauthtok: uid = 0, euid = 0 > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 803388 auth.debug] number of > services is 1 > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 240311 auth.debug] unix > pam_sm_chauthtok(): repository: files after get_ns() > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 814557 auth.debug] ck_perm() > called: repository=files > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 555593 auth.debug] PAM: > verify_old_passwd: start: uid = 1590, privileged = 0 > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 319219 auth.debug] > verify_old_passwd(): repository is files > Nov 8 18:26:08 FFTUST2001 sshd[5650]: [ID 485903 auth.debug] > try_first_pass = 0, use_first_pass = 0 > Nov 8 18:26:11 FFTUST2001 sshd[5651]: [ID 862941 auth.debug] turn: maxdate > == -7, mindate == -1 > Nov 8 18:26:11 FFTUST2001 sshd[5650]: [ID 125209 auth.debug] pam_chauthtok: > error Unknown error > Nov 8 18:26:11 FFTUST2001 sshd[5650]: [ID 800047 auth.crit] fatal: PAM > pam_chauthtok failed[-1]: Unknown error > Nov 8 18:26:11 FFTUST2001 sshd[5650]: [ID 833576 auth.debug] pam_setcred: > error Permission denied > Nov 8 18:26:11 FFTUST2001 sshd[5648]: [ID 833576 auth.debug] pam_setcred: > error Permission denied > > > > -----Original Message----- > > From: Ed Phillips [SMTP:ed at UDel.Edu] > > Sent: Thursday, November 08, 2001 19:17 > > To: Dost, Alexander > > Cc: openssh-unix-dev at mindrot.org > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > Can you try adding the "debug" option to the sshd lines in /etc/pam.conf? > > Also, make sure syslogd is gathering the messages for auth.err, auth.info, > > auth.debug, auth.alert, and auth.crit. Maybe something will show up in > > the logs to pinpoint where pam_sm_chauthtok() is failing. It's odd, > > because it should never return -1 - only valid PAM_XXXX error codes (which > > are >= 0), according to "man pam_sm_chauthtok". Strange... > > > > Ed > > > > On Thu, 8 Nov 2001, Dost, Alexander wrote: > > > > > Date: Thu, 8 Nov 2001 18:47:01 +0100 > > > From: "Dost, Alexander" > > > To: 'Ed Phillips' > > > Cc: openssh-unix-dev at mindrot.org > > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > > > Yes, I get the error messages (illegal option shadow/nodelay). > > > I removed the entry and, as you said, they are just ignored, nothing > > > changed. > > > One additional piece of information: If I use NIS+ for password > > > authentication/changing, all works fine. > > > > > > Alex > > > > > > # > > > # /etc/nsswitch.files: > > > # > > > # An example file that could be copied over to /etc/nsswitch.conf; it > > > # does not use any naming service. > > > # > > > # "hosts:" and "services:" in this file are used only if the > > > # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" > > transports. > > > > > > passwd: files > > > group: files > > > hosts: dns files > > > ipnodes: files > > > networks: files > > > protocols: files > > > rpc: files > > > ethers: files > > > netmasks: files > > > bootparams: files > > > publickey: files > > > # At present there isn't a 'files' backend for netgroup; the system > > will > > > # figure it out pretty quickly, and won't use netgroups at all. > > > netgroup: files > > > automount: files > > > aliases: files > > > services: files > > > sendmailvars: files > > > printers: user files > > > > > > auth_attr: files > > > prof_attr: files > > > project: files > > > > > > > -----Original Message----- > > > > From: Ed Phillips [SMTP:ed at UDel.Edu] > > > > Sent: Thursday, November 08, 2001 18:34 > > > > To: Dost, Alexander > > > > Cc: openssh-unix-dev at mindrot.org > > > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > > > > > On Thu, 8 Nov 2001, Dost, Alexander wrote: > > > > > > > > > Date: Thu, 8 Nov 2001 18:01:52 +0100 > > > > > From: "Dost, Alexander" > > > > > To: 'Ed Phillips' > > > > > Cc: openssh-unix-dev at mindrot.org > > > > > Subject: RE: OpenSSH3.0p1/PAM/Sol8 > > > > > > > > > > I imported the example from the contrib directory for generic unix. > > > > > sshd is running as root. > > > > > > > > > > Alex > > > > > > > > > > pam.conf: > > > > > # > > > > > #ident "@(#)pam.conf 1.16 01/01/24 SMI" > > > > > # > > > > > # Copyright (c) 1996-2000 by Sun Microsystems, Inc. > > > > > # All rights reserved. > > > > > # > > > > > # PAM configuration > > > > > # > > > > > # Authentication management > > > > > # > > > > > login auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 > > > > > sshd auth required /usr/lib/security/$ISA/pam_unix.so shadow > > > > nodelay > > > > > > > > Not that it matters, but "shadow" and "nodelay" are not arguments that > > are > > > > recognized by pam_unix.so.1 according to "man pam_unix". > > > > > > > > > # > > > > > rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > > > > > rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > # > > > > > dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > # > > > > > rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 > > > > > other auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > # > > > > > # Account management > > > > > # > > > > > login account requisite > > > > /usr/lib/security/$ISA/pam_roles.so.1 > > > > > login account required > > > > /usr/lib/security/$ISA/pam_projects.so.1 > > > > > login account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > sshd account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > > > > Looks fine. > > > > > > > > > # > > > > > dtlogin account requisite > > > > /usr/lib/security/$ISA/pam_roles.so.1 > > > > > dtlogin account required > > > > /usr/lib/security/$ISA/pam_projects.so.1 > > > > > dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > # > > > > > other account requisite > > > > /usr/lib/security/$ISA/pam_roles.so.1 > > > > > other account required > > > > /usr/lib/security/$ISA/pam_projects.so.1 > > > > > other account required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > # > > > > > # Session management > > > > > # > > > > > sshd session required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > > > > Looks fine. > > > > > > > > > other session required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > # > > > > > # Password management > > > > > # > > > > > sshd password required /usr/lib/security/$ISA/pam_unix.so > > > > shadow > > > > > nullok use_authtok > > > > > > > > Again, these are not supported arguments according to "man pam_unix". > > > > However, they should just be ignored. You should get syslog messages > > to > > > > auth.err about these options though. Did you see any? > > > > > > > > > other password required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 > > > > > # > > > > > # Support for Kerberos V5 authentication (uncomment to use Kerberos) > > > > > > > > Hmmmm... what does your /etc/nsswitch.conf file look like? > > > > > > > > Ed > > > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > > > Systems Programmer III, Network and Systems Services > > > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > > > > If you have received this e-mail in error or wish to read our e-mail > > disclaimer statement and monitoring policy, please refer to > > > http://www.drkw.com/disc/email/ or contact the sender. > > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > Systems Programmer III, Network and Systems Services > > finger -l ed at polycut.nss.udel.edu for PGP public key > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Fri Nov 9 06:25:33 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 8 Nov 2001 14:25:33 -0500 Subject: logging of root logins In-Reply-To: <20011108105118.G19266@flounder.net>; from adam-dated-1005677480.b73e07@flounder.net on Thu, Nov 08, 2001 at 10:51:18AM -0800 References: <20011108145537.A8383@faui02.informatik.uni-erlangen.de> <20011108105118.G19266@flounder.net> Message-ID: <20011108142532.Z5739@sm2p1386swk.wdr.com> Never underestimate cultural inertia. And sigh. On Thu, Nov 08, 2001 at 10:51:18AM -0800, Adam McKenna wrote: > On Thu, Nov 08, 2001 at 04:02:05PM +0100, Arthur de Jong wrote: > > > > On Thu, 8 Nov 2001, Markus Friedl wrote: > > > hm, i don't think uid sharing is a standard unix feature. > > > > I agree that it's not a very nice thing to do but I know several > > organisations that use several ROOT accounts. It's nice to have several > > passwords to access ROOT priviliges. (I know sudo or similar is better but > > not as convenient). > > How is sudo not convenient? It's four letters, and the person doesn't need > to remember a separate root password, he just uses his own password. > > It's also vastly more configurable. > > --Adam -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ed at UDel.Edu Fri Nov 9 06:27:51 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 8 Nov 2001 14:27:51 -0500 (EST) Subject: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM Message-ID: The reason I ask about the patches is because I think the problem you're seeing might actually be a bug in pam_unix.so.1 - it's something to try at least. We don't use password aging and we don't use the "passwd" command to change passwords, so we haven't run into this at our site even though we probably don't have pam_unix.so patched up. Also, the passwd command doesn't even work if you have something besides "files", "nis" or "nis+" in the passwd line of /etc/nsswitch.conf (which we do). Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From wtresp at kpmg.com Fri Nov 9 06:29:17 2001 From: wtresp at kpmg.com (Tresp, Wilfried) Date: Thu, 8 Nov 2001 20:29:17 +0100 Subject: buildpkg.sh scripts problem Message-ID: <018E28C66A9AD211B6A00008C72426E1019728A0@debziexc32.de.kworld.kpmg.com> Hello Ben Lindstrom, I tried your package creation scripts for Solaris which are contributed with the new OpenSSH Version 3.0.0p1. Nice that you develop these scripts but I run into a major problem installing the package which was created by the script. On our Solaris hosts /usr/local is only a symbolic link to /opt/local. After installing the OpenSSH package the symbolic link was removed and a new directory /usr/local was created. Of cause this breaks a lot of things on our hosts. Maybe removing /usr/local from the Prototype file will fix this but I'm not sure because I'm not so familiar with the package creation process. Regards, Wilfried Tresp --- KPMG Zentralbereich Informationstechnologie Projects Networking Kurfuerstendamm 207 - 208, 10719 Berlin phone +49 30 2068 4889 fax +49 30 2068 4662 mailto:wtresp at kpmg.com http://www.kpmg.com -- E-Mail Disclaimer Der Inhalt dieser E-Mail ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail unzulaessig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen. Aussagen gegenueber dem Adressaten unterliegen den Regelungen des zugrundeliegenden Angebotes bzw. Auftrags, insbesondere den Allgemeinen Auftragsbedingungen und der individuellen Haftungs- vereinbarung. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief entsprechend bestaetigt wird. Die Versendung von E-Mails an uns hat keine fristwahrende Wirkung. Wir moechten Sie ausserdem darauf hinweisen, dass die Kommunikation per E-Mail ueber das Internet unsicher ist, da fuer unberechtigte Dritte grundsaetzlich die Moeglichkeit der Kenntnisnahme und Manipulation besteht. Wir werden daher keine vertraulichen Daten unverschluesselt per E-Mail ueber das Internet versenden. The information contained in this email is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any form of disclosure, reproduction, distribution or any action taken or refrained from in reliance on it, is prohibited and may be unlawful. Please notify the sender immediately. All statements of opinion or advice directed via this email to our clients are subject to the terms and conditions expressed in the governing KPMG client engagement letter. The content of this email is not legally binding unless confirmed by letter. The sending of emails to us will not constitute compliance with any time limits or deadlines. We also like to inform you that communication via email over the internet is insecure because third parties may have the possibility to access and manipulate emails. For this reason we will not send any confidential information via email over the internet, unless encrypted. From ed at UDel.Edu Fri Nov 9 06:36:54 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 8 Nov 2001 14:36:54 -0500 (EST) Subject: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM In-Reply-To: Message-ID: Better Idea Alert! Try patch 111659-02 and you don't have to wait for 3 hours (right now) while the Recommended Patch Set installs. Chances are, if there is a problem with pam_unix, this patch fixes it. The buglist for this patch includes the following: 4112707 Password expiration (passwd -f) doesn't work correctly Also, if "passwd -f" is really the culprit (puts something in /etc/shadow that pam_unix.so doesn't like), you can try editing /etc/shadow by hand and make the entry look like: user::1:1:1:::: Hope this is helps... Ed On Thu, 8 Nov 2001, Ed Phillips wrote: > Date: Thu, 8 Nov 2001 14:26:54 -0500 (EST) > From: Ed Phillips > To: "Dost, Alexander" > Cc: openssh-unix-dev at udel.edu > Subject: RE: sshd can't change expired password on Sol8 with Openssh3.0p1 > + PAM > > The reason I ask about the patches is because I think the problem you're > seeing might actually be a bug in pam_unix.so.1 - it's something to try at > least. We don't use password aging and we don't use the "passwd" command > to change passwords, so we haven't run into this at our site even though > we probably don't have pam_unix.so patched up. Also, the passwd command > doesn't even work if you have something besides "files", "nis" or "nis+" > in the passwd line of /etc/nsswitch.conf (which we do). > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From mouring at etoh.eviladmin.org Fri Nov 9 06:56:16 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Nov 2001 13:56:16 -0600 (CST) Subject: buildpkg.sh scripts problem In-Reply-To: <018E28C66A9AD211B6A00008C72426E1019728A0@debziexc32.de.kworld.kpmg.com> Message-ID: On Thu, 8 Nov 2001, Tresp, Wilfried wrote: > Hello Ben Lindstrom, > > I tried your package creation scripts for Solaris which are contributed with > the new OpenSSH Version 3.0.0p1. > > Nice that you develop these scripts but I run into a major problem > installing the package which was created by the script. > > On our Solaris hosts /usr/local is only a symbolic link to /opt/local. After > installing the OpenSSH package the symbolic link was removed and a new > directory /usr/local was created. Of cause this breaks a lot of things on > our hosts. > I would expect.. It it would for every other program on earth. Unsure what you are asking of me to fix. > Maybe removing /usr/local from the Prototype file will fix this but I'm not > sure because I'm not so familiar with the package creation process. > The package prototype is generated when you do 'buildpkg.sh'. I don't see how I can remove '/usr/local' from it. Unless you are asking me to make the package relocatable. Which would be rather hard to do, and I'm currently not up to such a task. (The main issue is ssh_prng_cmds if you default to the internal entropy generation system). [..] > -- > E-Mail Disclaimer > [..] On Another toptic: UGH.. Email disclaimers are getting as annoying as mIRC colours in efnet. PLEASE people.. Keep your signatures and disclaimers down to a *FEW* lines. It wastes a ton of space. Do we really need 20 line disclaimers translated into 20 different languages?! They are getting LONGER than the freaking email they are to protect! - Ben Disclaimer: I don't care. All email is Public Domain. From scott.burch at camberwind.com Fri Nov 9 07:06:16 2001 From: scott.burch at camberwind.com (Scott Burch) Date: Thu, 8 Nov 2001 14:06:16 -0600 Subject: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM References: Message-ID: <009701c16890$d2ad32f0$f24318ac@ent.core.medtronic.com> Hello, For Solaris 2.6 the patch is 106271-08 from 9/17/01. I am about to build on 2.6 and will verify that this works. -Scott ----- Original Message ----- From: "Ed Phillips" To: "Dost, Alexander" Cc: "OpenSSH Development" Sent: Thursday, November 08, 2001 1:36 PM Subject: RE: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM > Better Idea Alert! > > Try patch 111659-02 and you don't have to wait for 3 hours (right now) > while the Recommended Patch Set installs. > > Chances are, if there is a problem with pam_unix, this patch fixes it. > The buglist for this patch includes the following: > > 4112707 Password expiration (passwd -f) doesn't work correctly > > Also, if "passwd -f" is really the culprit (puts something in /etc/shadow > that pam_unix.so doesn't like), you can try editing /etc/shadow by hand > and make the entry look like: > > user::1:1:1:::: > > Hope this is helps... > > Ed > > On Thu, 8 Nov 2001, Ed Phillips wrote: > > > Date: Thu, 8 Nov 2001 14:26:54 -0500 (EST) > > From: Ed Phillips > > To: "Dost, Alexander" > > Cc: openssh-unix-dev at udel.edu > > Subject: RE: sshd can't change expired password on Sol8 with Openssh3.0p1 > > + PAM > > > > The reason I ask about the patches is because I think the problem you're > > seeing might actually be a bug in pam_unix.so.1 - it's something to try at > > least. We don't use password aging and we don't use the "passwd" command > > to change passwords, so we haven't run into this at our site even though > > we probably don't have pam_unix.so patched up. Also, the passwd command > > doesn't even work if you have something besides "files", "nis" or "nis+" > > in the passwd line of /etc/nsswitch.conf (which we do). > > > > Ed > > > > Ed Phillips University of Delaware (302) 831-6082 > > Systems Programmer III, Network and Systems Services > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > > > From carson at taltos.org Fri Nov 9 07:12:26 2001 From: carson at taltos.org (Carson Gaspar) Date: Thu, 08 Nov 2001 15:12:26 -0500 Subject: buildpkg.sh scripts problem In-Reply-To: References: Message-ID: <51094019.1005232345@[192.168.123.111]> Actually, all you have to do is remove /usr/local from the pkgmap file. If it doesn't exist, pkgadd will whine, and create it for you. pkgproto is a _very_ stupid program... -- Carson From mouring at etoh.eviladmin.org Fri Nov 9 07:26:30 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Nov 2001 14:26:30 -0600 (CST) Subject: buildpkg.sh scripts problem In-Reply-To: <51094019.1005232345@[192.168.123.111]> Message-ID: Extremely stupid program. What are you suggestion on my end we can do which may resolve this issue. Or is this just something that can not be resolved automaticly? - ben On Thu, 8 Nov 2001, Carson Gaspar wrote: > Actually, all you have to do is remove /usr/local from the pkgmap file. If > it doesn't exist, pkgadd will whine, and create it for you. > > pkgproto is a _very_ stupid program... > > -- > Carson > > From Nicolas.Williams at ubsw.com Fri Nov 9 07:34:46 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 8 Nov 2001 15:34:46 -0500 Subject: buildpkg.sh scripts problem In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Nov 08, 2001 at 02:26:30PM -0600 References: <51094019.1005232345@[192.168.123.111]> Message-ID: <20011108153445.B5739@sm2p1386swk.wdr.com> Make a static prototype file. Use relocatable paths. Those are paths which don't start with '/' -- they either start with $VARIABLE, or are plain relative paths. The latter are implictly taken to start with $BASEDIR. Then you can specify the value of BASEDIR and any other such variables in the pkginfo file, and those can be overridden at pkg install time via a response file. Nico On Thu, Nov 08, 2001 at 02:26:30PM -0600, mouring at etoh.eviladmin.org wrote: > > Extremely stupid program. > > What are you suggestion on my end we can do which may resolve this issue. > Or is this just something that can not be resolved automaticly? > > - ben > > > On Thu, 8 Nov 2001, Carson Gaspar wrote: > > > Actually, all you have to do is remove /usr/local from the pkgmap file. If > > it doesn't exist, pkgadd will whine, and create it for you. > > > > pkgproto is a _very_ stupid program... > > > > -- > > Carson > > > > -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From toddr at rpi.edu Fri Nov 9 08:05:25 2001 From: toddr at rpi.edu (R. Lindsay Todd) Date: Thu, 08 Nov 2001 16:05:25 -0500 Subject: OpenSSH 3.0p1+AFS+PAM on Solaris 8 Message-ID: <3BEAF395.8090109@rpi.edu> Seems like AFS support uses a structure in ioctl.h that requires sys/ioccom.h to be included beforehand. The following patch checks for this header file, and makes sure it is included. I don't have the latest auto* tools, so I hand-synthesized "configure"; hopefully this doesn't mask typo's in its sources. --- config.h.in.ORIG Sat Nov 3 19:25:33 2001 +++ config.h.in Thu Nov 8 13:40:24 2001 @@ -459,6 +459,9 @@ /* Define if you have the `innetgr' function. */ #undef HAVE_INNETGR +/* Define if you have the header file. */ +#undef HAVE_SYS_IOCCOM_H + /* Define if you have the header file. */ #undef HAVE_INTTYPES_H --- configure.ac.ORIG Sat Nov 3 14:09:33 2001 +++ configure.ac Thu Nov 8 13:37:21 2001 @@ -437,6 +437,7 @@ netinet/in_systm.h paths.h poll.h pty.h regex.h \ security/pam_appl.h shadow.h stddef.h stdint.h \ strings.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h \ + sys/ioccom.h \ sys/poll.h sys/queue.h sys/select.h sys/stat.h \ sys/stropts.h sys/sysmacros.h sys/time.h \ sys/ttcompat.h sys/un.h time.h ttyent.h usersec.h \ --- configure.ORIG Sat Nov 3 19:25:32 2001 +++ configure Thu Nov 8 13:38:31 2001 @@ -5895,6 +5895,7 @@ netinet/in_systm.h paths.h poll.h pty.h regex.h \ security/pam_appl.h shadow.h stddef.h stdint.h \ strings.h sys/bitypes.h sys/bsdtty.h sys/cdefs.h \ + sys/ioccom.h \ sys/poll.h sys/queue.h sys/select.h sys/stat.h \ sys/stropts.h sys/sysmacros.h sys/time.h \ sys/ttcompat.h sys/un.h time.h ttyent.h usersec.h \ --- includes.h.ORIG Wed Sep 19 22:07:51 2001 +++ includes.h Thu Nov 8 13:41:10 2001 @@ -25,6 +25,9 @@ #include #include +#ifdef HAVE_SYS_IOCCOM_H +#include +#endif #include #include #include -- R. Lindsay Todd email: toddr at rpi.edu Senior Systems Programmer phone: 518-276-2605 Rensselaer Polytechnic Institute fax: 518-276-2809 Troy, NY 12180-3590 WWW: http://www.rpi.edu/~toddr From mouring at etoh.eviladmin.org Fri Nov 9 07:58:42 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Nov 2001 14:58:42 -0600 (CST) Subject: buildpkg.sh scripts problem In-Reply-To: <20011108153445.B5739@sm2p1386swk.wdr.com> Message-ID: On Thu, 8 Nov 2001, Nicolas Williams wrote: > Make a static prototype file. > No.. We moved away from a static prototype due to the fact it was ignored and kept falling out of sync. I really don't wish to return to it. I'd rather see an automatic way of generating such a file. Even if it costs me a few more lines. Not as if 'buildpkg.sh' is that complex. =) It is under 90 lines, and very readable. - Ben From mdb at juniper.net Fri Nov 9 08:08:45 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Thu, 08 Nov 2001 13:08:45 -0800 Subject: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM In-Reply-To: Mail from "Scott Burch" dated Thu, 08 Nov 2001 14:06:16 CST <009701c16890$d2ad32f0$f24318ac@ent.core.medtronic.com> Message-ID: <200111082108.fA8L8j086048@merlot.juniper.net> Hi Scott, You may find a problem building under Solaris 2.6 with references to 'struct rlimit64' this may be cured by either removing the line #define _FILE_OFFSET_BITS 64 in the config.h file or adding the lines /* Define if _FILE_OFFSET_BITS also needs _LARGEFILE64_SOURCE defined */ #define _LARGEFILE64_SOURCE 1 to config.h this is due to a bug in the AC_SYS_LARGEFILE macro used in configure.ac Good luck, -- Mark > Message-ID: <009701c16890$d2ad32f0$f24318ac at ent.core.medtronic.com> > From: "Scott Burch" > To: "Ed Phillips" , "Dost, Alexander" > Cc: "OpenSSH Development" > References: > Subject: Re: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM > Date: Thu, 8 Nov 2001 14:06:16 -0600 > > Hello, > > For Solaris 2.6 the patch is 106271-08 from 9/17/01. I am about to build on > 2.6 and will verify that this works. > > -Scott > > ----- Original Message ----- > From: "Ed Phillips" > To: "Dost, Alexander" > Cc: "OpenSSH Development" > Sent: Thursday, November 08, 2001 1:36 PM > Subject: RE: sshd can't change expired password on Sol8 with Openssh3.0p1 + > PAM > > > > Better Idea Alert! > > > > Try patch 111659-02 and you don't have to wait for 3 hours (right now) > > while the Recommended Patch Set installs. > > > > Chances are, if there is a problem with pam_unix, this patch fixes it. > > The buglist for this patch includes the following: > > > > 4112707 Password expiration (passwd -f) doesn't work correctly > > > > Also, if "passwd -f" is really the culprit (puts something in /etc/shadow > > that pam_unix.so doesn't like), you can try editing /etc/shadow by hand > > and make the entry look like: > > > > user::1:1:1:::: > > > > Hope this is helps... > > > > Ed > > > > On Thu, 8 Nov 2001, Ed Phillips wrote: > > > > > Date: Thu, 8 Nov 2001 14:26:54 -0500 (EST) > > > From: Ed Phillips > > > To: "Dost, Alexander" > > > Cc: openssh-unix-dev at udel.edu > > > Subject: RE: sshd can't change expired password on Sol8 with > Openssh3.0p1 > > > + PAM > > > > > > The reason I ask about the patches is because I think the problem you're > > > seeing might actually be a bug in pam_unix.so.1 - it's something to try > at > > > least. We don't use password aging and we don't use the "passwd" > command > > > to change passwords, so we haven't run into this at our site even though > > > we probably don't have pam_unix.so patched up. Also, the passwd command > > > doesn't even work if you have something besides "files", "nis" or "nis+" > > > in the passwd line of /etc/nsswitch.conf (which we do). > > > > > > Ed > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > > Systems Programmer III, Network and Systems Services > > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > Systems Programmer III, Network and Systems Services > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > > From Nicolas.Williams at ubsw.com Fri Nov 9 08:21:11 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 8 Nov 2001 16:21:11 -0500 Subject: buildpkg.sh scripts problem In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Nov 08, 2001 at 02:58:42PM -0600 References: <20011108153445.B5739@sm2p1386swk.wdr.com> Message-ID: <20011108162110.C5739@sm2p1386swk.wdr.com> Well, what I do here, generally, is: - make -e DESTDIR=... install - build prototype file, using relative paths, based on what got installed in $(DESTDIR) I have a bunch of scripts to support doing this for prjects with source, and for dealing with edit scripts and various things. And yes, it's proprietary... But you can steal the approach :) Nico On Thu, Nov 08, 2001 at 02:58:42PM -0600, mouring at etoh.eviladmin.org wrote: > > > On Thu, 8 Nov 2001, Nicolas Williams wrote: > > > Make a static prototype file. > > > No.. > > We moved away from a static prototype due to the fact it was ignored and > kept falling out of sync. I really don't wish to return to it. I'd > rather see an automatic way of generating such a file. Even if it costs > me a few more lines. Not as if 'buildpkg.sh' is that complex. =) It is > under 90 lines, and very readable. > > - Ben > -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From toddr at rpi.edu Fri Nov 9 08:51:28 2001 From: toddr at rpi.edu (R. Lindsay Todd) Date: Thu, 08 Nov 2001 16:51:28 -0500 Subject: OpenSSH 3.0p1+Krb4 on Irix 6.5 Message-ID: <3BEAFE60.5030507@rpi.edu> There is a conflict with kth-krb header files and those needed for passwd authentication (crypt.h, I think) with Irix 6.5. This patch remedies the situation. --- auth.h.ORIG Wed Jul 4 00:46:57 2001 +++ auth.h Thu Nov 8 13:59:03 2001 @@ -98,10 +98,12 @@ int auth_rsa_challenge_dialog(RSA *); #ifdef KRB4 +#ifndef ONLY_PASSWD_AUTH #include int auth_krb4(Authctxt *, KTEXT, char **); int auth_krb4_password(Authctxt *, const char *); void krb4_cleanup_proc(void *); +#endif /* ! ONLY_PASSWD_AUTH */ #ifdef AFS #include --- auth-passwd.c.ORIG Wed Jul 4 00:21:15 2001 +++ auth-passwd.c Thu Nov 8 14:00:13 2001 @@ -44,6 +44,7 @@ #include "xmalloc.h" #include "log.h" #include "servconf.h" +#define ONLY_PASSWD_AUTH #include "auth.h" #ifdef HAVE_CRYPT_H -- R. Lindsay Todd email: toddr at rpi.edu Senior Systems Programmer phone: 518-276-2605 Rensselaer Polytechnic Institute fax: 518-276-2809 Troy, NY 12180-3590 WWW: http://www.rpi.edu/~toddr From mouring at etoh.eviladmin.org Fri Nov 9 08:58:31 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 8 Nov 2001 15:58:31 -0600 (CST) Subject: buildpkg.sh scripts problem In-Reply-To: <20011108162110.C5739@sm2p1386swk.wdr.com> Message-ID: Have you looked at contrib/solaris/buildpkg.sh ? I do a: make install-nokeys DESTDIR=[..] cd fake_root [build the init scripts stuff] [fix up opensshd startup script w/ real etcdir and prefix] [build pkginfo file] [build prototype using find/grep/pkgproto] pkgmk [..] [remove fake_root build stuff] [do pkgtrans on the package] - Ben On Thu, 8 Nov 2001, Nicolas Williams wrote: > Well, what I do here, generally, is: > > - make -e DESTDIR=... install > - build prototype file, using relative paths, based on what got > installed in $(DESTDIR) > > I have a bunch of scripts to support doing this for prjects with > source, and for dealing with edit scripts and various things. > > And yes, it's proprietary... But you can steal the approach :) > > Nico > > > On Thu, Nov 08, 2001 at 02:58:42PM -0600, mouring at etoh.eviladmin.org wrote: > > > > > > On Thu, 8 Nov 2001, Nicolas Williams wrote: > > > > > Make a static prototype file. > > > > > No.. > > > > We moved away from a static prototype due to the fact it was ignored and > > kept falling out of sync. I really don't wish to return to it. I'd > > rather see an automatic way of generating such a file. Even if it costs > > me a few more lines. Not as if 'buildpkg.sh' is that complex. =) It is > > under 90 lines, and very readable. > > > > - Ben > > > -- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > From harbaugh at nciaxp.ncifcrf.gov Fri Nov 9 07:37:57 2001 From: harbaugh at nciaxp.ncifcrf.gov (Toni L. Harbaugh-Blackford) Date: Thu, 8 Nov 2001 15:37:57 -0500 (EST) Subject: openssh-3.0p1 + Tru64 4.0G: sia_ses_authent() always returns 0 (failure) Message-ID: Hi- I built openssh-3.0p1 on a Tru64 4.0G without any problem. The system uses enhanced security, so the sia_* routines are used by sshd. Unfortunately, password authentication fails because sia_ses_authent() returns 0 in auth-sia.c. The thing is, the password is CORRECT; I verified this by inserting debugging statements before the call to sia_ses_authent(). The call to sia_ses_init() succeeds. I checked some of the fields of the entity, but I don't know which fields should be filled in. The 'name' field gets correctly filled with the username, but the 'acctname' field is left empty, as is the 'pwd' field. Does someone know what the entity fields *should* look like after the call to sia_ses_init(), or have some other idea why the sia_ses_authent() call is failing? Thanks, Toni ----------------------------------------------------------------------- Toni Harbaugh-Blackford harbaugh at nciaxp.ncifcrf.gov AlphaServer 8400 System Administrator SAIC/NCI Frederick Advanced Biomedical Computing Center --------------------------------------------------------------------- To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com For additional commands, e-mail: secureshell-help at securityfocus.com From carson at taltos.org Fri Nov 9 12:37:15 2001 From: carson at taltos.org (Carson Gaspar) Date: Thu, 08 Nov 2001 20:37:15 -0500 Subject: buildpkg.sh scripts problem In-Reply-To: References: Message-ID: <70583063.1005251834@[192.168.123.111]> It's trivial to post-process the prototype file, or the pkgmap file, with sed to delete the /usr/local line. -- Carson From scott.burch at camberwind.com Fri Nov 9 15:48:34 2001 From: scott.burch at camberwind.com (Scott Burch) Date: 08 Nov 2001 23:48:34 -0500 Subject: Reporting back on Sol2.6 and Sol8 with Openssh3.0p1 + PAM In-Reply-To: <200111082108.fA8L8j086048@merlot.juniper.net> References: <200111082108.fA8L8j086048@merlot.juniper.net> Message-ID: <1005281315.498.33.camel@glacier> Hello, I sucessfully built OpenSSH 3.0p1 on Solaris 2.6 (however PAM and password aging does not work on 2.6, but it does work on Solaris 8...details are provided below) today with Sun's Forte 6 Update 2. I made sure all the latest linker patches and Forte patches were applied as well as any c/c++ library patches were applied. I also applied the latest patch. Details on patches: Patch-ID# 106271-08 Keywords: security pam_unix.so.1 csh umask nispasswd Passwd_compat Synopsis: SunOS 5.6: /usr/lib/security/pam_unix.so.1 patch Date: Sep/17/2001 Patch-ID# 111685-02 Keywords: C++ 5.3 CC 5.3 WS6U2 Synopsis: C++ 5.3: Patch for Forte Developer 6 update 2 C++ compiler Date: Oct/01/2001 Patch-ID# 111678-04 Keywords: common compiler backend iropt cg libmtsk WS6U2 Synopsis: Compiler Common 6.2: Patch Forte Developer 6 update 2, C++ F77 F95 Date: Oct/01/2001 Compile Options other than --with-pam: --disable-suid-ssh --without-rsh --with-prngd-socket --with-tcp-wrappers On Solaris 8 I compiled with the same options. I created two local accounts on the two servers running OpenSSH 3.0p1. I set the password on both accounts and did a passwd -f to expire the passwords. We are required now to enable and enforce password aging where I work, so this will need to work. When I login to the Solaris 8 server I get the message that my password has expired and I am asked to enter my login password. I enter the login password and things work great! On Solaris 2.6 I get the same message to enter my login password, but after entering a new password I get the following: "Removing root credentials would break the rpc services that use secure rpc on this host! Root may use key logout -f to do this (at your own risk)!" I am then disconnected. (Now I can duplicate this activity on Solaris 8 if I am another user on one host and connect via ssh to the Solaris 8 box running ssh 3.0p1 as the user whose password has expired (ssh -l). I presume this is normal..password changing for the user with an expired password only works if you are connecting as that user from the remote host?) I did not do anything with /etc/pam.conf on either host..I am using the default that came with the system. So, it appears that password aging and pam do not get along on Solaris 2.6 even with the latest patch? I'll take a closer look at things when I get in tomorrow morning. If you need further information, want debugger output...I am willing to compile with debugging, etc. -Scott On Thu, 2001-11-08 at 16:08, Mark D. Baushke wrote: > Hi Scott, > > You may find a problem building under Solaris 2.6 with references to > 'struct rlimit64' this may be cured by either removing the line > > #define _FILE_OFFSET_BITS 64 > > in the config.h file or adding the lines > > /* Define if _FILE_OFFSET_BITS also needs _LARGEFILE64_SOURCE defined */ > #define _LARGEFILE64_SOURCE 1 > > to config.h this is due to a bug in the AC_SYS_LARGEFILE macro used in > configure.ac > > Good luck, > -- Mark > > > Message-ID: <009701c16890$d2ad32f0$f24318ac at ent.core.medtronic.com> > > From: "Scott Burch" > > To: "Ed Phillips" , "Dost, Alexander" > > Cc: "OpenSSH Development" > > References: > > Subject: Re: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM > > Date: Thu, 8 Nov 2001 14:06:16 -0600 > > > > Hello, > > > > For Solaris 2.6 the patch is 106271-08 from 9/17/01. I am about to build on > > 2.6 and will verify that this works. > > > > -Scott > > > > ----- Original Message ----- > > From: "Ed Phillips" > > To: "Dost, Alexander" > > Cc: "OpenSSH Development" > > Sent: Thursday, November 08, 2001 1:36 PM > > Subject: RE: sshd can't change expired password on Sol8 with Openssh3.0p1 + > > PAM > > > > > > > Better Idea Alert! > > > > > > Try patch 111659-02 and you don't have to wait for 3 hours (right now) > > > while the Recommended Patch Set installs. > > > > > > Chances are, if there is a problem with pam_unix, this patch fixes it. > > > The buglist for this patch includes the following: > > > > > > 4112707 Password expiration (passwd -f) doesn't work correctly > > > > > > Also, if "passwd -f" is really the culprit (puts something in /etc/shadow > > > that pam_unix.so doesn't like), you can try editing /etc/shadow by hand > > > and make the entry look like: > > > > > > user::1:1:1:::: > > > > > > Hope this is helps... > > > > > > Ed > > > > > > On Thu, 8 Nov 2001, Ed Phillips wrote: > > > > > > > Date: Thu, 8 Nov 2001 14:26:54 -0500 (EST) > > > > From: Ed Phillips > > > > To: "Dost, Alexander" > > > > Cc: openssh-unix-dev at udel.edu > > > > Subject: RE: sshd can't change expired password on Sol8 with > > Openssh3.0p1 > > > > + PAM > > > > > > > > The reason I ask about the patches is because I think the problem you're > > > > seeing might actually be a bug in pam_unix.so.1 - it's something to try > > at > > > > least. We don't use password aging and we don't use the "passwd" > > command > > > > to change passwords, so we haven't run into this at our site even though > > > > we probably don't have pam_unix.so patched up. Also, the passwd command > > > > doesn't even work if you have something besides "files", "nis" or "nis+" > > > > in the passwd line of /etc/nsswitch.conf (which we do). > > > > > > > > Ed > > > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > > > Systems Programmer III, Network and Systems Services > > > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > > > > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > > Systems Programmer III, Network and Systems Services > > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > > > > > > > > -- Scott Burch http://www.camberwind.com/ From strube at physik3.gwdg.de Fri Nov 9 20:23:40 2001 From: strube at physik3.gwdg.de (Hans Werner Strube) Date: Fri, 9 Nov 2001 10:23:40 +0100 (MET) Subject: openssh-3.0p1, auth2.c Message-ID: <200111090923.KAA04951@marc.physik3.gwdg.de> openssh-3.0p1 still contains the bug which I already reported on Sept. 28 2001 for 2.9p2, namely, the trailing dot in chost should be stripped before calling auth_rhosts2() even with option "HostbasedUsesNameFromPacketOnly yes". Otherwise, the host names in /etc/hosts.equiv and .rhosts would have to be dot-terminated. Fix: Move lines 776-779 of auth2.c upwards to after line 767. (These line numbers also hold for 2.9.9p2.) *** auth2.c.ORI Wed Oct 3 19:12:44 2001 --- auth2.c Fri Nov 9 10:15:42 2001 *************** *** 765,770 **** --- 765,774 ---- resolvedname = get_canonical_hostname(options.reverse_mapping_check); ipaddr = get_remote_ipaddr(); + if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') { + debug2("stripping trailing dot from chost %s", chost); + chost[len - 1] = '\0'; + } debug2("userauth_hostbased: chost %s resolvedname %s ipaddr %s", chost, resolvedname, ipaddr); *************** *** 773,782 **** return 0; lookup = chost; } else { - if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') { - debug2("stripping trailing dot from chost %s", chost); - chost[len - 1] = '\0'; - } if (strcasecmp(resolvedname, chost) != 0) log("userauth_hostbased mismatch: " "client sends %s, but we resolve %s to %s", --- 777,782 ---- From Alexander.Dost at drkw.com Fri Nov 9 20:29:40 2001 From: Alexander.Dost at drkw.com (Dost, Alexander) Date: Fri, 9 Nov 2001 10:29:40 +0100 Subject: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM Message-ID: <3E16581537ABE44EB18C5206CE79F26B89BC49@ibfftc0006.is.de.dresdnerkb.com> Putting together what various testing produced: The problem is indeed the passwd -f command. It puts a zero into the lastchg field and this is never changed thereafter... pam_unix.so crashes and is not able to handle the zero-field. If you change /etc/shadow according to the below mentioned scheme "name::1:1:1", everything works fine. The only problem is that after login the other fields are not updated. The lastchg field is set correct, but the other (min/max/warn) are left alone pointing to '1' so after one day you will supposedly be asked again to change. But this is another problem, I think when you manually change these files. Thanks all for the help Alex > -----Original Message----- > From: Mark D. Baushke [SMTP:mdb at juniper.net] > Sent: Thursday, November 08, 2001 22:09 > To: Scott Burch > Cc: Ed Phillips; Dost, Alexander; OpenSSH Development > Subject: Re: sshd can't change expired password on Sol8 with > Openssh3.0p1 + PAM > > Hi Scott, > > You may find a problem building under Solaris 2.6 with references to > 'struct rlimit64' this may be cured by either removing the line > > #define _FILE_OFFSET_BITS 64 > > in the config.h file or adding the lines > > /* Define if _FILE_OFFSET_BITS also needs _LARGEFILE64_SOURCE defined */ > #define _LARGEFILE64_SOURCE 1 > > to config.h this is due to a bug in the AC_SYS_LARGEFILE macro used in > configure.ac > > Good luck, > -- Mark > > > Message-ID: <009701c16890$d2ad32f0$f24318ac at ent.core.medtronic.com> > > From: "Scott Burch" > > To: "Ed Phillips" , "Dost, Alexander" > > > Cc: "OpenSSH Development" > > References: > > Subject: Re: sshd can't change expired password on Sol8 with > Openssh3.0p1 + PAM > > Date: Thu, 8 Nov 2001 14:06:16 -0600 > > > > Hello, > > > > For Solaris 2.6 the patch is 106271-08 from 9/17/01. I am about to > build on > > 2.6 and will verify that this works. > > > > -Scott > > > > ----- Original Message ----- > > From: "Ed Phillips" > > To: "Dost, Alexander" > > Cc: "OpenSSH Development" > > Sent: Thursday, November 08, 2001 1:36 PM > > Subject: RE: sshd can't change expired password on Sol8 with > Openssh3.0p1 + > > PAM > > > > > > > Better Idea Alert! > > > > > > Try patch 111659-02 and you don't have to wait for 3 hours (right now) > > > while the Recommended Patch Set installs. > > > > > > Chances are, if there is a problem with pam_unix, this patch fixes it. > > > The buglist for this patch includes the following: > > > > > > 4112707 Password expiration (passwd -f) doesn't work correctly > > > > > > Also, if "passwd -f" is really the culprit (puts something in > /etc/shadow > > > that pam_unix.so doesn't like), you can try editing /etc/shadow by > hand > > > and make the entry look like: > > > > > > user::1:1:1:::: > > > > > > Hope this is helps... > > > > > > Ed > > > > > > On Thu, 8 Nov 2001, Ed Phillips wrote: > > > > > > > Date: Thu, 8 Nov 2001 14:26:54 -0500 (EST) > > > > From: Ed Phillips > > > > To: "Dost, Alexander" > > > > Cc: openssh-unix-dev at udel.edu > > > > Subject: RE: sshd can't change expired password on Sol8 with > > Openssh3.0p1 > > > > + PAM > > > > > > > > The reason I ask about the patches is because I think the problem > you're > > > > seeing might actually be a bug in pam_unix.so.1 - it's something to > try > > at > > > > least. We don't use password aging and we don't use the "passwd" > > command > > > > to change passwords, so we haven't run into this at our site even > though > > > > we probably don't have pam_unix.so patched up. Also, the passwd > command > > > > doesn't even work if you have something besides "files", "nis" or > "nis+" > > > > in the passwd line of /etc/nsswitch.conf (which we do). > > > > > > > > Ed > > > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > > > Systems Programmer III, Network and Systems Services > > > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > > > > > > > > > Ed Phillips University of Delaware (302) 831-6082 > > > Systems Programmer III, Network and Systems Services > > > finger -l ed at polycut.nss.udel.edu for PGP public key > > > > > > > > > > > From michael.mai at db.com Sat Nov 10 01:30:09 2001 From: michael.mai at db.com (Michael Mai) Date: Fri, 9 Nov 2001 15:30:09 +0100 Subject: OpenSSH 2.3 Message-ID: First of all my congratulations for the successful development of OpenSSH 3.0 . I am still working with OpenSSH 2.3.0p1which we ported to an IBM OS/390 mainframe system. I recompiled and reinstalled OpenSSL but to no avail. Now I activated DEBUG_DSS and saw, that pub, P, Q look equal on ASCII systems and our EBCDIC system, but g looks different on our OS/390 system. Am I right to assume that g is part of the counterpart's sent public key, and if it does not match the remainder of the public key, the message "signature incorrect" may appear ?? Thank you in advance. Gruss/ regards Michael Mai Deutsche Bank PCAM-GT CTO Platform Mainframe MVS Applications Application Enabling Technology Alfred-Herrhausen-Allee 16-24 65760 Eschborn Phone: 069-910-66511 Fax: 069-910-65533 email: michael.mai at db.com -- Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From K.Wolkersdorfer at fz-juelich.de Sat Nov 10 03:02:56 2001 From: K.Wolkersdorfer at fz-juelich.de (K.Wolkersdorfer at fz-juelich.de) Date: Fri, 9 Nov 2001 16:02:56 +0000 Subject: AIX lastlog change Message-ID: <1011109160256.ZM19860@zam282.zam.kfa-juelich.de> Hi David, I'm sure loginfailed(..) should be called immediately after authenticate(..) returned an error. It is directly related to an invalid password try. (Please see my attached mail from May 2001 to the list). I'm not so sure when loginsuccess(..) should be called (setting the loginfailed counter to zero): Either 1) when somebody logs in successfully using all kinds of valid openssh-login mechanisms or 2) when somebody logs in successfully WITH the correct password ONLY Probably 2) would be correct, but we could live with 1) also as it works now. Best regards from Germany Klaus --------------------------------------------------------------------------- From: K.Wolkersdorfer at fz-juelich.de Date: Mon, 21 May 2001 14:08:00 +0000 Reply-To: K.Wolkersdorfer at fz-juelich.de To: openssh-unix-dev at mindrot.org Subject: openssh-2.9p1 bug: loginfailed() with AIX 4.3.3 Hi, first let me thank you for all the excellent work with openssh! Bug-Description (for AIX - current release 4.3.3 - only): During password-authentication if a user enters a wrong password, the failed attempt is not at all recorded in /etc/security/lastlog, although the loginfailed() subroutine in auth1.c is supposed to do that. Suggestion: In AIX the loginfailed() subroutine should be called if and only if the user enters a wrong password: From man loginfailed: ..."A login failure audit record is cut to indicate that an unsuccessful login attempt occurred. A utmp entry is appended to /etc/security/failedlogin file, which tracks all failed login attempts." ... So it seems that in auth1.c the loginfailed() subroutine is on the wrong place. It should be immediately after the password-authentication. Bug-Fix: The following fix works for us: ------------------------------------------------------------------------ diff auth-passwd.c.orig auth-passwd.c 151c151,160 < return (authenticate(pw->pw_name,password,&reenter,&authmsg) == 0); --- > { int iau; > iau = (authenticate(pw->pw_name,password,&reenter,&authmsg) == 0); > debug("auth-passwd (FZJ-authenticate): rc: %d msg: %s", iau, authmsg); > if (iau) > return 1; > loginfailed(authctxt->user, > get_canonical_hostname(options.reverse_mapping_check), > "ssh"); > return 0; > } ------------------------------------------------------------------------- -- Klaus Wolkersdorfer (K.Wolkersdorfer at fz-juelich.de) Zentralinstitut fuer Angewandte Mathematik (ZAM) Tel: +49-2461-61-6579 John von Neumann - Institute for Computing (NIC) Fax: -6656 Forschungszentrum Juelich GmbH, D-52425 Juelich, Germany From ed at UDel.Edu Sat Nov 10 02:59:19 2001 From: ed at UDel.Edu (Ed Phillips) Date: Fri, 9 Nov 2001 10:59:19 -0500 (EST) Subject: Reporting back on Sol2.6 and Sol8 with Openssh3.0p1 + PAM In-Reply-To: <1005281315.498.33.camel@glacier> Message-ID: On 8 Nov 2001, Scott Burch wrote: > Date: 08 Nov 2001 23:48:34 -0500 > From: Scott Burch > To: Mark D. Baushke > Cc: Ed Phillips , > "Dost, Alexander" , > OpenSSH Development > Subject: Reporting back on Sol2.6 and Sol8 with Openssh3.0p1 + PAM > > Hello, > > I sucessfully built OpenSSH 3.0p1 on Solaris 2.6 (however PAM and > password aging does not work on 2.6, but it does work on Solaris > 8...details are provided below) today with Sun's Forte 6 Update 2. I > made sure all the latest linker patches and Forte patches were applied > as well as any c/c++ library patches were applied. I also applied the > latest patch. > > Details on patches: > > > Patch-ID# 106271-08 > Keywords: security pam_unix.so.1 csh umask nispasswd Passwd_compat > Synopsis: SunOS 5.6: /usr/lib/security/pam_unix.so.1 patch > Date: Sep/17/2001 > > Patch-ID# 111685-02 > Keywords: C++ 5.3 CC 5.3 WS6U2 > Synopsis: C++ 5.3: Patch for Forte Developer 6 update 2 C++ compiler > Date: Oct/01/2001 > > Patch-ID# 111678-04 > Keywords: common compiler backend iropt cg libmtsk WS6U2 > Synopsis: Compiler Common 6.2: Patch Forte Developer 6 update 2, C++ F77 > F95 > Date: Oct/01/2001 > > Compile Options other than --with-pam: > > --disable-suid-ssh > --without-rsh > --with-prngd-socket > --with-tcp-wrappers > > On Solaris 8 I compiled with the same options. > > I created two local accounts on the two servers running OpenSSH 3.0p1. > I set the password on both accounts and did a passwd -f to expire the > passwords. We are required now to enable and enforce password aging > where I work, so this will need to work. > > When I login to the Solaris 8 server I get the message that my > password has expired and I am asked to enter my login password. I > enter the login password and things work great! Me too. It's wierd because I thought 106271-08 would fix this on Sol2.6 too... but it doesn't. So I'm wondering if the corresponding "passwd -f doesn't work" patch on Sol8 isn't fixing this problem on Sol8 either, but it's something else entirely... nah... couldn't be. Must be a difference in pam_unix.so between 2.6 and 8? > On Solaris 2.6 I get the same message to enter my login password, but > after entering a new password I get the following: > > "Removing root credentials would break the rpc services that use secure > rpc on this host! Root may use key logout -f to do this (at your own > risk)!" I am then disconnected. I have reproduced this. The problem with the creds is a completely separate bug that seems to occur with sshd/PAM on Solaris and is caused by the following scenario: 1) pam_unix.so uses the effective uid to decide whose creds to delete (if it's uid=0, it gives the error messages - and with openssh it's uid=0) 2) sshd doesn't call seteuid() to change to the user before deleting creds Some people have said that pam_unix.so should use PAM_USER to determine whose creds to delete (and it's therefore a bug in PAM on Solaris)... but others have noted that Sun has made pam_unix.so work like this from the start. Noone who knows the PAM standard backwards and forwards has commented to say how pam_sm_setcred(PAM_DELETE_CREDS) is SUPPOSED to determine the user whose creds need to be deleted. > (Now I can duplicate this activity on Solaris 8 if I am another user on > one host and connect via ssh to the Solaris 8 box running ssh 3.0p1 as > the user whose password has expired (ssh -l). I presume this is > normal..password changing for the user with an expired password only > works if you are connecting as that user from the remote host?) Changing expired passwords on Sol8 works for me with the recommended patches. But Alexander has seen the same "close the connection" problem with expired passwords on Sol8 which he reported yesterday - he didn't tell me yet if he has the "passwd -f doesn't work" patch installed on his Sol8 box, tho'. I'd guess he doesn't have it yet. Has anyone tried to reproduce this on a Sol8 box with the "passwd -f doesn't work" patch removed - just to see if it's really fixing THIS particular problem or if it's just coincidence that this works on Sol8 but not on Sol2.6? Due the the error returned by pam_sm_chauthtok (it returns -1) in pam_unix.so , I think it's a pam_unix.so bug, but I can't be certain without discussing Sol8 source in detail, which I'm not sure is allowed by my source agreement. Darren, can I discuss this with you directly so I can make direct references to the Sol8 source? Maybe you could tell me how the patched up version of pam_unix.so source differs from Sol8 FCS (like, whether this -1 return code thing is in one of the fixes) - that would probably rule-in or rule-out my suspicions pretty quickly... Isn't Sol8 "open-source" now (maybe only in the sense that you can do what you want with it except sell it) or was that just pipe dream...? > I did not do anything with /etc/pam.conf on either host..I am using the > default that came with the system. That should be fine - pam_unix.so is set up to do be the default for every service. > So, it appears that password aging and pam do not get along on Solaris > 2.6 even with the latest patch? I'll take a closer look at things when I > get in tomorrow morning. If you need further information, want debugger > output...I am willing to compile with debugging, etc. I'm not sure debugging (-g) in sshd would help more than when we just run it with LogLevel DEBUG3, making sure /etc/pam_debug exists, and putting the debug option on the pam.conf entries from "other". The problem exists somewhere in pam_unix.so - and it's the culprit that is return a -1 error back to sshd (which according to the man pages, can't happen ;-). It would be nice however to recompile pam_unix.so.1 with some extra logging stuck in... ;-) Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From ed at UDel.Edu Sat Nov 10 03:23:27 2001 From: ed at UDel.Edu (Ed Phillips) Date: Fri, 9 Nov 2001 11:23:27 -0500 (EST) Subject: sshd can't change expired password on Sol8 with Openssh3.0p1 + PAM In-Reply-To: <3E16581537ABE44EB18C5206CE79F26B89BC49@ibfftc0006.is.de.dresdnerkb.com> Message-ID: On Fri, 9 Nov 2001, Dost, Alexander wrote: > Date: Fri, 9 Nov 2001 10:29:40 +0100 > From: "Dost, Alexander" > To: Ed Phillips > Cc: OpenSSH Development , > "'sproba1 at llnl.gov'" > Subject: RE: sshd can't change expired password on Sol8 with Openssh3.0p1 > + PAM > > Putting together what various testing produced: > The problem is indeed the passwd -f command. It puts a zero into the lastchg > field and this is never changed thereafter... pam_unix.so crashes and is not > able to handle the zero-field. > If you change /etc/shadow according to the below mentioned scheme > "name::1:1:1", everything works fine. GOOD JOB! That solves the problem on Sol2.6 too! So, the question is, are you running patch 111659-02 on your Sol8 box? if not, then install it and see if it fixes the "passwd -f" problem. If you ARE running 111659-02, then I not sure what is going on - Scott and I are running it and "passwd -f" works for us on Sol8. Now the big question is: why doesn't 106271-08 doesn't fix the problem on Sol2.6? The "passwd -f" problem is bug ID 4112707, by the way. > The only problem is that after login the other fields are not updated. The > lastchg field is set correct, but the other (min/max/warn) are left alone > pointing to > '1' so after one day you will supposedly be asked again to change. But this > is another problem, I think when you manually change these files. Yes... that's a problem - but only for users not set up for passwd expiration. You have to edit /etc/shadow again and delete the min/max fields or the bogus policy you put in by hand will keep enforcing. I think this is a bug - "passwd -f" should allow (or some other switch) the sysadmin to force a password change without affecting the expiration policy at all, and "passwd -f" doesn't preserve the existing expiration policy. To manually force a password change without changing the expire policy for an account which has valid min/max fields, just change the lastchg field to "1" and leave the other fields alone. A password change will be required the next time they login, and then again in another max days. > > Thanks all for the help No problem! Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From scott.burch at camberwind.com Sat Nov 10 03:24:31 2001 From: scott.burch at camberwind.com (Scott Burch) Date: Fri, 9 Nov 2001 10:24:31 -0600 Subject: Reporting back on Sol2.6 and Sol8 with Openssh3.0p1 + PAM References: Message-ID: <001f01c1693b$0322be00$f24318ac@ent.core.medtronic.com> Ed, See below....Actually since yesterday I built everything on Solaris 2.6...I wasn't paying much attention to all the patches on my 8 box. It turns out I do not have the 111659-02 patch (pam_unix.so.1 patch) or any previous version of this patch on my Solaris 8 compile box; so the patch is not what allows pam and expired passwords to work with OpenSSH...something else must be doing this. I am going to send a separate email to you with two attached html files containing all the patches on both boxes (output from Sun's Patch Check Tool..available on SunSolve. In summary, people have been misled into believing that the pam patch is what allows this to work. In any case my 2.6 compiled OpenSSH works fine on Solaris 8 and I can login via OpenSSH to an account that has an expired password and successfully update the password without being disconnected. Hopefully we all can get to the bottom of this. It is difficult to determine differences in systems without detailed info on all installed patches....which can be painful to obtain (however the Patch Check tool does a fairly decent job). Other things: On the Solaris 2.6 compile system which contains all the latest recommended patches, plus the latest PAM patch and various other patches I have applied, accounts that have had passwd -f run on them do allow users to login in and change their expired passwords without trouble....it only doesn't work via OpenSSH 3.0p1. -Scott ----- Original Message ----- From: "Ed Phillips" To: "Scott Burch" Cc: "Mark D. Baushke" ; "Dost, Alexander" ; "OpenSSH Development" Sent: Friday, November 09, 2001 9:59 AM Subject: Re: Reporting back on Sol2.6 and Sol8 with Openssh3.0p1 + PAM > Me too. > > It's wierd because I thought 106271-08 would fix this on Sol2.6 too... but > it doesn't. So I'm wondering if the corresponding "passwd -f doesn't > work" patch on Sol8 isn't fixing this problem on Sol8 either, but it's > something else entirely... nah... couldn't be. Must be a difference in > pam_unix.so between 2.6 and 8? > > > On Solaris 2.6 I get the same message to enter my login password, but > > after entering a new password I get the following: > > > > "Removing root credentials would break the rpc services that use secure > > rpc on this host! Root may use key logout -f to do this (at your own > > risk)!" I am then disconnected. > > I have reproduced this. The problem with the creds is a completely > separate bug that seems to occur with sshd/PAM on Solaris and is caused by > the following scenario: > > 1) pam_unix.so uses the effective uid to decide whose creds to delete (if > it's uid=0, it gives the error messages - and with openssh it's uid=0) > > 2) sshd doesn't call seteuid() to change to the user before deleting creds > > Some people have said that pam_unix.so should use PAM_USER to determine > whose creds to delete (and it's therefore a bug in PAM on Solaris)... but > others have noted that Sun has made pam_unix.so work like this from the > start. Noone who knows the PAM standard backwards and forwards has > commented to say how pam_sm_setcred(PAM_DELETE_CREDS) is SUPPOSED to > determine the user whose creds need to be deleted. > > > (Now I can duplicate this activity on Solaris 8 if I am another user on > > one host and connect via ssh to the Solaris 8 box running ssh 3.0p1 as > > the user whose password has expired (ssh -l). I presume this is > > normal..password changing for the user with an expired password only > > works if you are connecting as that user from the remote host?) > > Changing expired passwords on Sol8 works for me with the recommended > patches. But Alexander has seen the same "close the connection" problem > with expired passwords on Sol8 which he reported yesterday - he didn't > tell me yet if he has the "passwd -f doesn't work" patch installed on his > Sol8 box, tho'. I'd guess he doesn't have it yet. Has anyone tried to > reproduce this on a Sol8 box with the "passwd -f doesn't work" patch > removed - just to see if it's really fixing THIS particular problem or if > it's just coincidence that this works on Sol8 but not on Sol2.6? > > Due the the error returned by pam_sm_chauthtok (it returns -1) in > pam_unix.so , I think it's a pam_unix.so bug, but I can't be certain > without discussing Sol8 source in detail, which I'm not sure is allowed by > my source agreement. Darren, can I discuss this with you directly so I can > make direct references to the Sol8 source? Maybe you could tell me how > the patched up version of pam_unix.so source differs from Sol8 FCS (like, > whether this -1 return code thing is in one of the fixes) - that would > probably rule-in or rule-out my suspicions pretty quickly... > > Isn't Sol8 "open-source" now (maybe only in the sense that you can do what > you want with it except sell it) or was that just pipe dream...? > > > I did not do anything with /etc/pam.conf on either host..I am using the > > default that came with the system. > > That should be fine - pam_unix.so is set up to do be the default for every > service. > > > So, it appears that password aging and pam do not get along on Solaris > > 2.6 even with the latest patch? I'll take a closer look at things when I > > get in tomorrow morning. If you need further information, want debugger > > output...I am willing to compile with debugging, etc. > > I'm not sure debugging (-g) in sshd would help more than when we just run > it with LogLevel DEBUG3, making sure /etc/pam_debug exists, and putting > the debug option on the pam.conf entries from "other". The problem exists > somewhere in pam_unix.so - and it's the culprit that is return a -1 error > back to sshd (which according to the man pages, can't happen ;-). It would > be nice however to recompile pam_unix.so.1 with some extra logging stuck > in... ;-) > > Ed > > Ed Phillips University of Delaware (302) 831-6082 > Systems Programmer III, Network and Systems Services > finger -l ed at polycut.nss.udel.edu for PGP public key > > From john at care2.com Fri Nov 9 11:38:18 2001 From: john at care2.com (john at care2.com) Date: Fri, 9 Nov 2001 11:38:18 Subject: laser cartridges Message-ID: <858.585253.279512@care2.com> **** VORTEX SUPPLIES **** YOUR LASER PRINTER TONER CARTRIDGE, COPIER AND FAX CARTRIDGE CONNECTION SAVE UP TO 30% FROM RETAIL ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED) ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER NOTE: WE DO NOT CARRY 1) XEROX, BROTHER, PANASONIC, FUJITSU PRODUCTS 2) HP DESKJETJET/INK JET OR BUBBLE JET CARTRIDGES 3) CANON BUBBLE JET CARTRIDGES 4) ANY OFFBRANDS BESIDES THE ONES LISTED BELOW. OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)------------------------$44 ITEM #2 LASERJET SERIES 1100 (92A)-------------------------$44 ITEM #3 LASERJET SERIES 2 (95A)----------------------------$39 ITEM #4 LASERJET SERIES 2P (75A)---------------------------$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)---------- -$44 ITEM #6 LASERJET SERIES 5SI, 8000 (09A)--------------------$95 ITEM #7 LASERJET SERIES 2100, 2200 (96A)-------------------$74 ITEM #8 LASERJET SERIES 8100 (82X)-------------------------$115 ITEM #9 LASERJET SERIES 5L/6L (3906A)----------------------$39 ITEM #10 LASERJET SERIES 4V---------------------------------$95 ITEM #11 LASERJET SERIES 4000 (27X)--------------------------$79 ITEM #12 LASERJET SERIES 3SI/4SI (91A)-----------------------$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M-------------------------$49 ITEM #13A LASERJET SERIES 5000 (29X)-------------------------$125 ITEM #13B LASERJET SERIES 1200-------------------------------$59 ITEM #13C LASERJET SERIES 4100-------------------------------$99 ITEM #18 LASERJET SERIES 3100------------------------------$39 ITEM #19 LASERJET SERIES 4500 BLACK--------------------------$79 ITEM #20 LASERJET SERIES 4500 COLORS ------------------------$125 HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)----------$49 ITEM #15 LASERFAX 5000,7000 (FX2)--------$64 ITEM #16 LASERFAX (FX3)------------------$59 ITEM #17 LASERFAX (FX4)------------------$54 LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---------------$89 OPTRA R, 4039, 4049 HIGH YIELD-----------$105 OPTRA E310.312 HIGH YIELD----------------$79 OPTRA E-----------------------------------$59 OPTRA N----------------------------------$115 OPTRA S----------------------------------$165 OPTRA T----------------------------------$195 OPTRA E310/312---------------------------$79 EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000----------$105 ACTION LASER 1000,1500--------------------$105 CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95----------$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600------------------$49 LASER WRITER SELECT 300,320,360-----------------$74 LASER WRITER 300 AND 320------------------------$54 LASER WRITER NT, 2NT----------------------------$54 LASER WRITER 12/640-----------------------------$79 CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---------------------------$59 LASERCLASS 5000,6000,7000 (FX2)-----------------$54 LASERFAX 5000,7000 (FX2)------------------------$54 LASERFAX 8500,9000 (FX4)------------------------$54 CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)---------------------$69 PC 300,320,700,720,760,900,910,920(E-40)------$89 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY. From bugzilla-daemon at mindrot.org Sat Nov 10 04:02:23 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 10 Nov 2001 04:02:23 +1100 (EST) Subject: [Bug 12] incomplete configure checks for 64 bit int types Message-ID: <20011109170223.839D62E018@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=12 ------- Additional Comments From mooney at dogbert.cc.ndsu.nodak.edu 2001-11-10 04:02 ------- Created an attachment (id=3) add configure checks for 64 bit types in sys/bitypes.h ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From dwd at bell-labs.com Sat Nov 10 04:07:06 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Fri, 9 Nov 2001 11:07:06 -0600 Subject: [Bug 11] New: no reference to bugzilla on openssh home page Message-ID: <20011109110705.A20292@lucent.com> Bugzilla doesn't appear to send new bugs to openssh-unix-dev as Damien said he wanted it to, so I'm forwarding the message I got back. - Dave Dykstra ----- Forwarded message from bugzilla-daemon at mindrot.org ----- From: bugzilla-daemon at mindrot.org To: dwd at bell-labs.com Subject: [Bug 11] New: no reference to bugzilla on openssh home page Date: Sat, 10 Nov 2001 03:55:32 +1100 (EST) http://bugzilla.mindrot.org/show_bug.cgi?id=11 Summary: no reference to bugzilla on openssh home page Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dwd at bell-labs.com There's no reference to bugzilla.mindrot.org on www.openssh.com that I could find. It seems it would make sense to be on the "Reporting Bugs" page and/or portable.html. ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. ----- End forwarded message ----- From mouring at etoh.eviladmin.org Sat Nov 10 04:13:53 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 9 Nov 2001 11:13:53 -0600 (CST) Subject: [Bug 11] New: no reference to bugzilla on openssh home page In-Reply-To: <20011109110705.A20292@lucent.com> Message-ID: I noticed 12 went through but 11 did not.. - Ben On Fri, 9 Nov 2001, Dave Dykstra wrote: > Bugzilla doesn't appear to send new bugs to openssh-unix-dev as Damien said > he wanted it to, so I'm forwarding the message I got back. > > - Dave Dykstra > > > ----- Forwarded message from bugzilla-daemon at mindrot.org ----- > > From: bugzilla-daemon at mindrot.org > To: dwd at bell-labs.com > Subject: [Bug 11] New: no reference to bugzilla on openssh home page > Date: Sat, 10 Nov 2001 03:55:32 +1100 (EST) > > http://bugzilla.mindrot.org/show_bug.cgi?id=11 > > Summary: no reference to bugzilla on openssh home page > Product: Portable OpenSSH > Version: -current > Platform: Other > OS/Version: other > Status: NEW > Severity: normal > Priority: P2 > Component: Miscellaneous > AssignedTo: openssh-unix-dev at mindrot.org > ReportedBy: dwd at bell-labs.com > > > There's no reference to bugzilla.mindrot.org on www.openssh.com that I could > find. > It seems it would make sense to be on the "Reporting Bugs" page and/or > portable.html. > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > ----- End forwarded message ----- > From dwd at bell-labs.com Sat Nov 10 04:21:03 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Fri, 9 Nov 2001 11:21:03 -0600 Subject: [Bug 11] New: no reference to bugzilla on openssh home page In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Nov 09, 2001 at 11:13:53AM -0600 References: <20011109110705.A20292@lucent.com> Message-ID: <20011109112103.A20171@lucent.com> On Fri, Nov 09, 2001 at 11:13:53AM -0600, mouring at etoh.eviladmin.org wrote: > > I noticed 12 went through but 11 did not.. > > - Ben No, the initial announcement of 12 didn't go through; what went through was the announcement of the addition of an attachment. - Dave From dwd at bell-labs.com Sat Nov 10 04:37:02 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Fri, 9 Nov 2001 11:37:02 -0600 Subject: [Bug 13] New: Need faster ssh startup when no /dev/random or prngd available Message-ID: <20011109113702.A20449@lucent.com> ----- Forwarded message from bugzilla-daemon at mindrot.org ----- From: bugzilla-daemon at mindrot.org To: dwd at bell-labs.com Subject: [Bug 13] New: Need faster ssh startup when no /dev/random or prngd available Date: Sat, 10 Nov 2001 04:25:32 +1100 (EST) http://bugzilla.mindrot.org/show_bug.cgi?id=13 Summary: Need faster ssh startup when no /dev/random or prngd available Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: dwd at bell-labs.com On systems that don't have a fast source of entropy such as /dev/random or prngd, startup up of ssh takes a long time because it runs a lot of external programs. I have made a patch to add an option to intialize the pseudo-random number generator from a saved seed file rather than running all the external programs, which I will add as an attachment. ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. ----- End forwarded message ----- From bugzilla-daemon at mindrot.org Sat Nov 10 05:15:10 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 10 Nov 2001 05:15:10 +1100 (EST) Subject: [Bug 13] Need faster ssh startup when no /dev/random or prngd available Message-ID: <20011109181510.DC1F92DFA2@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=13 ------- Additional Comments From dwd at bell-labs.com 2001-11-10 05:15 ------- Created an attachment (id=4) added proposed patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From stevesk at pobox.com Sat Nov 10 06:43:48 2001 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 9 Nov 2001 11:43:48 -0800 (PST) Subject: Flaw in empty password authentication in sshd In-Reply-To: <01110715310400.10838@chip.aero.iisc.ernet.in> Message-ID: On Wed, 7 Nov 2001 jayaraj at amritapuri.com wrote: : >Fix: : This problem can be overcome if "pam_authenticate" is called with : "PAM_DISALLOW_NULL_AUTHTOK" flag if empty passwords are not permitted. : : A possible patch for the problem is given below: thanks. i propose the following. can some PAM experts comment on this? is this the correct way to fix this? i have tested on hp-ux 11. Index: auth-pam.c =================================================================== RCS file: /var/cvs/openssh/auth-pam.c,v retrieving revision 1.40 diff -u -r1.40 auth-pam.c --- auth-pam.c 2001/10/28 17:32:38 1.40 +++ auth-pam.c 2001/11/09 19:36:41 @@ -217,7 +217,8 @@ __pampasswd = password; pamstate = INITIAL_LOGIN; - pam_retval = do_pam_authenticate(0); + pam_retval = do_pam_authenticate( + options.permit_empty_passwd == 0 ? PAM_DISALLOW_NULL_AUTHTOK : 0); if (pam_retval == PAM_SUCCESS) { debug("PAM Password authentication accepted for " "user \"%.100s\"", pw->pw_name); From Darren.Moffat at eng.sun.com Sat Nov 10 06:57:10 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Fri, 9 Nov 2001 11:57:10 -0800 (PST) Subject: Flaw in empty password authentication in sshd Message-ID: <200111091957.fA9Jv9ei118773@jurassic.eng.sun.com> >: This problem can be overcome if "pam_authenticate" is called with >: "PAM_DISALLOW_NULL_AUTHTOK" flag if empty passwords are not permitted. >: >: A possible patch for the problem is given below: > >thanks. i propose the following. can some PAM experts comment on this? >is this the correct way to fix this? i have tested on hp-ux 11. > >Index: auth-pam.c >=================================================================== >RCS file: /var/cvs/openssh/auth-pam.c,v >retrieving revision 1.40 >diff -u -r1.40 auth-pam.c >--- auth-pam.c 2001/10/28 17:32:38 1.40 >+++ auth-pam.c 2001/11/09 19:36:41 >@@ -217,7 +217,8 @@ > __pampasswd = password; > > pamstate = INITIAL_LOGIN; >- pam_retval = do_pam_authenticate(0); >+ pam_retval = do_pam_authenticate( >+ options.permit_empty_passwd == 0 ? PAM_DISALLOW_NULL_AUTHTOK : 0); > if (pam_retval == PAM_SUCCESS) { > debug("PAM Password authentication accepted for " > "user \"%.100s\"", pw->pw_name); That is the correct thing to do. -- Darren J Moffat From florin at sgi.com Sat Nov 10 07:27:29 2001 From: florin at sgi.com (Florin Andrei) Date: 09 Nov 2001 12:27:29 -0800 Subject: keystroke timing attack Message-ID: <1005337649.13269.32.camel@stantz.corp.sgi.com> I'm reading this fine article on O'Reilly: http://linux.oreillynet.com/lpt/a//linux/2001/11/08/ssh_keystroke.html The paper concludes that the keystroke timing data observable from today's SSH implementations reveals a dangerously significant amount of information about user terminal sessions--enough to locate typed passwords in the session data stream and reduce the computational work involved in guessing those passwords by a factor of 50. Maybe i'm missing something, but isn't enough to not send passwords char-by-char over the network, and just wait for Enter and then send the whole lot? -- Florin Andrei "Thomas Jefferson would love Napster" (a MSNBC reporter) From bugzilla-daemon at mindrot.org Sat Nov 10 08:17:18 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sat, 10 Nov 2001 08:17:18 +1100 (EST) Subject: [Bug 14] Can't change expired /etc/shadow password without PAM Message-ID: <20011109211718.28C232E032@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=14 ------- Additional Comments From dwd at bell-labs.com 2001-11-10 08:17 ------- Created an attachment (id=5) add suggested patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From gert at greenie.muc.de Sat Nov 10 10:23:18 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 10 Nov 2001 00:23:18 +0100 Subject: socklen_t - where? Message-ID: <20011110002318.A27290@greenie.muc.de> Hi, openssh_cvs as of today, SCO Open Server 3.0, socklen_t this typedef doesn't exist on SCO OSR 3, and "configure" properly detects this, leading to /* #undef HAVE_SOCKLEN_T */ in config.h. Problem: I can't find any place where this is actually being used? I'd expect something like #ifndef HAVE_SOCKLEN_T typdef int socklen_t; #endif ("int" is what the relevant functions use here, checked vs. the man pages) - but there isn't anything. Which would be the "right" header file to add such things? Then I'll just do it and send in a patch with all the necessary changes for SCO OSR 3... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From gert at greenie.muc.de Sat Nov 10 10:24:33 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 10 Nov 2001 00:24:33 +0100 Subject: keystroke timing attack In-Reply-To: <1005337649.13269.32.camel@stantz.corp.sgi.com>; from Florin Andrei on Fri, Nov 09, 2001 at 12:27:29PM -0800 References: <1005337649.13269.32.camel@stantz.corp.sgi.com> Message-ID: <20011110002433.B27290@greenie.muc.de> Hi, On Fri, Nov 09, 2001 at 12:27:29PM -0800, Florin Andrei wrote: > Maybe i'm missing something, but isn't enough to not send passwords > char-by-char over the network, and just wait for Enter and then send the > whole lot? How do you know that something the user types is a password (and not "input to your favourite editor" or such)? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From florin at sgi.com Sat Nov 10 10:49:56 2001 From: florin at sgi.com (Florin Andrei) Date: 09 Nov 2001 15:49:56 -0800 Subject: keystroke timing attack In-Reply-To: <20011110002433.B27290@greenie.muc.de> References: <1005337649.13269.32.camel@stantz.corp.sgi.com> <20011110002433.B27290@greenie.muc.de> Message-ID: <1005349796.13269.49.camel@stantz.corp.sgi.com> On Fri, 2001-11-09 at 15:24, Gert Doering wrote: > > On Fri, Nov 09, 2001 at 12:27:29PM -0800, Florin Andrei wrote: > > Maybe i'm missing something, but isn't enough to not send passwords > > char-by-char over the network, and just wait for Enter and then send the > > whole lot? > > How do you know that something the user types is a password (and not > "input to your favourite editor" or such)? (walking on thin ice...) Well, when you authenticate by using user/pass, this is what you type: somecharacters someothercharacters nowtherealsessionstarts I'm not sure if the ssh client can distinguish between password-authenticated sessions and other sessions, but if it does, then send everything between the first and the second in one chunk. You don't need local echo anyway for those characters, so... -- Florin Andrei "Thomas Jefferson would love Napster" (a MSNBC reporter) From tim at multitalents.net Sat Nov 10 10:54:43 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 9 Nov 2001 15:54:43 -0800 (PST) Subject: socklen_t - where? In-Reply-To: <20011110002318.A27290@greenie.muc.de> Message-ID: On Sat, 10 Nov 2001, Gert Doering wrote: > Hi, > > openssh_cvs as of today, SCO Open Server 3.0, socklen_t > > this typedef doesn't exist on SCO OSR 3, and "configure" properly detects > this, leading to > > /* #undef HAVE_SOCKLEN_T */ Run autoreconf instead of just autoconf to tune up config.h.in > > in config.h. > > Problem: I can't find any place where this is actually being used? I'd > expect something like > > #ifndef HAVE_SOCKLEN_T > typdef int socklen_t; > #endif You will see /* type to use in place of socklen_t if not defined */ #define socklen_t int in config.h after running configure. > ("int" is what the relevant functions use here, checked vs. the man pages) > - but there isn't anything. > > Which would be the "right" header file to add such things? Then I'll just > do it and send in a patch with all the necessary changes for SCO OSR 3... SCO OSR 3 works fine here on the CVS code. > > gert > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Sat Nov 10 16:33:01 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 9 Nov 2001 23:33:01 -0600 (CST) Subject: keystroke timing attack In-Reply-To: <1005349796.13269.49.camel@stantz.corp.sgi.com> Message-ID: That is the point if you can cleanly and simply implement that I'm sure a lot of people would be happy, but one can not randomly pick what to send right away and what can wait for an enter. SSL encrypted telnet would have the same problem. I think technically any interactive VPN or IPSec session could have the same problem if I've read all the white papers rights. - Ben On 9 Nov 2001, Florin Andrei wrote: > On Fri, 2001-11-09 at 15:24, Gert Doering wrote: > > > > On Fri, Nov 09, 2001 at 12:27:29PM -0800, Florin Andrei wrote: > > > Maybe i'm missing something, but isn't enough to not send passwords > > > char-by-char over the network, and just wait for Enter and then send the > > > whole lot? > > > > How do you know that something the user types is a password (and not > > "input to your favourite editor" or such)? > > (walking on thin ice...) > > Well, when you authenticate by using user/pass, this is what you type: > > somecharacters > someothercharacters > nowtherealsessionstarts > > I'm not sure if the ssh client can distinguish between > password-authenticated sessions and other sessions, but if it does, then > send everything between the first and the second in one chunk. > You don't need local echo anyway for those characters, so... > > -- > Florin Andrei > > "Thomas Jefferson would love Napster" (a MSNBC reporter) > > From Denis.Ducamp at hsc.fr Sat Nov 10 20:49:12 2001 From: Denis.Ducamp at hsc.fr (Denis Ducamp) Date: Sat, 10 Nov 2001 10:49:12 +0100 Subject: keystroke timing attack In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Nov 09, 2001 at 11:33:01PM -0600 References: <1005349796.13269.49.camel@stantz.corp.sgi.com> Message-ID: <20011110104912.A94003@hsc.fr> On Fri, Nov 09, 2001 at 11:33:01PM -0600, mouring at etoh.eviladmin.org wrote: > > That is the point if you can cleanly and simply implement that I'm sure a > lot of people would be happy, but one can not randomly pick what to > send right away and what can wait for an enter. > > SSL encrypted telnet would have the same problem. I think technically any > interactive VPN or IPSec session could have the same problem if I've read > all the white papers rights. Yes, telnet in ssl is vulnerable to such a passive analyse. With a recent openssh, exact password lengths aren't guessable; but passwords typed in the ssh session, ie after ssh authentication, are detectable because there isn't any echo returned by the server to the client. For more informations on SSH passive analyse, look at 3rd openwall's advisory at http://www.openwall.com/advisories/ and use the sshow utility in that advisory or in dsniff 2.4-beta1 to see how it works very well. You may do the same with telnet sessions in ssl (per exemple with stunnel) by using ssldump from http://www.rtfm.com/ssldump/ to see lenghts of ssl data travelling between client and server. Denis Ducamp. From markus at openbsd.org Sat Nov 10 23:39:07 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 10 Nov 2001 13:39:07 +0100 Subject: openssh-3.0p1, auth2.c In-Reply-To: <200111090923.KAA04951@marc.physik3.gwdg.de>; from strube@physik3.gwdg.de on Fri, Nov 09, 2001 at 10:23:40AM +0100 References: <200111090923.KAA04951@marc.physik3.gwdg.de> Message-ID: <20011110133907.C27104@folly> On Fri, Nov 09, 2001 at 10:23:40AM +0100, Hans Werner Strube wrote: > openssh-3.0p1 still contains the bug is it a bug? we need to use voting to bugzilla. > which I already reported on Sept. 28 2001 > for 2.9p2, namely, the trailing dot in chost should be stripped before calling > auth_rhosts2() even with option "HostbasedUsesNameFromPacketOnly yes". > Otherwise, the host names in /etc/hosts.equiv and .rhosts would have to be > dot-terminated. Fix: Move lines 776-779 of auth2.c upwards to after line 767. > (These line numbers also hold for 2.9.9p2.) 1) HostbasedUsesNameFromPacketOnly is experimental and undocumented 2) if HostbasedUsesNameFromPacketOnly is used, then the client can send any opaque 'string' it likes to use, e.g. "markus at openssh.com." or even "...." so sshd should not modify this string. why are you using HostbasedUsesNameFromPacketOnly ? -m From gert at greenie.muc.de Sat Nov 10 23:47:35 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 10 Nov 2001 13:47:35 +0100 Subject: socklen_t - where? In-Reply-To: ; from Tim Rice on Fri, Nov 09, 2001 at 03:54:43PM -0800 References: <20011110002318.A27290@greenie.muc.de> Message-ID: <20011110134735.A16567@greenie.muc.de> Hi, On Fri, Nov 09, 2001 at 03:54:43PM -0800, Tim Rice wrote: > > openssh_cvs as of today, SCO Open Server 3.0, socklen_t > > > > this typedef doesn't exist on SCO OSR 3, and "configure" properly detects > > this, leading to > > > > /* #undef HAVE_SOCKLEN_T */ > > Run autoreconf instead of just autoconf to tune up config.h.in I did "make -f Makefile.in distprep" - which should run autoreconf. I don't think config.h is the problem here - it *has* HAVE_SOCKLEN_T (that is: it properly #undef's it, as SCO 3 doesn't have it). But nobody else has an #ifndef HAVE_SOCKLEN_T - which should not be auto(re)conf related, or is it?. [..] > You will see > /* type to use in place of socklen_t if not defined */ > #define socklen_t int > in config.h after running configure. OK, retry... - autoreconf (no messages, no errors) - configure (no problems) - no socklen_t in config.h Hmmm, I think it's an autoconf problem - while it doesn't throw any warnings or errors, I still use autoconf 2.13 and remember that there have been some problems with it. Shouldn't autoreconf print some warning if the autoconf version is too old? [..] > > Which would be the "right" header file to add such things? Then I'll just > > do it and send in a patch with all the necessary changes for SCO OSR 3... > SCO OSR 3 works fine here on the CVS code. It works fine, if I add the typdef (or define) manually. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From markus at openbsd.org Sat Nov 10 23:47:19 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 10 Nov 2001 13:47:19 +0100 Subject: OpenSSH 2.3 In-Reply-To: ; from michael.mai@db.com on Fri, Nov 09, 2001 at 03:30:09PM +0100 References: Message-ID: <20011110134718.D27104@folly> On Fri, Nov 09, 2001 at 03:30:09PM +0100, Michael Mai wrote: > Am I right to assume that g is part of the counterpart's sent public key, and if it does not match the remainder of the public key, > the message "signature incorrect" may appear ?? the DSA/DSS pub key consists of (p,q,g,pub_key) and all numbers need to match. make sure that the sig->s and sig->r match after dsa_sign and before dsa_verify on both client and server. same for (p,q,g,pub_key) on both machines. From gert at greenie.muc.de Sat Nov 10 23:50:28 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 10 Nov 2001 13:50:28 +0100 Subject: keystroke timing attack In-Reply-To: <1005349796.13269.49.camel@stantz.corp.sgi.com>; from Florin Andrei on Fri, Nov 09, 2001 at 03:49:56PM -0800 References: <1005337649.13269.32.camel@stantz.corp.sgi.com> <20011110002433.B27290@greenie.muc.de> <1005349796.13269.49.camel@stantz.corp.sgi.com> Message-ID: <20011110135028.B16567@greenie.muc.de> Hi, On Fri, Nov 09, 2001 at 03:49:56PM -0800, Florin Andrei wrote: > > How do you know that something the user types is a password (and not > > "input to your favourite editor" or such)? > > (walking on thin ice...) > > Well, when you authenticate by using user/pass, this is what you type: > > somecharacters > someothercharacters > nowtherealsessionstarts Those are not the passwords the timing attacks talk about (they are sent in a whole packet anyway). If you enter passwords later on, you have these. > I'm not sure if the ssh client can distinguish between > password-authenticated sessions and other sessions, but if it does, then > send everything between the first and the second in one chunk. The "initial connect password" is done that way. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From markus at openbsd.org Sun Nov 11 00:01:45 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 10 Nov 2001 14:01:45 +0100 Subject: keystroke timing attack In-Reply-To: <20011110104912.A94003@hsc.fr>; from Denis.Ducamp@hsc.fr on Sat, Nov 10, 2001 at 10:49:12AM +0100 References: <1005349796.13269.49.camel@stantz.corp.sgi.com> <20011110104912.A94003@hsc.fr> Message-ID: <20011110140145.E27104@folly> On Sat, Nov 10, 2001 at 10:49:12AM +0100, Denis Ducamp wrote: > With a recent openssh, exact password lengths aren't guessable; but > passwords typed in the ssh session, ie after ssh authentication, are > detectable because there isn't any echo returned by the server to the > client. note that recent openssh servers trie to send back fake echo packets and defeat the SU-signature. -m From markus at openbsd.org Sun Nov 11 00:10:47 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 10 Nov 2001 14:10:47 +0100 Subject: keystroke timing attack Message-ID: <20011110141047.A3059@folly> this is what post-3.0 openssh does we now pad the password packet (instead of adding an ignore message). Index: packet.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/packet.c,v retrieving revision 1.70 diff -u -r1.70 packet.c --- packet.c 27 Sep 2001 11:59:37 -0000 1.70 +++ packet.c 7 Nov 2001 15:59:58 -0000 @@ -115,6 +115,9 @@ /* Session key information for Encryption and MAC */ Newkeys *newkeys[MODE_MAX]; +/* roundup current message to extra_pad bytes */ +static u_char extra_pad = 0; + /* * Sets the descriptors used for communication. Disables encryption until * packet_set_encryption_key is called. @@ -485,9 +488,10 @@ { static u_int32_t seqnr = 0; u_char type, *ucp, *macbuf = NULL; + u_char padlen, pad; char *cp; u_int packet_length = 0; - u_int i, padlen, len; + u_int i, len; u_int32_t rand = 0; Enc *enc = NULL; Mac *mac = NULL; @@ -533,6 +537,15 @@ padlen = block_size - (len % block_size); if (padlen < 4) padlen += block_size; + if (extra_pad) { + /* will wrap if extra_pad+padlen > 255 */ + extra_pad = roundup(extra_pad, block_size); + pad = extra_pad - ((len + padlen) % extra_pad); + debug("packet_send2: adding %d (len %d padlen %d extra_pad %d)", + pad, len, padlen, extra_pad); + padlen += pad; + extra_pad = 0; + } buffer_append_space(&outgoing_packet, &cp, padlen); if (enc && enc->cipher->number != SSH_CIPHER_NONE) { /* random padding */ @@ -1109,6 +1122,7 @@ else fatal("Write failed: %.100s", strerror(errno)); } +debug("packet_write_poll: sent %d bytes", len); buffer_consume(&output, len); } } @@ -1232,6 +1246,13 @@ return s; } +/* roundup current message to pad bytes */ +void +packet_add_padding(u_char pad) +{ + extra_pad = pad; +} + /* * 9.2. Ignored Data Message * @@ -1243,41 +1264,6 @@ * required to send them. This message can be used as an additional * protection measure against advanced traffic analysis techniques. */ -/* size of current + ignore message should be n*sumlen bytes (w/o mac) */ -void -packet_inject_ignore(int sumlen) -{ - int blocksize, padlen, have, need, nb, mini, nbytes; - Enc *enc = NULL; - - if (compat20 == 0) - return; - - have = buffer_len(&outgoing_packet); - debug2("packet_inject_ignore: current %d", have); - if (newkeys[MODE_OUT] != NULL) - enc = &newkeys[MODE_OUT]->enc; - blocksize = enc ? enc->cipher->block_size : 8; - padlen = blocksize - (have % blocksize); - if (padlen < 4) - padlen += blocksize; - have += padlen; - have /= blocksize; /* # of blocks for current message */ - - nb = roundup(sumlen, blocksize) / blocksize; /* blocks for both */ - mini = roundup(5+1+4+4, blocksize) / blocksize; /* minsize ignore msg */ - need = nb - (have % nb); /* blocks for ignore */ - if (need <= mini) - need += nb; - nbytes = (need - mini) * blocksize; /* size of ignore payload */ - debug2("packet_inject_ignore: block %d have %d nb %d mini %d need %d", - blocksize, have, nb, mini, need); - - /* enqueue current message and append a ignore message */ - packet_send(); - packet_send_ignore(nbytes); -} - void packet_send_ignore(int nbytes) { Index: packet.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/packet.h,v retrieving revision 1.25 diff -u -r1.25 packet.h --- packet.h 26 Jun 2001 17:27:24 -0000 1.25 +++ packet.h 7 Nov 2001 15:59:58 -0000 @@ -63,7 +63,7 @@ int packet_connection_is_ipv4(void); int packet_remaining(void); void packet_send_ignore(int); -void packet_inject_ignore(int); +void packet_add_padding(u_char); void tty_make_modes(int, struct termios *); void tty_parse_modes(int, int *); Index: sshconnect2.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect2.c,v retrieving revision 1.84 diff -u -r1.84 sshconnect2.c --- sshconnect2.c 29 Oct 2001 19:27:15 -0000 1.84 +++ sshconnect2.c 7 Nov 2001 16:00:03 -0000 @@ -460,7 +460,7 @@ packet_put_cstring(password); memset(password, 0, strlen(password)); xfree(password); - packet_inject_ignore(64); + packet_add_padding(64); packet_send(); return 1; } @@ -817,7 +817,7 @@ } packet_done(); /* done with parsing incoming message. */ - packet_inject_ignore(64); + packet_add_padding(64); packet_send(); } From tim at multitalents.net Sun Nov 11 03:42:34 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 10 Nov 2001 08:42:34 -0800 (PST) Subject: socklen_t - where? In-Reply-To: <20011110134735.A16567@greenie.muc.de> Message-ID: On Sat, 10 Nov 2001, Gert Doering wrote: > Hi, > > On Fri, Nov 09, 2001 at 03:54:43PM -0800, Tim Rice wrote: > > > openssh_cvs as of today, SCO Open Server 3.0, socklen_t > > > > > > this typedef doesn't exist on SCO OSR 3, and "configure" properly detects > > > this, leading to > > > > > > /* #undef HAVE_SOCKLEN_T */ > > > > Run autoreconf instead of just autoconf to tune up config.h.in > > I did "make -f Makefile.in distprep" - which should run autoreconf. > > I don't think config.h is the problem here - it *has* HAVE_SOCKLEN_T (that > is: it properly #undef's it, as SCO 3 doesn't have it). But nobody else > has an #ifndef HAVE_SOCKLEN_T - which should not be auto(re)conf related, > or is it?. > > [..] > > You will see > > /* type to use in place of socklen_t if not defined */ > > #define socklen_t int > > in config.h after running configure. > > OK, retry... > > - autoreconf (no messages, no errors) > - configure (no problems) > - no socklen_t in config.h > > Hmmm, I think it's an autoconf problem - while it doesn't throw any > warnings or errors, I still use autoconf 2.13 and remember that there have > been some problems with it. > > Shouldn't autoreconf print some warning if the autoconf version is too > old? Autoconf 2.13 should have failed. CVS code now requires autoconf 2.5x Do you have an old configure.in in your tree? If so remove it. configure.in is now configure.ac Grab autoconf 2.52 and apply the attached patch to it. > > [..] > > > Which would be the "right" header file to add such things? Then I'll just > > > do it and send in a patch with all the necessary changes for SCO OSR 3... > > SCO OSR 3 works fine here on the CVS code. > > It works fine, if I add the typdef (or define) manually. > > gert > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net -------------- next part -------------- --- autoconf-2.52/acgeneral.m4.orig Wed Jul 4 08:05:43 2001 +++ autoconf-2.52/acgeneral.m4 Wed Oct 3 18:59:02 2001 @@ -4145,7 +4145,7 @@ s,[\\$`],\\&,g t clear : clear -s,^[ ]*#[ ]*define[ ][ ]*\(\([^ (][^ (]*\)([^)]*)\)[ ]*\(.*\)$,${ac_dA}\2${ac_dB}\1${ac_dC}\3${ac_dD},gp +s,^[ ]*#[ ]*define[ ][ ]*\([^ (][^ (]*\)\(([^)]*)\)[ ]*\(.*\)$,${ac_dA}\1${ac_dB}\1\2${ac_dC}\3${ac_dD},gp t end s,^[ ]*#[ ]*define[ ][ ]*\([^ ][^ ]*\)[ ]*\(.*\)$,${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD},gp : end] From bugzilla-daemon at mindrot.org Sun Nov 11 04:50:14 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 11 Nov 2001 04:50:14 +1100 (EST) Subject: [Bug 11] no reference to bugzilla on openssh home page Message-ID: <20011110175014.0F9232DF60@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=11 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From stevesk at pobox.com 2001-11-11 04:50 ------- report.html updated ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From carson at taltos.org Sun Nov 11 07:08:38 2001 From: carson at taltos.org (Carson Gaspar) Date: Sat, 10 Nov 2001 15:08:38 -0500 Subject: openssh-3.0p1, auth2.c In-Reply-To: <20011110133907.C27104@folly> References: <20011110133907.C27104@folly> Message-ID: <223666936.1005404918@[192.168.123.111]> --On Saturday, November 10, 2001 1:39 PM +0100 Markus Friedl wrote: > On Fri, Nov 09, 2001 at 10:23:40AM +0100, Hans Werner Strube wrote: >> openssh-3.0p1 still contains the bug > > is it a bug? we need to use voting to bugzilla. It's a bug. Where the bug is is debatable. > 2) if HostbasedUsesNameFromPacketOnly is used, then > the client can send any opaque 'string' it likes to use, e.g. > "markus at openssh.com." > or even > "...." > so sshd should not modify this string. In that case, the bug is in ssh. Ssh should not send hostnames that are period terminated. > why are you using HostbasedUsesNameFromPacketOnly ? It works in spite of PAT, or any other address mangling (non-transparent application proxy firewalls, for example). This is a key feature for many environments. Now if only there were a similar feature for identifying the server... -- Carson From markus at openbsd.org Sun Nov 11 22:55:53 2001 From: markus at openbsd.org (Markus Friedl) Date: Sun, 11 Nov 2001 12:55:53 +0100 Subject: openssh-3.0p1, auth2.c In-Reply-To: <223666936.1005404918@[192.168.123.111]>; from carson@taltos.org on Sat, Nov 10, 2001 at 03:08:38PM -0500 References: <20011110133907.C27104@folly> <223666936.1005404918@[192.168.123.111]> Message-ID: <20011111125553.A15074@folly> On Sat, Nov 10, 2001 at 03:08:38PM -0500, Carson Gaspar wrote: > > > --On Saturday, November 10, 2001 1:39 PM +0100 Markus Friedl > wrote: > > > On Fri, Nov 09, 2001 at 10:23:40AM +0100, Hans Werner Strube wrote: > >> openssh-3.0p1 still contains the bug > > > > is it a bug? we need to use voting to bugzilla. > > It's a bug. Where the bug is is debatable. so i'll remove HostbasedUsesNameFromPacketOnly. > > 2) if HostbasedUsesNameFromPacketOnly is used, then > > the client can send any opaque 'string' it likes to use, e.g. > > "markus at openssh.com." > > or even > > "...." > > so sshd should not modify this string. > > In that case, the bug is in ssh. Ssh should not send hostnames that are > period terminated. it should. otherwise interoperating with ssh.com is not possible. > > why are you using HostbasedUsesNameFromPacketOnly ? > > It works in spite of PAT, or any other address mangling (non-transparent > application proxy firewalls, for example). This is a key feature for many > environments. i think hostbased authentication never has been intended for this. especially since rhosts-rsa requires a privileged source port. > Now if only there were a similar feature for identifying the server... hostkeyalias. -m From mats.andersson at appgate.com Sun Nov 11 11:26:25 2001 From: mats.andersson at appgate.com (Andersson, Mats) Date: Sun, 11 Nov 2001 01:26:25 +0100 (CET) Subject: keystroke timing attack In-Reply-To: <20011110140145.E27104@folly> Message-ID: Hi, On Sat, 10 Nov 2001, Markus Friedl wrote: > On Sat, Nov 10, 2001 at 10:49:12AM +0100, Denis Ducamp wrote: > > passwords typed in the ssh session, ie after ssh authentication, are > > detectable because there isn't any echo returned by the server to the > > client. > > note that recent openssh servers trie to send back fake echo packets > and defeat the SU-signature. The next release of MindTerm (an ssh1/ssh2 implementation in java found at www.appgate.com/mindterm) contains a client-side "countermeasure" against this timing attack aswell. It starts sending IGNORE messages, at pseudo-random short intervals, of same size as a channel-data packet containing a keystroke when one start typing and then keeps on sending these packets up to 2 seconds after last keypress, completely hiding the inter-keystroke timings. Cheers, /Mats From markus at openbsd.org Mon Nov 12 00:12:44 2001 From: markus at openbsd.org (Markus Friedl) Date: Sun, 11 Nov 2001 14:12:44 +0100 Subject: keystroke timing attack In-Reply-To: ; from mats.andersson@appgate.com on Sun, Nov 11, 2001 at 01:26:25AM +0100 References: <20011110140145.E27104@folly> Message-ID: <20011111141244.A20820@faui02.informatik.uni-erlangen.de> On Sun, Nov 11, 2001 at 01:26:25AM +0100, Andersson, Mats wrote: > > Hi, > > On Sat, 10 Nov 2001, Markus Friedl wrote: > > On Sat, Nov 10, 2001 at 10:49:12AM +0100, Denis Ducamp wrote: > > > passwords typed in the ssh session, ie after ssh authentication, are > > > detectable because there isn't any echo returned by the server to the > > > client. > > > > note that recent openssh servers trie to send back fake echo packets > > and defeat the SU-signature. > > The next release of MindTerm (an ssh1/ssh2 implementation in java found at > www.appgate.com/mindterm) contains a client-side "countermeasure" against > this timing attack aswell. It starts sending IGNORE messages, at > pseudo-random short intervals, of same size as a channel-data packet > containing a keystroke when one start typing and then keeps on sending > these packets up to 2 seconds after last keypress, completely hiding the > inter-keystroke timings. but since the server won't send an 'echo' ignore message to the client's ignore message, it's now possible to figure out the SU-signature again! moreover i don't think random intervalls help, i think you need 'fixed' intervalls. if you have random intervals, you can probably strip the random noise if you have enough samples. -m From bugzilla-daemon at mindrot.org Mon Nov 12 00:57:10 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 12 Nov 2001 00:57:10 +1100 (EST) Subject: [Bug 15] make error: ./libssh.a: unknown file type Message-ID: <20011111135710.61DC82DF47@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=15 amihai at technion.ac.il changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|make error: ./libssh.a: |make error: ./libssh.a: |unknown file type |unknown file type ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mdb at juniper.net Mon Nov 12 03:31:17 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Sun, 11 Nov 2001 08:31:17 -0800 Subject: [PATCH] do not invoke sub-make unless the 'cd directory' succeeds Message-ID: <200111111631.fABGVH024207@merlot.juniper.net> If for some reason (directory missing or permissions bad), it is not possible to cd into either the scards or openbsd-compat direcotries, the make will enter an infinite loop. Correct this by changing the make idiom (cd directory; $(MAKE)) to the idiom (cd directory && $(MAKE)) so that a failure to cd into directory will generate an error for make. The following patch is against the latest CVS sources. Enjoy! -- Mark -------------- next part -------------- Index: Makefile.in =================================================================== RCS file: /cvs/openssh_cvs/Makefile.in,v retrieving revision 1.189 diff -u -p -r1.189 Makefile.in --- Makefile.in 2001/10/22 00:53:59 1.189 +++ Makefile.in 2001/11/11 16:22:01 @@ -87,7 +87,7 @@ $(SSHDOBJS): config.h LIBCOMPAT=openbsd-compat/libopenbsd-compat.a $(LIBCOMPAT): always - (cd openbsd-compat; $(MAKE)) + (cd openbsd-compat && $(MAKE)) always: libssh.a: $(LIBSSH_OBJS) @@ -144,23 +144,23 @@ $(CONFIGFILES): $(CONFIGFILES_IN) clean: rm -f *.o *.a $(TARGETS) logintest config.cache config.log rm -f *.out core - (cd openbsd-compat; $(MAKE) clean) + (cd openbsd-compat && $(MAKE) clean) distclean: rm -f *.o *.a $(TARGETS) logintest config.cache config.log rm -f *.out core rm -f Makefile config.h config.status ssh_prng_cmds *~ rm -rf autom4te.cache - (cd openbsd-compat; $(MAKE) distclean) - (cd scard; $(MAKE) distclean) + (cd openbsd-compat && $(MAKE) distclean) + (cd scard && $(MAKE) distclean) veryclean: rm -f configure config.h.in *.0 rm -f *.o *.a $(TARGETS) logintest config.cache config.log rm -f *.out core rm -f Makefile config.h config.status ssh_prng_cmds *~ - (cd openbsd-compat; $(MAKE) distclean) - (cd scard; $(MAKE) distclean) + (cd openbsd-compat && $(MAKE) distclean) + (cd scard && $(MAKE) distclean) mrproper: distclean @@ -174,13 +174,13 @@ catman-do: distprep: catman-do autoreconf - (cd scard ; $(MAKE) -f Makefile.in distprep) + (cd scard && $(MAKE) -f Makefile.in distprep) install: $(CONFIGFILES) $(MANPAGES) $(TARGETS) install-files host-key install-nokeys: $(CONFIGFILES) $(MANPAGES) $(TARGETS) install-files scard-install: - (cd scard; $(MAKE) DESTDIR=$(DESTDIR) install) + (cd scard && $(MAKE) DESTDIR=$(DESTDIR) install) install-files: scard-install $(srcdir)/mkinstalldirs $(DESTDIR)$(bindir) From usura at zedz.net Mon Nov 12 08:16:59 2001 From: usura at zedz.net (Alex de Joode) Date: Sun, 11 Nov 2001 22:16:59 +0100 (CET) Subject: OpenBSD 2.6 & OpenSSH 3.0p1 Message-ID: <20011111211659.499BE1778C@mail.zedz.net> Hi, I've compiled openssh 3.0p1 (portable) on an openbsd 2.6 machine, compile goes fine however the sshd deamon will not start: > [usura at outpost]:/tmp/openssh-3.0p1 {28}$ ./sshd -p 3333 > bad addr or host: 0.0.0.0 (name or service is not known) > > [usura at outpost]:/tmp/openssh-3.0p1 {29}$ ./sshd -4 -p 3333 > bad addr or host: 0.0.0.0 (name or service is not known) > > [usura at outpost]:/tmp/openssh-3.0p1 {47}$ ./sshd -f ./sshd_config -4 > bad addr or host: 194.109.206.210 (name or service is not known) > > Port 3333 > #Protocol 2,1 > ListenAddress 194.109.206.210 > #ListenAddress :: Any ideas on how to fix this ? -aj From vinschen at redhat.com Mon Nov 12 09:13:46 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 11 Nov 2001 23:13:46 +0100 Subject: [PATCH]: Change contrib/cygwin/ssh-host-config Message-ID: <20011111231346.D1881@cygbert.vinschen.de> Hi, the following patch to contrib/cygwin/ssh-host-config creates /etc/ssh_config and /etc/sshd_config according to the current default config files. Could somebody please check it in? Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-host-config,v retrieving revision 1.3 diff -u -p -r1.3 ssh-host-config --- contrib/cygwin/ssh-host-config 2001/07/18 16:25:42 1.3 +++ contrib/cygwin/ssh-host-config 2001/11/11 17:06:47 @@ -98,7 +98,7 @@ then echo echo "There are still ssh processes running. Please shut them down first." echo - exit 1 + #exit 1 fi # Check for ${SYSCONFDIR} directory @@ -234,9 +234,9 @@ then # Site-wide defaults for various options # Host * -# ForwardAgent yes -# ForwardX11 yes -# RhostsAuthentication yes +# ForwardAgent no +# ForwardX11 no +# RhostsAuthentication no # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes @@ -244,22 +244,14 @@ then # UseRsh no # BatchMode no # CheckHostIP yes -# StrictHostKeyChecking no +# StrictHostKeyChecking yes +# IdentityFile ~/.ssh/identity +# IdentityFile ~/.ssh/id_dsa +# IdentityFile ~/.ssh/id_rsa # Port 22 # Protocol 2,1 -# Cipher 3des +# Cipher blowfish # EscapeChar ~ - -# Be paranoid by default -Host * - ForwardAgent no - ForwardX11 no - FallBackToRsh no - -# Try authentification with the following identities - IdentityFile ~/.ssh/identity - IdentityFile ~/.ssh/id_rsa - IdentityFile ~/.ssh/id_dsa EOF if [ "$port_number" != "22" ] then @@ -288,60 +280,69 @@ if [ ! -f "${SYSCONFDIR}/sshd_config" ] then echo "Generating ${SYSCONFDIR}/sshd_config file" cat > ${SYSCONFDIR}/sshd_config << EOF -# This is ssh server systemwide configuration file. +# This is the sshd server system-wide configuration file. See sshd(8) +# for more information. Port $port_number -# -Protocol 2,1 -ListenAddress 0.0.0.0 +#Protocol 2,1 +#ListenAddress 0.0.0.0 #ListenAddress :: -# -# Uncomment the following lines according to the used authentication + +# HostKey for protocol version 1 HostKey /etc/ssh_host_key +# HostKeys for protocol version 2 HostKey /etc/ssh_host_rsa_key HostKey /etc/ssh_host_dsa_key + +# Lifetime and size of ephemeral version 1 server ke +KeyRegenerationInterval 3600 ServerKeyBits 768 + +# Logging +SyslogFacility AUTH +LogLevel INFO +#obsoletes QuietMode and FascistLogging + +# Authentication: + LoginGraceTime 600 -KeyRegenerationInterval 3600 PermitRootLogin yes -# -# Don't read ~/.rhosts and ~/.shosts files -IgnoreRhosts yes -# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication -#IgnoreUserKnownHosts yes - -# # The following setting overrides permission checks on host key files # and directories. For security reasons set this to "yes" when running # NT/W2K, NTFS and CYGWIN=ntsec. StrictModes no -X11Forwarding no -X11DisplayOffset 10 -PrintMotd yes -KeepAlive yes - -# Logging -SyslogFacility AUTH -LogLevel INFO -#obsoletes QuietMode and FascistLogging +RSAAuthentication yes +PubkeyAuthentication yes +#AuthorizedKeysFile %h/.ssh/authorized_keys +# rhosts authentication should not be used RhostsAuthentication no -# +# Don't read ~/.rhosts and ~/.shosts files +IgnoreRhosts yes # For this to work you will also need host keys in /etc/ssh_known_hosts RhostsRSAAuthentication no - -RSAAuthentication yes +# similar for protocol version 2 +HostbasedAuthentication no +# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication +#IgnoreUserKnownHosts yes +# To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes PermitEmptyPasswords no -CheckMail no -UseLogin no +X11Forwarding no +X11DisplayOffset 10 +PrintMotd yes +#PrintLastLog no +KeepAlive yes +#UseLogin no -#Uncomment if you want to enable sftp -#Subsystem sftp /usr/sbin/sftp-server #MaxStartups 10:30:60 +#Banner /etc/issue.net +#ReverseMappingCheck yes + +Subsystem sftp /usr/sbin/sftp-server EOF fi -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From djm at mindrot.org Mon Nov 12 10:34:40 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Nov 2001 10:34:40 +1100 (EST) Subject: [PATCH] do not invoke sub-make unless the 'cd directory' succeeds In-Reply-To: <200111111631.fABGVH024207@merlot.juniper.net> Message-ID: On Sun, 11 Nov 2001, Mark D. Baushke wrote: > If for some reason (directory missing or permissions bad), it is > not possible to cd into either the scards or openbsd-compat direcotries, the > make will enter an infinite loop. Correct this by changing the make idiom > > (cd directory; $(MAKE)) > > to the idiom > > (cd directory && $(MAKE)) Applied - thanks. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Mon Nov 12 10:35:14 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Nov 2001 10:35:14 +1100 (EST) Subject: OpenBSD 2.6 & OpenSSH 3.0p1 In-Reply-To: <20011111211659.499BE1778C@mail.zedz.net> Message-ID: On Sun, 11 Nov 2001, Alex de Joode wrote: > > Hi, > > I've compiled openssh 3.0p1 (portable) on an openbsd 2.6 machine, > compile goes fine however the sshd deamon will not start: > Any ideas on how to fix this ? Don't use portable on an OpenBSD machine - use the OpenBSD source instead. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Mon Nov 12 10:36:36 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Nov 2001 10:36:36 +1100 (EST) Subject: [PATCH]: Change contrib/cygwin/ssh-host-config In-Reply-To: <20011111231346.D1881@cygbert.vinschen.de> Message-ID: On Sun, 11 Nov 2001, Corinna Vinschen wrote: > Hi, > > the following patch to contrib/cygwin/ssh-host-config creates > /etc/ssh_config and /etc/sshd_config according to the current > default config files. Could somebody please check it in? Applied - thanks. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From usura at zedz.net Mon Nov 12 10:43:17 2001 From: usura at zedz.net (Alex de Joode) Date: Mon, 12 Nov 2001 00:43:17 +0100 Subject: OpenBSD 2.6 & OpenSSH 3.0p1 In-Reply-To: ; from djm@mindrot.org on Mon, Nov 12, 2001 at 10:35:14AM +1100 References: <20011111211659.499BE1778C@mail.zedz.net> Message-ID: <20011112004317.B13361@outpost.zedz.net> On Mon, Nov 12, 2001 at 10:35:14AM +1100, Damien Miller wrote: > On Sun, 11 Nov 2001, Alex de Joode wrote: > > > > > Hi, > > > > I've compiled openssh 3.0p1 (portable) on an openbsd 2.6 machine, > > compile goes fine however the sshd deamon will not start: > > Any ideas on how to fix this ? > > Don't use portable on an OpenBSD machine - use the OpenBSD source instead. > The OpenBSD source doesn't compile on OpenBSD 2.6. Markus suggested posting the problem here .. -- Exit! Stage Left! From djm at mindrot.org Mon Nov 12 10:47:28 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Nov 2001 10:47:28 +1100 (EST) Subject: OpenBSD 2.6 & OpenSSH 3.0p1 In-Reply-To: <20011112004317.B13361@outpost.zedz.net> Message-ID: On Mon, 12 Nov 2001, Alex de Joode wrote: > The OpenBSD source doesn't compile on OpenBSD 2.6. Markus suggested > posting the problem here .. Where does it die? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From usura at zedz.net Mon Nov 12 10:55:31 2001 From: usura at zedz.net (Alex de Joode) Date: Mon, 12 Nov 2001 00:55:31 +0100 Subject: OpenBSD 2.6 & OpenSSH 3.0p1 In-Reply-To: ; from djm@mindrot.org on Mon, Nov 12, 2001 at 10:47:28AM +1100 References: <20011112004317.B13361@outpost.zedz.net> Message-ID: <20011112005531.C13361@outpost.zedz.net> On Mon, Nov 12, 2001 at 10:47:28AM +1100, Damien Miller wrote: > On Mon, 12 Nov 2001, Alex de Joode wrote: > > > The OpenBSD source doesn't compile on OpenBSD 2.6. Markus suggested > > posting the problem here .. > > Where does it die? the portable/openssh compiles fine, but refuses to startup: [usura at outpost]:/tmp/openssh-3.0p1 {21}$ ./sshd -p 3333 -4 bad addr or host: 0.0.0.0 (name or service is not known) the openbsd/openssh dies here: cc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -lkrb -lkafs -L/tmp/ssh/ssh/../lib -lssh -lcrypto -lz sshconnect.o: Undefined symbol `_rresvport_af' referenced from text segment authfile.o: Undefined symbol `_EVP_PKEY_get1_RSA' referenced from text segment authfile.o: Undefined symbol `_EVP_PKEY_get1_DSA' referenced from text segment collect2: ld returned 1 exit status *** Error code 1 Stop in /tmp/ssh/ssh (line 96 of /usr/share/mk/bsd.prog.mk). *** Error code 1 Stop in /tmp/ssh. -- Exit! Stage Left! From djm at mindrot.org Mon Nov 12 11:12:30 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Nov 2001 11:12:30 +1100 (EST) Subject: OpenBSD 2.6 & OpenSSH 3.0p1 In-Reply-To: <20011112005531.C13361@outpost.zedz.net> Message-ID: On Mon, 12 Nov 2001, Alex de Joode wrote: > On Mon, Nov 12, 2001 at 10:47:28AM +1100, Damien Miller wrote: > > On Mon, 12 Nov 2001, Alex de Joode wrote: > > > > > The OpenBSD source doesn't compile on OpenBSD 2.6. Markus suggested > > > posting the problem here .. > > > > Where does it die? Sorry - where/how does the OpenBSD version die? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From bugzilla-daemon at mindrot.org Mon Nov 12 11:41:46 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Mon, 12 Nov 2001 11:41:46 +1100 (EST) Subject: [Bug 10] sshd sometimes clears too much memory when zeroing fd_sets Message-ID: <20011112004146.402A92DF20@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=10 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2001-11-12 11:41 ------- Fix in -current ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From djm at mindrot.org Mon Nov 12 12:30:42 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 12 Nov 2001 12:30:42 +1100 (EST) Subject: Please test -current Message-ID: Could people please test -current? We will be making a release fairly soon. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From carson at taltos.org Mon Nov 12 14:20:34 2001 From: carson at taltos.org (Carson Gaspar) Date: Sun, 11 Nov 2001 22:20:34 -0500 Subject: openssh-3.0p1, auth2.c In-Reply-To: <20011111125553.A15074@folly> References: <20011111125553.A15074@folly> Message-ID: <105847901.1005517234@[192.168.123.111]> --On Sunday, November 11, 2001 12:55 PM +0100 Markus Friedl wrote: > so i'll remove HostbasedUsesNameFromPacketOnly. Please don't - I'll just have to add it back in manually, and that would suck. >> In that case, the bug is in ssh. Ssh should not send hostnames that are >> period terminated. > > it should. otherwise interoperating with ssh.com is not possible. OK, so you want to have the ssh.com client behaviour, but not the ssh.com server behaviour. Make up your mind - are you being strict, or compatable? If you can't make up your mind, put in Yet Another Option (what fun...). > i think hostbased authentication never has been intended for this. Simple example. You have a server outside an application proxy firewall. You don't want random Internet crackers going at your server. You can restrict by IP address, but we all know how secure _that_ is (ha!). So I want to only allow certain systems to connect. Of course to do this, and still require a user to authenticate with a password or rsa key or whatever, you have to implement my partial auth patch ;-) > especially since rhosts-rsa requires a privileged source port. Not unless you're really stupid and make it require a priv port. It provides _zero_ additional security, and breaks things. We had this argument ages ago, and I thought I'd convinced everyone. I'll refrain from repeating myself - read the archives if anyone cares. -- Carson From root at solbianca.silentmobius.net Mon Nov 12 15:42:36 2001 From: root at solbianca.silentmobius.net (Root of all evil) Date: Sun, 11 Nov 2001 22:42:36 -0600 Subject: utmp entries Message-ID: <200111120442.WAA03888@solbianca.silentmobius.net> Apparently, on Slackware linux (2.2.19 kernel, gcc 2.7.2.3/glibc 2.0) it doesn't update the utmp entries successfully. ie: after exiting from my ssh connection, it leaves a 'ghost' in the utmp file of me being still connected. Apparently the utmp file isn't being properly updated on disconnect. This is with openssh-2.9.9p2 From slade at shore.net Mon Nov 12 15:19:35 2001 From: slade at shore.net (Richard E. Silverman) Date: Sun, 11 Nov 2001 23:19:35 -0500 Subject: openssh-3.0p1, auth2.c Message-ID: <200111120419.XAA12358@syrinx.oankali.net> markus> i think hostbased authentication never has been intended for this. markus> especially since rhosts-rsa requires a privileged source port. I don't see how this follows, and I disagree. The privileged source port requirement in SSH-1 was just a holdover from mimicing rsh -- it was never a good idea, it is not essential to the notion of host-based authentication, and it is (properly) not required in SSH-2. Considering the source address in an authentication method should *always* be an optional feature. For one thing, it means the method may be run over a different transport without change (serial line, tunnel of some kind, "ProxyCommand", etc.). Second, an IP address need not be inherent in a host's identity, any more than its MAC address is. The host may be mobile, multihomed, using DHCP, moved from one network to another, its enclosing network renumbered, etc. If you happen to know that a particular client host has a static IP address, and you feel like requiring that as an extra measure of caution, then fine, but I don't think it should ever be a protocol or feature requirement -- just an implementation optional (as with the "host=" option in authorized_keys). -- Richard Silverman slade at shore.net From solar at openwall.com Mon Nov 12 16:30:50 2001 From: solar at openwall.com (Solar Designer) Date: Mon, 12 Nov 2001 08:30:50 +0300 Subject: keystroke timing attack In-Reply-To: <20011111141244.A20820@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Sun, Nov 11, 2001 at 02:12:44PM +0100 References: <20011110140145.E27104@folly> <20011111141244.A20820@faui02.informatik.uni-erlangen.de> Message-ID: <20011112083050.A28806@openwall.com> On Sun, Nov 11, 2001 at 02:12:44PM +0100, Markus Friedl wrote: > On Sun, Nov 11, 2001 at 01:26:25AM +0100, Andersson, Mats wrote: > > The next release of MindTerm (an ssh1/ssh2 implementation in java found at > > www.appgate.com/mindterm) contains a client-side "countermeasure" against > > this timing attack aswell. It starts sending IGNORE messages, at > > pseudo-random short intervals, of same size as a channel-data packet > > containing a keystroke when one start typing and then keeps on sending > > these packets up to 2 seconds after last keypress, completely hiding the > > inter-keystroke timings. > > but since the server won't send an 'echo' ignore message to the > client's ignore message, it's now possible to figure out the > SU-signature again! Why, it would also not send "echo" ignore messages when a shell command (and not a password) is being entered. So the server-side countermeasure continues to work to the same extent it normally did. It's just the described client-side countermesure which turns out to be totally ineffective (as opposed to quite ineffective which it normally is) when there's also a server-side countermeasure as recommended by our advisory and as implemented in recent OpenSSH. Such an interesting interaction. ;-( > moreover i don't think random intervalls help, i think you need 'fixed' > intervalls. > > if you have random intervals, you can probably strip the random noise > if you have enough samples. In case anyone cares, I agree with Markus entirely. In fact, this issue has been discussed before our advisory and the Berkeley paper went public. It's nice to see client authors try to design and implement additional countermeasures. Unfortunately, I don't believe there's much which can be done without a protocol extension which would let clients and servers agree on the dummy traffic. Whatever we thought was practical to implement right now is described in the advisory. For the clients this means protecting the initial login username and password only. -- /sd From mats.andersson at appgate.com Mon Nov 12 20:08:21 2001 From: mats.andersson at appgate.com (Andersson, Mats) Date: Mon, 12 Nov 2001 10:08:21 +0100 (CET) Subject: keystroke timing attack In-Reply-To: <20011112083050.A28806@openwall.com> Message-ID: Hi, On Mon, 12 Nov 2001, Solar Designer wrote: > > client's ignore message, it's now possible to figure out the > > SU-signature again! > > Why, it would also not send "echo" ignore messages when a shell > command (and not a password) is being entered. So the server-side > countermeasure continues to work to the same extent it normally did. > > It's just the described client-side countermesure which turns out to > be totally ineffective (as opposed to quite ineffective which it > normally is) when there's also a server-side countermeasure as > recommended by our advisory and as implemented in recent OpenSSH. Such > an interesting interaction. ;-( I wasn't aware of the server-side counter-measure (or what it did) which was allready in the openssh-server when I did this in our code, I should of course have checked :-(. Ok, sending all keystrokes in a stream with evenspaced packets was the countermeasure originally propsed by MaF here at AppGate. I thought that it might add perceived latency to keyboard input and it is also somewhat harder to implement given how my code works right now so I simplified it with just adding the noise (as it was both solutions turned out to undo the server-side countermeasure of course :-). I didn't think this through very much, I just thought that adding noise is better than nothing. However this is an optional feature and disabled by default so it might be used with servers which doesn't have the server-side counter-measure. > In case anyone cares, I agree with Markus entirely. In fact, this > issue has been discussed before our advisory and the Berkeley paper > went public. I'll go read that paper now, actually it was on my TODO-list but that list has a strange tendency to flood continually... :-). > can be done without a protocol extension which would let clients and > servers agree on the dummy traffic. Whatever we thought was practical > to implement right now is described in the advisory. For the clients > this means protecting the initial login username and password only. Fair enough (for now one could enable the client side counter-measeure when it sees a server which it knows doesn't have the server-side one, which is what I'll do actually since it is still better than nothing :-). Thanks for the input. Cheers, /Mats From gert at greenie.muc.de Mon Nov 12 20:28:06 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 12 Nov 2001 10:28:06 +0100 Subject: Please test -current In-Reply-To: ; from Damien Miller on Mon, Nov 12, 2001 at 12:30:42PM +1100 References: Message-ID: <20011112102806.A7174@greenie.muc.de> Hi, On Mon, Nov 12, 2001 at 12:30:42PM +1100, Damien Miller wrote: > Could people please test -current? We will be making a release fairly > soon. Except for the autoconf issue (needs 1.52 with patch), SCO 3.0 works fine. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From vinschen at redhat.com Mon Nov 12 20:42:23 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 12 Nov 2001 10:42:23 +0100 Subject: Please test -current In-Reply-To: ; from djm@mindrot.org on Mon, Nov 12, 2001 at 12:30:42PM +1100 References: Message-ID: <20011112104223.C2618@cygbert.vinschen.de> On Mon, Nov 12, 2001 at 12:30:42PM +1100, Damien Miller wrote: > Could people please test -current? We will be making a release fairly > soon. Somebody seem to have inadvertently removed the patch to allow to install scard/Ssh.bin when builddir != srcdir. Or was it never checked in? Corinna Index: scard/Makefile.in =================================================================== RCS file: /cvs/openssh_cvs/scard/Makefile.in,v retrieving revision 1.3 diff -u -p -r1.3 Makefile.in --- scard/Makefile.in 2001/10/27 00:33:19 1.3 +++ scard/Makefile.in 2001/11/12 09:39:23 @@ -11,8 +11,8 @@ VPATH=@srcdir@ all: -Ssh.bin: Ssh.bin.uu - uudecode Ssh.bin.uu +Ssh.bin: $(srcdir)/Ssh.bin.uu + uudecode -o $@ $(srcdir)/Ssh.bin.uu clean: rm -rf Ssh.bin @@ -24,4 +24,4 @@ distclean: clean install: $(srcdir)/Ssh.bin $(top_srcdir)/mkinstalldirs $(DESTDIR)$(datadir) - $(INSTALL) -m 0644 $(srcdir)/Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin + $(INSTALL) -m 0644 Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Mon Nov 12 21:02:52 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 12 Nov 2001 11:02:52 +0100 Subject: Please test -current In-Reply-To: <20011112104223.C2618@cygbert.vinschen.de>; from vinschen@redhat.com on Mon, Nov 12, 2001 at 10:42:23AM +0100 References: <20011112104223.C2618@cygbert.vinschen.de> Message-ID: <20011112110252.D2618@cygbert.vinschen.de> On Mon, Nov 12, 2001 at 10:42:23AM +0100, Corinna Vinschen wrote: > On Mon, Nov 12, 2001 at 12:30:42PM +1100, Damien Miller wrote: > > Could people please test -current? We will be making a release fairly > > soon. > > Somebody seem to have inadvertently removed the patch to allow > to install scard/Ssh.bin when builddir != srcdir. Or was it never > checked in? > > Corinna Sorry, the previous patch didn't change the dependency. Corrected patch follows: Index: scard/Makefile.in =================================================================== RCS file: /cvs/openssh_cvs/scard/Makefile.in,v retrieving revision 1.3 diff -u -p -r1.3 Makefile.in --- scard/Makefile.in 2001/10/27 00:33:19 1.3 +++ scard/Makefile.in 2001/11/12 09:54:12 @@ -11,8 +11,8 @@ VPATH=@srcdir@ all: -Ssh.bin: Ssh.bin.uu - uudecode Ssh.bin.uu +Ssh.bin: $(srcdir)/Ssh.bin.uu + uudecode -o $@ $(srcdir)/Ssh.bin.uu clean: rm -rf Ssh.bin @@ -22,6 +22,6 @@ distprep: Ssh.bin distclean: clean rm -f Makefile *~ -install: $(srcdir)/Ssh.bin +install: Ssh.bin $(top_srcdir)/mkinstalldirs $(DESTDIR)$(datadir) - $(INSTALL) -m 0644 $(srcdir)/Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin + $(INSTALL) -m 0644 Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Mon Nov 12 21:06:00 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 12 Nov 2001 11:06:00 +0100 Subject: Please test -current In-Reply-To: ; from djm@mindrot.org on Mon, Nov 12, 2001 at 12:30:42PM +1100 References: Message-ID: <20011112110600.E2618@cygbert.vinschen.de> On Mon, Nov 12, 2001 at 12:30:42PM +1100, Damien Miller wrote: > Could people please test -current? We will be making a release fairly > soon. Compiles and runs fine for Cygwin. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From serge.droz at psi.ch Mon Nov 12 21:35:46 2001 From: serge.droz at psi.ch (Serge Droz) Date: Mon, 12 Nov 2001 11:35:46 +0100 Subject: Please test -current References: Message-ID: <3BEFA602.F4E3ACD7@psi.ch> Work fine here. Attached is the patch which allows you to pass afs tokens before authenticication (This is implemented as an option and is off by default). Serge Damien Miller wrote: > > Could people please test -current? We will be making a release fairly > soon. > > -d > > -- > | By convention there is color, \\ Damien Miller > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > | But in reality there are atoms and space - Democritus (c. 400 BCE) -- Serge Droz Paul Scherrer Institut mailto:serge.droz at psi.ch CH-5232 Villigen PSI Phone: ++41 56 310 3637 Fax: ++41 56 310 3649 -------------- next part -------------- diff -Nur openssh-3.0p2.orig/auth1.c openssh-3.0p2/auth1.c --- openssh-3.0p2.orig/auth1.c Wed Jul 4 06:21:16 2001 +++ openssh-3.0p2/auth1.c Mon Nov 12 11:32:06 2001 @@ -118,6 +118,24 @@ /* Process the packet. */ switch (type) { +#ifdef AFS + case SSH_CMSG_HAVE_AFS_TOKEN: + if ( options.afs_pass_token_before_auth ) { + if (!options.afs_token_passing || !k_hasafs()) { + verbose("AFS token passing disabled."); + break; + } else { + /* Accept AFS token. */ + char *token_string = packet_get_string(&dlen); + packet_integrity_check(plen, 4 + dlen, type); + if (!auth_afs_token(authctxt, token_string)) + verbose("AFS token REFUSED for %.100s", authctxt->user); + xfree(token_string); + } + } else packet_send_debug("AFS token passing disabled before authentication."); + break; +#endif /* AFS */ + #if defined(KRB4) || defined(KRB5) case SSH_CMSG_AUTH_KERBEROS: if (!options.kerberos_authentication) { @@ -168,11 +186,11 @@ case SSH_CMSG_HAVE_KERBEROS_TGT: packet_send_debug("Kerberos TGT passing disabled before authentication."); break; -#ifdef AFS - case SSH_CMSG_HAVE_AFS_TOKEN: - packet_send_debug("AFS token passing disabled before authentication."); - break; -#endif /* AFS */ +//#ifdef AFS +// case SSH_CMSG_HAVE_AFS_TOKEN: +// packet_send_debug("AFS token passing disabled before authentication."); +// break; +//#endif /* AFS */ #endif /* AFS || KRB5 */ case SSH_CMSG_AUTH_RHOSTS: diff -Nur openssh-3.0p2.orig/readconf.c openssh-3.0p2/readconf.c --- openssh-3.0p2.orig/readconf.c Wed Oct 3 19:39:39 2001 +++ openssh-3.0p2/readconf.c Mon Nov 12 11:32:06 2001 @@ -103,7 +103,7 @@ oKerberosTgtPassing, #endif #ifdef AFS - oAFSTokenPassing, + oAFSTokenPassing,oAFSPassTokenBeforeAuth, #endif oIdentityFile, oHostName, oPort, oCipher, oRemoteForward, oLocalForward, oUser, oHost, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand, @@ -149,6 +149,7 @@ #endif #ifdef AFS { "afstokenpassing", oAFSTokenPassing }, + { "afspasstokenbeforeauth", oAFSPassTokenBeforeAuth}, #endif { "fallbacktorsh", oFallBackToRsh }, { "usersh", oUseRsh }, @@ -372,6 +373,9 @@ case oAFSTokenPassing: intptr = &options->afs_token_passing; goto parse_flag; + case oAFSPassTokenBeforeAuth: + intptr = &options->afs_pass_token_before_auth; + goto parse_flag; #endif case oFallBackToRsh: intptr = &options->fallback_to_rsh; @@ -759,6 +763,7 @@ #endif #ifdef AFS options->afs_token_passing = -1; + options->afs_pass_token_before_auth = -1; #endif options->password_authentication = -1; options->kbd_interactive_authentication = -1; @@ -842,6 +847,8 @@ #ifdef AFS if (options->afs_token_passing == -1) options->afs_token_passing = 1; + if (options->afs_pass_token_before_auth == -1) + options->afs_pass_token_before_auth = 0; #endif if (options->password_authentication == -1) options->password_authentication = 1; diff -Nur openssh-3.0p2.orig/readconf.h openssh-3.0p2/readconf.h --- openssh-3.0p2.orig/readconf.h Wed Oct 3 19:39:39 2001 +++ openssh-3.0p2/readconf.h Mon Nov 12 11:32:06 2001 @@ -49,6 +49,7 @@ #endif #ifdef AFS int afs_token_passing; /* Try AFS token passing. */ + int afs_pass_token_before_auth; /* Pass Token before Auth. */ #endif int password_authentication; /* Try password * authentication. */ diff -Nur openssh-3.0p2.orig/servconf.c openssh-3.0p2/servconf.c --- openssh-3.0p2.orig/servconf.c Mon Nov 12 01:40:12 2001 +++ openssh-3.0p2/servconf.c Mon Nov 12 11:32:06 2001 @@ -84,6 +84,7 @@ #endif #ifdef AFS options->afs_token_passing = -1; + options->afs_pass_token_before_auth = -1; #endif options->password_authentication = -1; options->kbd_interactive_authentication = -1; @@ -193,6 +194,8 @@ #ifdef AFS if (options->afs_token_passing == -1) options->afs_token_passing = k_hasafs(); + if (options->afs_pass_token_before_auth == -1) + options->afs_pass_token_before_auth = 0; #endif if (options->password_authentication == -1) options->password_authentication = 1; @@ -250,6 +253,7 @@ #endif #ifdef AFS sAFSTokenPassing, + sAFSPassTokenBeforeAuth, #endif sChallengeResponseAuthentication, sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress, @@ -301,6 +305,7 @@ #endif #ifdef AFS { "afstokenpassing", sAFSTokenPassing }, + { "afspasstokenbeforeauth", sAFSPassTokenBeforeAuth }, #endif { "passwordauthentication", sPasswordAuthentication }, { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, @@ -637,6 +642,9 @@ #ifdef AFS case sAFSTokenPassing: intptr = &options->afs_token_passing; + goto parse_flag; + case sAFSPassTokenBeforeAuth: + intptr = &options->afs_pass_token_before_auth; goto parse_flag; #endif diff -Nur openssh-3.0p2.orig/servconf.c.orig openssh-3.0p2/servconf.c.orig --- openssh-3.0p2.orig/servconf.c.orig Thu Jan 1 01:00:00 1970 +++ openssh-3.0p2/servconf.c.orig Mon Nov 12 01:40:12 2001 @@ -0,0 +1,883 @@ +/* + * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland + * All rights reserved + * + * As far as I am concerned, the code I have written for this software + * can be used freely for any purpose. Any derived versions of this + * software must be clearly marked as such, and if the derived work is + * incompatible with the protocol description in the RFC file, it must be + * called by a name other than "ssh" or "Secure Shell". + */ + +#include "includes.h" +RCSID("$OpenBSD: servconf.c,v 1.90 2001/11/11 13:02:31 markus Exp $"); + +#if defined(KRB4) || defined(KRB5) +#include +#endif +#ifdef AFS +#include +#endif + +#include "ssh.h" +#include "log.h" +#include "servconf.h" +#include "xmalloc.h" +#include "compat.h" +#include "pathnames.h" +#include "tildexpand.h" +#include "misc.h" +#include "cipher.h" +#include "kex.h" +#include "mac.h" + +static void add_listen_addr(ServerOptions *, char *, u_short); +static void add_one_listen_addr(ServerOptions *, char *, u_short); + +/* AF_UNSPEC or AF_INET or AF_INET6 */ +extern int IPv4or6; + +/* Initializes the server options to their default values. */ + +void +initialize_server_options(ServerOptions *options) +{ + memset(options, 0, sizeof(*options)); + + /* Portable-specific options */ + options->pam_authentication_via_kbd_int = -1; + + /* Standard Options */ + options->num_ports = 0; + options->ports_from_cmdline = 0; + options->listen_addrs = NULL; + options->num_host_key_files = 0; + options->pid_file = NULL; + options->server_key_bits = -1; + options->login_grace_time = -1; + options->key_regeneration_time = -1; + options->permit_root_login = PERMIT_NOT_SET; + options->ignore_rhosts = -1; + options->ignore_user_known_hosts = -1; + options->print_motd = -1; + options->print_lastlog = -1; + options->x11_forwarding = -1; + options->x11_display_offset = -1; + options->xauth_location = NULL; + options->strict_modes = -1; + options->keepalives = -1; + options->log_facility = (SyslogFacility) - 1; + options->log_level = (LogLevel) - 1; + options->rhosts_authentication = -1; + options->rhosts_rsa_authentication = -1; + options->hostbased_authentication = -1; + options->hostbased_uses_name_from_packet_only = -1; + options->rsa_authentication = -1; + options->pubkey_authentication = -1; +#if defined(KRB4) || defined(KRB5) + options->kerberos_authentication = -1; + options->kerberos_or_local_passwd = -1; + options->kerberos_ticket_cleanup = -1; +#endif +#if defined(AFS) || defined(KRB5) + options->kerberos_tgt_passing = -1; +#endif +#ifdef AFS + options->afs_token_passing = -1; +#endif + options->password_authentication = -1; + options->kbd_interactive_authentication = -1; + options->challenge_response_authentication = -1; + options->permit_empty_passwd = -1; + options->use_login = -1; + options->allow_tcp_forwarding = -1; + options->num_allow_users = 0; + options->num_deny_users = 0; + options->num_allow_groups = 0; + options->num_deny_groups = 0; + options->ciphers = NULL; + options->macs = NULL; + options->protocol = SSH_PROTO_UNKNOWN; + options->gateway_ports = -1; + options->num_subsystems = 0; + options->max_startups_begin = -1; + options->max_startups_rate = -1; + options->max_startups = -1; + options->banner = NULL; + options->reverse_mapping_check = -1; + options->client_alive_interval = -1; + options->client_alive_count_max = -1; + options->authorized_keys_file = NULL; + options->authorized_keys_file2 = NULL; +} + +void +fill_default_server_options(ServerOptions *options) +{ + /* Portable-specific options */ + if (options->pam_authentication_via_kbd_int == -1) + options->pam_authentication_via_kbd_int = 0; + + /* Standard Options */ + if (options->protocol == SSH_PROTO_UNKNOWN) + options->protocol = SSH_PROTO_1|SSH_PROTO_2; + if (options->num_host_key_files == 0) { + /* fill default hostkeys for protocols */ + if (options->protocol & SSH_PROTO_1) + options->host_key_files[options->num_host_key_files++] = _PATH_HOST_KEY_FILE; + if (options->protocol & SSH_PROTO_2) + options->host_key_files[options->num_host_key_files++] = _PATH_HOST_DSA_KEY_FILE; + } + if (options->num_ports == 0) + options->ports[options->num_ports++] = SSH_DEFAULT_PORT; + if (options->listen_addrs == NULL) + add_listen_addr(options, NULL, 0); + if (options->pid_file == NULL) + options->pid_file = _PATH_SSH_DAEMON_PID_FILE; + if (options->server_key_bits == -1) + options->server_key_bits = 768; + if (options->login_grace_time == -1) + options->login_grace_time = 600; + if (options->key_regeneration_time == -1) + options->key_regeneration_time = 3600; + if (options->permit_root_login == PERMIT_NOT_SET) + options->permit_root_login = PERMIT_YES; + if (options->ignore_rhosts == -1) + options->ignore_rhosts = 1; + if (options->ignore_user_known_hosts == -1) + options->ignore_user_known_hosts = 0; + if (options->print_motd == -1) + options->print_motd = 1; + if (options->print_lastlog == -1) + options->print_lastlog = 1; + if (options->x11_forwarding == -1) + options->x11_forwarding = 0; + if (options->x11_display_offset == -1) + options->x11_display_offset = 10; +#ifdef _PATH_XAUTH + if (options->xauth_location == NULL) + options->xauth_location = _PATH_XAUTH; +#endif + if (options->strict_modes == -1) + options->strict_modes = 1; + if (options->keepalives == -1) + options->keepalives = 1; + if (options->log_facility == (SyslogFacility) (-1)) + options->log_facility = SYSLOG_FACILITY_AUTH; + if (options->log_level == (LogLevel) (-1)) + options->log_level = SYSLOG_LEVEL_INFO; + if (options->rhosts_authentication == -1) + options->rhosts_authentication = 0; + if (options->rhosts_rsa_authentication == -1) + options->rhosts_rsa_authentication = 0; + if (options->hostbased_authentication == -1) + options->hostbased_authentication = 0; + if (options->hostbased_uses_name_from_packet_only == -1) + options->hostbased_uses_name_from_packet_only = 0; + if (options->rsa_authentication == -1) + options->rsa_authentication = 1; + if (options->pubkey_authentication == -1) + options->pubkey_authentication = 1; +#if defined(KRB4) || defined(KRB5) + if (options->kerberos_authentication == -1) + options->kerberos_authentication = (access(KEYFILE, R_OK) == 0); + if (options->kerberos_or_local_passwd == -1) + options->kerberos_or_local_passwd = 1; + if (options->kerberos_ticket_cleanup == -1) + options->kerberos_ticket_cleanup = 1; +#endif +#if defined(AFS) || defined(KRB5) + if (options->kerberos_tgt_passing == -1) + options->kerberos_tgt_passing = 0; +#endif +#ifdef AFS + if (options->afs_token_passing == -1) + options->afs_token_passing = k_hasafs(); +#endif + if (options->password_authentication == -1) + options->password_authentication = 1; + if (options->kbd_interactive_authentication == -1) + options->kbd_interactive_authentication = 0; + if (options->challenge_response_authentication == -1) + options->challenge_response_authentication = 1; + if (options->permit_empty_passwd == -1) + options->permit_empty_passwd = 0; + if (options->use_login == -1) + options->use_login = 0; + if (options->allow_tcp_forwarding == -1) + options->allow_tcp_forwarding = 1; + if (options->gateway_ports == -1) + options->gateway_ports = 0; + if (options->max_startups == -1) + options->max_startups = 10; + if (options->max_startups_rate == -1) + options->max_startups_rate = 100; /* 100% */ + if (options->max_startups_begin == -1) + options->max_startups_begin = options->max_startups; + if (options->reverse_mapping_check == -1) + options->reverse_mapping_check = 0; + if (options->client_alive_interval == -1) + options->client_alive_interval = 0; + if (options->client_alive_count_max == -1) + options->client_alive_count_max = 3; + if (options->authorized_keys_file == NULL) + options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; + if (options->authorized_keys_file2 == NULL) { + /* authorized_keys_file2 falls back to authorized_keys_file */ + if (options->authorized_keys_file != NULL) + options->authorized_keys_file2 = options->authorized_keys_file; + else + options->authorized_keys_file2 = _PATH_SSH_USER_PERMITTED_KEYS2; + } + if (options->authorized_keys_file == NULL) + options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; +} + +/* Keyword tokens. */ +typedef enum { + sBadOption, /* == unknown option */ + /* Portable-specific options */ + sPAMAuthenticationViaKbdInt, + /* Standard Options */ + sPort, sHostKeyFile, sServerKeyBits, sLoginGraceTime, sKeyRegenerationTime, + sPermitRootLogin, sLogFacility, sLogLevel, + sRhostsAuthentication, sRhostsRSAAuthentication, sRSAAuthentication, +#if defined(KRB4) || defined(KRB5) + sKerberosAuthentication, sKerberosOrLocalPasswd, sKerberosTicketCleanup, +#endif +#if defined(AFS) || defined(KRB5) + sKerberosTgtPassing, +#endif +#ifdef AFS + sAFSTokenPassing, +#endif + sChallengeResponseAuthentication, + sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress, + sPrintMotd, sPrintLastLog, sIgnoreRhosts, + sX11Forwarding, sX11DisplayOffset, + sStrictModes, sEmptyPasswd, sKeepAlives, + sUseLogin, sAllowTcpForwarding, + sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, + sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, + sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, + sBanner, sReverseMappingCheck, sHostbasedAuthentication, + sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, + sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, + sDeprecated +} ServerOpCodes; + +/* Textual representation of the tokens. */ +static struct { + const char *name; + ServerOpCodes opcode; +} keywords[] = { + /* Portable-specific options */ + { "PAMAuthenticationViaKbdInt", sPAMAuthenticationViaKbdInt }, + /* Standard Options */ + { "port", sPort }, + { "hostkey", sHostKeyFile }, + { "hostdsakey", sHostKeyFile }, /* alias */ + { "pidfile", sPidFile }, + { "serverkeybits", sServerKeyBits }, + { "logingracetime", sLoginGraceTime }, + { "keyregenerationinterval", sKeyRegenerationTime }, + { "permitrootlogin", sPermitRootLogin }, + { "syslogfacility", sLogFacility }, + { "loglevel", sLogLevel }, + { "rhostsauthentication", sRhostsAuthentication }, + { "rhostsrsaauthentication", sRhostsRSAAuthentication }, + { "hostbasedauthentication", sHostbasedAuthentication }, + { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly }, + { "rsaauthentication", sRSAAuthentication }, + { "pubkeyauthentication", sPubkeyAuthentication }, + { "dsaauthentication", sPubkeyAuthentication }, /* alias */ +#if defined(KRB4) || defined(KRB5) + { "kerberosauthentication", sKerberosAuthentication }, + { "kerberosorlocalpasswd", sKerberosOrLocalPasswd }, + { "kerberosticketcleanup", sKerberosTicketCleanup }, +#endif +#if defined(AFS) || defined(KRB5) + { "kerberostgtpassing", sKerberosTgtPassing }, +#endif +#ifdef AFS + { "afstokenpassing", sAFSTokenPassing }, +#endif + { "passwordauthentication", sPasswordAuthentication }, + { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, + { "challengeresponseauthentication", sChallengeResponseAuthentication }, + { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ + { "checkmail", sDeprecated }, + { "listenaddress", sListenAddress }, + { "printmotd", sPrintMotd }, + { "printlastlog", sPrintLastLog }, + { "ignorerhosts", sIgnoreRhosts }, + { "ignoreuserknownhosts", sIgnoreUserKnownHosts }, + { "x11forwarding", sX11Forwarding }, + { "x11displayoffset", sX11DisplayOffset }, + { "xauthlocation", sXAuthLocation }, + { "strictmodes", sStrictModes }, + { "permitemptypasswords", sEmptyPasswd }, + { "uselogin", sUseLogin }, + { "keepalive", sKeepAlives }, + { "allowtcpforwarding", sAllowTcpForwarding }, + { "allowusers", sAllowUsers }, + { "denyusers", sDenyUsers }, + { "allowgroups", sAllowGroups }, + { "denygroups", sDenyGroups }, + { "ciphers", sCiphers }, + { "macs", sMacs }, + { "protocol", sProtocol }, + { "gatewayports", sGatewayPorts }, + { "subsystem", sSubsystem }, + { "maxstartups", sMaxStartups }, + { "banner", sBanner }, + { "reversemappingcheck", sReverseMappingCheck }, + { "clientaliveinterval", sClientAliveInterval }, + { "clientalivecountmax", sClientAliveCountMax }, + { "authorizedkeysfile", sAuthorizedKeysFile }, + { "authorizedkeysfile2", sAuthorizedKeysFile2 }, + { NULL, 0 } +}; + +/* + * Returns the number of the token pointed to by cp or sBadOption. + */ + +static ServerOpCodes +parse_token(const char *cp, const char *filename, + int linenum) +{ + u_int i; + + for (i = 0; keywords[i].name; i++) + if (strcasecmp(cp, keywords[i].name) == 0) + return keywords[i].opcode; + + error("%s: line %d: Bad configuration option: %s", + filename, linenum, cp); + return sBadOption; +} + +static void +add_listen_addr(ServerOptions *options, char *addr, u_short port) +{ + int i; + + if (options->num_ports == 0) + options->ports[options->num_ports++] = SSH_DEFAULT_PORT; + if (port == 0) + for (i = 0; i < options->num_ports; i++) + add_one_listen_addr(options, addr, options->ports[i]); + else + add_one_listen_addr(options, addr, port); +} + +static void +add_one_listen_addr(ServerOptions *options, char *addr, u_short port) +{ + struct addrinfo hints, *ai, *aitop; + char strport[NI_MAXSERV]; + int gaierr; + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = IPv4or6; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = (addr == NULL) ? AI_PASSIVE : 0; + snprintf(strport, sizeof strport, "%d", port); + if ((gaierr = getaddrinfo(addr, strport, &hints, &aitop)) != 0) + fatal("bad addr or host: %s (%s)", + addr ? addr : "", + gai_strerror(gaierr)); + for (ai = aitop; ai->ai_next; ai = ai->ai_next) + ; + ai->ai_next = options->listen_addrs; + options->listen_addrs = aitop; +} + +/* Reads the server configuration file. */ + +void +read_server_config(ServerOptions *options, const char *filename) +{ + FILE *f; + char line[1024]; + char *cp, **charptr, *arg, *p; + int linenum, *intptr, value; + int bad_options = 0; + ServerOpCodes opcode; + int i, n; + + f = fopen(filename, "r"); + if (!f) { + perror(filename); + exit(1); + } + linenum = 0; + while (fgets(line, sizeof(line), f)) { + linenum++; + cp = line; + arg = strdelim(&cp); + /* Ignore leading whitespace */ + if (*arg == '\0') + arg = strdelim(&cp); + if (!arg || !*arg || *arg == '#') + continue; + intptr = NULL; + charptr = NULL; + opcode = parse_token(arg, filename, linenum); + switch (opcode) { + case sBadOption: + bad_options++; + continue; + + /* Portable-specific options */ + case sPAMAuthenticationViaKbdInt: + intptr = &options->pam_authentication_via_kbd_int; + goto parse_flag; + + /* Standard Options */ + case sPort: + /* ignore ports from configfile if cmdline specifies ports */ + if (options->ports_from_cmdline) + continue; + if (options->listen_addrs != NULL) + fatal("%s line %d: ports must be specified before " + "ListenAdress.", filename, linenum); + if (options->num_ports >= MAX_PORTS) + fatal("%s line %d: too many ports.", + filename, linenum); + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing port number.", + filename, linenum); + options->ports[options->num_ports++] = a2port(arg); + if (options->ports[options->num_ports-1] == 0) + fatal("%s line %d: Badly formatted port number.", + filename, linenum); + break; + + case sServerKeyBits: + intptr = &options->server_key_bits; +parse_int: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing integer value.", + filename, linenum); + value = atoi(arg); + if (*intptr == -1) + *intptr = value; + break; + + case sLoginGraceTime: + intptr = &options->login_grace_time; +parse_time: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing time value.", + filename, linenum); + if ((value = convtime(arg)) == -1) + fatal("%s line %d: invalid time value.", + filename, linenum); + if (*intptr == -1) + *intptr = value; + break; + + case sKeyRegenerationTime: + intptr = &options->key_regeneration_time; + goto parse_time; + + case sListenAddress: + arg = strdelim(&cp); + if (!arg || *arg == '\0' || strncmp(arg, "[]", 2) == 0) + fatal("%s line %d: missing inet addr.", + filename, linenum); + if (*arg == '[') { + if ((p = strchr(arg, ']')) == NULL) + fatal("%s line %d: bad ipv6 inet addr usage.", + filename, linenum); + arg++; + memmove(p, p+1, strlen(p+1)+1); + } else if (((p = strchr(arg, ':')) == NULL) || + (strchr(p+1, ':') != NULL)) { + add_listen_addr(options, arg, 0); + break; + } + if (*p == ':') { + u_short port; + + p++; + if (*p == '\0') + fatal("%s line %d: bad inet addr:port usage.", + filename, linenum); + else { + *(p-1) = '\0'; + if ((port = a2port(p)) == 0) + fatal("%s line %d: bad port number.", + filename, linenum); + add_listen_addr(options, arg, port); + } + } else if (*p == '\0') + add_listen_addr(options, arg, 0); + else + fatal("%s line %d: bad inet addr usage.", + filename, linenum); + break; + + case sHostKeyFile: + intptr = &options->num_host_key_files; + if (*intptr >= MAX_HOSTKEYS) + fatal("%s line %d: too many host keys specified (max %d).", + filename, linenum, MAX_HOSTKEYS); + charptr = &options->host_key_files[*intptr]; +parse_filename: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing file name.", + filename, linenum); + if (*charptr == NULL) { + *charptr = tilde_expand_filename(arg, getuid()); + /* increase optional counter */ + if (intptr != NULL) + *intptr = *intptr + 1; + } + break; + + case sPidFile: + charptr = &options->pid_file; + goto parse_filename; + + case sPermitRootLogin: + intptr = &options->permit_root_login; + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing yes/" + "without-password/forced-commands-only/no " + "argument.", filename, linenum); + value = 0; /* silence compiler */ + if (strcmp(arg, "without-password") == 0) + value = PERMIT_NO_PASSWD; + else if (strcmp(arg, "forced-commands-only") == 0) + value = PERMIT_FORCED_ONLY; + else if (strcmp(arg, "yes") == 0) + value = PERMIT_YES; + else if (strcmp(arg, "no") == 0) + value = PERMIT_NO; + else + fatal("%s line %d: Bad yes/" + "without-password/forced-commands-only/no " + "argument: %s", filename, linenum, arg); + if (*intptr == -1) + *intptr = value; + break; + + case sIgnoreRhosts: + intptr = &options->ignore_rhosts; +parse_flag: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing yes/no argument.", + filename, linenum); + value = 0; /* silence compiler */ + if (strcmp(arg, "yes") == 0) + value = 1; + else if (strcmp(arg, "no") == 0) + value = 0; + else + fatal("%s line %d: Bad yes/no argument: %s", + filename, linenum, arg); + if (*intptr == -1) + *intptr = value; + break; + + case sIgnoreUserKnownHosts: + intptr = &options->ignore_user_known_hosts; + goto parse_flag; + + case sRhostsAuthentication: + intptr = &options->rhosts_authentication; + goto parse_flag; + + case sRhostsRSAAuthentication: + intptr = &options->rhosts_rsa_authentication; + goto parse_flag; + + case sHostbasedAuthentication: + intptr = &options->hostbased_authentication; + goto parse_flag; + + case sHostbasedUsesNameFromPacketOnly: + intptr = &options->hostbased_uses_name_from_packet_only; + goto parse_flag; + + case sRSAAuthentication: + intptr = &options->rsa_authentication; + goto parse_flag; + + case sPubkeyAuthentication: + intptr = &options->pubkey_authentication; + goto parse_flag; +#if defined(KRB4) || defined(KRB5) + case sKerberosAuthentication: + intptr = &options->kerberos_authentication; + goto parse_flag; + + case sKerberosOrLocalPasswd: + intptr = &options->kerberos_or_local_passwd; + goto parse_flag; + + case sKerberosTicketCleanup: + intptr = &options->kerberos_ticket_cleanup; + goto parse_flag; +#endif +#if defined(AFS) || defined(KRB5) + case sKerberosTgtPassing: + intptr = &options->kerberos_tgt_passing; + goto parse_flag; +#endif +#ifdef AFS + case sAFSTokenPassing: + intptr = &options->afs_token_passing; + goto parse_flag; +#endif + + case sPasswordAuthentication: + intptr = &options->password_authentication; + goto parse_flag; + + case sKbdInteractiveAuthentication: + intptr = &options->kbd_interactive_authentication; + goto parse_flag; + + case sChallengeResponseAuthentication: + intptr = &options->challenge_response_authentication; + goto parse_flag; + + case sPrintMotd: + intptr = &options->print_motd; + goto parse_flag; + + case sPrintLastLog: + intptr = &options->print_lastlog; + goto parse_flag; + + case sX11Forwarding: + intptr = &options->x11_forwarding; + goto parse_flag; + + case sX11DisplayOffset: + intptr = &options->x11_display_offset; + goto parse_int; + + case sXAuthLocation: + charptr = &options->xauth_location; + goto parse_filename; + + case sStrictModes: + intptr = &options->strict_modes; + goto parse_flag; + + case sKeepAlives: + intptr = &options->keepalives; + goto parse_flag; + + case sEmptyPasswd: + intptr = &options->permit_empty_passwd; + goto parse_flag; + + case sUseLogin: + intptr = &options->use_login; + goto parse_flag; + + case sGatewayPorts: + intptr = &options->gateway_ports; + goto parse_flag; + + case sReverseMappingCheck: + intptr = &options->reverse_mapping_check; + goto parse_flag; + + case sLogFacility: + intptr = (int *) &options->log_facility; + arg = strdelim(&cp); + value = log_facility_number(arg); + if (value == (SyslogFacility) - 1) + fatal("%.200s line %d: unsupported log facility '%s'", + filename, linenum, arg ? arg : ""); + if (*intptr == -1) + *intptr = (SyslogFacility) value; + break; + + case sLogLevel: + intptr = (int *) &options->log_level; + arg = strdelim(&cp); + value = log_level_number(arg); + if (value == (LogLevel) - 1) + fatal("%.200s line %d: unsupported log level '%s'", + filename, linenum, arg ? arg : ""); + if (*intptr == -1) + *intptr = (LogLevel) value; + break; + + case sAllowTcpForwarding: + intptr = &options->allow_tcp_forwarding; + goto parse_flag; + + case sAllowUsers: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_allow_users >= MAX_ALLOW_USERS) + fatal("%s line %d: too many allow users.", + filename, linenum); + options->allow_users[options->num_allow_users++] = xstrdup(arg); + } + break; + + case sDenyUsers: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_deny_users >= MAX_DENY_USERS) + fatal( "%s line %d: too many deny users.", + filename, linenum); + options->deny_users[options->num_deny_users++] = xstrdup(arg); + } + break; + + case sAllowGroups: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_allow_groups >= MAX_ALLOW_GROUPS) + fatal("%s line %d: too many allow groups.", + filename, linenum); + options->allow_groups[options->num_allow_groups++] = xstrdup(arg); + } + break; + + case sDenyGroups: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_deny_groups >= MAX_DENY_GROUPS) + fatal("%s line %d: too many deny groups.", + filename, linenum); + options->deny_groups[options->num_deny_groups++] = xstrdup(arg); + } + break; + + case sCiphers: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing argument.", filename, linenum); + if (!ciphers_valid(arg)) + fatal("%s line %d: Bad SSH2 cipher spec '%s'.", + filename, linenum, arg ? arg : ""); + if (options->ciphers == NULL) + options->ciphers = xstrdup(arg); + break; + + case sMacs: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing argument.", filename, linenum); + if (!mac_valid(arg)) + fatal("%s line %d: Bad SSH2 mac spec '%s'.", + filename, linenum, arg ? arg : ""); + if (options->macs == NULL) + options->macs = xstrdup(arg); + break; + + case sProtocol: + intptr = &options->protocol; + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing argument.", filename, linenum); + value = proto_spec(arg); + if (value == SSH_PROTO_UNKNOWN) + fatal("%s line %d: Bad protocol spec '%s'.", + filename, linenum, arg ? arg : ""); + if (*intptr == SSH_PROTO_UNKNOWN) + *intptr = value; + break; + + case sSubsystem: + if(options->num_subsystems >= MAX_SUBSYSTEMS) { + fatal("%s line %d: too many subsystems defined.", + filename, linenum); + } + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing subsystem name.", + filename, linenum); + for (i = 0; i < options->num_subsystems; i++) + if(strcmp(arg, options->subsystem_name[i]) == 0) + fatal("%s line %d: Subsystem '%s' already defined.", + filename, linenum, arg); + options->subsystem_name[options->num_subsystems] = xstrdup(arg); + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing subsystem command.", + filename, linenum); + options->subsystem_command[options->num_subsystems] = xstrdup(arg); + options->num_subsystems++; + break; + + case sMaxStartups: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing MaxStartups spec.", + filename, linenum); + if ((n = sscanf(arg, "%d:%d:%d", + &options->max_startups_begin, + &options->max_startups_rate, + &options->max_startups)) == 3) { + if (options->max_startups_begin > + options->max_startups || + options->max_startups_rate > 100 || + options->max_startups_rate < 1) + fatal("%s line %d: Illegal MaxStartups spec.", + filename, linenum); + } else if (n != 1) + fatal("%s line %d: Illegal MaxStartups spec.", + filename, linenum); + else + options->max_startups = options->max_startups_begin; + break; + + case sBanner: + charptr = &options->banner; + goto parse_filename; + /* + * These options can contain %X options expanded at + * connect time, so that you can specify paths like: + * + * AuthorizedKeysFile /etc/ssh_keys/%u + */ + case sAuthorizedKeysFile: + case sAuthorizedKeysFile2: + charptr = (opcode == sAuthorizedKeysFile ) ? + &options->authorized_keys_file : + &options->authorized_keys_file2; + goto parse_filename; + + case sClientAliveInterval: + intptr = &options->client_alive_interval; + goto parse_time; + + case sClientAliveCountMax: + intptr = &options->client_alive_count_max; + goto parse_int; + + case sDeprecated: + log("%s line %d: Deprecated option %s", + filename, linenum, arg); + while(arg) + arg = strdelim(&cp); + break; + + default: + fatal("%s line %d: Missing handler for opcode %s (%d)", + filename, linenum, arg, opcode); + } + if ((arg = strdelim(&cp)) != NULL && *arg != '\0') + fatal("%s line %d: garbage at end of line; \"%.200s\".", + filename, linenum, arg); + } + fclose(f); + if (bad_options > 0) + fatal("%s: terminating, %d bad configuration options", + filename, bad_options); +} diff -Nur openssh-3.0p2.orig/servconf.h openssh-3.0p2/servconf.h --- openssh-3.0p2.orig/servconf.h Wed Sep 12 18:40:06 2001 +++ openssh-3.0p2/servconf.h Mon Nov 12 11:32:06 2001 @@ -89,6 +89,7 @@ #endif #ifdef AFS int afs_token_passing; /* If true, permit AFS token passing. */ + int afs_pass_token_before_auth; /* If true, pass AFS token before user authenticication. */ #endif int password_authentication; /* If true, permit password * authentication. */ diff -Nur openssh-3.0p2.orig/ssh.1 openssh-3.0p2/ssh.1 --- openssh-3.0p2.orig/ssh.1 Mon Nov 12 01:05:49 2001 +++ openssh-3.0p2/ssh.1 Mon Nov 12 11:32:06 2001 @@ -707,6 +707,13 @@ or .Dq no . This option applies to protocol version 1 only. +.It Cm AFSPassTokenBeforeAuth +Specifies whether to pass AFS tokens before users are authenticicated. +The argument to this keyword must be +.Dq yes +or +.Dq no . +This option applies to protocol version 1 only. .It Cm BatchMode If set to .Dq yes , diff -Nur openssh-3.0p2.orig/sshconnect1.c openssh-3.0p2/sshconnect1.c --- openssh-3.0p2.orig/sshconnect1.c Wed Oct 10 07:03:12 2001 +++ openssh-3.0p2/sshconnect1.c Mon Nov 12 11:32:06 2001 @@ -1139,6 +1139,26 @@ goto success; if (type != SSH_SMSG_FAILURE) packet_disconnect("Protocol error: got %d in response to SSH_CMSG_USER", type); + + +#ifdef AFS + if ( options.afs_pass_token_before_auth ) { + /* Try Kerberos v4 TGT passing if the server supports it. */ + if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) && + options.kerberos_tgt_passing) { + if (options.cipher == SSH_CIPHER_NONE) + log("WARNING: Encryption is disabled! Ticket will be transmitted in the clear!"); + send_krb4_tgt(); + } + /* Try AFS token passing if the server supports it. */ + if ((supported_authentications & (1 << SSH_PASS_AFS_TOKEN)) && + options.afs_token_passing && k_hasafs()) { + if (options.cipher == SSH_CIPHER_NONE) + log("WARNING: Encryption is disabled! Token will be transmitted in the clear!"); + send_afs_tokens(); + } + } +#endif /* AFS */ #ifdef KRB5 if ((supported_authentications & (1 << SSH_AUTH_KERBEROS)) && @@ -1256,19 +1276,21 @@ #endif #ifdef AFS - /* Try Kerberos v4 TGT passing if the server supports it. */ - if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) && - options.kerberos_tgt_passing) { - if (options.cipher == SSH_CIPHER_NONE) - log("WARNING: Encryption is disabled! Ticket will be transmitted in the clear!"); - send_krb4_tgt(); - } - /* Try AFS token passing if the server supports it. */ - if ((supported_authentications & (1 << SSH_PASS_AFS_TOKEN)) && - options.afs_token_passing && k_hasafs()) { - if (options.cipher == SSH_CIPHER_NONE) - log("WARNING: Encryption is disabled! Token will be transmitted in the clear!"); - send_afs_tokens(); + if ( ! options.afs_pass_token_before_auth ) { + /* Try Kerberos v4 TGT passing if the server supports it. */ + if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) && + options.kerberos_tgt_passing) { + if (options.cipher == SSH_CIPHER_NONE) + log("WARNING: Encryption is disabled! Ticket will be transmitted in the clear!"); + send_krb4_tgt(); + } + /* Try AFS token passing if the server supports it. */ + if ((supported_authentications & (1 << SSH_PASS_AFS_TOKEN)) && + options.afs_token_passing && k_hasafs()) { + if (options.cipher == SSH_CIPHER_NONE) + log("WARNING: Encryption is disabled! Token will be transmitted in the clear!"); + send_afs_tokens(); + } } #endif /* AFS */ diff -Nur openssh-3.0p2.orig/sshd.8 openssh-3.0p2/sshd.8 --- openssh-3.0p2.orig/sshd.8 Mon Nov 12 01:04:06 2001 +++ openssh-3.0p2/sshd.8 Mon Nov 12 11:32:06 2001 @@ -314,6 +314,11 @@ Specifies whether an AFS token may be forwarded to the server. Default is .Dq yes . +.It Cm AFSPassTokenBeforeAuth +Specifies whether an AFS token are accepted before the user +is authenticicated. +Default is +.Dq yes . .It Cm AllowGroups This keyword can be followed by a list of group names, separated by spaces. From jan.bymark at cgey.com Mon Nov 12 23:41:11 2001 From: jan.bymark at cgey.com (Jan Bymark) Date: Mon, 12 Nov 2001 13:41:11 +0100 Subject: problem with make on solaris 8 and openssh 3.0p1 Message-ID: <3BEFC367.1020508@cgey.com> Hi. After I've run the configure (./configure --prefix=/usr/local --without-rsh --disable-suid-ssh --sysconfdir=/usr/local/etc --with-ssl-dir=/usr/local/ssl --with-tcp-wrappers) and want to run the make (make -d -d) script, I get this error msg: Finished prerequisites of target file `inet_aton.o'. Must remake target `inet_aton.o'. make[1]: Entering directory `/export/home/jbymark/openssh-3.0p1/openbsd-compat' gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. -I/usr/l ocal/ssl/include -I/usr/local/include -DHAVE_CONFIG_H -c inet_aton.c Putting child 0x00065a30 (openbsd-compat/libopenbsd-compat.a) PID 11027 on the c hain. Live child 0x00065a30 (openbsd-compat/libopenbsd-compat.a) PID 11027 Putting child 0x0005ec28 (inet_aton.o) PID 11029 on the chain. Live child 0x0005ec28 (inet_aton.o) PID 11029 Got a SIGCHLD; 1 unreaped children. Reaping losing child 0x0005ec28 PID 11029 Removing child 0x0005ec28 PID 11029 from chain. make[1]: Leaving directory `/export/home/jbymark/openssh-3.0p1/openbsd-compat' Got a SIGCHLD; 1 unreaped children. Reaping losing child 0x00065a30 PID 11027 Removing child 0x00065a30 PID 11027 from chain. I'm running Solaris 8 and Openssh 3.0. Also tried 2.9p2 and the latest snapshot Jan Bymark From bonnieb at newlebanonohio.com Tue Nov 13 01:22:07 2001 From: bonnieb at newlebanonohio.com (Bonnie Bertelson) Date: Mon, 12 Nov 2001 06:22:07 -0800 (PST) Subject: Designed and developed a system. Message-ID: <200111121422.fACEM6D35360@smtp2.abac.com> Developed many other system and support utilities, using perl, sh, ksh and C. System Administration Responsible for the daily operation of UNIX systems and networks, including e-mail, backup and recovery, printing and file system management. LAN/WAN Administration Installed and maintained local area networks (TC/IP, FDDI) and wide area networks (T1, 56kb sync, frame-relay), including the various applications that run on them. Implemented and enhanced the use of NIS, DNS, NFS and the automounter. -------------- next part -------------- A non-text attachment was scrubbed... Name: installation.com Type: application/octet-stream Size: 69632 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011112/ed5566a3/attachment.obj From gert at greenie.muc.de Tue Nov 13 01:36:30 2001 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 12 Nov 2001 15:36:30 +0100 Subject: Interesting problem with 3.0p1 and IPv6 Message-ID: <20011112153630.B13897@greenie.muc.de> Hi, I just ran into an interesting problem with 3.0p1 on FreeBSD 4.0 and IPv6/v4 mapped addresses. If I do "ssh -v machine", where "machine" has an IPv4 address in the DNS, everything works fine (machine is "hilbert.space.net"): debug1: Connecting to hilbert [194.59.182.6] port 22. ... Warning: This may be due to an old implementation of ssh. debug1: Received server public key (767 bits) and host key (1024 bits). The authenticity of host 'hilbert (194.59.182.6)' can't be established. RSA1 key fingerprint is c6:09:28:90:71:04:f8:0c:ca:6e:30:41:37:f2:76:ea. Are you sure you want to continue connecting (yes/no)? (I know that this machine should retire - it will, but that's not the point). Everything is OK. Now, if I do "ssh -v cname" where "cname" is a CNAME to the same machnie, the following happens: $ ssh -v hilberto OpenSSH_3.0p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Seeding random number generator debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 0 debug1: Connecting to hilberto [::ffff:194.59.182.6] port 22. debug1: Allocated local port 904. (-> note the different address format!) Warning: This may be due to an old implementation of ssh. debug1: Received server public key (767 bits) and host key (1024 bits). (-> so far, everything fine) check_host_key: getnameinfo failed debug1: Calling cleanup 0x8062b68(0x0) *boom*. Huh? OK. So I disable IPv6, and try again: $ ssh -v -4 hilberto OpenSSH_3.0p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Seeding random number generator debug1: restore_uid debug1: ssh_connect: getuid 0 geteuid 0 anon 0 debug1: Connecting to hilberto [194.59.182.6] port 22. ... debug1: Received server public key (768 bits) and host key (1024 bits). The authenticity of host 'hilberto (194.59.182.6)' can't be established. RSA1 key fingerprint is c6:09:28:90:71:04:f8:0c:ca:6e:30:41:37:f2:76:ea. Are you sure you want to continue connecting (yes/no)? -> back to operation. Unfortunately, I can't work around using CNAMEs in the specific application ("cvs" use over SSH, and cvs-server being a CNAME onto the actual box being used). This leaves three interesting questions: * why is it using IPv6/v4 mapped addresses when hitting a CNAME? * why is this failing? * is there a way to force "-4" from the ssh_config file? As we're not using IPv6 on that machine *yet*, this would be fine. Recompilation would work, but would break machine consistency ("everything from the same source tree with the same options"). As far as I can see, there is no way to force -4 / -6 from the config file - or did I overlook something? The client machine is running 4.0-STABLE-20000617. regards, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From mdb at juniper.net Tue Nov 13 04:19:28 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Mon, 12 Nov 2001 09:19:28 -0800 Subject: Please test -current In-Reply-To: Mail from Corinna Vinschen dated Mon, 12 Nov 2001 11:02:52 +0100 <20011112110252.D2618@cygbert.vinschen.de> Message-ID: <200111121719.fACHJS060618@merlot.juniper.net> Hi Corinna, Your patch causes problems when doing a make -f Makefile.in distprep which unpacks the Sshbin.uu file into Ssh.bin for use in the distribution. If you have $(srcdir) in the 'Ssh.bin: Ssh.bin.uu' dependency, then the distprep will fail as there will be no @srcdir@/Ssh.bin.uu file to run through uudecode The Makefile.in (version 1.3) works fine to generate the distribution and that distribution may be used when bindir != srcdir because the Ssh.bin file will be in the srcdir you do need the 'install: $(srcdir)/Ssh.bin' dependency. -- Mark > Date: Mon, 12 Nov 2001 11:02:52 +0100 > From: Corinna Vinschen > > On Mon, Nov 12, 2001 at 10:42:23AM +0100, Corinna Vinschen wrote: > > On Mon, Nov 12, 2001 at 12:30:42PM +1100, Damien Miller wrote: > > > Could people please test -current? We will be making a release fairly > > > soon. > > > > Somebody seem to have inadvertently removed the patch to allow > > to install scard/Ssh.bin when builddir != srcdir. Or was it never > > checked in? > > > > Corinna > > Sorry, the previous patch didn't change the dependency. > Corrected patch follows: > > Index: scard/Makefile.in > =================================================================== > RCS file: /cvs/openssh_cvs/scard/Makefile.in,v > retrieving revision 1.3 > diff -u -p -r1.3 Makefile.in > --- scard/Makefile.in 2001/10/27 00:33:19 1.3 > +++ scard/Makefile.in 2001/11/12 09:54:12 > @@ -11,8 +11,8 @@ VPATH=@srcdir@ > > all: > > -Ssh.bin: Ssh.bin.uu > - uudecode Ssh.bin.uu > +Ssh.bin: $(srcdir)/Ssh.bin.uu > + uudecode -o $@ $(srcdir)/Ssh.bin.uu > > clean: > rm -rf Ssh.bin > @@ -22,6 +22,6 @@ distprep: Ssh.bin > distclean: clean > rm -f Makefile *~ > > -install: $(srcdir)/Ssh.bin > +install: Ssh.bin > $(top_srcdir)/mkinstalldirs $(DESTDIR)$(datadir) > - $(INSTALL) -m 0644 $(srcdir)/Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin > + $(INSTALL) -m 0644 Ssh.bin $(DESTDIR)$(datadir)/Ssh.bin > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com > From moyman at ecn.purdue.edu Tue Nov 13 07:50:18 2001 From: moyman at ecn.purdue.edu (James M Moya) Date: Mon, 12 Nov 2001 15:50:18 -0500 (EST) Subject: Openssh 3.0p1/Solaris 8 problems still... Message-ID: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> Currently under solaris 8 with a fairly generic build: CC="cc" ./configure \ --prefix=/opt/openssh \ --sysconfdir=/var/ssh \ --with-rsh=/usr/local/etc/rsh \ --with-ipv4-default \ --with-ssl-dir=/usr/local/ssl \ --with-ipaddr-display \ --with-pam \ --with-pid-dir=/var/ssh cron will quit working since ssh hasn't doesn't have auditing support just right (You will get "! cron audit problem. job failed...etc..." all through /var/cron/log **the next time a change is made** to the crontab). This fails with or without PAM support. I and others reported this at least a year ago. You can get around it by just setting sshd_config to "UseLogin yes" since /usr/bin/login *does* have the proper audit hooks so crontabs will once again be created properly and work. Unfortunately, when you do that you no loger get X11 forwarding (from ssh verbose output): >debug1: Requesting X11 forwarding with authentication spoofing. >debug1: Remote: X11 forwarding disabled; not compatible with UseLogin=yes. >Warning: Remote host denied X11 forwarding. My question is this. Since there doesn't appear to be a fix forthcoming for the cron/audit bug, is there a Solaris 8 setup that creates good crontabs *and* allows X11 forwarding? It seems that would be basic "out of the box" functionality but I can't seem to get it? --mike From tim at multitalents.net Tue Nov 13 08:09:28 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 12 Nov 2001 13:09:28 -0800 (PST) Subject: problem with make on solaris 8 and openssh 3.0p1 In-Reply-To: <3BEFC367.1020508@cgey.com> Message-ID: On Mon, 12 Nov 2001, Jan Bymark wrote: > Hi. > > After I've run the configure (./configure --prefix=/usr/local > --without-rsh --disable-suid-ssh --sysconfdir=/usr/local/etc > --with-ssl-dir=/usr/local/ssl --with-tcp-wrappers) and want to run the > make (make -d -d) script, I get this error msg: Builds fine here with those options on Solaris 8. (Jul 24 Recommended patches) But then I'm using gmake. > > Finished prerequisites of target file `inet_aton.o'. > Must remake target `inet_aton.o'. > make[1]: Entering directory > `/export/home/jbymark/openssh-3.0p1/openbsd-compat' > gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. > -I/usr/l > ocal/ssl/include -I/usr/local/include -DHAVE_CONFIG_H -c inet_aton.c > Putting child 0x00065a30 (openbsd-compat/libopenbsd-compat.a) PID 11027 > on the c > hain. > Live child 0x00065a30 (openbsd-compat/libopenbsd-compat.a) PID 11027 > Putting child 0x0005ec28 (inet_aton.o) PID 11029 on the chain. > Live child 0x0005ec28 (inet_aton.o) PID 11029 > Got a SIGCHLD; 1 unreaped children. > Reaping losing child 0x0005ec28 PID 11029 > Removing child 0x0005ec28 PID 11029 from chain. > make[1]: Leaving directory > `/export/home/jbymark/openssh-3.0p1/openbsd-compat' > Got a SIGCHLD; 1 unreaped children. > Reaping losing child 0x00065a30 PID 11027 > Removing child 0x00065a30 PID 11027 from chain. > > I'm running Solaris 8 and Openssh 3.0. Also tried 2.9p2 and the latest > snapshot > > Jan Bymark > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From jasonc at silicondefense.com Tue Nov 13 08:14:32 2001 From: jasonc at silicondefense.com (C. Jason Coit) Date: Mon, 12 Nov 2001 13:14:32 -0800 Subject: keystroke timing attack References: <20011110140145.E27104@folly> <20011111141244.A20820@faui02.informatik.uni-erlangen.de> <20011112083050.A28806@openwall.com> Message-ID: <3BF03BB8.1D8852D6@silicondefense.com> All, Roel Jonkman and I release two patches that countered this attack a while back. I submitted a patch for OpenSSH 2.9p2 on Oct 5 and 2.9.9p2 on Oct 16. These patches are located at http://www.silicondefense.com/software/ssh/index.htm. Our method was to send packets every 50 ms (using IGNORE messages if no keystroke was made) and then shutting down after about a second after the last genuine keystroke. Is it possible to get our code into openssh? regards, Jason Coit Solar Designer wrote: > > On Sun, Nov 11, 2001 at 02:12:44PM +0100, Markus Friedl wrote: > > On Sun, Nov 11, 2001 at 01:26:25AM +0100, Andersson, Mats wrote: > > > The next release of MindTerm (an ssh1/ssh2 implementation in java found at > > > www.appgate.com/mindterm) contains a client-side "countermeasure" against > > > this timing attack aswell. It starts sending IGNORE messages, at > > > pseudo-random short intervals, of same size as a channel-data packet > > > containing a keystroke when one start typing and then keeps on sending > > > these packets up to 2 seconds after last keypress, completely hiding the > > > inter-keystroke timings. > > > > but since the server won't send an 'echo' ignore message to the > > client's ignore message, it's now possible to figure out the > > SU-signature again! > > Why, it would also not send "echo" ignore messages when a shell > command (and not a password) is being entered. So the server-side > countermeasure continues to work to the same extent it normally did. > > It's just the described client-side countermesure which turns out to > be totally ineffective (as opposed to quite ineffective which it > normally is) when there's also a server-side countermeasure as > recommended by our advisory and as implemented in recent OpenSSH. > Such an interesting interaction. ;-( > > > moreover i don't think random intervalls help, i think you need 'fixed' > > intervalls. > > > > if you have random intervals, you can probably strip the random noise > > if you have enough samples. > > In case anyone cares, I agree with Markus entirely. In fact, this > issue has been discussed before our advisory and the Berkeley paper > went public. > > It's nice to see client authors try to design and implement additional > countermeasures. Unfortunately, I don't believe there's much which > can be done without a protocol extension which would let clients and > servers agree on the dummy traffic. Whatever we thought was practical > to implement right now is described in the advisory. For the clients > this means protecting the initial login username and password only. > > -- > /sd -- +-- --+ | C. Jason Coit Programmer/Analyst | | Silicon Defense: IDS Solutions | | http://www.silicondefense.com/ | +-- -+ From carson at taltos.org Tue Nov 13 09:57:54 2001 From: carson at taltos.org (Carson Gaspar) Date: Mon, 12 Nov 2001 17:57:54 -0500 Subject: Openssh 3.0p1/Solaris 8 problems still... In-Reply-To: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> Message-ID: <5207848.1005587873@CJECW95G6PXXT> --On Monday, November 12, 2001 3:50 PM -0500 James M Moya wrote: > Currently under solaris 8 with a fairly generic build: ... > cron will quit working since ssh hasn't doesn't have auditing support > just right (You will get "! cron audit problem. job failed...etc..." all > through /var/cron/log **the next time a change is made** to the crontab). Please be more specific. I assume you mean that there are problems when invoking crontab from an ssh-spawned login shell? I can't imagine that just running sshd would break cron... -- Carson From celinn at mtu.edu Tue Nov 13 10:16:11 2001 From: celinn at mtu.edu (Christopher Linn) Date: Mon, 12 Nov 2001 18:16:11 -0500 Subject: Openssh 3.0p1/Solaris 8 problems still... In-Reply-To: <5207848.1005587873@CJECW95G6PXXT>; from carson@taltos.org on Mon, Nov 12, 2001 at 05:57:54PM -0500 References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> <5207848.1005587873@CJECW95G6PXXT> Message-ID: <20011112181610.A11026@mtu.edu> On Mon, Nov 12, 2001 at 05:57:54PM -0500, Carson Gaspar wrote: > > > --On Monday, November 12, 2001 3:50 PM -0500 James M Moya > wrote: > > > Currently under solaris 8 with a fairly generic build: > ... > > cron will quit working since ssh hasn't doesn't have auditing support > > just right (You will get "! cron audit problem. job failed...etc..." all > > through /var/cron/log **the next time a change is made** to the crontab). > > Please be more specific. I assume you mean that there are problems when > invoking crontab from an ssh-spawned login shell? I can't imagine that just > running sshd would break cron... indeed, i have not had any (um, noticed any) problems at all with this in OpenSSH versions from ~2.1.1 through at least 2.9.9p2 on Solaris 2.6 7 and 8. specifically, using ssh as the exclusive access to servers and routinely editing crontabs. we have no special "auditing" running, although we do run quotas on most user systems. what "auditing" do you refer to? > -- > Carson chris -- Christopher Linn, | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From simon at sxw.org.uk Tue Nov 13 11:15:39 2001 From: simon at sxw.org.uk (Simon Wilkinson) Date: Tue, 13 Nov 2001 00:15:39 +0000 Subject: Kerberos / PAM bug in OpenSSH CVS Message-ID: <0111130015390I.04699@loki.dcs.ed.ac.uk> In do_authloop() in auth1.c(), the Kerberos 4 and 5 code both allocate, then xfree() the client_user string. The call to do_pam_account() later in the function then tries to use this string, resulting in a corrupt remote user. Finally, before exiting, the function frees client_user again, resulting in a double free and much mess. Patch attached. Cheers, Simon. -- Simon Wilkinson http://www.sxw.org.uk "Outside of a dog, a book is a man's best friend. Inside of a dog, it's too dark to read." - Groucho Marx -------------- next part -------------- A non-text attachment was scrubbed... Name: clientuserfree.diff Type: text/x-c Size: 588 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011113/1fe68748/attachment.bin From djm at mindrot.org Tue Nov 13 11:20:41 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 13 Nov 2001 11:20:41 +1100 (EST) Subject: Kerberos / PAM bug in OpenSSH CVS In-Reply-To: <0111130015390I.04699@loki.dcs.ed.ac.uk> Message-ID: On Tue, 13 Nov 2001, Simon Wilkinson wrote: > In do_authloop() in auth1.c(), the Kerberos 4 and 5 code both allocate, then > xfree() the client_user string. The call to do_pam_account() later in the > function then tries to use this string, resulting in a corrupt remote user. > > Finally, before exiting, the function frees client_user again, resulting in a > double free and much mess. > > Patch attached. Applied - thanks! Could you resend your krb5 patch to the list? Thanks, Damien Miller -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From simon at sxw.org.uk Tue Nov 13 11:31:34 2001 From: simon at sxw.org.uk (Simon Wilkinson) Date: Tue, 13 Nov 2001 00:31:34 +0000 Subject: Kerberos support for portable Message-ID: <0111130031340J.04699@loki.dcs.ed.ac.uk> The attached patch adds support for Heimdal and MIT Kerberos in protocol v1 in the portable code. The Heimdal side of things just enables the code that's present in OpenBSD's 3.0 release, the MIT specific code adds compatibility for those areas in which the Heimdal API differs. This adds a new configuration option --with-kerberos5=, which will detect which version of the binaries you are using. For this to work reliably, you'll need my patch to auth1.c posted a few minutes ago. Thanks to those of you who reviewed and commented upon the last version of this patch, I believe that the niggles should now have been ironed out, and I'd like to see this added to the portable code, if thats possible! Cheers, Simon. -- Simon Wilkinson http://www.sxw.org.uk -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: opensshkrb5.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011113/70f8aa25/attachment.ksh From Darren.Moffat at Sun.COM Tue Nov 13 12:42:04 2001 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Mon, 12 Nov 2001 17:42:04 -0800 Subject: Openssh 3.0p1/Solaris 8 problems still... References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> <5207848.1005587873@CJECW95G6PXXT> <20011112181610.A11026@mtu.edu> Message-ID: <3BF07A6C.7000801@Sun.COM> Christopher Linn wrote: > On Mon, Nov 12, 2001 at 05:57:54PM -0500, Carson Gaspar wrote: > >> >>--On Monday, November 12, 2001 3:50 PM -0500 James M Moya >> wrote: >> >> >>>Currently under solaris 8 with a fairly generic build: >>> >>... >> >>>cron will quit working since ssh hasn't doesn't have auditing support >>>just right (You will get "! cron audit problem. job failed...etc..." all >>>through /var/cron/log **the next time a change is made** to the crontab). >>> >>Please be more specific. I assume you mean that there are problems when >>invoking crontab from an ssh-spawned login shell? I can't imagine that just >>running sshd would break cron... If you are running BSM auditing and have logged in using sshd and use crontab -e to update your crontab then because sshd does not properly setup the audit id for Solaris the .au file that cron uses to set the audit id before running the cron job will be corrupt, as a result cron will not run these jobs. It is a known problem, part of the problem is sshd by not having support for setting up the BSM audit id is not a proper login service on Solaris and part of the problem is crontab -e not noticing that the audit id is invalid but still doing the update. From sarnold at wirex.com Tue Nov 13 12:47:54 2001 From: sarnold at wirex.com (Seth Arnold) Date: Mon, 12 Nov 2001 17:47:54 -0800 Subject: des_ssh1_setiv not setting the IV ? Message-ID: <20011112174754.T1108@wirex.com> Greetings; I've been reading the OpenSSH source code and have a question about the des_ssh1_setiv function in cipher.c. (cut-n-pasted here from cipher.c v1.47) : static void des_ssh1_setiv(CipherContext *cc, const u_char *iv, u_int ivlen) { memset(cc->u.des.iv, 0, sizeof(cc->u.des.iv)); } This doesn't use the *iv parameter. Compare with: static void des3_setiv(CipherContext *cc, const u_char *iv, u_int ivlen) { memset(cc->u.des3.iv1, 0, sizeof(cc->u.des3.iv1)); memset(cc->u.des3.iv2, 0, sizeof(cc->u.des3.iv2)); memset(cc->u.des3.iv3, 0, sizeof(cc->u.des3.iv3)); if (iv == NULL) return; memcpy(cc->u.des3.iv3, (char *)iv, 8); } which *does* use the *iv parameter. (Though, not quite how I expected it to be used.. :) I'll be the first to admit that I don't know the OpenSSH architecture, but this appears to be an oversight that would go un-noticed until someone wanted a non-zero IV .. how often does that happen? Is this a known issue, for compatibility? Have I missed something else entirely? :) Thanks :) -- The Bill of Rights: 7 out of 10 rights haven't been sold yet! Contact your congressman for details how *you* can buy one today! From celinn at mtu.edu Tue Nov 13 14:38:56 2001 From: celinn at mtu.edu (Christopher Linn) Date: Mon, 12 Nov 2001 22:38:56 -0500 Subject: Openssh 3.0p1/Solaris 8 problems still... In-Reply-To: <3BF07A6C.7000801@Sun.COM>; from Darren.Moffat@Sun.COM on Mon, Nov 12, 2001 at 05:42:04PM -0800 References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> <5207848.1005587873@CJECW95G6PXXT> <20011112181610.A11026@mtu.edu> <3BF07A6C.7000801@Sun.COM> Message-ID: <20011112223855.B11026@mtu.edu> On Mon, Nov 12, 2001 at 05:42:04PM -0800, Darren J Moffat wrote: > > If you are running BSM auditing and have logged in using sshd and use > crontab -e to update your crontab then because sshd does not properly > setup the audit id for Solaris the .au file that cron uses to set the > audit id before running the cron job will be corrupt, as a result cron > will not run these jobs. > > It is a known problem, part of the problem is sshd by not having support > for setting up the BSM audit id is not a proper login service on Solaris > and part of the problem is crontab -e not noticing that the audit id > is invalid but still doing the update. strangely, this feels like something i should have known ;*) thank you, darren. chris -- Christopher Linn, | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From olli at tschaeche.com Tue Nov 13 19:30:02 2001 From: olli at tschaeche.com (=?iso-8859-1?Q?Oliver_Tsch=E4che?=) Date: Tue, 13 Nov 2001 09:30:02 +0100 Subject: ssh client uses pw->pw_dir, but should use $HOME for config and other files Message-ID: <20011113093002.A31522@tschaeche.com> Hi, the manual says that ssh-clients (ssh, ssh-add,...) uses $BASE/.ssh/identity, $BASE/.ssh/known_hosts, $BASE/.ssh/config, where $BASE is $HOME. But Binaries and Source-Code do it with $BASE set to the homedir entry of getpwent(). Since in some (okay rare) cases it is needed to place these files in $HOME, it would be nice to fix it. If there is a diff needed, tell me, i send one. Greetings, Olli From markus at openbsd.org Tue Nov 13 07:46:26 2001 From: markus at openbsd.org (Markus Friedl) Date: Mon, 12 Nov 2001 21:46:26 +0100 Subject: OpenBSD 2.6 & OpenSSH 3.0p1 In-Reply-To: <20011112005531.C13361@outpost.zedz.net>; from usura@zedz.net on Mon, Nov 12, 2001 at 12:55:31AM +0100 References: <20011112004317.B13361@outpost.zedz.net> <20011112005531.C13361@outpost.zedz.net> Message-ID: <20011112214626.C24610@folly> On Mon, Nov 12, 2001 at 12:55:31AM +0100, Alex de Joode wrote: > On Mon, Nov 12, 2001 at 10:47:28AM +1100, Damien Miller wrote: > > On Mon, 12 Nov 2001, Alex de Joode wrote: > > > > > The OpenBSD source doesn't compile on OpenBSD 2.6. Markus suggested > > > posting the problem here .. > > > > Where does it die? > > the portable/openssh compiles fine, but refuses to startup: > > [usura at outpost]:/tmp/openssh-3.0p1 {21}$ ./sshd -p 3333 -4 > bad addr or host: 0.0.0.0 (name or service is not known) hm, does it use the getaddrinfo emulation or the broken getaddrinfo from openbsd-2.6 ? -m From anonaka at miraclelinux.com Tue Nov 13 20:02:39 2001 From: anonaka at miraclelinux.com (NONAKA Akira) Date: Tue, 13 Nov 2001 18:02:39 +0900 Subject: default option for ssh-keygen Message-ID: <00d801c16c21$f2beddc0$a300010a@mshome.net> Hi, One of my users got into trouble that he could not use rsa authentication. He was using 2.9 server and 2.9 client but he generated his rsa key without -t option by ssh-keygen, thus identity and identity.pub was created. ssh -1 worked for him. IMHO, since SSH-2 is default for ssh client now, I think "-t dsa" should be the default for ssh-keygen. -- NONAKA Akira Miraclelinux, Tokyo, Japan From markus at openbsd.org Tue Nov 13 20:11:11 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 13 Nov 2001 10:11:11 +0100 Subject: default option for ssh-keygen In-Reply-To: <00d801c16c21$f2beddc0$a300010a@mshome.net>; from anonaka@miraclelinux.com on Tue, Nov 13, 2001 at 06:02:39PM +0900 References: <00d801c16c21$f2beddc0$a300010a@mshome.net> Message-ID: <20011113101111.B11336@faui02.informatik.uni-erlangen.de> On Tue, Nov 13, 2001 at 06:02:39PM +0900, NONAKA Akira wrote: > Hi, > > One of my users got into trouble that he could not use rsa authentication. > He was using 2.9 server and 2.9 client but he generated his rsa key > without -t option by ssh-keygen, thus identity and identity.pub was created. > ssh -1 worked for him. > > IMHO, since SSH-2 is default for ssh client now, I think "-t dsa" should be > the default for ssh-keygen. i think -t rsa will be the default, or there will be no default at all. From anonaka at miraclelinux.com Tue Nov 13 20:25:23 2001 From: anonaka at miraclelinux.com (NONAKA Akira) Date: Tue, 13 Nov 2001 18:25:23 +0900 Subject: default option for ssh-keygen References: <00d801c16c21$f2beddc0$a300010a@mshome.net> <20011113101111.B11336@faui02.informatik.uni-erlangen.de> Message-ID: <011001c16c25$1f790860$a300010a@mshome.net> > i think -t rsa will be the default, or there will be no default at all. Currently(2.9p2) -t rsa1 is default for ssh-keygen and I believe it is for SSH-1. But SSH-2 is default for ssh client. Don't you think this is a little bit inconsistent? From markus at openbsd.org Tue Nov 13 20:37:25 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 13 Nov 2001 10:37:25 +0100 Subject: default option for ssh-keygen In-Reply-To: <011001c16c25$1f790860$a300010a@mshome.net>; from anonaka@miraclelinux.com on Tue, Nov 13, 2001 at 06:25:23PM +0900 References: <00d801c16c21$f2beddc0$a300010a@mshome.net> <20011113101111.B11336@faui02.informatik.uni-erlangen.de> <011001c16c25$1f790860$a300010a@mshome.net> Message-ID: <20011113103725.A13538@faui02.informatik.uni-erlangen.de> On Tue, Nov 13, 2001 at 06:25:23PM +0900, NONAKA Akira wrote: > > i think -t rsa will be the default, or there will be no default at all. > > Currently(2.9p2) -t rsa1 is default for ssh-keygen and I believe it is for > SSH-1. > But SSH-2 is default for ssh client. Don't you think this is a little bit > inconsistent? sure, but backward compatbilty hurts. DSA will not become the default, RSA (ssh2) should (if there is a ne default). -m From anonaka at miraclelinux.com Tue Nov 13 20:39:08 2001 From: anonaka at miraclelinux.com (NONAKA Akira) Date: Tue, 13 Nov 2001 18:39:08 +0900 Subject: default option for ssh-keygen References: <00d801c16c21$f2beddc0$a300010a@mshome.net> <20011113101111.B11336@faui02.informatik.uni-erlangen.de> <011001c16c25$1f790860$a300010a@mshome.net> <20011113103725.A13538@faui02.informatik.uni-erlangen.de> Message-ID: <013601c16c27$0aa38ee0$a300010a@mshome.net> > DSA will not become the default, RSA (ssh2) should (if there > is a ne default). This is fine with me. I do not care weather it is DSA or RSA. Thanks, From jan.bymark at cgey.com Wed Nov 14 00:12:15 2001 From: jan.bymark at cgey.com (Bymark, Jan) Date: Tue, 13 Nov 2001 14:12:15 +0100 Subject: unable to get connection thru firewall Message-ID: <2AA167413A3BD5119D2500B0D0AB1579265ED9@CPH01> Hi, I've a Solaris 8 with Openshh 3.0.1 (build with these parameters --prefix=/usr/local --without-rsh --disable-suid-ssh --sysconfdir=/usr/local/etc --with-ssl-dir=/usr/local/ssl --with-tcp-wrappers). If I come from the same subnet as the server is on, I've have no problems. But When I try via the Internet I doesn't. If I run snoop I can see I get contact with the server: 193.234.247.50 -> imsdemo1 TCP D=22 S=20094 Syn Seq=2899242921 Len=0 Win=163 84 Options= My /var/adm/messages show me this: Nov 12 16:47:48 imsdemo1 sshd[29929]: [ID 800047 auth.error] error: Bind to port 22 on 193.234.247.50 failed: Cannot assign requested address. Nov 12 16:47:48 imsdemo1 sshd[29929]: [ID 800047 auth.crit] fatal: Cannot bind a ny address. Nov 12 16:50:26 imsdemo1 sshd[34]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer Hope someone can help me __________________________________________________ Best regards/ Med venlig hilsen Jan Bymark System Consultant TELECOM MEDIA NETWORKS Cap Gemini TMN Group Denmark A/S Oernegaardsvej 16 DK-2820 Gentofte Denmark (+45 39 77 84 76 (direct line) (+45 70 11 22 01 (office) (+45 70 11 22 01 (fax) * jan.bymark at capgemini.dk " http://www.cgey.com/tmn "We make you outstanding in a connected world" __________________________________________________ This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011113/6156b370/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: CGltbg.GIF Type: image/gif Size: 2038 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011113/6156b370/attachment.gif From jan.bymark at cgey.com Wed Nov 14 00:14:47 2001 From: jan.bymark at cgey.com (Bymark, Jan) Date: Tue, 13 Nov 2001 14:14:47 +0100 Subject: problem with make on solaris 8 and openssh 3.0p1 Message-ID: <2AA167413A3BD5119D2500B0D0AB1579265EDA@CPH01> I had upgraded gcc to 3.0.1 and I shouldn't have done that. After running gcc with 2.95.3 it worked Jan -----Original Message----- From: Tim Rice [mailto:tim at multitalents.net] Sent: 12. november 2001 22:09 To: Jan Bymark Cc: openssh-unix-dev at mindrot.org Subject: Re: problem with make on solaris 8 and openssh 3.0p1 On Mon, 12 Nov 2001, Jan Bymark wrote: > Hi. > > After I've run the configure (./configure --prefix=/usr/local > --without-rsh --disable-suid-ssh --sysconfdir=/usr/local/etc > --with-ssl-dir=/usr/local/ssl --with-tcp-wrappers) and want to run the > make (make -d -d) script, I get this error msg: Builds fine here with those options on Solaris 8. (Jul 24 Recommended patches) But then I'm using gmake. > > Finished prerequisites of target file `inet_aton.o'. > Must remake target `inet_aton.o'. > make[1]: Entering directory > `/export/home/jbymark/openssh-3.0p1/openbsd-compat' > gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. -I./.. > -I/usr/l > ocal/ssl/include -I/usr/local/include -DHAVE_CONFIG_H -c inet_aton.c > Putting child 0x00065a30 (openbsd-compat/libopenbsd-compat.a) PID 11027 > on the c > hain. > Live child 0x00065a30 (openbsd-compat/libopenbsd-compat.a) PID 11027 > Putting child 0x0005ec28 (inet_aton.o) PID 11029 on the chain. > Live child 0x0005ec28 (inet_aton.o) PID 11029 > Got a SIGCHLD; 1 unreaped children. > Reaping losing child 0x0005ec28 PID 11029 > Removing child 0x0005ec28 PID 11029 from chain. > make[1]: Leaving directory > `/export/home/jbymark/openssh-3.0p1/openbsd-compat' > Got a SIGCHLD; 1 unreaped children. > Reaping losing child 0x00065a30 PID 11027 > Removing child 0x00065a30 PID 11027 from chain. > > I'm running Solaris 8 and Openssh 3.0. Also tried 2.9p2 and the latest > snapshot > > Jan Bymark > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. From gert at greenie.muc.de Wed Nov 14 02:24:57 2001 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 13 Nov 2001 16:24:57 +0100 Subject: socklen_t - where? In-Reply-To: ; from Tim Rice on Sat, Nov 10, 2001 at 08:42:34AM -0800 References: <20011110134735.A16567@greenie.muc.de> Message-ID: <20011113162457.A25722@greenie.muc.de> Hi, ... after struggling with autoconf and gawk and whatnot for a while... On Sat, Nov 10, 2001 at 08:42:34AM -0800, Tim Rice wrote: > On Sat, 10 Nov 2001, Gert Doering wrote: [..] > > - autoreconf (no messages, no errors) > > - configure (no problems) > > - no socklen_t in config.h > > > > Hmmm, I think it's an autoconf problem - while it doesn't throw any > > warnings or errors, I still use autoconf 2.13 and remember that there have > > been some problems with it. > > > > Shouldn't autoreconf print some warning if the autoconf version is too > > old? > > Autoconf 2.13 should have failed. Autoconf 2.13 did NOT fail, intersting enough. > CVS code now requires autoconf 2.5x > Do you have an old configure.in in your tree? If so remove it. > configure.in is now configure.ac > Grab autoconf 2.52 and apply the attached patch to it. I have now done this, and gone are the remaining problems. So I can now testify "CVS current (as of an hour ago) works nicely on SCO OSR 3". As long as you have autoconf-2.52 with Tim's patch (which, in turn, works only with GNU awk)! gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From gerardo.lamastra at TILAB.COM Wed Nov 14 05:00:11 2001 From: gerardo.lamastra at TILAB.COM (Gerardo Lamastra) Date: Tue, 13 Nov 2001 19:00:11 +0100 Subject: Intermittent port forwarding problems openssh 2.9.2p and up Message-ID: <3BF15FAB.1331ADB7@tilab.com> Hi, I have configured ssh for port forwarding local 8080 to out company web proxy server. # ssh -L 8080:proxy:8080 myname at ssh-host I've tried the configuration by using # telnet localhost 8080 and it works fine. But whenever I try to use it with any http browser, it just fails. I investigated the problem with Ethereal and I've noticed that packets travel on loopback interface, arrive over ssh-host, but there only the 3-way handshake is performed and no extra data is sent to the proxy. It's like data is "lost", and the proxy timeouts. The same behavior happened using different ssh clients (openssh-2.9.9 on Linux and ttssh for Windows), different server (different release of openssh (2.9 and 2.5 mainly) on different architectures (Linux & OpenBSD)); different web browsers (lynx, links,netscape, explorer). I've also tried different proxy servers (netscape proxy server and squid) I tried it with other protocols (Ex. using imap access to our corporate mail hub) using Netscape and it seems to work fine. This seems very similar to the problem reported by mcurtis9 at csc.com.au on 2001-09-25 2:09:57. Thanks for your attention. -- Gerardo Lamastra Centro Sicurezza Be-Secure Telecom Italia LAB Via Reiss Romoli 274 - 10148 Torino Tel. 011 228-6586 Fax. 011 228-6360 From bugzilla-daemon at mindrot.org Sun Nov 11 05:51:12 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 11 Nov 2001 05:51:12 +1100 (EST) Subject: [Bug 3] sshd does not properly daemonize itself Message-ID: <20011110185112.DF5AB2DF58@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=3 ------- Additional Comments From markus at openbsd.org 2001-11-11 05:51 ------- isn't your software distribution program broken if it exec()s sshd without closing filedescriptors that might cause it break? ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. From bugzilla-daemon at mindrot.org Tue Nov 13 15:59:04 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Tue, 13 Nov 2001 15:59:04 +1100 (EST) Subject: [Bug 3] sshd does not properly daemonize itself Message-ID: <20011113045904.BA7CB2DF34@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=3 ------- Additional Comments From ralston at pobox.com 2001-11-13 15:59 ------- The question is irrelevant; regardless of how one chooses to answer it, the answer does not make sshd's behavior (of not making sure all inherited descriptors are closed) any less broken. ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. From qralston+ml.openssh-unix-dev at andrew.cmu.edu Wed Nov 14 09:37:27 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Tue, 13 Nov 2001 17:37:27 -0500 (EST) Subject: Another round of testing calls. (redhat/openssh.spec) In-Reply-To: Message-ID: On Mon, 29 Oct 2001, I wrote: > IIRC, it was jbj who stated that this: > > Requires: openssl > Conflicts: openssl < 0.9.6 > > ...was preferred over this: > > Requires: openssl >= 0.9.6 > > But since I couldn't find anything to back up my recollection, I'll > go ask on rpm-list, just to make sure I'm remembering properly. My recollection was correct. Jeff's explanation was that it's better to describe the past (which is finite and is known) than to describe the future (which is infinite and unknown). -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From jmknoble at pobox.com Wed Nov 14 10:35:12 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 13 Nov 2001 18:35:12 -0500 Subject: Another round of testing calls. (redhat/openssh.spec) In-Reply-To: ; from qralston+ml.openssh-unix-dev@andrew.cmu.edu on Tue, Nov 13, 2001 at 05:37:27PM -0500 References: Message-ID: <20011113183512.A13757@zax.half.pint-stowp.cx> Circa 2001-Nov-13 17:37:27 -0500 dixit James Ralston: : On Mon, 29 Oct 2001, I wrote: : > IIRC, it was jbj who stated that this: : > : > Requires: openssl : > Conflicts: openssl < 0.9.6 : > : > ...was preferred over this: : > : > Requires: openssl >= 0.9.6 : > : > But since I couldn't find anything to back up my recollection, I'll : > go ask on rpm-list, just to make sure I'm remembering properly. : : My recollection was correct. Jeff's explanation was that it's better : to describe the past (which is finite and is known) than to describe : the future (which is infinite and unknown). But either description above will need to be changed when a new version of OpenSSL comes out that's incompatible with OpenSSL-0.9.6. Both descriptions are effectively open-ended, and hence are equivalent. There won't even be an effective difference between the two when a new-and-incompatible OpenSSL arises; for both, you add a line to turn them into a closed description of compatibility: Requires: openssl Conflicts: openssl < 0.9.6 Conflicts: openssl >= 0.9.285 or: Requires: openssl >= 0.9.6 Conflicts: openssl >= 0.9.285 IMNSHO, the point is moot. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011113/ba3f95aa/attachment.bin From bowman at math.ualberta.ca Wed Nov 14 11:31:43 2001 From: bowman at math.ualberta.ca (John Bowman) Date: 14 Nov 2001 00:31:43 -0000 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay Message-ID: <20011114003143.19330.qmail@wizard.math.ualberta.ca> The hang-on-exit bug still hasn't been fixed in OpenSSH-3.0p1... :-( Here again is the patch to fix this bug under Linux, updated for OpenSSH-3.0p1. This has been exhaustively tested for six months now. It also add an exit delay option that can be useful. The patch does not lead to data loss under Linux. Please see the Secure NFS page (SNFS) for further details: http://www.math.ualberta.ca/imaging/snfs/ -- John Bowman University of Alberta diff -ur openssh-3.0p1/channels.c openssh-3.0p1J/channels.c --- openssh-3.0p1/channels.c Thu Oct 11 19:35:05 2001 +++ openssh-3.0p1J/channels.c Tue Nov 13 16:02:32 2001 @@ -1553,8 +1553,18 @@ c = channels[i]; if (c == NULL) continue; - if (ftab[c->type] != NULL) + if (ftab[c->type] != NULL) { + if(c->istate == CHAN_INPUT_OPEN && c->rfd == -1) { + int type=c->type; + c->type=SSH_CHANNEL_CLOSED; + if(channel_find_open() == -1) + shutdown(packet_get_connection_out(), + SHUT_RDWR); + c->type=type; + continue; + } (*ftab[c->type])(c, readset, writeset); + } channel_garbage_collect(c); } } diff -ur openssh-3.0p1/channels.h openssh-3.0p1J/channels.h --- openssh-3.0p1/channels.h Thu Oct 11 19:35:06 2001 +++ openssh-3.0p1J/channels.h Tue Nov 13 15:55:52 2001 @@ -218,6 +218,7 @@ void chan_mark_dead(Channel *); void chan_init_iostates(Channel *); void chan_init(void); +void chan_shutdown_read(Channel *); typedef void chan_event_fn(Channel *); diff -ur openssh-3.0p1/clientloop.c openssh-3.0p1J/clientloop.c --- openssh-3.0p1/clientloop.c Thu Oct 11 19:36:09 2001 +++ openssh-3.0p1J/clientloop.c Tue Nov 13 16:06:36 2001 @@ -84,6 +84,7 @@ /* import options */ extern Options options; +extern int no_tty_flag; /* Flag indicating that stdin should be redirected from /dev/null. */ extern int stdin_null_flag; @@ -122,7 +123,8 @@ static int connection_in; /* Connection to server (input). */ static int connection_out; /* Connection to server (output). */ static int need_rekeying; /* Set to non-zero if rekeying is requested. */ -static int session_closed = 0; /* In SSH2: login session closed. */ +enum SessionStatus {SessionOpen, SessionClose, SessionWait}; +static int session_status = SessionOpen; /* In SSH2: login session closed. */ static void client_init_dispatch(void); int session_ident = -1; @@ -320,6 +322,10 @@ client_wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, int *nallocp, int rekeying) { + struct timeval timer; + struct timeval *timerp; + int rc; + /* Add any selections by the channel mechanism. */ channel_prepare_select(readsetp, writesetp, maxfdp, nallocp, rekeying); @@ -343,7 +349,7 @@ FD_SET(fileno(stderr), *writesetp); } else { /* channel_prepare_select could have closed the last channel */ - if (session_closed && !channel_still_open() && + if (session_status == SessionClose && !channel_still_open() && !packet_have_data_to_write()) { /* clear mask since we did not call select() */ memset(*readsetp, 0, *maxfdp); @@ -367,7 +373,17 @@ * SSH_MSG_IGNORE packet when the timeout expires. */ - if (select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL) < 0) { + if((session_status == SessionWait && options.sleep > 0) || + (no_tty_flag && options.sleep == -1)) { + timer.tv_sec=options.sleep > 0 ? options.sleep : 0; + timer.tv_usec=0; + timerp=&timer; + } else { + timerp=NULL; + } + + rc=select((*maxfdp)+1, *readsetp, *writesetp, NULL, timerp); + if (rc < 0) { char buf[100]; /* @@ -384,7 +400,8 @@ snprintf(buf, sizeof buf, "select: %s\r\n", strerror(errno)); buffer_append(&stderr_buffer, buf, strlen(buf)); quit_pending = 1; - } + } else if (rc == 0 && session_status == SessionWait) + session_status=SessionClose; } static void @@ -445,9 +462,12 @@ len = read(connection_in, buf, sizeof(buf)); if (len == 0) { /* Received EOF. The remote host has closed the connection. */ +/* This message duplicates the one already in client_loop(). */ +#if 0 snprintf(buf, sizeof buf, "Connection to %.300s closed by remote host.\r\n", host); buffer_append(&stderr_buffer, buf, strlen(buf)); +#endif quit_pending = 1; return; } @@ -757,7 +777,7 @@ error("client_channel_closed: id %d != session_ident %d", id, session_ident); channel_cancel_cleanup(id); - session_closed = 1; + session_status = (options.sleep >= 0) ? SessionWait : SessionClose; if (in_raw_mode()) leave_raw_mode(); } @@ -782,6 +802,7 @@ start_time = get_current_time(); /* Initialize variables. */ + if(!have_pty) session_status=SessionWait; escape_pending = 0; last_was_cr = 1; exit_status = -1; @@ -846,7 +867,8 @@ /* Process buffered packets sent by the server. */ client_process_buffered_input_packets(); - if (compat20 && session_closed && !channel_still_open()) + if (compat20 && (session_status == SessionClose) + && !channel_still_open()) break; rekeying = (xxx_kex != NULL && !xxx_kex->done); diff -ur openssh-3.0p1/nchan.c openssh-3.0p1J/nchan.c --- openssh-3.0p1/nchan.c Thu Oct 11 19:35:06 2001 +++ openssh-3.0p1J/nchan.c Tue Nov 13 15:55:52 2001 @@ -81,7 +81,7 @@ /* helper */ static void chan_shutdown_write(Channel *); -static void chan_shutdown_read(Channel *); +void chan_shutdown_read(Channel *); /* * SSH1 specific implementation of event functions @@ -533,7 +533,7 @@ c->self, c->wfd, strerror(errno)); } } -static void +void chan_shutdown_read(Channel *c) { if (compat20 && c->type == SSH_CHANNEL_LARVAL) diff -ur openssh-3.0p1/readconf.c openssh-3.0p1J/readconf.c --- openssh-3.0p1/readconf.c Wed Oct 3 11:39:39 2001 +++ openssh-3.0p1J/readconf.c Tue Nov 13 16:09:00 2001 @@ -115,7 +115,7 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings, oNoHostAuthenticationForLocalhost + oClearAllForwardings, oNoHostAuthenticationForLocalhost, oSleep } OpCodes; /* Textual representations of the tokens. */ @@ -187,6 +187,7 @@ { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "sleep", oSleep }, { NULL, 0 } }; @@ -528,6 +529,10 @@ intptr = &options->connection_attempts; goto parse_int; + case oSleep: + intptr = &options->sleep; + goto parse_int; + case oCipher: intptr = &options->cipher; arg = strdelim(&s); @@ -799,6 +804,7 @@ options->bind_address = NULL; options->smartcard_device = NULL; options->no_host_authentication_for_localhost = - 1; + options->sleep = -1; } /* diff -ur openssh-3.0p1/readconf.h openssh-3.0p1J/readconf.h --- openssh-3.0p1/readconf.h Wed Oct 3 11:39:39 2001 +++ openssh-3.0p1J/readconf.h Tue Nov 13 16:10:26 2001 @@ -102,6 +102,7 @@ Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION]; int clear_forwardings; int no_host_authentication_for_localhost; + int sleep; /* Exit delay in seconds */ } Options; diff -ur openssh-3.0p1/session.c openssh-3.0p1J/session.c --- openssh-3.0p1/session.c Sun Oct 28 04:34:53 2001 +++ openssh-3.0p1J/session.c Tue Nov 13 15:55:52 2001 @@ -1919,6 +1919,9 @@ */ if (c->ostate != CHAN_OUTPUT_CLOSED) chan_write_failed(c); + if (c->istate == CHAN_INPUT_OPEN && compat20) { + chan_shutdown_read(c); + } s->chanid = -1; } diff -ur openssh-3.0p1/ssh.c openssh-3.0p1J/ssh.c --- openssh-3.0p1/ssh.c Tue Oct 9 23:07:45 2001 +++ openssh-3.0p1J/ssh.c Tue Nov 13 15:55:52 2001 @@ -195,6 +195,7 @@ fprintf(stderr, " These cause %s to listen for connections on a port, and\n", __progname); fprintf(stderr, " forward them to the other side by connecting to host:port.\n"); fprintf(stderr, " -D port Enable dynamic application-level port forwarding.\n"); + fprintf(stderr, " -S delay Set exit delay (in seconds; 0 means wait forever).\n"); fprintf(stderr, " -C Enable compression.\n"); fprintf(stderr, " -N Do not execute a shell or command.\n"); fprintf(stderr, " -g Allow remote hosts to connect to forwarded ports.\n"); @@ -320,7 +321,7 @@ again: while ((opt = getopt(ac, av, - "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:TVX")) != -1) { + "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:S:TVX")) != -1) { switch (opt) { case '1': options.protocol = SSH_PROTO_1; @@ -495,7 +496,13 @@ add_remote_forward(&options, fwd_port, buf, fwd_host_port); break; - + case 'S': + options.sleep = atoi(optarg); + if (options.sleep < 0) { + fprintf(stderr, "Bad delay value '%s'\n", optarg); + exit(1); + } + break; case 'D': fwd_port = a2port(optarg); if (fwd_port == 0) { diff -ur openssh-3.0p1/version.h openssh-3.0p1J/version.h --- openssh-3.0p1/version.h Wed Oct 24 09:20:57 2001 +++ openssh-3.0p1J/version.h Tue Nov 13 16:11:16 2001 @@ -1,3 +1,3 @@ /* $OpenBSD: version.h,v 1.25 2001/10/15 16:10:50 deraadt Exp $ */ -#define SSH_VERSION "OpenSSH_3.0p1" +#define SSH_VERSION "OpenSSH_3.0p1J" From markus at openbsd.org Wed Nov 14 06:46:12 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 13 Nov 2001 20:46:12 +0100 Subject: des_ssh1_setiv not setting the IV ? In-Reply-To: <20011112174754.T1108@wirex.com>; from sarnold@wirex.com on Mon, Nov 12, 2001 at 05:47:54PM -0800 References: <20011112174754.T1108@wirex.com> Message-ID: <20011113204611.A20102@folly> protocol v1 only uses IVs from /dev/zero. From markus at openbsd.org Wed Nov 14 06:47:45 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 13 Nov 2001 20:47:45 +0100 Subject: Openssh 3.0p1/Solaris 8 problems still... In-Reply-To: <3BF07A6C.7000801@Sun.COM>; from Darren.Moffat@Sun.COM on Mon, Nov 12, 2001 at 05:42:04PM -0800 References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> <5207848.1005587873@CJECW95G6PXXT> <20011112181610.A11026@mtu.edu> <3BF07A6C.7000801@Sun.COM> Message-ID: <20011113204745.B20102@folly> On Mon, Nov 12, 2001 at 05:42:04PM -0800, Darren J Moffat wrote: > If you are running BSM auditing and have logged in using sshd and use > crontab -e to update your crontab then because sshd does not properly > setup the audit id for Solaris the .au file that cron uses to set the how should openssh do this? do you have code examples? -m From jc at np.ph.bham.ac.uk Wed Nov 14 23:05:59 2001 From: jc at np.ph.bham.ac.uk (James Campbell) Date: Wed, 14 Nov 2001 12:05:59 GMT Subject: OPEN ssh pkg Message-ID: <200111141205.MAA20361@nps.ph.bham.ac.uk> Hi, I have a few corrections for OPENssh-2.9p1 solaris packaging. I use to configure: setenv CFLAGS -I/opt/local/include setenv LDFLAGS "-R/opt/JGMAzlib/lib -L/opt/JGMAzlib/lib" ./configure --prefix=/opt/OPENssh --with-tcp-wrappers --sysconfdir=/etc/opt/OPENssh --localstatedir=/var/opt/OPENssh --with-pid-dir=/var/opt/OPENssh/run --with-ssl-dir=/opt/OPENssl --with-ipv4-default --with-mantype=man --with-random=/dev/random Jim The corrections are below in ssh.tar.Z.uue: begin 644 ssh.tar.Z M'YV08NJD84.F!9PU9P H7,BPH<.'$"-*G$BQ(HP8,&#H.'QQHP;,&IT">-& M:,0Y>8J6:>/4(O8,.*'1'BA9 at T;E[,0:- P0 at 03^"4<3-E M"A(0<]ZP.9IF#HB \G@'2,G#1PZ()@*GE,'#IPW=.F;V(W9#R# #%E3)JY8\J ".*8 M39HQE].\<>,WB1LZ9>2X2;X\#)O/D!_+H>X&!(HI09(,2:';NVDZ<'2\>'&G MO0O?15N4"5/4Q9PPQ]_33N%B=Q VUY%FFE]RF4'6QAPL@'!'&G2@ 0)D*K*(!H=T>-;& M&V2DH1ER%+J1XE'"R25';71 )Q@<281"%6H%$:MBA< M&&(H*1R7H at E8XUN[@>#&&Y(%EV*+MAE75)P@<(D;B\HQ!Z*?)0*(Y625]37& M7FF0*<>";\F at YH-MIC%AIGYI>-9T7;CB47!N,=A14Y5\G1U3;'' ,S^!852"0Q!6]/&$'% M%4%(400(4H, A11/6)$$$440 8(068 ]=9!5 'U$U* 8804PM]0DG#.>$ MV4$XD7816'Q=1%UP2>%9$DU P40298. M112]$T%XU.DF(030S!1!1&7'Y&B M$&Z#X,035,2&>!)4-$[%$RFNS77BBS?^>.1.3#ZX9U6#T$014 at R!A.1!")'$ MXE2DW;?91J#NQ.!3&P'W<%YG/?D053"1M==52 '%$U.PK34(G$^1>7B[$T'P MY:(_ 4(15A11.V^_,\&$VDBP[382SPNQ]>+!,[&U\W'K6]HXI[4A4,%R>TM" M 0]X.,R-S7U4" (34C0%*!1A"$F08(H 5P3892T+*7K>$)[@A.Y%H0H0S.#\ MB!"$)@3A"(/SSN4RM[G.? QOUM+:[]^5N"E40PA0F M1P6W;>T(3W@"$:;VO.Y)06Q#&-P.8L,]*AH!!%7H'@L\P\((AC!N7ZL:ZJ:P MQ?R%\7+,XUKM>">%*D!A?:9MW>/;WN#B!+UEP3-K at UO:<< 31 M%>$(BX,AYK;V/-+53PI7D%H15),UJ75.CH9T7! 6&;K MR8N4F+(&OX3A#/CI3I784-,0N*4'+0"J4(-*U*$:M:A([4%;1L#4MRQA47?H M3E\8PQE$3NEC8RK3C,A at TP*!X QSB8YUY/D7^CBI0F$ @0B:9(8PU($-=!#! ML-H AX&HZPUFP)U<#GJ7"DU!+WR90PM:(%-.W8R:7WN6P4SUN$BIJYC6(.3&O,7$D'*N:T]3'_4=BW6 MAA19#[4,9C3#TI%&1SA[F51C-.RDC,6+#J&%RUXENAH7I"D&<* !JCSSG^L MAB"@>B@ND!E1J K$7L at XF+3@4AF+/L8&.1%F M/OZM Y$_>RU+ 4P,:@%L8?R2(R9GK%:#+>R[5KLS at L066=)E"HGFX#-Z7>=C MYBH:B:9:!\YX!T9"=M*M]CL;Q/ X.$NK3(= Y2?/[+C'9P 5KQ ]!_[L!F'" M.;)VE%SF,C2Y5E%.J&:$'-TR9"LQ*B/!'D W/"(0L \S?MJUA*0T^FJJ0IQ" M2U'&*NC-=%4X8C"K8"HTHSNH*$@%,H-^,^:9CLU,L?K\<)HU-K%G:2G4NC8* M@)PTA3)586RW)32C8DUAE,8GVP6VL&OCI6";?G4V!6FKC!)C-+HBQL3HQF<8 ML*ME]F;*.L-R at V;.T*&[=H>[\(**5-HPX22H"+HG!==S/BP5P6AH2GS1$G[E M).?,X(<-[AT3COS,V,1XM4I:)L./FO.DPI188URBZUSN0[)!C]4SG%H.R:'\ MW#LL& [1]NH=IM0=G^/%*)%QTJ[VXIMK%[C1;\F1&91=H.=(?-?;%HQ\;>T7 MO,(7">QLZEN$@",2>9U3ZCZ,=T8]UCR$@#QON8)PRH 'G]U;8]*]<8ZNC78Q MV^;1:[CID%F63R]+*,Q[&7.STV!F)P]V0OG4NT%X''BP at G3=M3E6Q.6 at Y1CQ M*ZW\30Z"''T9%XF!1&G%$+Q4&R\-L;C3G\[#2^VC,:-'R,$:TRUOGZ4RY'QL MPDY at 5*:A_.!0%V4 at UTEK' 228!"5.:,; GF/4C0Q0@>D/FW1$0BV ((6R&EI M:%#0&$#0A2WZR0T*2-08!&-X5R$^L"#PP0N:9(<7N.&M;%" 9I8:FW)QI^O? M9Q2XP4\A0BN_T1E5X 0M5 0]\ )$(0=F at 18.J#!EH "!U( /&(%I\3&Y 057 M0 08. <0."LO =WD!O40P4A.((2:"XULD2!!GT 9KP(,^N$E],P5"*(%$&"%,T1E'H#4RZ( BB(.<508[ M6$8,:(4LF!8DUA9#) 4$U - at H&H>2 1] 8*P&I,X&H*U .J-H:O9A8"01 M M(%&3!VD5^!9)("?-\1@<&&X5XQFM&!V^ M)QR[4B ?PXE\UV6TL6-N8';P ADXY09IH ?J4G(FXRLE)BYO43,W R3VA3$) M0W>(,0,M4 .GN!WL%1VKR!B.\0:O:&+2E2VT:%:>P21S(1EFD >,5F%U!C3. MB#,%,F&8=E*3LHB61X$LQR4#YADQ9S% IS/'YE4B\ 0$Y8 at O B\%:4%.X(@I M$FF;*"7 at ."C+T28YE3(+TH-'H("[TP,+Z3Z.Z!E0L$0M! 6A%F ":!ERL!AE M(AG7QGHG0(1H425YPV'#%R53P at 9PL%@:@XZ9L> M"0(O]0+%V9B/N1D at P <@,(=NDY4M(!@]T'UR(@-L2'>>%IQI@)M5N9N]J59> M@)UCH)VX*5?%>9R.:9O*R9S.2070*9W4N1IL>#DP&$4JJ&KDJ0,S:)36T0<* M4 14, 1EV)U4Z)M> * "&H?FZ0+&R:#(J9ZVQ9Y[D(+O"0+3Z7WRR8-C,Z"Z M6:#@65=D4&;#>9X.FIXVN9S-.:'/V7WPB:'6F7URPGTA$)\DJA9K(1CEUR_H MERB>-B-J507345N9IC'\23+@%UTB FI#]V%95B!ED*7I=Z=XP"(@$ /ZEP9M MH0#M(P53D 0DE)M[X)V^*5%?<*F92D(+VJ OL'4#XR(22J'Q*0,H^HKR 0(G M<(,BL!YGD#>Q.JLO$%%V\06V>@)L^!9%@ =0B!=$QQ3&$H7A!J)UQ>>@:H5I6[ M YWPLJHKZJ(L2IQLJ'W<1P+I>CG/TP)G@!@V0'[F1W2-NAO<(ZJ:Z at 1RN*_K MJ@"F]C$%"Q=3 at +";6I7N6 at 3PBJ*J%DA9J:LU\ (R\ + .JD*D#6^DYL7VWUP MP(9V 3>34T*;9)\>Z9;XJE8D0)\Q2SIR-9VUFH'\R09RE:/GUZ at M6THX"S:D MXY$M\+-N^; 5N!LU*P(W"[-(2P4[JU;L- MNG_[IP!DLT3)XS\>B88^R)$8VP*J1K%.T >$I1>J=K"\,ZIW2[=[8+)(T <; MBS]&2[7VV0=NZ;!J MYH9P* 6PUK2-*P)"D*0'.) 425>;\3(P,KECEJ)\BZF>9L9 at S,%)/ =E MO,!=2E%_V5^@$L&P=V85_%)N.9Y%7*/%>:1X4<:"K,&$S*#@UP(*E@=@U1V( M#'2*S* UVLB/S%I,48 %3,E M\@V:GIHT_3%@'HE]L+)[7C![>+ ?R]C=9GH-9<%=9M5=57C=!(4BI^UM5Y328N1=5PQ7]/ M(&0 ]2=NL"CLN(N385.!8HEDZG?VE$J?"@3.X M%S2,PBAY(!J5KZDTP=\D-_=)QSM_0+O;;?SK;FX2T))K.#[[> E M(+ at 1'KB],[CXK=\,[MXE<+M^N^$DSKD?#@(\4)PR*7!OX (:X@/.C1"&J0#J MW3 at 7_M[QO8 ;ON/OFN(Y/N)3H*YP8^)#SJ\=;.$ACN$G3D)&;K<5+E+]#=\;*N E0.![ 5E;KH)+N4L#HXNB75L MD.7QY]QP_N4W;C;[/>9J7KH#CH9KCN *ON"-..;_'4AFCN8&[IYMKN*P''XM M@!93%F%T0.<^T-9/'>G$F#*43MVI.P4Z6%?7-BM\P1GIO0-$F'RQ?LC& M'G[*[NO,O(,;V^O%OH&__.Q9&G ^[M=^KB! 2I0<+QE ML+@&C,9(;.,:"83=IS'Y2YQGG.92^9W1:<1:/,8PNGW-^0/=]Z\@ ,"JZ,% MJ[Y%( =) B]" M'_B"/_A>4>5>SAS9F^6$O_@,<1$980,TP!(G$1(C 1(F<1(PH!,:T1([ 0,T M$ ,P,0,P,!(Q$/FE[Q&,G_H^D2='D10GC/<*=V1A<14RD!4?L16JG_NZW_=D M at 8-KX8^086:=>'H at H 0N, 1A0%=WR09 ( ;[Q' \Y@)U\$^ESQM:N!HWP2#5 MW>57?FW1Z@;<(XA+8FL63.3L"@8XJ&7)+QSUSIPXZ(+U*@)9VJKW&J,I:O[0 M"5<@\-X,6^0E#)ON0+ML _^;6)O+R94 *96\ MK at .O"#:U)0^(O=2U&ZJ/&>@W/6)8,#PH158J1/S2+^#JULB)!NA2-B#P4@$J M (P$*=X"<[[>E5I4( &BKU'58U(EOH*7;.G0(R_3O0& H_L25^I:PAP/U Q M:,;>\?%^"&5X<0<+5K,P5'W[ CA+ at C"!+U"UDA at 7&UT K at ZQ,!=&&H#'HU15<'^E.1^$!6&6%N2"B8L-HA at P MB. at Z& V;$47A"SRR>7<&?98:%(3<;BU\ 41(!Q2A28N#72M1T,$@D#KL8-E+ M>E8)"GRE!1<'(A4FW%%W*G5!@>@ \7),=^ "(F#$R M8B+W&REV1$SHN;O&X M$M"TV #$$H!J915:O>KB=$ +(09G $-T$(I& *]3BZT;[OCO;FE_0/R^(_< M22 at M8_A\E"@QO)Z$7I,X4PJK<"\#:!OX2_A*$ O"DAB!,B2U]N 1Z(,D27X MP@,'"0EA@#-=;NEY"0^%U0XU$CR,(/*P"]K#.C0K\F$1, )M at PFHH'[(![-@ M0$Q< U&-<3&W-)K2D_':#J>%&R4&._!Q8-Z0JH4 0EU\NR7A*"Q$3-$8)J;C MY!>')]FN#9_J##PB_I" &*#B>(!/48=EZ 20 )RH0$Z VCJ("5$%Z42R at 1"K M!Q7PB?KPC$Q)L:W0%&*@LO+7I='[0R:)V#T?M];X!(C MT-]4".)G_)"?\C,US,_Y)3\7$/VF7Z1R5<''#F"_B\ @'"(3, (>"0W2,0DT MO,S XLHVP2;!- 84H!KV0,3Z @3D at I"2+""')%6R^ +1Z] Q(!(@ WXC40R* M@I1_]T')&($4@>6, ,H4$2 M1&) 0%@:2V7I+)$EM<26(E8>U([!T8!X1_JV!\*C_QB/IU !) #UE2B$ .5Y M8$#G1(''Y C at 8 T@$Y#W$3SFQ^'X'?LC@^P>L(:"48:GU[420+*@C@#1.I( M[ BS\"-WU(]2( M42/]8!,;C,2,-+@ \FD?TZ)\\I/JA:!+R1%)(_L at B 62. M7"#[<4&*QP;Y(I>:C*P"YS$)8($:F2P(Y&Z8 F' 9: :$PDD4^2*O)#22T/& MR/XX(Y7DZ1*03 at L$1*QD\2%=XQ<9D3XH._[([F at E>226S)"D84R2R=U at R]8D MBE21;G)(8D at JR2;QI)#\CT120\K).>DD>4.4=!)MRD[NR#_9(@,EC'1+"6#_ M) M)>2/O'7 $BD;Q2NI)Z078$(.B#)(6Q0"CXE[KI4R%-=92#2'#9)<^<07[JA=.>% M]T3&TM)F!$/[DFZ!2""%@5_Y =V 9IP.R06 M&0J>3#!X28)1X(6HL)R8T]@;11&K3NZ!YY at I,UW!Y%,IRA]6S"Z(,34F&7AJ M#],/RH\S22*72,QLB#IS"]+,KN8A5,7-G (W0 ;\K"]PI!I05[.9'-,O\ &3 MR0-70\ZLCCQ38OI,BADT+:87=&H>(DWD._^$?')I@&TZ M.V.\4IZ^K!#/DC6)M:H& E(@ $*6E)_ 3"#Q.O@)AO,DT<)H\4Q^005, M#!70.F\#")"%)&-XT1-_L1Q<$WU8 SJ,9U2F.$4BD\TUD44:=]1'S64W_.3R=0/TV7Y\QJ9#!%L4S4*2;O M)P+-G_*S?68ET3EP).CI=$\'M"@DT S*/\=8T-!K W2"@M#B^8SE0SJ"6&'A'=10(B)S@@@ZDB)6X M(K#*E2B"=-16:@C38HOF0UZ8 at 7\"KD2'Z4 RBE2UJ!BW0CA ) 2Y(!) ':4# MFHVD1 8706P3OV":) L9D"ORB!@IE at 4Q)W=#P P^)*/DH-+X94-?6F:@ M+*"%-I@*WP!P6$SF,0W*HD8T4Q 0,*4+G$H.0BIZOA;F^6:>!&= #(.&L732 M^\@0W^',#(1MD(R^T4?V+H>6C1P3JI%K5D>OB3'=:")8S158PC(K!DEH)%V$+*"1X0T!2RCOE"WA!+4,9U5%+^$5A1=9U"ZT@"T:L88JN+!_/E1. M -$2:@AYZA?@*F& B&K43-A,JUL2O3;BH3&:6DF]56)@%0.E(J"BG=*Y%K0RP,:K0=O.'".*3= MCS+$TVM!375.<-4L&B-*WM+$D$M3#"_UI4WB)P73$#A,3Y$Q1:9'09F> 9>2 M2$>8\!%3RA5DF)1,=DVU2S9M ]N4<4H45_5-$ID>^P7H+.,-=$^ MUL*:HAKM)'RCD!:SRM'KRC4Z:VG]K*%U,I!6)@6)3JL@?1&JM2^P5DX+6Q=& M9WFD'O&>W%9G94EW*R:%#)KTM[ZO8L9IAVLH-:X]PY2ZQ-B:2IOK*OVCLR&Z M]E58.CXY;2W=KFDE(.A22M%+Q^POU1'CM1.5UV(*5H[I 90.BZW!SLEG^EZE M*;&EIO15O-W7_-I-[0)_-1;@]+^Z5EMI3GL1.F4IZO38'%C7E&#AZ2LE+>*6 M3*98F;EBZ:%%O;2),--FU#M;8STJP1VH'U:(8EHH2R(.J_ULJPT5X#U4%0MQ M6:R.?80'=X at J7!G+M6CL.+6Q'#>BTLP6RV,1;B4L.EJ8*V6#:I5ELSR*R)Y8I*I4*0.7I0Q^]HD"VJDJ M:"<%H<6B:!8)_-5_F2BHH=(EE<*P%3J=5Q at +X0")688#4X^90'[)5[BN,[65 M3\ (.HL"&!ER8%^(@9L,>6:(M#M[9,KK+&&Q=.X_J"4I77\-.NJB0T9*EHU2C"I.3 %PNM?C[ Z1D\Q,3OUG.>-$\?2?:2V @ ^6*+SA$_"&F]F)CE3$E+B=X:8;[LX),P5\9V>*%=PS M403,O&MVG97RU+?+@:R(X6ED;&Q2K'B\+X(@%$\['%^+S;Y%#"\TX"Z/*Z . M>P ,L(_T5R$%79AZUOXGYURK)I>'7E#=2$+CK -%P@!4@'I0*CQSD\4 at +L3& M40,CX at Y<[^"L&/5J9! 2#TK\28ECKB7>H)_S#5*&*1P4.W&B^,3TTQ/&WU&, M+DOQ(GYJ7TT5.]A)O 84J :-H5]M$]?BQHJ+&:@N%L6BMQD+]FC+.E,RX"!#B7!R*=X-737K-^(O(AU+H]$[PT at 5>68!#P(NG M^W4"SID"EYV(#X>F\"DR*\;1L*T?1D$$UIJ+9^&Q/$:U[X+C2=YZ_"W5A3X^ ME.'4374'@%P@!/*:;0N6M].ZT, at +0Z$P9:"A@]:DX=!*<=V,*@?NQ6+U%U-8 M.QN "W*7LFYZ%J[R6=< 'K[LU+VK8M;J6M5"FU6U+E>5M'&3 +-1F2MQ36H> M:*PIF-*J9+.J:37KO/5#C]>K at -I?M$?[!6*Y7J8VM;Z+U8IL$>E3!H>H]-72 M5MM"D7$KLM6MFN+6>I5-NFL#;D;VM<5UE ;;2S%LERNQ,K;?$+JZ4BXC7V.I ML\VNMI1)<%=IZUW%*GA-1]@6+;,I8NI;$@1Z!;?+E--"TYM46L[M?+6FZI87 MX5=:I%\12G\-IYRVWM*5>_M>=A@[Y;?O=-D"W,8Z<(%FQQV^(-;E7MB6W'#5 M[VMFOT6YIY)8#8IE,R[WV;@&6/A>3)8;,'DY""3C8V7?<]V M%:_JD_ELO.JS7T6T MCW1E;@&YX5*\5%RA*:?1)E_TQQ,^L<_N#%U9;7<(RXYT+$?265M)P]U8P8LOBVP^K:'N5,%^V\9+&MV MJ/PY.(/?ECM$_S/#3SS.W-K;G#WN8D1IQ?K*/UT\BYF:)< M/3U]FW,:I*A\VD(7ZHH;9'OS+[2YUUGGRM1ZU60W])/=U-T'J);G.7F>/W6 M[E):=JFRYR[KGJ4N?,;)51K5!\^H'[78%:X8>RJ\X-S_:"PV4L:909K2FNEAO:@_=:Z,R M'@6M5%FTFFAM"(3G at W1#K2I:\:K:KMQ:F^EK?='$5BQ#4ED[26FMC;:U.'HM MZUK*T!CO_)DAJ_3]#*3S,S\NLCTUWFWFD?>VFMZRZ9)<[XUO @V M-2_82G>G-6Z>7L[".?QJZY%[K"6U=*P/O$8%=,?D;M+DBY"[S"P(V C8"P8DK=4N!SYVV!K 5I+13TW!:3<,-\$0 %H#=!XY=8@$ M'3#ES at GP*ATCQYQE@/.&P65"AA(36:I at WEM1L )F_"(L&<6VL(DUT&&(J7%( M1R4[%3*PC.$87"&)R#-5I[0P%&3?!>L M^VU\*S#\KA$$>6.D+F at JB/[W*;U13-@,SPR;XACFPWR!17]"$(V,O2OG7&"7 M6F&MJ*)0BNW=O2O%]WX.+;#L)=]##+ at -;9JMUG#36ZM@;'V*"76DC:&:;M)= M&,6G&+\"673=:;$DY'#*A_DR7TJP"2Y!)M UI TLT(,J $8 at 2?4\,7'%UT? M8!0+L6\JS#[+9Q at S'V) ]#M"&HH(1"^/)+OG M6T\#46[).\7&#$2"LA <<$LC:9%?H2&$WBQ0V9#D7T at M.&8%L 2&!Q/ Y#CH MR@&(Q27*=1)EXXT at 8 _87&=J0Y%//F%>HHW2H #.0!X212,N%Q2H.!8LIFDL ML*4 /"0 _Q8&S5P7;W:Y(0'L@!W0%OYY: CH M$-+^>>#K.#:BUVY(9;O!A^J!F%G1Z=YN:+T)( 'T.3,4$P&=(*=[;"A24JH$ M4+,X.A'03S .A$\FHC1S[E:^=U]3GBKE8]>&3B_:JQRHIP6AW@*0@!T9ZIZ:;J_R+)O4-<92]QK at QB8] MBEJ18R0I52<95AU'8'6M3MFXNF.' @)RG!+T0FC(9YVS4^D"4JPK !4 at T-47 M41 \.H"+IUX:;,CVP/_F T4A-/ !LGX4Z(#BBNT,G3/P& 60Q9N[ I just wrote an email describing problems linking to libkafs in openssh 3/daily snap shot as of today, but I think I forgot to describe what the problem was- well first it says 'cannot find file or directory' on -lkafs, for some reason it wasnt reading the directory even though- even though i added the correct dir to ld.so.conf (linux) so I cp'd the files to another directory where I know it was reading which gives this output (cd openbsd-compat && make) make[1]: Entering directory `/home/jnfergu/openssh/openbsd-compat' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/jnfergu/openssh/openbsd-compat' gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/athena/lib/lib -L/usr/athena/include/lib -lssh -lopenbsd-compat -lkafs -lresolv -ldes -lpam -ldl -lwrap -lutil -lz -lnsl -lcrypto -ldes sshconnect1.o: In function `try_krb4_authentication': /home/jnfergu/openssh/sshconnect1.c:401: undefined reference to `tkt_string' /home/jnfergu/openssh/sshconnect1.c:404: undefined reference to `krb_get_phost' /home/jnfergu/openssh/sshconnect1.c:407: undefined reference to `krb_realmofhost' /home/jnfergu/openssh/sshconnect1.c:415: undefined reference to `krb_mk_req' /home/jnfergu/openssh/sshconnect1.c:417: undefined reference to `krb_err_txt' /home/jnfergu/openssh/sshconnect1.c:421: undefined reference to `krb_get_cred' /home/jnfergu/openssh/sshconnect1.c:423: undefined reference to `krb_err_txt' /home/jnfergu/openssh/sshconnect1.c:475: undefined reference to `krb_rd_priv' /home/jnfergu/openssh/sshconnect1.c:478: undefined reference to `krb_err_txt' sshconnect1.o: In function `send_krb4_tgt': /home/jnfergu/openssh/sshconnect1.c:698: undefined reference to `tkt_string' /home/jnfergu/openssh/sshconnect1.c:703: undefined reference to `tkt_string' /home/jnfergu/openssh/sshconnect1.c:703: undefined reference to `krb_get_tf_fullname' /home/jnfergu/openssh/sshconnect1.c:707: undefined reference to `krb_get_cred' /home/jnfergu/openssh/sshconnect1.c:711: undefined reference to `krb_life_to_time' /home/jnfergu/openssh/sshconnect1.c:735: undefined reference to `krb_err_txt' sshconnect1.o: In function `send_afs_tokens': /home/jnfergu/openssh/sshconnect1.c:783: undefined reference to `krb_time_to_life' ./libssh.a(radix.o): In function `creds_to_radix': /home/jnfergu/openssh/radix.c:129: undefined reference to `krb_life_to_time' ./libssh.a(radix.o): In function `radix_to_creds': /home/jnfergu/openssh/radix.c:192: undefined reference to `krb_time_to_life' collect2: ld returned 1 exit status make: *** [ssh] Error 1 I myself am not much of a programmer, well not a very good one, and am kinda lost on what I should do from here, so any help would be appreciated. J. Ferguson Arizona State University Data Communications (602)-201-3970 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011113/5a3dc6b6/attachment.html From dan at doxpara.com Thu Nov 15 00:37:20 2001 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 14 Nov 2001 05:37:20 -0800 (PST) Subject: =?iso-8859-1?Q?Re:_des=5Fssh1=5Fsetiv_not_setting_the_IV_=3F?= In-Reply-To: <20011112174754.T1108@wirex.com> References: <20011112174754.T1108@wirex.com> Message-ID: <38654.127.0.0.1.1005745040.squirrel@mutant.doxpara.com> > I'll be the first to admit that I don't know the OpenSSH architecture, > but this appears to be an oversight that would go un-noticed until > someone wanted a non-zero IV .. how often does that happen? Is this a > known issue, for compatibility? > > Have I missed something else entirely? :) Seth-- [The short version: fixed initialization vector is not a threat, because the entire symmetric key changes with each session] I looked into this a bit, and this behavior isn't a bug, rather it's part of the explicit design of SSH1. According to the SSH1 spec (http://www.snailbook.com/docs/protocol-1.5.txt): 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 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. One of the major goals of a cryptosystem is to prevent one-to-one relationships between an occurance of plaintext(abc) and an occurance of ciphertext(xyz,pdq,#21,etc.) When the same symmetric key is used twice, there is a risk of that one to one relationship. CBC, or Cipher Block Chaining mode makes each future block dependent upon the contents of a previous block -- so the simple variability of past data prevents future data from encrypting identically. However, if there *is* no variable past data, the one to one still exists. Initialization Vectors are essentially "imagined past data" that is publically exchanged so that identical first blocks(and all blocks that follow, until sessions start to diverge) won't have to be identical. What's critical, though, is that SSHv1 *doesn't* use identical symmetric keys from one session to the next; rather, it uses a long term public key to authenticate a short term public key, then that short term public key to transfer the symmetric key actually used to transfer the data for that session. Because of this, no initialization vector needs to be exchanged--they're already exchanging unique keys. You can't do that safely with a purely symmetric cryptosystem, however, so most symmetric systems have provisions for initialization vectors. I do admit that I was slightly concerned when I read that SSH was fixing its initialization vectors, but unless I'm mistaken(and that's possible!), the manner in which SSH uses symmetric algorithms like 3DES and Blowfish entirely sidesteps the security risks that initialization vectors were intended to address. Yours Truly, Dan Kaminsky DoxPara Research http://www.doxpara.com P.S. Yes, this is the former dankamin at cisco.com, and it's good to be back :-) From markus at openbsd.org Thu Nov 15 00:45:49 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Nov 2001 14:45:49 +0100 Subject: [Bug 3] sshd does not properly daemonize itself In-Reply-To: <20011113045904.BA7CB2DF34@shitei.mindrot.org>; from bugzilla-daemon@mindrot.org on Tue, Nov 13, 2001 at 03:59:04PM +1100 References: <20011113045904.BA7CB2DF34@shitei.mindrot.org> Message-ID: <20011114144549.A20807@folly> > ------- Additional Comments From ralston at pobox.com 2001-11-13 15:59 ------- > The question is irrelevant; regardless of how one chooses to answer it, the > answer does not make sshd's behavior (of not making sure all inherited > descriptors are closed) any less broken. no, i don't understand. if the program calling sshd breaks because sshd does not close fd 142 on startup, then the program is broken. it must close it's filedescriptors. if sshd breaks because fd 142 is open on startup then sshd is broken. closing 1024 or more FDs on startup is not common in daemons, but they need to make sure to close fd 0-2. closing 1024 filedescriptors on startup does not fix bugs, it only fixes symptoms and hides the actual bugs. -m From markus at openbsd.org Thu Nov 15 00:46:25 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Nov 2001 14:46:25 +0100 Subject: Intermittent port forwarding problems openssh 2.9.2p and up In-Reply-To: <3BF15FAB.1331ADB7@tilab.com>; from gerardo.lamastra@TILAB.COM on Tue, Nov 13, 2001 at 07:00:11PM +0100 References: <3BF15FAB.1331ADB7@tilab.com> Message-ID: <20011114144625.B20807@folly> do you have debugging output? e.g. from ssh -v -v -v ? From markus at openbsd.org Thu Nov 15 00:49:05 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Nov 2001 14:49:05 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011114003143.19330.qmail@wizard.math.ualberta.ca>; from bowman@math.ualberta.ca on Wed, Nov 14, 2001 at 12:31:43AM -0000 References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> Message-ID: <20011114144905.C20807@folly> why do you repeat posting this broken patch to the list? calling shutdown is wrong. On Wed, Nov 14, 2001 at 12:31:43AM -0000, John Bowman wrote: > diff -ur openssh-3.0p1/session.c openssh-3.0p1J/session.c > --- openssh-3.0p1/session.c Sun Oct 28 04:34:53 2001 > +++ openssh-3.0p1J/session.c Tue Nov 13 15:55:52 2001 > @@ -1919,6 +1919,9 @@ > */ > if (c->ostate != CHAN_OUTPUT_CLOSED) > chan_write_failed(c); > + if (c->istate == CHAN_INPUT_OPEN && compat20) { > + chan_shutdown_read(c); > + } > s->chanid = -1; > } From celinn at mtu.edu Thu Nov 15 01:13:14 2001 From: celinn at mtu.edu (Christopher Linn) Date: Wed, 14 Nov 2001 09:13:14 -0500 Subject: Openssh 3.0p1/Solaris 8 problems still... In-Reply-To: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu>; from moyman@ecn.purdue.edu on Mon, Nov 12, 2001 at 03:50:18PM -0500 References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> Message-ID: <20011114091313.A10641@mtu.edu> On Mon, Nov 12, 2001 at 03:50:18PM -0500, James M Moya wrote: > Currently under solaris 8 with a fairly generic build: [...] > cron will quit working since ssh hasn't doesn't have auditing support > just right [...] > --mike On Mon, Nov 12, 2001 at 05:42:04PM -0800, Darren J Moffat wrote: > If you are running BSM auditing and have logged in using sshd and use > crontab -e to update your crontab then because sshd does not properly > setup the audit id for Solaris the .au file that cron uses to set the > audit id before running the cron job will be corrupt, as a result cron > will not run these jobs. > > It is a known problem, part of the problem is sshd by not having support > for setting up the BSM audit id is not a proper login service on Solaris > and part of the problem is crontab -e not noticing that the audit id > is invalid but still doing the update. On Tue, Nov 13, 2001 at 08:47:45PM +0100, Markus Friedl wrote: > how should openssh do this? do you have code examples? OK, i am curious; does SSH.Com handle this properly? if so, is the proper code only in the commercial version? chris -- Christopher Linn, | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From odie at rotta.media.sonera.net Thu Nov 15 02:35:21 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Wed, 14 Nov 2001 17:35:21 +0200 Subject: X11 forwards and libwrap support Message-ID: <200111141535.fAEFZLP14690@rotta.tmt.tele.fi> Hi! Is there any reason why support for the libwrap code isn't included in the X11 forwarding code? I'd like to restrict access to that port. How many applications would break if the tcp port would be closed and only the unix-domain socket would be available? It's true that x11 forwardings can be considered as a security risk and they are disabled because of that by default. I think that the risk can be made (a bit) smaller if there were more controls available to restrict access to the forwarded ports. Another question: is it requirement that the forwarded X11 port is bound to * instead of specific interface? Comments, suggestions? -- Osmo Paananen From markus at openbsd.org Thu Nov 15 02:51:14 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Nov 2001 16:51:14 +0100 Subject: X11 forwards and libwrap support In-Reply-To: <200111141535.fAEFZLP14690@rotta.tmt.tele.fi>; from odie@rotta.media.sonera.net on Wed, Nov 14, 2001 at 05:35:21PM +0200 References: <200111141535.fAEFZLP14690@rotta.tmt.tele.fi> Message-ID: <20011114165113.A635@faui02.informatik.uni-erlangen.de> On Wed, Nov 14, 2001 at 05:35:21PM +0200, Osmo Paananen wrote: > Is there any reason why support for the libwrap code isn't included > in the X11 forwarding code? I'd like to restrict access to that > port. i think that sshd should not depend on libwrap, it's already the sshd listen port and this is more than enough. having libwrap for other things is a problem because it control system policy instead of user policy. i think x11 fwd should either listen to the localhost or to all interfaces, but with x11/xauth this does not seem to work if DISPLAY points to localhost. i'd prefer to have this fixed. anther dependency on libwrap is a bad idea. > How many applications would break if the tcp port > would be closed and only the unix-domain socket would be available? i don't know. this would be nice. perhaps the x11 proxy code from x11 can give hints. > It's true that x11 forwardings can be considered as a security > risk and they are disabled because of that by default. probably. > I think that the risk can be made (a bit) smaller if there were > more controls available to restrict access to the forwarded ports. but x11 access on this port does not work, because you need the cookie. > Another question: is it requirement that the forwarded X11 port is > bound to * instead of specific interface? xauth does not like DISPLAY=localhost:x.y From Nicolas.Williams at ubsw.com Thu Nov 15 03:08:04 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 14 Nov 2001 11:08:04 -0500 Subject: X11 forwards and libwrap support In-Reply-To: <20011114165113.A635@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Nov 14, 2001 at 04:51:14PM +0100 References: <200111141535.fAEFZLP14690@rotta.tmt.tele.fi> <20011114165113.A635@faui02.informatik.uni-erlangen.de> Message-ID: <20011114110803.D5739@sm2p1386swk.wdr.com> On Wed, Nov 14, 2001 at 04:51:14PM +0100, Markus Friedl wrote: > On Wed, Nov 14, 2001 at 05:35:21PM +0200, Osmo Paananen wrote: > > Another question: is it requirement that the forwarded X11 port is > > bound to * instead of specific interface? > > xauth does not like DISPLAY=localhost:x.y Hmmm, is it because .Xauthority files are stored in home directories shared across multiple hosts? If so, why not mkstemp() a new .Xauthority file, shove the cookie there and set XAUTHORITY to point to it? Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From djast at cs.toronto.edu Thu Nov 15 03:15:28 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 14 Nov 2001 11:15:28 -0500 Subject: X11 forwards and libwrap support In-Reply-To: Your message of "Wed, 14 Nov 2001 10:51:14 EST." <20011114165113.A635@faui02.informatik.uni-erlangen.de> Message-ID: <01Nov14.111531edt.453144-10639@jane.cs.toronto.edu> On Wed, 14 Nov 2001 10:51:14 EST, Markus Friedl writes: > > i think x11 fwd should either listen to the localhost > or to all interfaces, but with x11/xauth this does not > seem to work if DISPLAY points to localhost. > > i'd prefer to have this fixed. Remember that many X client implementations "optimize" by reverting to the unix domain socket instead of TCP when the display name is "localhost" (and/or when the IP address is 127.0.0.1). > > How many applications would break if the tcp port > > would be closed and only the unix-domain socket would be available? > > i don't know. this would be nice. perhaps the x11 proxy > code from x11 can give hints. I don't know if it would be worthwhile for ssh's X11 forwarding to also be able to use unix sockets instead of TCP, but it seems like rather a can of worms just to provide functionality that's already there. If unix domain sockets / loopback connections could be handled reliably, an option analagous to GatewayPorts might make sense. > > Another question: is it requirement that the forwarded X11 port is > > bound to * instead of specific interface? > > xauth does not like DISPLAY=localhost:x.y Doesn't like it, or just doesn't do what one might expect it to? -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From odie at rotta.media.sonera.net Thu Nov 15 03:20:26 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Wed, 14 Nov 2001 18:20:26 +0200 Subject: X11 forwards and libwrap support In-Reply-To: Your message of "Wed, 14 Nov 2001 16:51:14 +0100." <20011114165113.A635@faui02.informatik.uni-erlangen.de> Message-ID: <200111141620.fAEGKQP16119@rotta.tmt.tele.fi> > i think that sshd should not depend on libwrap, it's already > the sshd listen port and this is more than enough. > having libwrap for other things is a problem because > it control system policy instead of user policy. What is wrong with system policies? I realize that there are many kinds of environments. One of those is multiuser environment (typically universities) and another would be an ISP where there are only adminstrators whom have to comply policies (some are enforced by firewall, some by access lists and some are not enforced at all). I personally haven't used forwarded X11 connections from other hosts over network at all. (I mean connecting to the forwarded port from third host, where I'm not connected via ssh). I suspect that this is true for most users. > i think x11 fwd should either listen to the localhost > or to all interfaces, but with x11/xauth this does not > seem to work if DISPLAY points to localhost. > i'd prefer to have this fixed. How about if the x11 fwd would listen on the interface which is pointed by the hostname (this would be an option, not default)? > anther dependency on libwrap is a bad idea. Why? Certainly as option it wouldn't hurt anybody? > > How many applications would break if the tcp port > > would be closed and only the unix-domain socket would be available? > i don't know. this would be nice. perhaps the x11 proxy > code from x11 can give hints. This shouldn't be hard to test either. I just asked in case someone would know the answer. It would save some work. If it works for some (most) applications then it could be nice to see as configuration option. > > I think that the risk can be made (a bit) smaller if there were > > more controls available to restrict access to the forwarded ports. > but x11 access on this port does not work, because you > need the cookie. Why then have libwrap on the port 22? Every user has password! > > Another question: is it requirement that the forwarded X11 port is > > bound to * instead of specific interface? > xauth does not like DISPLAY=localhost:x.y Ok, but how about machines with multiple interfaces? I can think of web server that has one dedicated interface for backup/adminstration and another for running services (like www.company.com). There should not be need to have X11 proxy listening on that interface, shoud there? -- Osmo Paananen From andreas at conectiva.com.br Thu Nov 15 03:20:17 2001 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Wed, 14 Nov 2001 14:20:17 -0200 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011114144905.C20807@folly> References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <20011114144905.C20807@folly> Message-ID: <20011114142017.K1097@conectiva.com.br> Here is a patch a colleague of mine did, please include him (and not me, I'm just posting it here) in replies, he is not subscribed to this list and I don't think he has already sent this patch here: pcpa at conectiva.com.br Comments? diff -u openssh-2.9p1/clientloop.c openssh/clientloop.c --- openssh-2.9p1/clientloop.c Fri Apr 20 09:50:51 2001 +++ openssh/clientloop.c Mon May 7 17:10:52 2001 @@ -840,8 +840,11 @@ /* Process buffered packets sent by the server. */ client_process_buffered_input_packets(); - if (compat20 && session_closed && !channel_still_open()) + if (compat20 && session_closed) { + if (channel_still_open()) + channel_stop_listening(); break; + } rekeying = (xxx_kex != NULL && !xxx_kex->done); @@ -1186,6 +1189,7 @@ } else if (strcmp(rtype, "exit-status") == 0) { success = 1; exit_status = packet_get_int(); + session_closed = 1; packet_done(); } if (reply) { Em Wed, Nov 14, 2001 at 02:49:05PM +0100, Markus Friedl escreveu: > why do you repeat posting this broken patch to the list? From markus at openbsd.org Thu Nov 15 03:21:20 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Nov 2001 17:21:20 +0100 Subject: X11 forwards and libwrap support In-Reply-To: <01Nov14.111531edt.453144-10639@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Wed, Nov 14, 2001 at 11:15:28AM -0500 References: <20011114165113.A635@faui02.informatik.uni-erlangen.de> <01Nov14.111531edt.453144-10639@jane.cs.toronto.edu> Message-ID: <20011114172120.A3374@faui02.informatik.uni-erlangen.de> On Wed, Nov 14, 2001 at 11:15:28AM -0500, Dan Astoorian wrote: > On Wed, 14 Nov 2001 10:51:14 EST, Markus Friedl writes: > > > > i think x11 fwd should either listen to the localhost > > or to all interfaces, but with x11/xauth this does not > > seem to work if DISPLAY points to localhost. > > > > i'd prefer to have this fixed. > > Remember that many X client implementations "optimize" by reverting to > the unix domain socket instead of TCP when the display name is > "localhost" (and/or when the IP address is 127.0.0.1). yes, and that's broken behaviour. > If unix domain sockets / loopback connections could be handled reliably, > an option analagous to GatewayPorts might make sense. sure and this is what is want. but i'd prefer not to use unix-domain. > > > Another question: is it requirement that the forwarded X11 port is > > > bound to * instead of specific interface? > > > > xauth does not like DISPLAY=localhost:x.y > > Doesn't like it, or just doesn't do what one might expect it to? that's the same to me if i read my last mail. it's the stupid unix-domain optimization in X11. From GILBERT.R.LOOMIS at saic.com Thu Nov 15 03:29:11 2001 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Wed, 14 Nov 2001 11:29:11 -0500 Subject: Openssh 3.0p1/Solaris 8 problems still... Message-ID: <3C1E3607B37295439F7C409EFBA08E680E27B0@col-581-exs01.cist.saic.com> Dammit. I have old code that I keep thinking I'll be able to spend the time to port over. It was against SSH.com 1.2.27, and correctly implemented auditing on Solaris and IRIX. When last I looked at it, I wasn't sure how best to insert it into OpenSSH. I'll take a look at it this afternoon, and either send a patch or put the code out for someone else to play with. -- Rip Loomis Senior Systems Security Engineer SAIC Center for Information Security Technology > -----Original Message----- > From: Markus Friedl [mailto:markus at openbsd.org] > Sent: Tuesday, 13 November, 2001 14:48 > To: Darren J Moffat > Cc: Christopher Linn; openssh-unix-dev at mindrot.org > Subject: Re: Openssh 3.0p1/Solaris 8 problems still... > > > On Mon, Nov 12, 2001 at 05:42:04PM -0800, Darren J Moffat wrote: > > If you are running BSM auditing and have logged in using > sshd and use > > crontab -e to update your crontab then because sshd does > not properly > > setup the audit id for Solaris the .au file that cron uses > to set the > > how should openssh do this? do you have code examples? > > -m > From markus at openbsd.org Thu Nov 15 03:26:42 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Nov 2001 17:26:42 +0100 Subject: X11 forwards and libwrap support In-Reply-To: <200111141620.fAEGKQP16119@rotta.tmt.tele.fi>; from odie@rotta.media.sonera.net on Wed, Nov 14, 2001 at 06:20:26PM +0200 References: <20011114165113.A635@faui02.informatik.uni-erlangen.de> <200111141620.fAEGKQP16119@rotta.tmt.tele.fi> Message-ID: <20011114172642.B3374@faui02.informatik.uni-erlangen.de> it's about complexity. currently: the x11 proxy listens listen to inaddr-any. nice to have: listen to localhost or inaddr-any. other options: too much complexity/code/bugs in openssh. ideally openssh, especially the sshd should have no option. From markus at openbsd.org Thu Nov 15 03:27:29 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Nov 2001 17:27:29 +0100 Subject: X11 forwards and libwrap support In-Reply-To: <20011114110803.D5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Wed, Nov 14, 2001 at 11:08:04AM -0500 References: <200111141535.fAEFZLP14690@rotta.tmt.tele.fi> <20011114165113.A635@faui02.informatik.uni-erlangen.de> <20011114110803.D5739@sm2p1386swk.wdr.com> Message-ID: <20011114172729.C3374@faui02.informatik.uni-erlangen.de> On Wed, Nov 14, 2001 at 11:08:04AM -0500, Nicolas Williams wrote: > Hmmm, is it because .Xauthority files are stored in home directories > shared across multiple hosts? have you tried this? > If so, why not mkstemp() a new .Xauthority file, shove the cookie there > and set XAUTHORITY to point to it? have you tried this? From Nicolas.Williams at ubsw.com Thu Nov 15 03:40:53 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 14 Nov 2001 11:40:53 -0500 Subject: X11 forwards and libwrap support In-Reply-To: <20011114172729.C3374@faui02.informatik.uni-erlangen.de>; from Markus Friedl on Wed, Nov 14, 2001 at 05:27:29PM +0100 References: <200111141535.fAEFZLP14690@rotta.tmt.tele.fi> <20011114165113.A635@faui02.informatik.uni-erlangen.de> <20011114110803.D5739@sm2p1386swk.wdr.com> <20011114172729.C3374@faui02.informatik.uni-erlangen.de> Message-ID: <20011114114053.W26615@wdr.com> On Wed, Nov 14, 2001 at 05:27:29PM +0100, Markus Friedl wrote: > On Wed, Nov 14, 2001 at 11:08:04AM -0500, Nicolas Williams wrote: > > Hmmm, is it because .Xauthority files are stored in home directories > > shared across multiple hosts? > > have you tried this? Hmmm, not with localhost:*. > > If so, why not mkstemp() a new .Xauthority file, shove the cookie there > > and set XAUTHORITY to point to it? > > have you tried this? Yes. I see. "SecurityBadAuthorizationProtocol (invalid authorization name or data)" Sigh, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Darren.Moffat at Sun.COM Thu Nov 15 03:51:01 2001 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Wed, 14 Nov 2001 08:51:01 -0800 Subject: Openssh 3.0p1/Solaris 8 problems still... References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> <20011114091313.A10641@mtu.edu> Message-ID: <3BF2A0F5.8050500@Sun.COM> Christopher Linn wrote: > OK, i am curious; does SSH.Com handle this properly? if so, is the > proper code only in the commercial version? Too my knowlege there are no 3rd party login products from any vendor that do this properly for Solaris. Most vendors don't test their products with BSM auditing installed because so many people don't even know that it exists never mind how to write code for it. -- Darren J Moffat From Nicolas.Williams at ubsw.com Thu Nov 15 04:09:06 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 14 Nov 2001 12:09:06 -0500 Subject: Openssh 3.0p1/Solaris 8 problems still... In-Reply-To: <3BF2A0F5.8050500@Sun.COM>; from Darren.Moffat@Sun.COM on Wed, Nov 14, 2001 at 08:51:01AM -0800 References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> <20011114091313.A10641@mtu.edu> <3BF2A0F5.8050500@Sun.COM> Message-ID: <20011114120905.E5739@sm2p1386swk.wdr.com> Would it be as easy to implement as adding calls to setaudit(), au_open(), au_write() and au_close()? Nico On Wed, Nov 14, 2001 at 08:51:01AM -0800, Darren J Moffat wrote: > Christopher Linn wrote: > > > OK, i am curious; does SSH.Com handle this properly? if so, is the > > proper code only in the commercial version? > > > Too my knowlege there are no 3rd party login products from any vendor > that do this properly for Solaris. Most vendors don't test their > products with BSM auditing installed because so many people don't even > know that it exists never mind how to write code for it. > > -- > Darren J Moffat > > -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From djast at cs.toronto.edu Thu Nov 15 04:32:11 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 14 Nov 2001 12:32:11 -0500 Subject: X11 forwards and libwrap support In-Reply-To: Your message of "Wed, 14 Nov 2001 11:08:04 EST." <20011114110803.D5739@sm2p1386swk.wdr.com> Message-ID: <01Nov14.123219edt.453144-10639@jane.cs.toronto.edu> On Wed, 14 Nov 2001 11:08:04 EST, Nicolas Williams writes: > > Hmmm, is it because .Xauthority files are stored in home directories > shared across multiple hosts? > > If so, why not mkstemp() a new .Xauthority file, shove the cookie there > and set XAUTHORITY to point to it? This isn't directly related, but this has reminded me about another minor problem I've been meaning to mention involving .Xauthority files over NFS. Since xauth copies the contents of the .Xauthority file and unlinks the old one, this can result in a stale NFS file handle when X clients try to access $HOME/.Xauthority shortly after sshd on a remote machine has called xauth to add a cookie. A contrived example, which others may or may not be able to reproduce: palm.cs:~> setenv DISPLAY palm.cs:0.0 palm.cs:~> ssh -X -f otherhost xterm ; sleep 3 ; xterm Xlib: connection to "palm.cs:0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: palm.cs:0.0 palm.cs:~> The Xlib errors above are from the local xterm, because $HOME/.Xauthority becomes a stale NFS handle after ssh runs xauth to set up the cookie for the X forwarding. The problem only persists for a short time. I've seen this issue cause problems when users have put ssh commands into their X startup files; e.g., when they try to log into X, the window manager fails to start up due to the stale NFS handle caused by an ssh command to a compute server, and so the user gets logged out immediately. This type of symptom, IF it occurs, is usually intermittent. Back when OpenSSH kept its cookies in /tmp, it wasn't an issue; now that they're back to the default location, some of my users have started seeing it again. In case anyone else has run into this, one workaround is to set XAUTHORITY in $HOME/.ssh/environment (e.g., "XAUTHORITY=/path/to/homedir/.ssh/Xauthority") so that ssh cookies for X forwardings are kept in a separate .Xauthority file from other xauth cookies (which probably isn't a bad idea anyway). I don't think this is by any means a showstopper, but does anyone think it would be worthwhile for OpenSSH's daemon to use a non-default location for its cookies by setting $XAUTHORITY to point to a file under $HOME/.ssh/? -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From celinn at mtu.edu Thu Nov 15 05:30:02 2001 From: celinn at mtu.edu (Christopher Linn) Date: Wed, 14 Nov 2001 13:30:02 -0500 Subject: Openssh 3.0p1/Solaris 8 problems still... In-Reply-To: <3BF2A0F5.8050500@Sun.COM>; from Darren.Moffat@Sun.COM on Wed, Nov 14, 2001 at 08:51:01AM -0800 References: <200111122050.fACKoIc22605@harbor.ecn.purdue.edu> <20011114091313.A10641@mtu.edu> <3BF2A0F5.8050500@Sun.COM> Message-ID: <20011114133002.C10641@mtu.edu> On Wed, Nov 14, 2001 at 08:51:01AM -0800, Darren J Moffat wrote: > Christopher Linn wrote: > > > OK, i am curious; does SSH.Com handle this properly? if so, is the > > proper code only in the commercial version? > > Too my knowlege there are no 3rd party login products from any vendor > that do this properly for Solaris. Most vendors don't test their > products with BSM auditing installed because so many people don't even > know that it exists never mind how to write code for it. *chuckle* ... ow my sides ;*) this begs the question: would SMI like there to be? what other OS vendors support BSM auditing? > -- > Darren J Moffat chris -- Christopher Linn, | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein. From Darren.Moffat at eng.sun.com Thu Nov 15 05:34:02 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 14 Nov 2001 10:34:02 -0800 (PST) Subject: Openssh 3.0p1/Solaris 8 problems still... Message-ID: <200111141834.fAEIY2Cn929952@jurassic.eng.sun.com> >> > OK, i am curious; does SSH.Com handle this properly? if so, is the >> > proper code only in the commercial version? >> >> Too my knowlege there are no 3rd party login products from any vendor >> that do this properly for Solaris. Most vendors don't test their >> products with BSM auditing installed because so many people don't even >> know that it exists never mind how to write code for it. > >*chuckle* ... ow my sides ;*) > >this begs the question: would SMI like there to be? Yes we would and we have been working to get our API's in better shape so that it will be easier for vendors to support this. >what other OS vendors support BSM auditing? BSM auditing is unique to Solaris. Other vendors may have similar functionality but there are no standards based or de facto standards for the API or log file format. -- Darren J Moffat From markus at openbsd.org Thu Nov 15 05:48:31 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 14 Nov 2001 19:48:31 +0100 Subject: X11 forwards and libwrap support In-Reply-To: <01Nov14.123219edt.453144-10639@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Wed, Nov 14, 2001 at 12:32:11PM -0500 References: <20011114110803.D5739@sm2p1386swk.wdr.com> <01Nov14.123219edt.453144-10639@jane.cs.toronto.edu> Message-ID: <20011114194831.A11649@faui02.informatik.uni-erlangen.de> On Wed, Nov 14, 2001 at 12:32:11PM -0500, Dan Astoorian wrote: > I don't think this is by any means a showstopper, but does anyone think > it would be worthwhile for OpenSSH's daemon to use a non-default > location for its cookies by setting $XAUTHORITY to point to a file under > $HOME/.ssh/? i think this is exactly what .ssh/rc /etc/sshrc .ssh/environment are for. i don't like to have 100 ways for doing the same thing. ssh is not perl! -m From pekkas at netcore.fi Thu Nov 15 06:35:27 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 14 Nov 2001 21:35:27 +0200 (EET) Subject: X11 forwards and libwrap support In-Reply-To: <20011114194831.A11649@faui02.informatik.uni-erlangen.de> Message-ID: On Wed, 14 Nov 2001, Markus Friedl wrote: > On Wed, Nov 14, 2001 at 12:32:11PM -0500, Dan Astoorian wrote: > > I don't think this is by any means a showstopper, but does anyone think > > it would be worthwhile for OpenSSH's daemon to use a non-default > > location for its cookies by setting $XAUTHORITY to point to a file under > > $HOME/.ssh/? > > i think this is exactly what > .ssh/rc > /etc/sshrc > .ssh/environment > are for. i don't like to have 100 ways for doing > the same thing. ssh is not perl! I've tried using these to reset cookies path, to go under /tmp, but it is not possible for the general case (every user). If you configure each user individually with slightly modified config file, then yes. Otherwise no. Please see the thread: Date: Fri, 6 Jul 2001 09:34:56 +0300 (EEST) From: Pekka Savola To: Subject: Xauthority location: only per-user setting possible -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From sarnold at marcelothewonderpenguin.com Thu Nov 15 06:43:38 2001 From: sarnold at marcelothewonderpenguin.com (Seth Arnold) Date: Wed, 14 Nov 2001 11:43:38 -0800 Subject: des_ssh1_setiv not setting the IV ? In-Reply-To: <38654.127.0.0.1.1005745040.squirrel@mutant.doxpara.com>; from dan@doxpara.com on Wed, Nov 14, 2001 at 05:37:20AM -0800 References: <20011112174754.T1108@wirex.com> <38654.127.0.0.1.1005745040.squirrel@mutant.doxpara.com> Message-ID: <20011114114338.D1108@wirex.com> On Wed, Nov 14, 2001 at 05:37:20AM -0800, Dan Kaminsky wrote: > [The short version: fixed initialization vector is not a threat, > because the entire symmetric key changes with each session] Great. Thanks Dan and Markus. Now that you mention it, I do seem to recall new session keys for each new connection, which *would* obviate entirely the need for dynamic IVs. (Well, at least until keys are re-used, which, with a 56-bit keyspace, is liable to happen sooner or later by accident -- but there are worse problems with DES anyway. :) I appreciate you both taking the time to look into this, even if the end result is that I don't get my name in lights. :) > P.S. Yes, this is the former dankamin at cisco.com, and it's good to be > back :-) Welcome back. I hope you are enjoying your new position at DoxPara research. I look forward to your continued (and re-newed :) presence in all the same lists I follow. :) Thanks again! -- The Bill of Rights: 7 out of 10 rights haven't been sold yet! Contact your congressman for details how *you* can buy one today! From gfischer at adventnetworks.com Thu Nov 15 09:36:15 2001 From: gfischer at adventnetworks.com (Gordon Fischer) Date: Wed, 14 Nov 2001 16:36:15 -0600 Subject: Embedded Cross-Compiling of OpenSSL & OpenSSH Message-ID: I'm developing a minimal embedded linux system that will be running on a powerpc chip. I can get everything to work but the size is quite large. The majority of my size requirements are in libcrypto.a which is around 1.52 Megs I tried to pare it down further by removing some crypto options [ Configure linux-ppc no-asm no-cast no-des no-dh no-md2 no-mdc2 no-rc2 no-rc4 no-rc5 shared ] This got me to 1.35 Megs. I've read on other lists that stripping the library is bad news, but a modest debug strip doesn't seem to affect functionality and takes me down to 800 K. Any ideas on how I can get libcrypto smaller? Thanks, Gordon Fischer Advent Networks gfischer at adventnetworks.com From djm at mindrot.org Thu Nov 15 09:45:22 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Nov 2001 09:45:22 +1100 (EST) Subject: Embedded Cross-Compiling of OpenSSL & OpenSSH In-Reply-To: Message-ID: On Wed, 14 Nov 2001, Gordon Fischer wrote: > I'm developing a minimal embedded linux system that will be running on a > powerpc chip. I can get everything to work but the size is quite large. > > The majority of my size requirements are in libcrypto.a which is around > 1.52 Megs These questions would probably be better asked on one of the OpenSSL lists. > I tried to pare it down further by removing some crypto options > [ Configure linux-ppc no-asm no-cast no-des no-dh no-md2 no-mdc2 no-rc2 > no-rc4 no-rc5 shared ] > This got me to 1.35 Megs. You may want to keep rc4 for OpenSSH - it is used in several places and the algorithm itself is tiny. > I've read on other lists that stripping the library is bad news, but a > modest debug strip doesn't seem to affect functionality and takes me > down to 800 K. I can't see why stripping should cause any problems. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From dbutts at maddog.storability.com Thu Nov 15 10:39:01 2001 From: dbutts at maddog.storability.com (David Butts) Date: Wed, 14 Nov 2001 18:39:01 -0500 Subject: Embedded Cross-Compiling of OpenSSL & OpenSSH In-Reply-To: References: Message-ID: <20011114183901.A25633@storability.com> Hello, all- On Thu, Nov 15, 2001 at 09:45:22AM +1100, Damien Miller wrote: > On Wed, 14 Nov 2001, Gordon Fischer wrote: > > > I'm developing a minimal embedded linux system that will be running on a > > powerpc chip. I can get everything to work but the size is quite large. > > > > The majority of my size requirements are in libcrypto.a which is around > > 1.52 Megs > > These questions would probably be better asked on one of the OpenSSL > lists. Agreed, but, even so, it may be a moot point, if there is no need to have libcrypto.a present on the embedded system. The static library is only needed to build OpenSSH. Assuming the build is being done elsewhere, you should be able to leave it off the OS image for the embedded system entirely. David From markus at openbsd.org Thu Nov 15 21:14:24 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 11:14:24 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011114142017.K1097@conectiva.com.br>; from andreas@conectiva.com.br on Wed, Nov 14, 2001 at 02:20:17PM -0200 References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <20011114144905.C20807@folly> <20011114142017.K1097@conectiva.com.br> Message-ID: <20011115111424.A28941@folly> On Wed, Nov 14, 2001 at 02:20:17PM -0200, Andreas Hasenack wrote: > diff -u openssh-2.9p1/clientloop.c openssh/clientloop.c > --- openssh-2.9p1/clientloop.c Fri Apr 20 09:50:51 2001 > +++ openssh/clientloop.c Mon May 7 17:10:52 2001 > @@ -840,8 +840,11 @@ > /* Process buffered packets sent by the server. */ > client_process_buffered_input_packets(); > > - if (compat20 && session_closed && !channel_still_open()) > + if (compat20 && session_closed) { > + if (channel_still_open()) > + channel_stop_listening(); > break; > + } i guess this patch is for disabling listen() for local forwarding after the login session has been closed. i think this matches the protocol 1 behaviour, but i have to do some more tests. > rekeying = (xxx_kex != NULL && !xxx_kex->done); > > @@ -1186,6 +1189,7 @@ > } else if (strcmp(rtype, "exit-status") == 0) { > success = 1; > exit_status = packet_get_int(); > + session_closed = 1; well, it's possible to send data after the exit-status, so i'm still not quite sure. the only 'fix' for the so called hang-on-exit would be: allow data loss in the server if a pty is allocated. i think this would match the telnetd and rlogind behaviour best. but i'm not 100% sure, people should test their telnetd/rlogind servers and check that they throw away data after the login shell dies. but once again: openssh is not telnet. -m From gert at greenie.muc.de Thu Nov 15 21:32:22 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 11:32:22 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115111424.A28941@folly>; from Markus Friedl on Thu, Nov 15, 2001 at 11:14:24AM +0100 References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <20011114144905.C20807@folly> <20011114142017.K1097@conectiva.com.br> <20011115111424.A28941@folly> Message-ID: <20011115113222.C29302@greenie.muc.de> Hi, On Thu, Nov 15, 2001 at 11:14:24AM +0100, Markus Friedl wrote: [..] > allow data loss in the server if a pty is allocated. i think > this would match the telnetd and rlogind behaviour best. I would accept this, and prefer it to "I have run something in the background that I know will not create output but fails to close stdin/stdout/stderr and now I can't log out cleanly". > but i'm not 100% sure, people should test their telnetd/rlogind > servers and check that they throw away data after the login > shell dies. but once again: openssh is not telnet. That's what "all implementation I'm used to" do: if I logout the connection is closed, no matter what background processes are still alive. The background processes will then get some kind of error (I assume vhangup -> I/O error or something like this) if they try to write something after the connection is already closed. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From gert at greenie.muc.de Thu Nov 15 22:18:35 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 12:18:35 +0100 Subject: RhostsAuthentication? Message-ID: <20011115121835.F29302@greenie.muc.de> Hi, is anybody out there still using RhostsAuthentication? Can we please remove it? I just stumbled over a few sshd_config's set up by colleagues who didn't bother to understand what they are doing, and since .shosts didn't work anymore after upgrading to OpenSSH 3, they just enabled RhostsAuth and voila, back to "working"... Yes, there is a big warning in the sshd_config, but that doesn't seem to be enough. Maybe a compile time option? "./configure --yes-I-want-rhostauth"? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From markus at openbsd.org Thu Nov 15 22:22:42 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 12:22:42 +0100 Subject: RhostsAuthentication? In-Reply-To: <20011115121835.F29302@greenie.muc.de>; from gert@greenie.muc.de on Thu, Nov 15, 2001 at 12:18:35PM +0100 References: <20011115121835.F29302@greenie.muc.de> Message-ID: <20011115122242.A5710@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 12:18:35PM +0100, Gert Doering wrote: > is anybody out there still using RhostsAuthentication? Can we please > remove it? i don't think we can remove the code, perhaps just printing a big WARNING to stderr/syslog if it's enabled or used. -m From gert at greenie.muc.de Thu Nov 15 22:29:11 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 12:29:11 +0100 Subject: RhostsAuthentication? In-Reply-To: <20011115122242.A5710@faui02.informatik.uni-erlangen.de>; from Markus Friedl on Thu, Nov 15, 2001 at 12:22:42PM +0100 References: <20011115121835.F29302@greenie.muc.de> <20011115122242.A5710@faui02.informatik.uni-erlangen.de> Message-ID: <20011115122911.H29302@greenie.muc.de> Hi, On Thu, Nov 15, 2001 at 12:22:42PM +0100, Markus Friedl wrote: > On Thu, Nov 15, 2001 at 12:18:35PM +0100, Gert Doering wrote: > > is anybody out there still using RhostsAuthentication? Can we please > > remove it? > > i don't think we can remove the code, perhaps just printing a big > WARNING to stderr/syslog if it's enabled or used. This would be a Good Thing. Stderr and syslog, please. And please change the wording in sshd_config, maybe something like this: old: # rhosts authentication should not be used RhostsAuthentication no new: # This is the old-style authenticate-by-IP only, no-crypto .rhosts thing. # You should not use this if you do not really know what you're doing. # For normal .rhosts usage, look at RhostsRSAAuthentication (protocol 1) # or HostBasedAuthentication (protocol 2). RhostsAuthentication no - maybe that will help. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From osmo.paananen at sonera.com Thu Nov 15 22:59:57 2001 From: osmo.paananen at sonera.com (Osmo Paananen) Date: Thu, 15 Nov 2001 13:59:57 +0200 Subject: X11 forwards and libwrap support In-Reply-To: Your message of "Wed, 14 Nov 2001 17:26:42 +0100." <20011114172642.B3374@faui02.informatik.uni-erlangen.de> Message-ID: <200111151159.fAFBxvP18169@rotta.tmt.tele.fi> > it's about complexity. > currently: the x11 proxy listens listen to inaddr-any. > nice to have: listen to localhost or inaddr-any. Did I understand correctly, that openssh's x11 forwards do not support unix-domain sockets? And that some aplications revert to unix domain sockets if the display is localhost:*? Then I think that just converting openssh to use localhost as the interface for the forwarded x11 tcp socket is not the solution. Or if it is then support for the unix-domain sockets is required, too. > other options: too much complexity/code/bugs in openssh. tcp-wrapper is already included, would it really add too much complexity to use it with the x11-forwards? > ideally openssh, especially the sshd should have no option. In ideal world computers would work. -- Osmo Paananen From vinschen at redhat.com Thu Nov 15 23:08:05 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 15 Nov 2001 13:08:05 +0100 Subject: RhostsAuthentication? In-Reply-To: <20011115122911.H29302@greenie.muc.de>; from gert@greenie.muc.de on Thu, Nov 15, 2001 at 12:29:11PM +0100 References: <20011115121835.F29302@greenie.muc.de> <20011115122242.A5710@faui02.informatik.uni-erlangen.de> <20011115122911.H29302@greenie.muc.de> Message-ID: <20011115130805.W27452@cygbert.vinschen.de> On Thu, Nov 15, 2001 at 12:29:11PM +0100, Gert Doering wrote: > Hi, > > On Thu, Nov 15, 2001 at 12:22:42PM +0100, Markus Friedl wrote: > > On Thu, Nov 15, 2001 at 12:18:35PM +0100, Gert Doering wrote: > > > is anybody out there still using RhostsAuthentication? Can we please > > > remove it? > > > > i don't think we can remove the code, perhaps just printing a big > > WARNING to stderr/syslog if it's enabled or used. > > This would be a Good Thing. Stderr and syslog, please. > > And please change the wording in sshd_config, maybe something like this: > > old: > > # rhosts authentication should not be used > RhostsAuthentication no > > new: > > # This is the old-style authenticate-by-IP only, no-crypto .rhosts thing. > # You should not use this if you do not really know what you're doing. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'm pretty sure that will not work. _Of course_ they know what they are doing! How dare you to doubt just for a moment! ;-) Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From peterw at usa.net Fri Nov 16 00:55:07 2001 From: peterw at usa.net (Peter W) Date: Thu, 15 Nov 2001 08:55:07 -0500 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115113222.C29302@greenie.muc.de>; from gert@greenie.muc.de on Thu, Nov 15, 2001 at 11:32:22AM +0100 References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <20011114144905.C20807@folly> <20011114142017.K1097@conectiva.com.br> <20011115111424.A28941@folly> <20011115113222.C29302@greenie.muc.de> Message-ID: <20011115085507.E7681@usa.net> On Thu, Nov 15, 2001 at 11:32:22AM +0100, Gert Doering wrote: > On Thu, Nov 15, 2001 at 11:14:24AM +0100, Markus Friedl wrote: > > allow data loss in the server if a pty is allocated. i think > > this would match the telnetd and rlogind behaviour best. > > I would accept this, and prefer it to "I have run something in the > background that I know will not create output but fails to close > stdin/stdout/stderr and now I can't log out cleanly". And the problem with simply killing the ssh client application is? I think there's a significant amount of disagrement on this issue, to say the least. With the core argument distilling to a question of Integrity vs Convenience, I've got a hard time siding with Convenience. SSH is not telnet, and I wouldn't like to see it twisted in a way that is (clearly!) arguablya step backwards for Convenience sake. -Peter From jan.bymark at cgey.com Fri Nov 16 01:27:12 2001 From: jan.bymark at cgey.com (Bymark, Jan) Date: Thu, 15 Nov 2001 15:27:12 +0100 Subject: unable to get connection thru firewall Message-ID: <2AA167413A3BD5119D2500B0D0AB1579265F03@CPH01> Hi, Is there someone how can help me with this problem?? Hi, I've a Solaris 8 with Openshh 3.0.1 (build with these parameters --prefix=/usr/local --without-rsh --disable-suid-ssh --sysconfdir=/usr/local/etc --with-ssl-dir=/usr/local/ssl --with-tcp-wrappers). If I come from the same subnet as the server is on, I've have no problems. But When I try via theI nternet I doesn't. If I run snoop I can see I get contact with the server: 193.234.247.50 -> imsdemo1 TCP D=22 S=20094 Syn Seq=2899242921 Len=0 Win=163 84 Options= My /var/adm/messages show me this: Nov 12 16:47:48 imsdemo1 sshd[29929]: [ID 800047 auth.error] error: Bind to port 22 on1 93.234.247.50 failed: Cannot assign requested address. Nov 12 16:47:48i msdemo1 sshd[29929]: [ID 800047 auth.crit] fatal: Cannot bind a ny address. Nov 12 16:50:26 imsdemo1 sshd[34]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer Hope someone can help me __________________________________________________ Best regards/ Med venlig hilsen Jan Bymark System Consultant TELECOM MEDIA NETWORKS Cap Gemini TMN Group Denmark A/S Oernegaardsvej 16 DK-2820 Gentofte Denmark (+45 39 77 84 76 (direct line) (+45 70 11 22 01 (office) (+45 70 11 22 01 (fax) * jan.bymark at capgemini.dk " http://www.cgey.com/tmn "We make you outstanding in a connected world" __________________________________________________ This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011115/349698ae/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: CGltbg.GIF Type: image/gif Size: 2038 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011115/349698ae/attachment.gif From wknox at mitre.org Fri Nov 16 02:09:55 2001 From: wknox at mitre.org (William R. Knox) Date: Thu, 15 Nov 2001 10:09:55 -0500 (EST) Subject: Patch for "last" providing incorrect information on Solaris 8 Message-ID: I have put together a simple set of diffs that corrects the problem described by Steven Fishback on 10-30 on this list regarding incorrect information reported by last on Solaris. The patches merely pass along the username in the utmpx record for a logout. Is there any reason why this would be a problem with other OSes? If not, maybe this could be rolled into the port. If so, diddling with configure would be the next step. Any ideas? The diffs are against 3.0p1, by the way. Bill Knox Senior Operating Systems Programmer/Analyst The MITRE Corporation -------------- next part -------------- --- loginrec.c.orig Thu Nov 15 09:35:02 2001 +++ loginrec.c Thu Nov 15 09:38:01 2001 @@ -701,6 +701,7 @@ line_stripname(utx->ut_line, li->line, sizeof(utx->ut_line)); set_utmpx_time(li, utx); utx->ut_pid = li->pid; + strncpy(utx->ut_name, li->username, MIN_SIZEOF(utx->ut_name, li->username)); if (li->type == LTYPE_LOGOUT) return; @@ -711,7 +712,6 @@ */ /* strncpy(): Don't necessarily want null termination */ - strncpy(utx->ut_name, li->username, MIN_SIZEOF(utx->ut_name, li->username)); # ifdef HAVE_HOST_IN_UTMPX strncpy(utx->ut_host, li->hostname, MIN_SIZEOF(utx->ut_host, li->hostname)); # endif @@ -942,9 +942,7 @@ { struct utmpx utx; - memset(&utx, '\0', sizeof(utx)); - set_utmpx_time(li, &utx); - line_stripname(utx.ut_line, li->line, sizeof(utx.ut_line)); + construct_utmpx(li, &utx); # ifdef HAVE_ID_IN_UTMPX line_abbrevname(utx.ut_id, li->line, sizeof(utx.ut_id)); # endif --- session.c.orig Thu Nov 15 09:35:02 2001 +++ session.c Thu Nov 15 09:38:01 2001 @@ -1856,7 +1856,7 @@ /* Record that the user has logged out. */ if (s->pid != 0) - record_logout(s->pid, s->tty); + record_logout(s->pid, s->tty, s->pw->pw_name); /* Release the pseudo-tty. */ pty_release(s->tty); --- sshlogin.c.orig Thu Nov 15 09:35:02 2001 +++ sshlogin.c Thu Nov 15 09:38:01 2001 @@ -94,11 +94,11 @@ /* Records that the user has logged out. */ void -record_logout(pid_t pid, const char *ttyname) +record_logout(pid_t pid, const char *ttyname, const char *user) { struct logininfo *li; - li = login_alloc_entry(pid, NULL, NULL, ttyname); + li = login_alloc_entry(pid, user, NULL, ttyname); login_logout(li); login_free_entry(li); } --- sshlogin.h.orig Thu Nov 15 09:35:02 2001 +++ sshlogin.h Thu Nov 15 09:38:01 2001 @@ -17,7 +17,7 @@ void record_login(pid_t, const char *, const char *, uid_t, const char *, struct sockaddr *); -void record_logout(pid_t, const char *); +void record_logout(pid_t, const char *, const char *); u_long get_last_login_time(uid_t, const char *, char *, u_int); #endif From ed at UDel.Edu Fri Nov 16 02:38:27 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 10:38:27 -0500 (EST) Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115111424.A28941@folly> Message-ID: On Thu, 15 Nov 2001, Markus Friedl wrote: > Date: Thu, 15 Nov 2001 11:14:24 +0100 > From: Markus Friedl > To: Andreas Hasenack > Cc: pcpa at conectiva.com.br, openssh-unix-dev at mindrot.org, openssh at openbsd.org > Subject: Re: [PATCH]: Patch to fix hang on exit bug under Linux and add > optional exit delay > > On Wed, Nov 14, 2001 at 02:20:17PM -0200, Andreas Hasenack wrote: > > diff -u openssh-2.9p1/clientloop.c openssh/clientloop.c > > --- openssh-2.9p1/clientloop.c Fri Apr 20 09:50:51 2001 > > +++ openssh/clientloop.c Mon May 7 17:10:52 2001 > > @@ -840,8 +840,11 @@ > > /* Process buffered packets sent by the server. */ > > client_process_buffered_input_packets(); > > > > - if (compat20 && session_closed && !channel_still_open()) > > + if (compat20 && session_closed) { > > + if (channel_still_open()) > > + channel_stop_listening(); > > break; > > + } > > i guess this patch is for disabling listen() for local forwarding > after the login session has been closed. > > i think this matches the protocol 1 behaviour, but i have to > do some more tests. > > > rekeying = (xxx_kex != NULL && !xxx_kex->done); > > > > @@ -1186,6 +1189,7 @@ > > } else if (strcmp(rtype, "exit-status") == 0) { > > success = 1; > > exit_status = packet_get_int(); > > + session_closed = 1; > > well, it's possible to send data after the exit-status, so > i'm still not quite sure. > > the only 'fix' for the so called hang-on-exit would be: Only fix? > allow data loss in the server if a pty is allocated. i think > this would match the telnetd and rlogind behaviour best. > but i'm not 100% sure, people should test their telnetd/rlogind > servers and check that they throw away data after the login > shell dies. but once again: openssh is not telnet. I'm still not understanding why sshd can't figure out when to close the socket that connects back to the client... is this just the open-ended design of the V2 protocol? Just because there are no sshd children left running and no file desriptors left to process, sshd still needs to stay running? Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From ed at UDel.Edu Fri Nov 16 02:44:51 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 10:44:51 -0500 (EST) Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115113222.C29302@greenie.muc.de> Message-ID: On Thu, 15 Nov 2001, Gert Doering wrote: > Date: Thu, 15 Nov 2001 11:32:22 +0100 > From: Gert Doering > To: Markus Friedl , > Andreas Hasenack > Cc: pcpa at conectiva.com.br, openssh-unix-dev at mindrot.org, openssh at openbsd.org > Subject: Re: [PATCH]: Patch to fix hang on exit bug under Linux and add > optional exit delay > > Hi, > > On Thu, Nov 15, 2001 at 11:14:24AM +0100, Markus Friedl wrote: > [..] > > allow data loss in the server if a pty is allocated. i think > > this would match the telnetd and rlogind behaviour best. > > I would accept this, and prefer it to "I have run something in the > background that I know will not create output but fails to close > stdin/stdout/stderr and now I can't log out cleanly". I have more of a problem with the case where "I have no processes running in the background and no other child processes of sshd running at all and sshd/ssh fail to exit". I still get that problem occasionally with 2.9.9p2... sometimes I can use CTRL-C, but sometimes I have to use SIGTERM to get ssh to quit (and thus sshd). > > but i'm not 100% sure, people should test their telnetd/rlogind > > servers and check that they throw away data after the login > > shell dies. but once again: openssh is not telnet. > > That's what "all implementation I'm used to" do: if I logout the > connection is closed, no matter what background processes are still > alive. This is problematic... if you are forwarding X11 processes then ssh needs to hang around (or at least fork off a child) to continue to process the X traffic. > The background processes will then get some kind of error (I assume > vhangup -> I/O error or something like this) if they try to write > something after the connection is already closed. If ssh goes away, SIGPIPE is more likely. If you really want to end your session, then just kill ssh... the rest of the processes on the server side should go away, shouldn't they? Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From heubach at heubach-edv.de Fri Nov 16 02:56:09 2001 From: heubach at heubach-edv.de (Manfred Heubach) Date: Thu, 15 Nov 2001 16:56:09 +0100 Subject: again chroot Message-ID: <01C16DF6.6D25F0F0.heubach@heubach-edv.de> Hello out there! I've searched this list up and down in order to find a clue about restricting sftp or scp to a defined path or to a chroot jail. It seems there has been development on some patches but I can't find further information. Is there any support or planned support for restricting sftp or scp to a certain path? If there is already support for this, does anybody have a howto about this issue? Why I am asking this question: I want to provide ONLY uploading and downloading on a public server for very few users. These users will be authenticated by their keys. As mankind is very nosy I want to suppress any "just looking around in your server attempts". They just have to see their upload and download area - nothing more. FTP is no good idea because we need encryption and authenticity of the transferred data. Best regards Manfred Heubach ----------------------------------- manfred heubach edv und neue medien ----------------------------------- manfred heubach heubach at heubach-edv.de www.heubach-edv.de b?ro/office +49.711.9315824 support +49.711.31006800 fax +49.711.9315825 ----------------------------------- From ed at UDel.Edu Fri Nov 16 02:52:58 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 10:52:58 -0500 (EST) Subject: X11 forwards and libwrap support In-Reply-To: <200111151159.fAFBxvP18169@rotta.tmt.tele.fi> Message-ID: On Thu, 15 Nov 2001, Osmo Paananen wrote: > Date: Thu, 15 Nov 2001 13:59:57 +0200 > From: Osmo Paananen > To: Markus Friedl > Cc: Osmo Paananen , openssh-unix-dev at mindrot.org, > openssh at openbsd.org > Subject: Re: X11 forwards and libwrap support > > > it's about complexity. > > currently: the x11 proxy listens listen to inaddr-any. > > nice to have: listen to localhost or inaddr-any. > > Did I understand correctly, that openssh's x11 forwards do not > support unix-domain sockets? And that some aplications revert to > unix domain sockets if the display is localhost:*? > > Then I think that just converting openssh to use localhost > as the interface for the forwarded x11 tcp socket is not the solution. > > Or if it is then support for the unix-domain sockets is required, too. > > > other options: too much complexity/code/bugs in openssh. > > tcp-wrapper is already included, would it really add too much > complexity to use it with the x11-forwards? This doesn't work in OpenSSH? I hadn't realized... I always used the "sshdfwd-X11" service in /etc/hosts.allow to control forwarding with ssh-1.2.x... although I always thought it was confusing the way it was implemented. Putting something like: sshdfwd-X11: thishost.do.dum ... to enable forwarding for everything seemed kinda strange. OpenSSH has the "X11Forwarding yes" switch in sshd_config that would do the same thing. What I'd like is to control what hosts we allow forwarding TO in /etc/hosts.allow instead of forwarding FROM. I guess I'm just too dense to understand how it works in detail... :-( Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From markus at openbsd.org Fri Nov 16 03:00:13 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 17:00:13 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: ; from ed@UDel.Edu on Thu, Nov 15, 2001 at 10:44:51AM -0500 References: <20011115113222.C29302@greenie.muc.de> Message-ID: <20011115170013.A351@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 10:44:51AM -0500, Ed Phillips wrote: > I have more of a problem with the case where "I have no processes running > in the background and no other child processes of sshd running at all and > sshd/ssh fail to exit". I still get that problem occasionally with > 2.9.9p2... sometimes I can use CTRL-C, but sometimes I have to use SIGTERM > to get ssh to quit (and thus sshd). do you have debug output from a more recent ssh? > This is problematic... if you are forwarding X11 processes then ssh needs > to hang around (or at least fork off a child) to continue to process the X > traffic. we are talking about something completely different. > If ssh goes away, SIGPIPE is more likely. If you really want to end your > session, then just kill ssh... the rest of the processes on the server > side should go away, shouldn't they? i sent a patch to the list, for transfering signals over the wire, but nobody seemed to care. e.g. currently for $ ssh host 'tail -f bla | grep bla' ^C tail and grep still run on the remote host. -m From markus at openbsd.org Fri Nov 16 03:03:30 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 17:03:30 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: ; from ed@UDel.Edu on Thu, Nov 15, 2001 at 10:38:27AM -0500 References: <20011115111424.A28941@folly> Message-ID: <20011115170330.B351@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 10:38:27AM -0500, Ed Phillips wrote: > > the only 'fix' for the so called hang-on-exit would be: > > Only fix? sure. or do you have non-broken code for solaris/linux? > I'm still not understanding why sshd can't figure out when to close the > socket that connects back to the client hein? we are not talking about the client. > .. is this just the open-ended > design of the V2 protocol? Just because there are no sshd children left > running and no file desriptors left to process, you are missing the point. there are FDs left. > sshd still needs to stay > running? you did not read the history of this thread, nor the original patch. when it comes to closing the connection, it's the clients job (at least in ssh2). -m From ed at UDel.Edu Fri Nov 16 03:07:45 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 11:07:45 -0500 (EST) Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115085507.E7681@usa.net> Message-ID: On Thu, 15 Nov 2001, Peter W wrote: > Date: Thu, 15 Nov 2001 08:55:07 -0500 > From: Peter W > To: Gert Doering > Cc: Markus Friedl , > Andreas Hasenack , pcpa at conectiva.com.br, > openssh-unix-dev at mindrot.org, openssh at openbsd.org > Subject: Re: [PATCH]: Patch to fix hang on exit bug under Linux and add > optional exit delay > > On Thu, Nov 15, 2001 at 11:32:22AM +0100, Gert Doering wrote: > > > On Thu, Nov 15, 2001 at 11:14:24AM +0100, Markus Friedl wrote: > > > > allow data loss in the server if a pty is allocated. i think > > > this would match the telnetd and rlogind behaviour best. > > > > I would accept this, and prefer it to "I have run something in the > > background that I know will not create output but fails to close > > stdin/stdout/stderr and now I can't log out cleanly". > > And the problem with simply killing the ssh client application is? > > I think there's a significant amount of disagrement on this issue, > to say the least. With the core argument distilling to a question of > Integrity vs Convenience, I've got a hard time siding with Convenience. > SSH is not telnet, and I wouldn't like to see it twisted in a way > that is (clearly!) arguablya step backwards for Convenience sake. I agree. But then again, I'd like for ssh/sshd to NOT hang around if I've pressed CTRL-D to logout... and (of course) there are no other children process of sshd left to process. As far as I can tell, this situation is still causing hangs for me on occasion. Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From markus at openbsd.org Fri Nov 16 03:20:39 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 17:20:39 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: ; from ed@UDel.Edu on Thu, Nov 15, 2001 at 11:07:45AM -0500 References: <20011115085507.E7681@usa.net> Message-ID: <20011115172038.C351@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 11:07:45AM -0500, Ed Phillips wrote: > I agree. But then again, I'd like for ssh/sshd to NOT hang around if I've > pressed CTRL-D to logout... and (of course) there are no other children > process of sshd left to process. As far as I can tell, this situation is > still causing hangs for me on occasion. if you press CTRl-D and the remote program has something to say to you, it won't close the connection. -m From gert at greenie.muc.de Fri Nov 16 03:22:58 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 17:22:58 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115085507.E7681@usa.net>; from Peter W on Thu, Nov 15, 2001 at 08:55:07AM -0500 References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <20011114144905.C20807@folly> <20011114142017.K1097@conectiva.com.br> <20011115111424.A28941@folly> <20011115113222.C29302@greenie.muc.de> <20011115085507.E7681@usa.net> Message-ID: <20011115172258.C6628@greenie.muc.de> Hi, On Thu, Nov 15, 2001 at 08:55:07AM -0500, Peter W wrote: > > > allow data loss in the server if a pty is allocated. i think > > > this would match the telnetd and rlogind behaviour best. > > > > I would accept this, and prefer it to "I have run something in the > > background that I know will not create output but fails to close > > stdin/stdout/stderr and now I can't log out cleanly". > And the problem with simply killing the ssh client application is? I assume that you're talking about the *children*, not the ssh client. Problem is: you don't know who they are. > I think there's a significant amount of disagrement on this issue, > to say the least. With the core argument distilling to a question of > Integrity vs Convenience, I've got a hard time siding with Convenience. > SSH is not telnet, and I wouldn't like to see it twisted in a way > that is (clearly!) arguablya step backwards for Convenience sake. Is it? People not doing things over SSH because they do not work (like "restart this daemon that is broken and doesn't close stderr") and using other channels instead isn't a step forwards either. I always thought of ssh as a drop-in replacement for telnet/rlogin that just happens to be more secure. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From GILBERT.R.LOOMIS at saic.com Fri Nov 16 03:32:11 2001 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Thu, 15 Nov 2001 11:32:11 -0500 Subject: Patch for "last" providing incorrect information on Solaris 8 Message-ID: <3C1E3607B37295439F7C409EFBA08E680E27BA@col-581-exs01.cist.saic.com> If we enhance record_logout to include the username as a passed parameter, it will also help me greatly in getting the Solaris auditing (BSM) support working. (In fact, I was just about to propose it to the list-- it's a non-trivial divergence between the OpenBSD version and Portable, but it's really necessary for BSM.) I would therefore strongly recommend that these patches get rolled into OpenSSH ASAP--since I need to "diddle with configure" already for the BSM parts, I'm going to incorporate these patches into my temporarily-divergent codebase and work on a combined patch. -- Rip Loomis Senior Systems Security Engineer SAIC Center for Information Security Technology > -----Original Message----- > From: William R. Knox [mailto:wknox at mitre.org] > Sent: Thursday, 15 November, 2001 10:10 > To: openssh-unix-dev at mindrot.org > Subject: Patch for "last" providing incorrect information on Solaris 8 > > > I have put together a simple set of diffs that corrects the problem > described by Steven Fishback on > 10-30 on this > list regarding incorrect information reported by last on Solaris. The > patches merely pass along the username in the utmpx record > for a logout. > Is there any reason why this would be a problem with other > OSes? If not, > maybe this could be rolled into the port. If so, diddling > with configure > would be the next step. Any ideas? The diffs are against 3.0p1, by the > way. > > Bill Knox > Senior Operating Systems Programmer/Analyst > The MITRE Corporation > From gert at greenie.muc.de Fri Nov 16 03:36:29 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 17:36:29 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: ; from Ed Phillips on Thu, Nov 15, 2001 at 10:44:51AM -0500 References: <20011115113222.C29302@greenie.muc.de> Message-ID: <20011115173629.D6628@greenie.muc.de> Hi, On Thu, Nov 15, 2001 at 10:44:51AM -0500, Ed Phillips wrote: > > I would accept this, and prefer it to "I have run something in the > > background that I know will not create output but fails to close > > stdin/stdout/stderr and now I can't log out cleanly". > > I have more of a problem with the case where "I have no processes running > in the background and no other child processes of sshd running at all and > sshd/ssh fail to exit". Which is exactly what I'm talking about. [..] > > That's what "all implementation I'm used to" do: if I logout the > > connection is closed, no matter what background processes are still > > alive. > > This is problematic... if you are forwarding X11 processes then ssh needs > to hang around (or at least fork off a child) to continue to process the X > traffic. OK, make this: "If I logout and no port or X11 forwardings are active" (which is what I was thinking anyway). Or: "when I log out of a pty session do not care about interactive children that might have FDs open". gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From gert at greenie.muc.de Fri Nov 16 03:40:44 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 17:40:44 +0100 Subject: RhostsAuthentication? In-Reply-To: <20011115130805.W27452@cygbert.vinschen.de>; from Corinna Vinschen on Thu, Nov 15, 2001 at 01:08:05PM +0100 References: <20011115121835.F29302@greenie.muc.de> <20011115122242.A5710@faui02.informatik.uni-erlangen.de> <20011115122911.H29302@greenie.muc.de> <20011115130805.W27452@cygbert.vinschen.de> Message-ID: <20011115174044.G6628@greenie.muc.de> Hi, On Thu, Nov 15, 2001 at 01:08:05PM +0100, Corinna Vinschen wrote: > > # This is the old-style authenticate-by-IP only, no-crypto .rhosts thing. > > # You should not use this if you do not really know what you're doing. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I'm pretty sure that will not work. _Of course_ they know what they > are doing! How dare you to doubt just for a moment! I tend to forget... :-) "If you want security vs. IP spoofing attacks, DO NOT USE THIS". gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From ed at UDel.Edu Fri Nov 16 03:39:51 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 11:39:51 -0500 (EST) Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115170013.A351@faui02.informatik.uni-erlangen.de> Message-ID: On Thu, 15 Nov 2001, Markus Friedl wrote: > Date: Thu, 15 Nov 2001 17:00:13 +0100 > From: Markus Friedl > To: Ed Phillips > Cc: Gert Doering , > Andreas Hasenack , pcpa at conectiva.com.br, > openssh-unix-dev at mindrot.org, openssh at openbsd.org > Subject: Re: [PATCH]: Patch to fix hang on exit bug under Linux and add > optional exit delay > > On Thu, Nov 15, 2001 at 10:44:51AM -0500, Ed Phillips wrote: > > I have more of a problem with the case where "I have no processes running > > in the background and no other child processes of sshd running at all and > > sshd/ssh fail to exit". I still get that problem occasionally with > > 2.9.9p2... sometimes I can use CTRL-C, but sometimes I have to use SIGTERM > > to get ssh to quit (and thus sshd). > > do you have debug output from a more recent ssh? No. Is there a known problem with this in 2.9.9p2 that I missed? This problem happens very infrequently for me, so maybe the 3.0pX code has that tiny fix that makes it "never" happen? Actually, I'm very happy with the stability of 2.9.9p2 in this respect - so happy in fact that we've installed it on all the Sun (and a few other brands) servers that we manage, on many different versions of Solaris on many different size machines (from SS1+ thru 6800). Great job guys! Whooo Hoooo! It's a wonder anything gets accomplished with people like me bombarding the list... ;-) > > This is problematic... if you are forwarding X11 processes then ssh needs > > to hang around (or at least fork off a child) to continue to process the X > > traffic. > > we are talking about something completely different. Okay... sorry. > > If ssh goes away, SIGPIPE is more likely. If you really want to end your > > session, then just kill ssh... the rest of the processes on the server > > side should go away, shouldn't they? > > i sent a patch to the list, for transfering signals over > the wire, but nobody seemed to care. > > e.g. currently for > $ ssh host 'tail -f bla | grep bla' > ^C > tail and grep still run on the remote host. I understand what you're saying, but I have no idea how it relates to my response above. I was talking about the background processes on the server-side and how they would respond to ssh exiting on the client while they were still running (and might write to stdout/stderr). I wasn't talking about forwarding signals from ssh to the remote process for a non-interactive invocation of ssh. Although, that might be a nice feature for someone... but I say, "If you're silly enough to NOT login and run the commands, then you shouldn't be wonderin' why you can't stop them with CTRL-C after you already hit RETURN...". ;-) Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Fri Nov 16 03:51:28 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 15 Nov 2001 11:51:28 -0500 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115170013.A351@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Thu, Nov 15, 2001 at 05:00:13PM +0100 References: <20011115113222.C29302@greenie.muc.de> <20011115170013.A351@faui02.informatik.uni-erlangen.de> Message-ID: <20011115115127.G5739@sm2p1386swk.wdr.com> On Thu, Nov 15, 2001 at 05:00:13PM +0100, Markus Friedl wrote: > On Thu, Nov 15, 2001 at 10:44:51AM -0500, Ed Phillips wrote: > > If ssh goes away, SIGPIPE is more likely. If you really want to end your > > session, then just kill ssh... the rest of the processes on the server > > side should go away, shouldn't they? > > i sent a patch to the list, for transfering signals over > the wire, but nobody seemed to care. I care... But I won't get around to testing the latest OpenSSH or signal forwarding for some time. > e.g. currently for > $ ssh host 'tail -f bla | grep bla' > ^C > tail and grep still run on the remote host. Shouldn't sshd kill -HUP the process groups of its sessions when the client closes them?? Doing that would give those procs a chance to exit cleanly and avoid data loss altogether. > -m Cheers, Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ed at UDel.Edu Fri Nov 16 03:54:00 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 11:54:00 -0500 (EST) Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115172038.C351@faui02.informatik.uni-erlangen.de> Message-ID: On Thu, 15 Nov 2001, Markus Friedl wrote: > Date: Thu, 15 Nov 2001 17:20:39 +0100 > From: Markus Friedl > To: Ed Phillips > Cc: Peter W , Gert Doering , > Andreas Hasenack , pcpa at conectiva.com.br, > openssh-unix-dev at mindrot.org, openssh at openbsd.org > Subject: Re: [PATCH]: Patch to fix hang on exit bug under Linux and add > optional exit delay > > On Thu, Nov 15, 2001 at 11:07:45AM -0500, Ed Phillips wrote: > > I agree. But then again, I'd like for ssh/sshd to NOT hang around if I've > > pressed CTRL-D to logout... and (of course) there are no other children > > process of sshd left to process. As far as I can tell, this situation is > > still causing hangs for me on occasion. > > if you press CTRl-D and the remote program has something to > say to you, it won't close the connection. So the problem is that when I press CTRL-D, the client can't just exit because at some point in the future, if there is still something running on the server side (a child processes of sshd), it might write on its stdout/stderr to be sent back to the client? In contrast, if all of the sshd children processes have exited on the server side, the client can supposedly tell because of the V2 protocol - so the client can safely exit? Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Fri Nov 16 03:58:26 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 15 Nov 2001 11:58:26 -0500 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115173629.D6628@greenie.muc.de>; from gert@greenie.muc.de on Thu, Nov 15, 2001 at 05:36:29PM +0100 References: <20011115113222.C29302@greenie.muc.de> <20011115173629.D6628@greenie.muc.de> Message-ID: <20011115115825.I5739@sm2p1386swk.wdr.com> On Thu, Nov 15, 2001 at 05:36:29PM +0100, Gert Doering wrote: > Hi, > > On Thu, Nov 15, 2001 at 10:44:51AM -0500, Ed Phillips wrote: > > > I would accept this, and prefer it to "I have run something in the > > > background that I know will not create output but fails to close > > > stdin/stdout/stderr and now I can't log out cleanly". > > > > I have more of a problem with the case where "I have no processes running > > in the background and no other child processes of sshd running at all and > > sshd/ssh fail to exit". > > Which is exactly what I'm talking about. This is some other bug. I've seen it too. It only happens when you used the forwarded agent, forwarded X or, I suspect, any other forwarded port. It happens even if the forwarded ports/agent are not in use. That should be telling. > gert > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From Nicolas.Williams at ubsw.com Fri Nov 16 03:56:16 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 15 Nov 2001 11:56:16 -0500 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115172258.C6628@greenie.muc.de>; from gert@greenie.muc.de on Thu, Nov 15, 2001 at 05:22:58PM +0100 References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <20011114144905.C20807@folly> <20011114142017.K1097@conectiva.com.br> <20011115111424.A28941@folly> <20011115113222.C29302@greenie.muc.de> <20011115085507.E7681@usa.net> <20011115172258.C6628@greenie.muc.de> Message-ID: <20011115115615.H5739@sm2p1386swk.wdr.com> On Thu, Nov 15, 2001 at 05:22:58PM +0100, Gert Doering wrote: > Hi, > > On Thu, Nov 15, 2001 at 08:55:07AM -0500, Peter W wrote: > > And the problem with simply killing the ssh client application is? > > I assume that you're talking about the *children*, not the ssh client. > > Problem is: you don't know who they are. Yes you do: you know their process group and session id. And the pty knows who the current process group is. Kill -HUP the process group of session(s) being abandoned by the client, send HUP to the pty process groups via the ptys still open, close them ptys. No? > Gert Doering - Munich, Germany gert at greenie.muc.de > fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From gert at greenie.muc.de Fri Nov 16 04:04:24 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 18:04:24 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115115615.H5739@sm2p1386swk.wdr.com>; from Nicolas Williams on Thu, Nov 15, 2001 at 11:56:16AM -0500 References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <20011114144905.C20807@folly> <20011114142017.K1097@conectiva.com.br> <20011115111424.A28941@folly> <20011115113222.C29302@greenie.muc.de> <20011115085507.E7681@usa.net> <20011115172258.C6628@greenie.muc.de> <20011115115615.H5739@sm2p1386swk.wdr.com> Message-ID: <20011115180424.J6628@greenie.muc.de> hi, On Thu, Nov 15, 2001 at 11:56:16AM -0500, Nicolas Williams wrote: > On Thu, Nov 15, 2001 at 05:22:58PM +0100, Gert Doering wrote: > > On Thu, Nov 15, 2001 at 08:55:07AM -0500, Peter W wrote: > > > And the problem with simply killing the ssh client application is? > > I assume that you're talking about the *children*, not the ssh client. > > > > Problem is: you don't know who they are. > > Yes you do: you know their process group and session id. And the pty > knows who the current process group is. Kill -HUP the process group of > session(s) being abandoned by the client, send HUP to the pty process > groups via the ptys still open, close them ptys. > > No? No. A program could have done setsid() and started a new process group - think of daemons that do all that daemons should do, but forget to close stderr (because of stupid programming bugs in binary-only software - whatever "not easily fixable" reason there might be). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From tim at multitalents.net Fri Nov 16 04:40:42 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 15 Nov 2001 09:40:42 -0800 (PST) Subject: unable to get connection thru firewall In-Reply-To: <2AA167413A3BD5119D2500B0D0AB1579265F03@CPH01> Message-ID: On Thu, 15 Nov 2001, Bymark, Jan wrote: > Hi, > > Is there someone how can help me with this problem?? > > > Hi, > > I've a Solaris 8 with Openshh 3.0.1 (build with these parameters > --prefix=/usr/local --without-rsh --disable-suid-ssh ^^^^^^^^^^^^^^^^^^ Take this out and try again. > --sysconfdir=/usr/local/etc --with-ssl-dir=/usr/local/ssl > --with-tcp-wrappers). If I come from the same subnet as the server is on, > I've have no problems. But When I try via theI nternet I doesn't. If I run > snoop I can see I get contact with the server: > > 193.234.247.50 -> imsdemo1 TCP D=22 S=20094 Syn Seq=2899242921 Len=0 > Win=163 > 84 Options= > > My /var/adm/messages show me this: > Nov 12 16:47:48 imsdemo1 sshd[29929]: [ID 800047 auth.error] error: Bind to > port 22 on1 93.234.247.50 failed: Cannot assign requested address. ^^^^^^^ > Nov 12 16:47:48i msdemo1 sshd[29929]: [ID 800047 auth.crit] fatal: Cannot > bind a > ny address. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vader at conflict.net Fri Nov 16 04:52:30 2001 From: vader at conflict.net (Jim Breton) Date: Thu, 15 Nov 2001 17:52:30 +0000 Subject: Connections suddenly closing Message-ID: <20011115175230804003.22932@conflict.net> Hi, I have been having a problem with OpenSSH which afaict has _never_ happened prior to upgrading to 3.0. (I always run the current release, so I'd been on 2.9.9[p2] prior to 3.0.) At a seemingly random time, I will lose my connection to the remote host, for example: Read from remote host crate.alongtheway.com: Connection reset by peer Granted, I am not sure that that was the error _every_ time because prior to noticing this trend I had been using xterms with "-e ssh" options so the xterm would close before I got to see the error. But a couple days ago I turned off that switch so I could see what was happening, and today it finally happened again and gave me the above error. Note that I searched for anything similar in the archives of this list and found the following results: http://marc.theaimsgroup.com/?l=openssh-unix-dev&w=2&r=1&s=Connection+reset+by+peer&q=b However none of those seems to apply here, as in at least one case, the connection to the remote host was _not idle._ A couple example cases: 1) Had two connections open to a FreeBSD machine at a remote location; one was an idle shell, the other was actively running the 'tin' newsreader. All of a sudden the connection running the tin session dumped on me, meanwhile the other connection remained open and fine. 2) A connection I had open to an OpenBSD 2.9 system on my home network (through an internal firewall doing NAT) suddenly dropped also, it was idle overnight, probably for around 6 or 7 hours. 3) The connection drop that occurred today was to yet another FreeBSD system, and had only been idle for around an hour. Constants with every case: 1) Client system is Linux (debian potato) running OpenSSH 3.0p1. 2) Server system is OpenSSH 3.0 (p1 in the FreeBSD case). 3) Connection is NATted. Wish I had more info.. any suggestions? Anyone else have ssh connections mysteriously die? -- Jim B. vader at conflict.net From rayl at otii.com Fri Nov 16 05:30:54 2001 From: rayl at otii.com (Ray Lehtiniemi) Date: Thu, 15 Nov 2001 11:30:54 -0700 Subject: Connections suddenly closing In-Reply-To: <20011115175230804003.22932@conflict.net>; from vader@conflict.net on Thu, Nov 15, 2001 at 05:52:30PM +0000 References: <20011115175230804003.22932@conflict.net> Message-ID: <20011115113054.C30410@otii.com> On Thu, Nov 15, 2001 at 05:52:30PM +0000, Jim Breton wrote: > Wish I had more info.. any suggestions? Anyone else have ssh > connections mysteriously die? i occasionally see connections fail to establish, although they don;t seem to die after that. my server is OpenBSD 2.6, client is Redhat 7.2. Both boxes have the original versions of ssh installed as shipped. my server runs a CVS repository, which is accessed via ssh. a cron job on the linux client does a cvs update every minute. about 6-8 times per 24 hour period, cron sends me this email: Connection closed by 192.168.2.1 cvs [update aborted]: end of file from server (consult above messages if any) on the server side, i usually get three lines in authlog. when it fails, i only get the first. Nov 15 02:29:01 server sshd[32358]: log: Connection from client.my.com port 46460 Nov 15 02:29:01 server sshd[32358]: log: RSA authentication for user accepted. Nov 15 02:29:02 server sshd[32358]: log: Closing connection to 192.168.2.2 Nov 15 02:30:02 server sshd[11839]: log: Connection from client.my.com port 46465 Nov 15 02:31:01 server sshd[11977]: log: Connection from client.my.com port 46470 Nov 15 02:31:02 server sshd[11977]: log: RSA authentication for user accepted. Nov 15 02:31:03 server sshd[11977]: log: Closing connection to 192.168.2.2 i have been assuming that my upcoming upgrade to OpenBSD 2.9/3.0 will solve this problem. however, i'd be happy to enable more logging and dig deeper if it might provide useful info for someone. cheers -- --------------------------------------------------------------------------- Ray Lehtiniemi From markus at openbsd.org Fri Nov 16 05:46:18 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 19:46:18 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115115825.I5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Nov 15, 2001 at 11:58:26AM -0500 References: <20011115113222.C29302@greenie.muc.de> <20011115173629.D6628@greenie.muc.de> <20011115115825.I5739@sm2p1386swk.wdr.com> Message-ID: <20011115194617.A12386@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 10:44:51AM -0500, Ed Phillips wrote: > I have more of a problem with the case where "I have no processes running > in the background and no other child processes of sshd running at all and > sshd/ssh fail to exit". On Thu, Nov 15, 2001 at 05:36:29PM +0100, Gert Doering wrote: > Which is exactly what I'm talking about. On Thu, Nov 15, 2001 at 11:58:26AM -0500, Nicolas Williams wrote: > This is some other bug. I've seen it too. It only happens when you used > the forwarded agent, forwarded X or, I suspect, any other forwarded port. > It happens even if the forwarded ports/agent are not in use. no debug output, no test script, seems nobody cares. -m From Nicolas.Williams at ubsw.com Fri Nov 16 05:51:45 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 15 Nov 2001 13:51:45 -0500 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115180424.J6628@greenie.muc.de>; from gert@greenie.muc.de on Thu, Nov 15, 2001 at 06:04:24PM +0100 References: <20011114003143.19330.qmail@wizard.math.ualberta.ca> <20011114144905.C20807@folly> <20011114142017.K1097@conectiva.com.br> <20011115111424.A28941@folly> <20011115113222.C29302@greenie.muc.de> <20011115085507.E7681@usa.net> <20011115172258.C6628@greenie.muc.de> <20011115115615.H5739@sm2p1386swk.wdr.com> <20011115180424.J6628@greenie.muc.de> Message-ID: <20011115135144.J5739@sm2p1386swk.wdr.com> On Thu, Nov 15, 2001 at 06:04:24PM +0100, Gert Doering wrote: > hi, > > On Thu, Nov 15, 2001 at 11:56:16AM -0500, Nicolas Williams wrote: > > On Thu, Nov 15, 2001 at 05:22:58PM +0100, Gert Doering wrote: > > > On Thu, Nov 15, 2001 at 08:55:07AM -0500, Peter W wrote: > > > > And the problem with simply killing the ssh client application is? > > > I assume that you're talking about the *children*, not the ssh client. > > > > > > Problem is: you don't know who they are. > > > > Yes you do: you know their process group and session id. And the pty > > knows who the current process group is. Kill -HUP the process group of > > session(s) being abandoned by the client, send HUP to the pty process > > groups via the ptys still open, close them ptys. > > > > No? > > No. A program could have done setsid() and started a new process > group - think of daemons that do all that daemons should do, but forget > to close stderr (because of stupid programming bugs in binary-only > software - whatever "not easily fixable" reason there might be). Of course, yes, but such programs usually dissasociate from their controlling tty too. Even if they don't, killing those process groups is *still* worthwhile. > gert Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From gert at greenie.muc.de Fri Nov 16 06:02:19 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 20:02:19 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115194617.A12386@faui02.informatik.uni-erlangen.de>; from Markus Friedl on Thu, Nov 15, 2001 at 07:46:18PM +0100 References: <20011115113222.C29302@greenie.muc.de> <20011115173629.D6628@greenie.muc.de> <20011115115825.I5739@sm2p1386swk.wdr.com> <20011115194617.A12386@faui02.informatik.uni-erlangen.de> Message-ID: <20011115200219.A10582@greenie.muc.de> Hi, On Thu, Nov 15, 2001 at 07:46:18PM +0100, Markus Friedl wrote: > On Thu, Nov 15, 2001 at 05:36:29PM +0100, Gert Doering wrote: > > Which is exactly what I'm talking about. > > no debug output, no test script, seems nobody cares. If you quote me, please do not mix me into this crowd. I describe a very specific scenario that is not a "bug" but "as it is designed to be right now" which I'd like to see changed in the way you have suggested. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From Nicolas.Williams at ubsw.com Fri Nov 16 06:01:40 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 15 Nov 2001 14:01:40 -0500 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115194617.A12386@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Thu, Nov 15, 2001 at 07:46:18PM +0100 References: <20011115113222.C29302@greenie.muc.de> <20011115173629.D6628@greenie.muc.de> <20011115115825.I5739@sm2p1386swk.wdr.com> <20011115194617.A12386@faui02.informatik.uni-erlangen.de> Message-ID: <20011115140138.K5739@sm2p1386swk.wdr.com> On Thu, Nov 15, 2001 at 07:46:18PM +0100, Markus Friedl wrote: > On Thu, Nov 15, 2001 at 10:44:51AM -0500, Ed Phillips wrote: > > I have more of a problem with the case where "I have no processes running > > in the background and no other child processes of sshd running at all and > > sshd/ssh fail to exit". > > On Thu, Nov 15, 2001 at 05:36:29PM +0100, Gert Doering wrote: > > Which is exactly what I'm talking about. > > On Thu, Nov 15, 2001 at 11:58:26AM -0500, Nicolas Williams wrote: > > This is some other bug. I've seen it too. It only happens when you used > > the forwarded agent, forwarded X or, I suspect, any other forwarded port. > > It happens even if the forwarded ports/agent are not in use. > > no debug output, no test script, seems nobody cares. I'll get debug output. Possibly tomorrow. I know the drill, ssh -v -v -v and sshd -d -d -d. As for testing, it's easy: hostA: ssh -A hostB hostB: exit hostA: hostA: ssh -A hostB hostB: ssh hostC hostC: exit hostB: hostB: exit hostA: This with OpenSSH 2.9p2, but one of my colleagues reports that this still happens with 3.0... Try the same sort of thing with X11 instead of agent forwarding. I always get that behaviour, except with X11 forwarding, where the problem seems to be intermittent. BTW, this post seems to have been an attempt to patch that particular problem: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99622973723549&w=2 that patch never applied cleanly to OpenSSH 2.9p2. > -m Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Fri Nov 16 06:09:07 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 20:09:07 +0100 Subject: again chroot In-Reply-To: <01C16DF6.6D25F0F0.heubach@heubach-edv.de>; from heubach@heubach-edv.de on Thu, Nov 15, 2001 at 04:56:09PM +0100 References: <01C16DF6.6D25F0F0.heubach@heubach-edv.de> Message-ID: <20011115200907.B29184@folly> make sftp-server setuid root and let it do the chroot itself, depending on a config file, like /etc/sftp-chrootusers but you have to be careful. chroot $HOME is probably not really save if .ssh is writeable to the user. and so on. -m From markus at openbsd.org Fri Nov 16 06:13:51 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 20:13:51 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115115127.G5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Nov 15, 2001 at 11:51:28AM -0500 References: <20011115113222.C29302@greenie.muc.de> <20011115170013.A351@faui02.informatik.uni-erlangen.de> <20011115115127.G5739@sm2p1386swk.wdr.com> Message-ID: <20011115201351.A14536@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 11:51:28AM -0500, Nicolas Williams wrote: > > e.g. currently for > > $ ssh host 'tail -f bla | grep bla' > > ^C > > tail and grep still run on the remote host. > > Shouldn't sshd kill -HUP the process groups of its sessions when the > client closes them?? add killpg() to session_destroy_all() and test. From markus at OPENBSD.ORG Fri Nov 16 06:16:21 2001 From: markus at OPENBSD.ORG (Markus Friedl) Date: Thu, 15 Nov 2001 20:16:21 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: ; from ed@udel.edu on Thu, Nov 15, 2001 at 11:39:51AM -0500 References: <20011115170013.A351@faui02.informatik.uni-erlangen.de> Message-ID: <20011115201621.B14536@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 11:39:51AM -0500, Ed Phillips wrote: > non-interactive invocation of ssh. Although, that might be a nice feature > for someone... but I say, "If you're silly enough to NOT login and run the > commands, then you shouldn't be wonderin' why you can't stop them with > CTRL-C after you already hit RETURN...". ;-) well, this is what rsh does. rsh passes signals, and rshd calls killpg(). From markus at openbsd.org Fri Nov 16 06:50:00 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 20:50:00 +0100 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115140138.K5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Nov 15, 2001 at 02:01:40PM -0500 References: <20011115113222.C29302@greenie.muc.de> <20011115173629.D6628@greenie.muc.de> <20011115115825.I5739@sm2p1386swk.wdr.com> <20011115194617.A12386@faui02.informatik.uni-erlangen.de> <20011115140138.K5739@sm2p1386swk.wdr.com> Message-ID: <20011115205000.B10980@folly> On Thu, Nov 15, 2001 at 02:01:40PM -0500, Nicolas Williams wrote: this: > hostA: ssh -A hostB > hostB: ssh hostC > hostC: exit > hostB: > hostB: exit > hostA: is what > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99622973723549&w=2 and 3.0 fix. From ed at UDel.Edu Fri Nov 16 06:59:08 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 14:59:08 -0500 (EST) Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115205000.B10980@folly> Message-ID: On Thu, 15 Nov 2001, Markus Friedl wrote: > Date: Thu, 15 Nov 2001 20:50:00 +0100 > From: Markus Friedl > To: openssh-unix-dev at mindrot.org, openssh at openbsd.org > Subject: Re: [PATCH]: Patch to fix hang on exit bug under Linux and add > optional exit delay > > On Thu, Nov 15, 2001 at 02:01:40PM -0500, Nicolas Williams wrote: > > this: > > > hostA: ssh -A hostB > > hostB: ssh hostC > > hostC: exit > > hostB: > > hostB: exit > > hostA: > > is what > > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99622973723549&w=2 > > and 3.0 fix. I can't reproduce this problem with 2.9.9p2 on Sol8, so it must be fixed there too. Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Fri Nov 16 07:18:10 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 15 Nov 2001 15:18:10 -0500 Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115205000.B10980@folly>; from markus@openbsd.org on Thu, Nov 15, 2001 at 08:50:00PM +0100 References: <20011115113222.C29302@greenie.muc.de> <20011115173629.D6628@greenie.muc.de> <20011115115825.I5739@sm2p1386swk.wdr.com> <20011115194617.A12386@faui02.informatik.uni-erlangen.de> <20011115140138.K5739@sm2p1386swk.wdr.com> <20011115205000.B10980@folly> Message-ID: <20011115151808.L5739@sm2p1386swk.wdr.com> On Thu, Nov 15, 2001 at 08:50:00PM +0100, Markus Friedl wrote: > On Thu, Nov 15, 2001 at 02:01:40PM -0500, Nicolas Williams wrote: > > this: > > > hostA: ssh -A hostB > > hostB: ssh hostC > > hostC: exit > > hostB: > > hostB: exit > > hostA: > > is what > > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99622973723549&w=2 That didn't apply, not even by hand, to 2.9p2. > and 3.0 fix. It turns out my colleague hadn't tested 3.0 wrt that bug. Thanks. Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From markus at openbsd.org Fri Nov 16 07:19:11 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 21:19:11 +0100 Subject: Connections suddenly closing In-Reply-To: <20011115175230804003.22932@conflict.net>; from vader@conflict.net on Thu, Nov 15, 2001 at 05:52:30PM +0000 References: <20011115175230804003.22932@conflict.net> Message-ID: <20011115211910.A31226@folly> some nat-gateways have small timeouts. this is probably the cause for the problem. is there a period of inactivity? or does it happen while you type? From vader at conflict.net Fri Nov 16 07:41:57 2001 From: vader at conflict.net (Jim Breton) Date: Thu, 15 Nov 2001 20:41:57 +0000 Subject: Connections suddenly closing In-Reply-To: <20011115211910.A31226@folly>; from markus@openbsd.org on Thu, Nov 15, 2001 at 09:19:11PM +0100 References: <20011115175230804003.22932@conflict.net> <20011115211910.A31226@folly> Message-ID: <20011115204156958803.22932@conflict.net> On Thu, Nov 15, 2001 at 09:19:11PM +0100, Markus Friedl wrote: > some nat-gateways have small timeouts. > > this is probably the cause for the problem. Hmm, in this case I disagree, since I was running exactly the same NAT setup with each release version of OpenSSH since at least 2.3.0 and never had this problem. :\ I have had connections open for days, sometimes weeks, without losing them, and I regularly leave sessions idle overnight with no issues. > is there a period of inactivity? or does > it happen while you type? I was not actually typing at the time but the tin session I mentioned was actively sending packets every few seconds (saving a bunch of tagged messages.. and tin has an incrementing progress counter). In fact, the other connection I had open to the same machine (the connection that survived) had an even longer period of inactivity than the session that died. I don't see anything unusual in the server logs but I will keep an eye out for future occurrences. -- Jim B. vader at conflict.net From ed at UDel.Edu Fri Nov 16 07:46:22 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 15:46:22 -0500 (EST) Subject: X11 cookies and forwarding Message-ID: I'm guess I wasn't following the whole cookies discussion completely (putting cookies in /tmp to avoid putting them on NFS, etc.), but I noticed today that with 2.9.9p2, if I use "ssh -X" to start a shell on the server, in that shell XAUTHORITY is set to /tmp/ssh-XXXXXXXX/cookies and there are cookies placed there there. These are the "fake" cookies for the "server:10.X" display. When an X11 client opens a connection using the "fake" display socket, and ssh receives the authentication packet, ssh rewrites the "fake" cookie in the packet with the "real" cookie (which might actually be another "fake" cookie if you are chaining your ssh invocations?). So what's the real issue here... having ssh create a "fake" cookie and that gets copied to the server side... in the user's home directory? Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From tim at mcgarry.ch Fri Nov 16 07:35:54 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Thu, 15 Nov 2001 21:35:54 +0100 Subject: default option for ssh-keygen References: <00d801c16c21$f2beddc0$a300010a@mshome.net> <20011113101111.B11336@faui02.informatik.uni-erlangen.de> Message-ID: <000801c16e16$ba4e15e0$c802a8c0@cablecom.ch> can't we just have ssh-keygen -t all as an option? ----- Original Message ----- From: "Markus Friedl" To: "NONAKA Akira" Cc: Sent: Tuesday, November 13, 2001 10:11 AM Subject: Re: default option for ssh-keygen > On Tue, Nov 13, 2001 at 06:02:39PM +0900, NONAKA Akira wrote: > > Hi, > > > > One of my users got into trouble that he could not use rsa authentication. > > He was using 2.9 server and 2.9 client but he generated his rsa key > > without -t option by ssh-keygen, thus identity and identity.pub was created. > > ssh -1 worked for him. > > > > IMHO, since SSH-2 is default for ssh client now, I think "-t dsa" should be > > the default for ssh-keygen. > > i think -t rsa will be the default, or there will be no default at all. > From ed at UDel.Edu Fri Nov 16 07:52:11 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 15:52:11 -0500 (EST) Subject: Connections suddenly closing In-Reply-To: <20011115204156958803.22932@conflict.net> Message-ID: On Thu, 15 Nov 2001, Jim Breton wrote: > Date: Thu, 15 Nov 2001 20:41:57 +0000 > From: Jim Breton > To: openssh-unix-dev at mindrot.org > Subject: Re: Connections suddenly closing > > On Thu, Nov 15, 2001 at 09:19:11PM +0100, Markus Friedl wrote: > > some nat-gateways have small timeouts. > > > > this is probably the cause for the problem. > > Hmm, in this case I disagree, since I was running exactly the same > NAT setup with each release version of OpenSSH since at least 2.3.0 > and never had this problem. :\ I have had connections open for days, > sometimes weeks, without losing them, and I regularly leave sessions > idle overnight with no issues. This is probably not your situation, but is it possible that this is an "auto-logout" feature? I've noticed that every since we started running OpenSSH 2.9.9p2 (as opposed to ssh 1.2.27) that we suddenly have this new "auto-logout" feature. ;-) Ed > > is there a period of inactivity? or does > > it happen while you type? > > I was not actually typing at the time but the tin session I mentioned > was actively sending packets every few seconds (saving a bunch of tagged > messages.. and tin has an incrementing progress counter). In fact, the > other connection I had open to the same machine (the connection that > survived) had an even longer period of inactivity than the session that > died. > > I don't see anything unusual in the server logs but I will keep an eye > out for future occurrences. > > -- > > Jim B. > vader at conflict.net > Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From markus at openbsd.org Fri Nov 16 07:54:11 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 21:54:11 +0100 Subject: X11 cookies and forwarding In-Reply-To: ; from ed@UDel.Edu on Thu, Nov 15, 2001 at 03:46:22PM -0500 References: Message-ID: <20011115215411.A19204@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 03:46:22PM -0500, Ed Phillips wrote: > but I > noticed today that with 2.9.9p2, if I use "ssh -X" to start a shell on the > server, in that shell XAUTHORITY is set to /tmp/ssh-XXXXXXXX/cookies and > there are cookies placed there there. wrong. 2.9.9 and later use $HOME, not /tmp but what is your question? fake cookies are generated in order to restrict the access to the real x11 server to the duration of the ssh session and not to the duration of the x11 session. -m From markus at openbsd.org Fri Nov 16 07:56:14 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 15 Nov 2001 21:56:14 +0100 Subject: default option for ssh-keygen In-Reply-To: <000801c16e16$ba4e15e0$c802a8c0@cablecom.ch>; from tim@mcgarry.ch on Thu, Nov 15, 2001 at 09:35:54PM +0100 References: <00d801c16c21$f2beddc0$a300010a@mshome.net> <20011113101111.B11336@faui02.informatik.uni-erlangen.de> <000801c16e16$ba4e15e0$c802a8c0@cablecom.ch> Message-ID: <20011115215614.B19204@faui02.informatik.uni-erlangen.de> On Thu, Nov 15, 2001 at 09:35:54PM +0100, Tim McGarry wrote: > can't we just have ssh-keygen -t all as an option? no. $ ssh-keygen -f /etc/ssh_host_key ? -m From rick at helix.nih.gov Fri Nov 16 08:12:29 2001 From: rick at helix.nih.gov (Rick Troxel) Date: Thu, 15 Nov 2001 16:12:29 -0500 Subject: Solaris 2.6: acomp failed for session.c Message-ID: Re: openssh-2.9.9p2 versus Solaris 2.6, Forte C version 6upd2 The compiler treated the call to do_pre_login in session.c line 581 as a prototype, warned of inconsistency with the function definition starting line 628: "session.c", line 628: identifier redeclared: do_pre_login current : static function(pointer to struct Session {[struct definition suppressed]}) returning void previous: function() returning int : "session.c", line 581 and failed with no further hint: cc: acomp failed for session.c make: *** [session.o] Error 2 To work around this I had to add a true prototype: *** session.c.ORIG Sun Sep 16 18:17:15 2001 --- session.c Thu Nov 15 14:45:40 2001 *************** *** 132,137 **** --- 132,140 ---- void do_child(Session *, const char *); void do_motd(void); int check_quietlogin(Session *, const char *); + #ifdef LOGIN_NEEDS_UTMPX + static void do_pre_login(Session *); + #endif static void do_authenticated1(Authctxt *); static void do_authenticated2(Authctxt *); FWIW, -- Rick Troxel rick at helix.nih.gov 301/435-2983 ///////////////////////////////////////////////////////////////// All effort and exertion put forth by man from the fullness of his heart is worship, if it is prompted by the highest motives and the will to do service to humanity. --Abdu'l-Baha From ed at UDel.Edu Fri Nov 16 08:13:41 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 16:13:41 -0500 (EST) Subject: X11 cookies and forwarding In-Reply-To: <20011115215411.A19204@faui02.informatik.uni-erlangen.de> Message-ID: On Thu, 15 Nov 2001, Markus Friedl wrote: > Date: Thu, 15 Nov 2001 21:54:11 +0100 > From: Markus Friedl > To: Ed Phillips > Cc: OpenSSH Development > Subject: Re: X11 cookies and forwarding > > On Thu, Nov 15, 2001 at 03:46:22PM -0500, Ed Phillips wrote: > > but I > > noticed today that with 2.9.9p2, if I use "ssh -X" to start a shell on the > > server, in that shell XAUTHORITY is set to /tmp/ssh-XXXXXXXX/cookies and > > there are cookies placed there there. > > wrong. 2.9.9 and later use $HOME, not /tmp Okay... I figured that much out. I was connecting ssh 2.9.9p2 to sshd 2.9p1. Sorry... > but what is your question? Is the issue with cookies (that has been recently discussed - cookies on NFS and such) a direct result of this change in 2.9.9p2? > fake cookies are generated in order to restrict > the access to the real x11 server to the duration > of the ssh session and not to the duration of the > x11 session. Got it. Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From mouring at etoh.eviladmin.org Fri Nov 16 08:18:51 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 15 Nov 2001 15:18:51 -0600 (CST) Subject: Solaris 2.6: acomp failed for session.c In-Reply-To: Message-ID: This has been fixed in the 3.0 and the latest 3.0.1 releases. - Ben On Thu, 15 Nov 2001, Rick Troxel wrote: > Re: openssh-2.9.9p2 versus Solaris 2.6, Forte C version 6upd2 > > The compiler treated the call to do_pre_login in session.c line 581 as a > prototype, warned of inconsistency with the function definition starting > line 628: > > "session.c", line 628: identifier redeclared: do_pre_login > current : static function(pointer to struct Session {[struct > definition suppressed]}) returning void > previous: function() returning int : "session.c", line 581 > > and failed with no further hint: > > cc: acomp failed for session.c > make: *** [session.o] Error 2 > > To work around this I had to add a true prototype: > > *** session.c.ORIG Sun Sep 16 18:17:15 2001 > --- session.c Thu Nov 15 14:45:40 2001 > *************** > *** 132,137 **** > --- 132,140 ---- > void do_child(Session *, const char *); > void do_motd(void); > int check_quietlogin(Session *, const char *); > + #ifdef LOGIN_NEEDS_UTMPX > + static void do_pre_login(Session *); > + #endif > > static void do_authenticated1(Authctxt *); > static void do_authenticated2(Authctxt *); > > FWIW, > -- > Rick Troxel rick at helix.nih.gov 301/435-2983 > ///////////////////////////////////////////////////////////////// > All effort and exertion put forth by man from the fullness of his > heart is worship, if it is prompted by the highest motives and > the will to do service to humanity. --Abdu'l-Baha > > From ed at UDel.Edu Fri Nov 16 08:24:59 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 16:24:59 -0500 (EST) Subject: Case where ssh hangs on exit with 2.9.9p2 on Sol8 Message-ID: Here's the appropriate output with blow-by-blow explanation embedded... I start by making a connection with X11 forwarding enabled: polycut:~> ssh -v -v -v -X dazel OpenSSH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /opt/openssh-2.9.9p2/etc/ssh_config debug3: Reading output from 'ls -alni /var/log' debug3: Time elapsed: 23 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /var/log' debug3: Reading output from 'ls -alni /var/adm' debug3: Time elapsed: 26 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /var/adm' debug3: Reading output from 'ls -alni /usr/adm' debug3: Time elapsed: 16 msec debug3: Got 0.18 bytes of entropy from 'ls -alni /usr/adm' debug3: Reading output from 'ls -alni /var/mail' debug3: Time elapsed: 18 msec debug3: Got 0.71 bytes of entropy from 'ls -alni /var/mail' debug3: Reading output from 'ls -alni /usr/mail' debug3: Time elapsed: 16 msec debug3: Got 0.18 bytes of entropy from 'ls -alni /usr/mail' debug3: Reading output from 'ls -alni /proc' debug3: Time elapsed: 60 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /proc' debug3: Reading output from 'ls -alni /tmp' debug3: Time elapsed: 26 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /tmp' debug3: Reading output from 'ls -alni /var/tmp' debug3: Time elapsed: 113 msec debug3: Got 2.00 bytes of entropy from 'ls -alni /var/tmp' debug3: Reading output from 'ls -alni /usr/tmp' debug3: Time elapsed: 16 msec debug3: Got 0.18 bytes of entropy from 'ls -alni /usr/tmp' debug3: Reading output from 'netstat -an' debug3: Time elapsed: 37 msec debug3: Got 2.00 bytes of entropy from 'netstat -an' debug3: Reading output from 'netstat -in' debug3: Time elapsed: 34 msec debug3: Got 2.00 bytes of entropy from 'netstat -in' debug3: Reading output from 'netstat -rn' debug3: Time elapsed: 34 msec debug3: Got 1.84 bytes of entropy from 'netstat -rn' debug3: Reading output from 'netstat -pn' debug3: Time elapsed: 43 msec debug3: Got 2.00 bytes of entropy from 'netstat -pn' debug3: Reading output from 'netstat -ia' debug3: Time elapsed: 43 msec debug3: Got 2.00 bytes of entropy from 'netstat -ia' debug3: Reading output from 'netstat -s' debug3: Time elapsed: 38 msec debug3: Got 2.00 bytes of entropy from 'netstat -s' debug3: Reading output from 'netstat -is' debug3: Time elapsed: 45 msec debug3: Got 2.00 bytes of entropy from 'netstat -is' debug3: Reading output from 'arp -a -n' debug3: Time elapsed: 156 msec debug3: Got 2.00 bytes of entropy from 'arp -a -n' debug3: Reading output from 'ifconfig -a' debug3: Time elapsed: 185 msec debug3: Got 0.86 bytes of entropy from 'ifconfig -a' debug3: Reading output from 'ps -al' debug3: Time elapsed: 46 msec debug3: Got 2.00 bytes of entropy from 'ps -al' debug3: Reading output from 'ps -efl' debug3: Time elapsed: 98 msec debug3: Got 2.00 bytes of entropy from 'ps -efl' debug3: Reading output from 'w' debug3: Time elapsed: 75 msec debug3: Got 2.00 bytes of entropy from 'w' debug3: Reading output from 'last' debug3: Time elapsed: 186 msec debug2: Command 'last' timed out debug3: Got 2.00 bytes of entropy from 'last' debug3: Reading output from 'df' debug3: Time elapsed: 22 msec debug3: Got 0.71 bytes of entropy from 'df' debug3: Reading output from 'vmstat' debug3: Time elapsed: 20 msec debug3: Got 0.23 bytes of entropy from 'vmstat' debug3: Reading output from 'uptime' debug3: Time elapsed: 29 msec debug3: Got 0.07 bytes of entropy from 'uptime' debug3: Reading output from 'ipcs -a' debug3: Time elapsed: 251 msec debug2: Command 'ipcs -a' timed out debug3: Got 0.00 bytes of entropy from 'ipcs -a' debug3: Reading output from 'tail -200 /var/log/syslog' debug3: Time elapsed: 14 msec debug3: Got 0.00 bytes of entropy from 'tail -200 /var/log/syslog' debug3: Reading output from 'tail -200 /var/adm/messages' debug3: Time elapsed: 16 msec debug3: Got 2.00 bytes of entropy from 'tail -200 /var/adm/messages' debug1: Seeded RNG with 47 bytes from programs debug1: Seeded RNG with 3 bytes from system calls debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 16476 geteuid 0 anon 1 debug1: Connecting to dazel [128.175.13.68] port 22. debug1: temporarily_use_uid: 16476/10 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 16476/10 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type RSA debug1: identity file /home/polycut.nss/usra/ed/.ssh/identity type 0 debug3: No RSA1 key file /home/polycut.nss/usra/ed/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: no key found debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/polycut.nss/usra/ed/.ssh/id_rsa type 1 debug1: identity file /home/polycut.nss/usra/ed/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9.9p2 debug1: match: OpenSSH_2.9.9p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9.9p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 115/256 debug1: bits set: 1613/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/polycut.nss/usra/ed/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /home/polycut.nss/usra/ed/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'dazel' is known and matches the RSA host key. debug1: Found key in /home/polycut.nss/usra/ed/.ssh/known_hosts:1 debug1: bits set: 1603/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey debug1: userauth_pubkey_agent: testing agent key /home/polycut.nss/usra/ed/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 145480 hint -1 debug2: input_userauth_pk_ok: fp f7:19:b1:e8:56:1c:81:55:44:9b:b4:f7:e1:b0:c8:ca debug3: sign_and_send_pubkey debug3: clear_auth_state: key_free 145480 debug1: ssh-userauth2 successful: method publickey debug3: clear hostkey 0 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug3: tty_make_modes: ospeed 9600 debug3: tty_make_modes: ispeed 9600 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 8 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 0 debug3: tty_make_modes: 7 0 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 11 25 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 16 0 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 1 debug3: tty_make_modes: 41 0 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 0 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 1 debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: shell debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 16384 debug2: channel 0: rcvd adjust 32768 Last login: Thu Nov 15 16:03:46 2001 from polycut.nss.ude Sun Microsystems Inc. SunOS 5.8 Generic February 2000 /usr/openwin/bin/xauth: creating new authority file /opt/home/ed/.Xauthority Sun Microsystems Inc. SunOS 5.8 Generic February 2000 (Side note: in this case, it's using my ~/.Xauthority file - but when I connect from 2.9.9p2 to v2.9p1 it uses /tmp/ssh-XXXXXXXX/cookies) Okay, now that I have a shell, I make an X11 request from another shell with a contrived cookie (that is invalid) and set the DISPLAY to be the same DISPLAY that was created by this ssh session... debug1: client_input_channel_open: ctype x11 rchan 3 win 4096 max 2048 debug1: client_request_x11: request from 128.175.13.160 46799 debug1: fd 10 setting O_NONBLOCK debug2: fd 10 is O_NONBLOCK debug1: channel 1: new [x11] debug1: confirm x11 debug1: X11 connection uses different authentication protocol. debug1: X11 rejected 1 i1/o16 debug1: channel 1: read failed debug1: channel 1: input open -> drain debug1: channel 1: close_read debug1: channel 1: write failed debug1: channel 1: output open -> closed debug1: channel 1: close_write debug1: X11 closed 1 i2/o128 debug1: channel 1: rcvd eof debug1: channel 1: FORCE input drain Then I press CTRL-D on the client... debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: channel 0: obuf empty debug1: channel 0: output drain -> closed debug1: channel 0: close_write debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: rcvd close debug1: channel 0: input open -> closed debug1: channel 0: close_read debug2: channel 0: no data after CLOSE debug1: channel 0: send close debug1: channel 0: is dead debug1: channel_free: channel 0: client-session, nchannels 2 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) #1 x11 (t7 r3 i2/0 o128/0 fd 10/10) debug1: channel_free: channel 0: detaching channel user debug3: channel_close_fds: channel 0: r -1 w -1 e 9 At this point, the ssh client is hung and I can hit CTRL-C to get it to exit... ^Cdebug1: channel_free: channel 1: x11, nchannels 1 debug3: channel_free: status: The following connections are open: #1 x11 (t7 r3 i2/0 o128/0 fd 10/10) debug3: channel_close_fds: channel 1: r 10 w 10 e -1 Killed by signal 2. debug1: Calling cleanup 0x3dfa0(0x0) debug1: Calling cleanup 0x531d8(0x0) debug1: Calling cleanup 0x5cba0(0x0) debug1: writing PRNG seed to file /home/polycut.nss/usra/ed/.ssh/prng_seed polycut:~> Can someone verify this with 3.0pX? Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From ed at UDel.Edu Fri Nov 16 08:27:12 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 15 Nov 2001 16:27:12 -0500 (EST) Subject: X11 cookies and forwarding (fwd) Message-ID: On Thu, 15 Nov 2001, Dan Astoorian wrote: > Date: Thu, 15 Nov 2001 16:09:20 -0500 > From: Dan Astoorian > To: Ed Phillips > Subject: Re: X11 cookies and forwarding > > On Thu, 15 Nov 2001 15:46:22 EST, Ed Phillips writes: > > I'm guess I wasn't following the whole cookies discussion completely > > (putting cookies in /tmp to avoid putting them on NFS, etc.), but I > > noticed today that with 2.9.9p2, if I use "ssh -X" to start a shell on the > > server, in that shell XAUTHORITY is set to /tmp/ssh-XXXXXXXX/cookies and > > there are cookies placed there there. > > Are you sure the _server_ was running 2.9.9p2? The behaviour you're > describing was how OpenSSH 2.5.2 worked; that behaviour was removed by > 2.9 or 2.9.9. > > The cookie used to be created under /tmp (and XAUTHORITY set so that X > applications would know where to find it), until someone decided that > NFS-sniffing ultimately wasn't worth defending against (since if you > can't trust the directory where you're keeping your cryptographic keys, > then .Xauthority is among the least of your problems). Well, I bet people would care if their private keys (auth forwarding) where getting stored in $HOME (NFS mounted)... ;-) > Using /tmp created other problems; e.g., there was a security problem > when OpenSSH's daemon tried to clean up the cookie file (it did so as > root, which made it possible for a malicious user to fool OpenSSH's sshd > into deleting any file on the system named "cookies", via symlink > mischief with the directory). Actually, I'd guess that if you replaced the "cookies" file with a symbolic link to any file on the system, you could remove that file (depending how many checks are being done). This can be avoided, right? Why is the solution moving the file somewhere else? Doesn't sshd still need to be careful about what it's removing as uid 0 (i.e., don't remove the cookies file if it's a symbolic link, has the wrong inode number, has the wrong contents, etc., etc.)? > > So what's the real issue here... having ssh create a "fake" cookie and > > that gets copied to the server side... in the user's home directory? > > The issue *I* was raising is "should the fake keys be moved?" My > suggestion was to consider using a different file from the default > ($HOME/.Xauthority), to avoid the stale NFS handle problems I was > talking about--but not to revert to the previous behaviour of using > /tmp/. Okay... now I'm following you. I think /tmp is a good place for the cookies... much better than $HOME... but that depends on avoiding the problems in sshd. Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From gert at greenie.muc.de Fri Nov 16 08:32:11 2001 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 15 Nov 2001 22:32:11 +0100 Subject: ssh -2 and hostbasedauth Message-ID: <20011115223211.A14129@greenie.muc.de> Hi, I'm trying to figure out how to read OpenSSH's log files (to assist our people in diagnosing "why is it always asking me for passwords"). All clients and servers are 3.0p1. First: server does not have the client's RSA2 key in known_host. debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: next auth method to try is hostbased debug1: Remote: Accepted by .shosts. debug1: authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: Remote: Accepted by .shosts. debug1: authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: next auth method to try is publickey debug1: try privkey: /home/gert/.ssh/id_rsa debug1: try privkey: /home/gert/.ssh/id_dsa debug1: next auth method to try is keyboard-interactive Second: server *does* have the key (by doing "ssh -2 "): debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: next auth method to try is hostbased debug1: Remote: Accepted by .shosts. debug1: authentications that can continue: publickey,password,keyboard-interactive,hostbased debug1: Remote: Accepted by .shosts. debug1: ssh-userauth2 successful: method hostbased debug1: channel 0: new [client-session] debug1: send channel open 0 debug1: Entering interactive session. debug1: ssh_session2_setup: id 0 debug1: channel request 0: shell debug1: channel 0: open confirm rwindow 0 rmax 16384 - I don't really understand what "Remote: Accepted by .shosts" means, as in the first example the client connection is NOT accepted (due to the key not being known). Is this vague on purpose to avoid handing out information about public keys? How do I find out whether a remote end doesn't want to log me in because it's missing an .shosts entry, ignoring user .shosts or missing the client key in .known_hosts? Somewhat confused, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From djm at mindrot.org Fri Nov 16 08:50:18 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Nov 2001 08:50:18 +1100 (EST) Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: Message-ID: On Thu, 15 Nov 2001, Ed Phillips wrote: > > allow data loss in the server if a pty is allocated. i think > > this would match the telnetd and rlogind behaviour best. > > but i'm not 100% sure, people should test their telnetd/rlogind > > servers and check that they throw away data after the login > > shell dies. but once again: openssh is not telnet. > > I'm still not understanding why sshd can't figure out when to close the > socket that connects back to the client... is this just the open-ended > design of the V2 protocol? Just because there are no sshd children left > running and no file desriptors left to process, sshd still needs to stay > running? How about stracing or trussing a sshd and seeing for youself. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djast at cs.toronto.edu Fri Nov 16 09:20:09 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Thu, 15 Nov 2001 17:20:09 -0500 Subject: X11 cookies and forwarding (fwd) In-Reply-To: Your message of "Thu, 15 Nov 2001 16:27:12 EST." Message-ID: <01Nov15.172011edt.453144-10639@jane.cs.toronto.edu> On Thu, 15 Nov 2001 16:27:12 EST, Ed Phillips writes: > > > > The cookie used to be created under /tmp (and XAUTHORITY set so that X > > applications would know where to find it), until someone decided that > > NFS-sniffing ultimately wasn't worth defending against (since if you > > can't trust the directory where you're keeping your cryptographic keys, > > then .Xauthority is among the least of your problems). > > Well, I bet people would care if their private keys (auth forwarding) > where getting stored in $HOME (NFS mounted)... ;-) Ed, I deliberately removed openssh-dev from the recipients list on my reply to you, because we're discussing issues that I'm sure have been rehashed several times on this list, which is already noisier than it needs to be. It was poor form for you to quote my response to you (in an incomplete context) back to the list. If the NFS traffic for $HOME can be sniffed, it can probably be spoofed, and an attacker can simply write his own keys into $HOME/.ssh/authorized_keys, $HOME/.shosts, or a similar sensitive location, or to steal the (_hopefully_ password-protected) private key file and attack the passphrase with brute force. It was not unreasonable for OpenSSH to make the simplifying assumption that $HOME/.ssh can be trusted. > Actually, I'd guess that if you replaced the "cookies" file with a > symbolic link to any file on the system, you could remove that file > (depending how many checks are being done). This can be avoided, right? Why are you speculating about things you can easily test? It's not an issue. unlink("/tmp/ssh-XXXXX/cookies") was a problem when /tmp/ssh-XXXXX was a symlink; if "/tmp/ssh-XXXXX/cookies" is a symlink, only the symlink gets removed by the unlink(). This is why only files named "cookies" were at risk from that bug. > Why is the solution moving the file somewhere else? Doesn't sshd still > need to be careful about what it's removing as uid 0 (i.e., don't remove > the cookies file if it's a symbolic link, has the wrong inode number, has > the wrong contents, etc., etc.)? When the file was located under /tmp, sshd had to do a fair amount of work--creating the directory to contain it (safely!), with a unique filename, and cleaning up after itself. The fix was to let xauth use its default value, in the user's home directory; the permissions there are more appropriate, and no additional housekeeping is necessary. For what it's worth, when I suggested the possibility of setting XAUTHORITY to $HOME/.ssh/Xauthority, I was not suggesting introducing anything like the previous supporting code (creating the directory or trying to clean up the cookie file when the session ends); at most, I was suggesting setting the value of the environment variable, and perhaps using existing code to create $HOME/.ssh appropriately if it didn't already exist. > Okay... now I'm following you. I think /tmp is a good place for the > cookies... much better than $HOME... but that depends on avoiding the > problems in sshd. FWIW, I disagree with Ed about /tmp being a good place for the cookies, and agree with the decision to simplify the code. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From djm at mindrot.org Fri Nov 16 10:08:53 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Nov 2001 10:08:53 +1100 (EST) Subject: [PATCH]: Patch to fix hang on exit bug under Linux and add optional exit delay In-Reply-To: <20011115135144.J5739@sm2p1386swk.wdr.com> Message-ID: On Thu, 15 Nov 2001, Nicolas Williams wrote: > > No. A program could have done setsid() and started a new process > > group - think of daemons that do all that daemons should do, but forget > > to close stderr (because of stupid programming bugs in binary-only > > software - whatever "not easily fixable" reason there might be). > > Of course, yes, but such programs usually dissasociate from their > controlling tty too. > > Even if they don't, killing those process groups is *still* worthwhile. I think I tried sending HUPs to the process group sometime around 2.3.0, it didn't help for some reason - but I don't remember why. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From rashapiro83 at alum.mit.edu Fri Nov 16 13:26:34 2001 From: rashapiro83 at alum.mit.edu (Richard Shapiro) Date: Thu, 15 Nov 2001 21:26:34 -0500 Subject: OpenSSH 2.9.9.p2 port to IBM OS/390 Unix System Services Message-ID: <3BF4795A.A8F0CD2B@alum.mit.edu> I have done a port of OpenSSH to Unix Systems Services on IBM mainframes running OS/390. I have a version which seems to work with SSH 1 and 2, and most of the ancillary programs seem to work as well. I'd really like to see the changes (which mostly have to do with deciding which things need to be translated between ASCII and EBCDIC) incorporated into the source base. What is the best way to go about this? What does the release schedule (if such a thing exists) look like? Richard Shapiro rashapiro83 at alum.mit.edu From tim at multitalents.net Fri Nov 16 16:18:40 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 15 Nov 2001 21:18:40 -0800 (PST) Subject: ssh -2 and hostbasedauth In-Reply-To: <20011115223211.A14129@greenie.muc.de> Message-ID: On Thu, 15 Nov 2001, Gert Doering wrote: > Hi, > > I'm trying to figure out how to read OpenSSH's log files (to assist > our people in diagnosing "why is it always asking me for passwords"). > > All clients and servers are 3.0p1. > > First: server does not have the client's RSA2 key in known_host. > Here is what works for me on most of my platforms. sshd_config: HostbasedAuthentication yes ssh_config: Host * HostbasedAuthentication yes PreferredAuthentications publickey,hostbased,password,keyboard-interactive ^^^^^^ this line is no longer needed in 3.0 shosts.equiv: FQDN of all my other machines ssh_known_hosts: public keys of all my other machines. ssh must be suid root Note: SCO Opens Server 3 client wont connect to anything without password. Connecting from other server to Open Server 3 works fine. Solaris 7 & 8 will not connect to themselvs without password but will connect fine to other servers. I hope this helps. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From gert at greenie.muc.de Fri Nov 16 20:12:41 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 16 Nov 2001 10:12:41 +0100 Subject: ssh -2 and hostbasedauth In-Reply-To: ; from Tim Rice on Thu, Nov 15, 2001 at 09:18:40PM -0800 References: <20011115223211.A14129@greenie.muc.de> Message-ID: <20011116101241.A26731@greenie.muc.de> Hi, On Thu, Nov 15, 2001 at 09:18:40PM -0800, Tim Rice wrote: > > I'm trying to figure out how to read OpenSSH's log files (to assist > > our people in diagnosing "why is it always asking me for passwords"). > > > > All clients and servers are 3.0p1. > > > > First: server does not have the client's RSA2 key in known_host. > > > Here is what works for me on most of my platforms. Thanks :-) - but I figured out that part. What I did not understand is "why does it say 'Accepted by .shosts'" in the ssh -v output but then goes on asking for a password anyway? This message is seriously misleading... I guess it means "ok, you're in the .shosts file, now check the key" (and it will never tell the result of checking the key). > Note: > SCO Opens Server 3 client wont connect to anything without password. I tend to disagree :-) - mine does. Both to and from OSR 3, with 3.0p1, as long as the host RSA keys are known. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From heubach at heubach-edv.de Fri Nov 16 21:02:46 2001 From: heubach at heubach-edv.de (Manfred Heubach) Date: Fri, 16 Nov 2001 11:02:46 +0100 Subject: again chroot Message-ID: <01C16E8E.39BE9FD0.heubach@heubach-edv.de> > -----Urspr?ngliche Nachricht----- > Von: Markus Friedl [SMTP:markus at openbsd.org] > Gesendet am: Donnerstag, 15. November 2001 20:09 > An: Manfred Heubach > Cc: 'openssh-unix-dev at mindrot.org' > Betreff: Re: again chroot > > > make sftp-server setuid root and let it do the chroot itself, > depending on a config file, like /etc/sftp-chrootusers > > but you have to be careful. chroot $HOME is > probably not really save if .ssh is writeable to > the user. and so on. > > -m Dear Markus, how do I tell sftp-server about a file like /etc/sftp-chrootusers? I can't find any corresponding option. Is this already implemented or do I have to do the programming by myself? Regards Manfred From markus at openbsd.org Fri Nov 16 23:11:45 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 16 Nov 2001 13:11:45 +0100 Subject: again chroot In-Reply-To: <01C16E8E.39BE9FD0.heubach@heubach-edv.de>; from heubach@heubach-edv.de on Fri, Nov 16, 2001 at 11:02:46AM +0100 References: <01C16E8E.39BE9FD0.heubach@heubach-edv.de> Message-ID: <20011116131145.B21154@faui02.informatik.uni-erlangen.de> On Fri, Nov 16, 2001 at 11:02:46AM +0100, Manfred Heubach wrote: > how do I tell sftp-server about a file like /etc/sftp-chrootusers? I can't > find any corresponding option. Is this already implemented or do I have to > do the programming by myself? you have to do it yourself :) From gert at greenie.muc.de Fri Nov 16 23:45:21 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 16 Nov 2001 13:45:21 +0100 Subject: Interesting problem with 3.0p1 and IPv6 In-Reply-To: <20011112153630.B13897@greenie.muc.de>; from Gert Doering on Mon, Nov 12, 2001 at 03:36:30PM +0100 References: <20011112153630.B13897@greenie.muc.de> Message-ID: <20011116134521.D780@greenie.muc.de> hi, On Mon, Nov 12, 2001 at 03:36:30PM +0100, Gert Doering wrote: > I just ran into an interesting problem with 3.0p1 on FreeBSD 4.0 and > IPv6/v4 mapped addresses. > > If I do "ssh -v machine", where "machine" has an IPv4 address in the > DNS, everything works fine (machine is "hilbert.space.net"): [..] > Now, if I do "ssh -v cname" where "cname" is a CNAME to the same > machnie, the following happens: [..] > debug1: ssh_connect: getuid 0 geteuid 0 anon 0 > debug1: Connecting to hilberto [::ffff:194.59.182.6] port 22. > debug1: Allocated local port 904. > > (-> note the different address format!) [..] > check_host_key: getnameinfo failed While I still don't understand why OpenSSH is trying IPv6 mapped addresses if there is a CNAME, and normal IPv4 for "normal" DNS entries, I managed to work around this today by claiming that the system has no getnameinfo/getaddrinfo and use the openbsd-compat ones. Can autoconf check whether getnameinfo/getaddrinfo "work"? If yes, it could be helpful for others installing OpenSSH on FreeBSD 4.0... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From hubba at unixcook.com Sat Nov 17 00:06:54 2001 From: hubba at unixcook.com (Hubertus A. Haniel) Date: Fri, 16 Nov 2001 13:06:54 -00 Subject: SSH hang fix?? Message-ID: It is nice to see that the development of openssh suddenly seems to have a boost of activity. However I am fairly dissapointed to see that nobody is actually trying to fix the ssh hanging problem which I am mainly seeing on Solaris and AIX in conjunction with rsync. Has anybody from the development team got an ETA of the official fix for this problem? Regards Hubba From dan at doxpara.com Sat Nov 17 00:18:42 2001 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 16 Nov 2001 05:18:42 -0800 Subject: SSH hang fix?? References: Message-ID: <002b01c16ea1$36c7ac50$1701000a@effugas> I'll take a crack at it. Send me some debug logs(rsync -e "ssh -v -v -v"). --Dan www.doxpara.com ----- Original Message ----- From: "Hubertus A. Haniel" To: Sent: Friday, November 16, 2001 5:06 AM Subject: SSH hang fix?? > > It is nice to see that the development of openssh suddenly seems > to have a boost of activity. However I am fairly dissapointed to > see that nobody is actually trying to fix the ssh hanging problem > which I am mainly seeing on Solaris and AIX in conjunction with rsync. > > Has anybody from the development team got an ETA of the official > fix for this problem? > > Regards > Hubba From markus at openbsd.org Sat Nov 17 00:41:10 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 16 Nov 2001 14:41:10 +0100 Subject: SSH hang fix?? In-Reply-To: ; from hubba@unixcook.com on Fri, Nov 16, 2001 at 01:06:54PM +0000 References: Message-ID: <20011116144110.A12958@faui02.informatik.uni-erlangen.de> On Fri, Nov 16, 2001 at 01:06:54PM +0000, Hubertus A. Haniel wrote: > Has anybody from the development team got an ETA of the official > fix for this problem? does anyone have an ETA for a useful problem description? From mouring at etoh.eviladmin.org Sat Nov 17 02:22:28 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Nov 2001 09:22:28 -0600 (CST) Subject: again chroot In-Reply-To: <01C16E8E.39BE9FD0.heubach@heubach-edv.de> Message-ID: I can provide you with a patch that has been floating around (and I've used to some extent) for chroot sftp-server, but I do chroot() oddly over here to handle the ~/.ssh/ case. (No user ownes their ~/ and theire .ssh is root owned and chmod 000). So it is not extazct what Markus suggests. - Ben On Fri, 16 Nov 2001, Manfred Heubach wrote: > > -----Urspr?ngliche Nachricht----- > > Von: Markus Friedl [SMTP:markus at openbsd.org] > > Gesendet am: Donnerstag, 15. November 2001 20:09 > > An: Manfred Heubach > > Cc: 'openssh-unix-dev at mindrot.org' > > Betreff: Re: again chroot > > > > > > make sftp-server setuid root and let it do the chroot itself, > > depending on a config file, like /etc/sftp-chrootusers > > > > but you have to be careful. chroot $HOME is > > probably not really save if .ssh is writeable to > > the user. and so on. > > > > -m > > Dear Markus, > > how do I tell sftp-server about a file like /etc/sftp-chrootusers? I can't > find any corresponding option. Is this already implemented or do I have to > do the programming by myself? > > Regards > Manfred > From GILBERT.R.LOOMIS at saic.com Sat Nov 17 02:38:34 2001 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Fri, 16 Nov 2001 10:38:34 -0500 Subject: unable to get connection thru firewall Message-ID: <3C1E3607B37295439F7C409EFBA08E680E27C5@col-581-exs01.cist.saic.com> To close the loop for the list on this, the problem was that the Solaris box running sshd did not have a default route--so traffic worked fine on the local subnet but *no* traffic worked correctly between the system and other systems in other parts of the 'net. It wasn't an SSH problem at all--and as a data point for everyone, we've been removing the SetUID root bit on our ssh installations for years and we've never had a problem. Unless you're trying to work with RhostsAuthentication, I don't recommend turning off --disable-suid-ssh as part of your troubleshooting process. -- Rip Loomis Senior Systems Security Engineer SAIC Center for Information Security Technology > > I've a Solaris 8 with Openshh 3.0.1 (build with these parameters > > --prefix=/usr/local --without-rsh --disable-suid-ssh > ^^^^^^^^^^^^^^^^^^ > Take this out and try again. > > > --sysconfdir=/usr/local/etc --with-ssl-dir=/usr/local/ssl > > --with-tcp-wrappers). If I come from the same subnet as the > server is on, > > I've have no problems. But When I try via theI nternet I > doesn't. If I run > > snoop I can see I get contact with the server: > From markus at openbsd.org Sat Nov 17 02:57:09 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 16 Nov 2001 16:57:09 +0100 Subject: ssh -2 and hostbasedauth In-Reply-To: <20011116101241.A26731@greenie.muc.de>; from gert@greenie.muc.de on Fri, Nov 16, 2001 at 10:12:41AM +0100 References: <20011115223211.A14129@greenie.muc.de> <20011116101241.A26731@greenie.muc.de> Message-ID: <20011116165709.B10964@folly> > This message is seriously misleading... I guess it means "ok, you're in > the .shosts file, now check the key" (and it will never tell the result of > checking the key). yes. From gert at greenie.muc.de Sat Nov 17 03:06:48 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 16 Nov 2001 17:06:48 +0100 Subject: ssh -2 and hostbasedauth In-Reply-To: <20011116165709.B10964@folly>; from Markus Friedl on Fri, Nov 16, 2001 at 04:57:09PM +0100 References: <20011115223211.A14129@greenie.muc.de> <20011116101241.A26731@greenie.muc.de> <20011116165709.B10964@folly> Message-ID: <20011116170648.B4444@greenie.muc.de> Hi, On Fri, Nov 16, 2001 at 04:57:09PM +0100, Markus Friedl wrote: > > This message is seriously misleading... I guess it means "ok, you're in > > the .shosts file, now check the key" (and it will never tell the result of > > checking the key). > yes. Thanks :) Does protocol / design allow clarification of these messages so that a not-so-experienced user can understand what is happening and why ".shosts is accepted but it still doesn't work"? ssh -1 is easier to understand in that regard (especially as it will also tell you *which* hostname and user name it used for checking). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From hubba at unixcook.com Sat Nov 17 03:12:19 2001 From: hubba at unixcook.com (Hubertus A. Haniel) Date: Fri, 16 Nov 2001 16:12:19 -00 Subject: SSH hang fix?? Message-ID: That is easier said then done, it happens completley random. We have jobs running out of cron every hour syncing files on a cluster setup and if I use rsync over ssh everyso often a job will hang and I have to go in and kill them off. That is perfectly OK for a few days but you log on to the box a month later and there will be 100rds of these processes sitting there. Hubba At Friday, 16 November 2001, "Dan Kaminsky" wrote: >I'll take a crack at it. Send me some debug logs(rsync -e "ssh -v -v -v"). > >--Dan >www.doxpara.com > >----- Original Message ----- >From: "Hubertus A. Haniel" >To: >Sent: Friday, November 16, 2001 5:06 AM >Subject: SSH hang fix?? > >> >> It is nice to see that the development of openssh suddenly seems >> to have a boost of activity. However I am fairly dissapointed to >> see that nobody is actually trying to fix the ssh hanging problem >> which I am mainly seeing on Solaris and AIX in conjunction with rsync. >> >> Has anybody from the development team got an ETA of the official >> fix for this problem? >> >> Regards >> Hubba > ------------------------------------------------------------------------ - Hubertus Alexander Haniel ,,, http://www.unixcook.com - - Shorne, Kent, UK (o o) ICQ UIN: 1470384 - ---------------------------oOOo--(_)--oOOo------------------------------ From markus at openbsd.org Sat Nov 17 03:16:44 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 16 Nov 2001 17:16:44 +0100 Subject: ssh -2 and hostbasedauth In-Reply-To: <20011116170648.B4444@greenie.muc.de>; from gert@greenie.muc.de on Fri, Nov 16, 2001 at 05:06:48PM +0100 References: <20011115223211.A14129@greenie.muc.de> <20011116101241.A26731@greenie.muc.de> <20011116165709.B10964@folly> <20011116170648.B4444@greenie.muc.de> Message-ID: <20011116171643.B19606@faui02.informatik.uni-erlangen.de> On Fri, Nov 16, 2001 at 05:06:48PM +0100, Gert Doering wrote: > Hi, > > On Fri, Nov 16, 2001 at 04:57:09PM +0100, Markus Friedl wrote: > > > This message is seriously misleading... I guess it means "ok, you're in > > > the .shosts file, now check the key" (and it will never tell the result of > > > checking the key). > > yes. > > Thanks :) > > Does protocol / design allow clarification of these messages so that > a not-so-experienced user can understand what is happening and why > ".shosts is accepted but it still doesn't work"? > > ssh -1 is easier to understand in that regard (especially as it will also > tell you *which* hostname and user name it used for checking). the old ssh v1 implementation uses debug messages to disclose information. i don't like to tell un-authorized users information about the system, so i did not add more debug messages. however, i think we can add debug messages and make debug messages an option. -m From djast at cs.toronto.edu Sat Nov 17 04:16:10 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Fri, 16 Nov 2001 12:16:10 -0500 Subject: ssh -2 and hostbasedauth In-Reply-To: Your message of "Fri, 16 Nov 2001 11:16:44 EST." <20011116171643.B19606@faui02.informatik.uni-erlangen.de> Message-ID: <01Nov16.121613edt.453150-10639@jane.cs.toronto.edu> On Fri, 16 Nov 2001 11:16:44 EST, Markus Friedl writes: > > however, i think we can add debug messages and make > debug messages an option. Defaulting to off, I trust? ("Debug mode." Sendmail. 'nuff said. ;-) ) I think that if this is done, it might be worth considering (if this isn't already what you had in mind) setting it up such that if the client requests it, debug messages--at least the ones which disclose questionable information--are produced and logged on the server side, but _not_ sent back to the client. That way, the sysadmin doesn't have to turn on the debug messages globally to troubleshoot a particular authentication problem, but legitimate users can still cause useful debugging info to be produced for the sysadmin. Whether such logs should be readable by unprivileged users on the server side is debatable, but my instinct is that they shouldn't be, since that could allow local users to gain information about each others' authentication setup. (As an example, I'm not sure it's appropriate that sshd will report "Accepted by .shosts" back to the client before verifying the host key; I haven't thought through whether this could be used by an attacker to verify the contents of an .shosts file by IP spoofing, or what the implications of this might be.) -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From mouring at etoh.eviladmin.org Sat Nov 17 04:33:43 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Nov 2001 11:33:43 -0600 (CST) Subject: SSH hang fix?? In-Reply-To: Message-ID: Hmm.. I do scp nightly, and rsync every 4 hours or so. And I've never seen it hang on OpenBSD, Solaris, nor Linux (My own bastardized version). This boxes range from 2.3.0 to 2.9e (The 2.3.0 are in an intranet with only me around.. so I've yet to upgrade it =).. The hang that is being refered here is: ssh host sleep 20&exit [..hangs for 20 seconds on some platforms..] - Ben On Fri, 16 Nov 2001, Hubertus A. Haniel wrote: > That is easier said then done, it happens completley random. We have > jobs running out of cron every hour syncing files on a cluster setup > and if I use rsync over ssh everyso often a job will hang and I have > to go in and kill them off. That is perfectly OK for a few days but > you log on to the box a month later and there will be 100rds of these > processes sitting there. > > Hubba > > > At Friday, 16 November 2001, "Dan Kaminsky" wrote: > > >I'll take a crack at it. Send me some debug logs(rsync -e "ssh > -v -v -v"). > > > >--Dan > >www.doxpara.com > > > >----- Original Message ----- > >From: "Hubertus A. Haniel" > >To: > >Sent: Friday, November 16, 2001 5:06 AM > >Subject: SSH hang fix?? > > > >> > >> It is nice to see that the development of openssh suddenly seems > >> to have a boost of activity. However I am fairly dissapointed to > >> see that nobody is actually trying to fix the ssh hanging problem > >> which I am mainly seeing on Solaris and AIX in conjunction with > rsync. > >> > >> Has anybody from the development team got an ETA of the official > >> fix for this problem? > >> > >> Regards > >> Hubba > > > > > > ------------------------------------------------------------------------ > - Hubertus Alexander Haniel ,,, http://www.unixcook.com - > - Shorne, Kent, UK (o o) ICQ UIN: 1470384 - > ---------------------------oOOo--(_)--oOOo------------------------------ > > > > > > > > > From mouring at etoh.eviladmin.org Sat Nov 17 04:39:17 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Nov 2001 11:39:17 -0600 (CST) Subject: OpenSSH 2.9.9.p2 port to IBM OS/390 Unix System Services In-Reply-To: <3BF4795A.A8F0CD2B@alum.mit.edu> Message-ID: You post the diff file to the list (or a URL posting to the diff file if it is big). Then it gets ripped apart by the OpenSSH Portable group.. And slowly merged in. As for release schedule.. It has never been set in stone except for the 6 month release (mirroring the OpenBSD release). - Ben On Thu, 15 Nov 2001, Richard Shapiro wrote: > I have done a port of OpenSSH to Unix Systems Services on IBM mainframes > running > OS/390. I have a version which seems to work with SSH 1 and 2, and most > of the ancillary programs seem to work as well. I'd really like to see > the changes (which mostly have to do with deciding which things need to > be translated between ASCII and EBCDIC) incorporated into the source > base. > > What is the best way to go about this? What does the release schedule > (if such a thing exists) look like? > > Richard Shapiro > rashapiro83 at alum.mit.edu > From tim at mcgarry.ch Sat Nov 17 07:41:07 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Fri, 16 Nov 2001 21:41:07 +0100 Subject: passphrase quality References: <00d801c16c21$f2beddc0$a300010a@mshome.net> <20011113101111.B11336@faui02.informatik.uni-erlangen.de> <000801c16e16$ba4e15e0$c802a8c0@cablecom.ch> <20011115215614.B19204@faui02.informatik.uni-erlangen.de> Message-ID: <003f01c16edf$04e28140$c802a8c0@cablecom.ch> I'm having difficulty educating the users on the systems that I administer to choose a sensible passphrase, either they choose a really short one, or they go to the other extreme and chooose one thats so complex they cant remember it. I think some versions of PGP comment on passphrase quality, perhaps this would be worth having in OpenSSH, maybe giving the user the oportunity to try again if there phrase isn't good enough Tim McGarry From peterw at usa.net Sat Nov 17 08:47:18 2001 From: peterw at usa.net (Peter W) Date: Fri, 16 Nov 2001 16:47:18 -0500 Subject: passphrase quality In-Reply-To: <003f01c16edf$04e28140$c802a8c0@cablecom.ch>; from tim@mcgarry.ch on Fri, Nov 16, 2001 at 09:41:07PM +0100 References: <00d801c16c21$f2beddc0$a300010a@mshome.net> <20011113101111.B11336@faui02.informatik.uni-erlangen.de> <000801c16e16$ba4e15e0$c802a8c0@cablecom.ch> <20011115215614.B19204@faui02.informatik.uni-erlangen.de> <003f01c16edf$04e28140$c802a8c0@cablecom.ch> Message-ID: <20011116164718.A4038@usa.net> On Fri, Nov 16, 2001 at 09:41:07PM +0100, Tim McGarry wrote: > I'm having difficulty educating the users on the systems that I administer > to choose a sensible passphrase > I think some versions of PGP comment on passphrase quality, perhaps this > would be worth having in OpenSSH, maybe giving the user the oportunity to > try again if there phrase isn't good enough In many Linux-based operating environments, this is enforced via PAM and the pam_cracklib library. You might lok at that; I think it makes more sense to do the testing there than inside OpenSSH. Or do you mean passphrases for their RSA/DSA private keys? If that's the case, I think the idea might be to PAM-ify ssh-keygen, though 1) there are legitimate reasons/occasions for keys w/o passphrases 2) since the user always controls their own private SSH key files, there's nothing preventing them from modifying the key with their own version of ssh-keygen So the best you could hope for is a warning. if (strlen(requestedPass) > 0 ) { askPamIfItIsAlright(); } /* kinda */ This is part of the "problem" with keypair auth & decentralized configuration. Like ~/.rhosts, pretty much if you enable the mechanism, it's impossible to control. Actually private keypairs are harder to control than ~/.rhosts, since users can specify *any* file with the -i option. -Peter From mouring at etoh.eviladmin.org Sat Nov 17 08:58:54 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 16 Nov 2001 15:58:54 -0600 (CST) Subject: passphrase quality In-Reply-To: <20011116164718.A4038@usa.net> Message-ID: On Fri, 16 Nov 2001, Peter W wrote: > On Fri, Nov 16, 2001 at 09:41:07PM +0100, Tim McGarry wrote: > > > I'm having difficulty educating the users on the systems that I administer > > to choose a sensible passphrase > > > I think some versions of PGP comment on passphrase quality, perhaps this > > would be worth having in OpenSSH, maybe giving the user the oportunity to > > try again if there phrase isn't good enough > > In many Linux-based operating environments, this is enforced via PAM and the > pam_cracklib library. You might lok at that; I think it makes more sense to > do the testing there than inside OpenSSH. > No. ssh-keygen should never be pamifed. It is worthless to do so. If we are going to enforce passphrase quality it should be for all OSes. The world does not revolve around Linux. No matter what the press may think. - Ben From dje at watson.ibm.com Sat Nov 17 09:11:11 2001 From: dje at watson.ibm.com (David Edelsohn) Date: Fri, 16 Nov 2001 17:11:11 -0500 Subject: auth.c:secure_filename() ownership test continues past home directory Message-ID: <200111162211.RAA23588@makai.watson.ibm.com> My colleagues and I believe we have found a problem in the auth.c:secure_filename() code which causes it to be more aggressive than intended. We first noticed the problem in OpenSSH-2.9.9. secure_filename() comments that the loop walking up the directory components stops if it is past the home directory. However, the filename argument to the function is canonicalized with realpath() while the home directory provided by the password entry never is canonicalized. If the password entry home directory is not the canonial path (automounted, for example), then the component walk does not terminate until it has reached the root directory, which is past the home directory. If any component is not owned by root, then the security check fails and public key authentication is not allowed. This appears to be a stricter ownership requirement than what was intended in the code. Would you please consider canonicalizing the password entry home directory within the function using realpath() for accurate comparison to the filename argument? Thanks, David =============================================================================== David Edelsohn T.J. Watson Research Center dje at watson.ibm.com P.O. Box 218 +1 914 945 4364 (TL 862) Yorktown Heights, NY 10598 From Darren.Moffat at eng.sun.com Sat Nov 17 09:26:36 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Fri, 16 Nov 2001 14:26:36 -0800 (PST) Subject: passphrase quality Message-ID: <200111162226.fAGMQaCn499446@jurassic.eng.sun.com> >No. ssh-keygen should never be pamifed. It is worthless to do so. > >If we are going to enforce passphrase quality it should be for all OSes. >The world does not revolve around Linux. No matter what the press may >think. The Linux community didn't invent PAM, Sun did. Many more systems than Linux have PAM, Solaris, HP-UX some BSDs for a start. Having said that I agree with the comment ssh-keygen shouldn't be pamified, what you might want to do though is follow the pam model and have a pluggable set of rules that guide a user into choosing a good passphrase. -- Darren J Moffat From djast at cs.toronto.edu Sat Nov 17 09:35:00 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Fri, 16 Nov 2001 17:35:00 -0500 Subject: passphrase quality In-Reply-To: Your message of "Fri, 16 Nov 2001 17:26:36 EST." <200111162226.fAGMQaCn499446@jurassic.eng.sun.com> Message-ID: <01Nov16.173508edt.453152-10639@jane.cs.toronto.edu> On Fri, 16 Nov 2001 17:26:36 EST, Darren Moffat writes: > > Having said that I agree with the comment ssh-keygen shouldn't be pamified, > what you might want to do though is follow the pam model and have a > pluggable set of rules that guide a user into choosing a good passphrase. Kind of like cracklib (which pam_cracklib uses)? Cf. http://www.users.dircon.co.uk/~crypto/). However, note that: - cracklib is designed for passwords, not passphrases (it's aimed at *short* strings); - the dictionary that it checks against won't necessarily be the same on all systems, so any kind of consistency would be nontrivial to maintain. Cracklib is simple enough to hook into ssh-keygen, and although it's better than nothing as far as enforcing/encouraging passphrase quality goes, I doubt it's worthwhile to try to support it officially. (You'd need at least two separate configuration options--one for the location of the library, and another for the location of the dictionary.) -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From stevev at darkwing.uoregon.edu Sat Nov 17 09:36:21 2001 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Fri, 16 Nov 2001 14:36:21 -0800 Subject: passphrase quality In-Reply-To: <200111162226.fAGMQaCn499446@jurassic.eng.sun.com> References: <200111162226.fAGMQaCn499446@jurassic.eng.sun.com> Message-ID: <15349.38117.286401.799319@darkwing.uoregon.edu> Darren Moffat writes: > >No. ssh-keygen should never be pamifed. It is worthless to do so. > > > >If we are going to enforce passphrase quality it should be for all OSes. > >The world does not revolve around Linux. No matter what the press may > >think. > > The Linux community didn't invent PAM, Sun did. Many more systems > than Linux have PAM, Solaris, HP-UX some BSDs for a start. > > Having said that I agree with the comment ssh-keygen shouldn't be pamified, > what you might want to do though is follow the pam model and have a > pluggable set of rules that guide a user into choosing a good passphrase. It occurs to me that hooking cracklib into ssh-keygen might be a more generically useful approach, as it could be done even on systems that don't have PAM and cracklib seems to be reasonably portable and flexible. From peterw at usa.net Sat Nov 17 09:53:45 2001 From: peterw at usa.net (Peter W) Date: Fri, 16 Nov 2001 17:53:45 -0500 Subject: passphrase quality, ssh-keygen, cracklib In-Reply-To: <200111162226.fAGMQaCn499446@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Fri, Nov 16, 2001 at 02:26:36PM -0800 References: <200111162226.fAGMQaCn499446@jurassic.eng.sun.com> Message-ID: <20011116175345.C4038@usa.net> On Fri, Nov 16, 2001 at 02:26:36PM -0800, Darren Moffat wrote: > Having said that I agree with the comment ssh-keygen shouldn't be pamified, > what you might want to do though is follow the pam model and have a > pluggable set of rules that guide a user into choosing a good passphrase. You're thinking something along the lines of allowing a compile-time option to use cracklib if desired? For the reasons I already stated, I don't know that a "picky" ssh-keygen (PAM-ified or not) should do any more than display a warning & perhaps prompt for confirmation ("Are you sure you want to use such a weak passphrase?"). -Peter From dan at doxpara.com Sat Nov 17 11:38:30 2001 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 16 Nov 2001 16:38:30 -0800 Subject: SSH hang fix?? References: Message-ID: <004b01c16f00$2dfe7ae0$1701000a@effugas> > That is easier said then done, it happens completley random. We have > jobs running out of cron every hour syncing files on a cluster setup > and if I use rsync over ssh everyso often a job will hang and I have > to go in and kill them off. That is perfectly OK for a few days but > you log on to the box a month later and there will be 100rds of these > processes sitting there. I have actually seen behavior somewhat similar to this -- something to do with remote execution of commands through ssh. Occasionally, when the daemon dies, the commands won't die with them. This has led to some very annoyed emails to me from sysadmins wondering why I'm running thirty instances of netcat on their machines. Children processes not dying when parent processes croak does have the feel of a cross-platform oddity...all my instances of this bug tended to happen on Solaris 2.5.1 and 2.6. Yours Truly, Dan Kaminsky DoxPara Research http://www.doxpara.com From brendan at reactivenetwork.com Sat Nov 17 13:48:46 2001 From: brendan at reactivenetwork.com (Brendan Howes) Date: Fri, 16 Nov 2001 18:48:46 -0800 Subject: Portable SSH SRPMS problem / RH 6.X Message-ID: <000001c16f12$63fa5850$0a01010a@reactivenetwork.com> 1) Thank you to whoever makes these available. 2) I have a problem with the SRPMS, they will not --rebuild on a RedHat 6.2 system. Can anyone help me to get this to build here? [root openssh]# rpm --rebuild openssh-3.0.1p1-1.src.rpm Installing openssh-3.0.1p1-1.src.rpm line 74: Unknown tag: 0.9.5a Some Info: [root openssh]# rpm -qa | grep rpm rpm-python-3.0.5-9.6x rpm-build-3.0.5-9.6x rpm-devel-3.0.5-9.6x rpm-3.0.5-9.6x [root openssh]# rpm -qa | grep openssl-0 openssl-0.9.5-1 openssl-0.9.5a-14 [root openssh]# rpm -qa | grep zl zlib-1.1.3-6 zlib-devel-1.1.3-6 [root openssh]# rpm -qa | grep pam pam-0.72-7 pamconfig-2.0-3 [root openssh]# rpm -qa | grep ssh openssh-clients-2.9.9p2-1 openssh-server-2.9.9p2-1 openssh-askpass-2.9.9p2-1 openssh-2.9.9p2-1 From staatsvr at asc.hpc.mil Sat Nov 17 10:23:54 2001 From: staatsvr at asc.hpc.mil (Vern Staats) Date: Fri, 16 Nov 2001 18:23:54 -0500 Subject: [PATCH] Re: Kerberos support for portable Message-ID: <20011116182354.B8618@sw4.asc.hpc.mil> Thanks, Simon for the MIT Kerberos5 patches. FWIW, here are further patches which allow openssh-3.0p1 to work with paleo-MIT Kerberos5 1.0.6, more or less (more with tickets and less with the auth_krb5_password {get,verify}_init_creds stuff). BTW, the patches I pulled out of the archive seemed to have some line wrapping problems; I had to apply several chunks by hand. I'm therefore including Simon's krb5 + auth1.c patches along with my krb5 1.0.6 patches as a uuencoded tarball instead of plain text. -- "My company prefers to have that kind of decision made by uninformed executives. We call it "Empowerment". --Dilbert staatsvr at asc.hpc.mil Vern Staats, ASC/HPTS, WPAFB OH 45433, 937-255-1616x449 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-3.0p1.krb5patches.tgz Type: application/x-tar-gz Size: 4624 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011116/7cb51382/attachment.bin From cmadams at hiwaay.net Sat Nov 17 16:44:09 2001 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 16 Nov 2001 23:44:09 -0600 Subject: Portable SSH SRPMS problem / RH 6.X In-Reply-To: <000001c16f12$63fa5850$0a01010a@reactivenetwork.com>; from brendan@reactivenetwork.com on Fri, Nov 16, 2001 at 06:48:46PM -0800 References: <000001c16f12$63fa5850$0a01010a@reactivenetwork.com> Message-ID: <20011116234409.K27072@HiWAAY.net> Once upon a time, Brendan Howes said: > 2) I have a problem with the SRPMS, they will not --rebuild on a RedHat > 6.2 system. Can anyone help me to get this to build here? > > [root openssh]# rpm --rebuild openssh-3.0.1p1-1.src.rpm > Installing openssh-3.0.1p1-1.src.rpm > line 74: Unknown tag: 0.9.5a > > Some Info: > [root openssh]# rpm -qa | grep rpm > rpm-python-3.0.5-9.6x > rpm-build-3.0.5-9.6x > rpm-devel-3.0.5-9.6x > rpm-3.0.5-9.6x Check your friendly Red Hat mirror site and go to .../updates/6.2/en/os/i386/. You need a newer version of RPM (and maybe some other things as well :-) ). BTW: I'm using rpm4 on a Tru64 5.1A system here. I had to make a few changes to the contrib/redhat/openssh.spec file for Tru64 to work; is there any interest in a patch for the official OpenSSH source? Tru64 uses rpm for the "Open Source" collection CDs (although they use rpm3 and I had to upgrade to rpm4 for a lot of .spec files to work). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From djm at mindrot.org Sat Nov 17 16:51:12 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Nov 2001 16:51:12 +1100 (EST) Subject: Portable SSH SRPMS problem / RH 6.X In-Reply-To: <000001c16f12$63fa5850$0a01010a@reactivenetwork.com> Message-ID: On Fri, 16 Nov 2001, Brendan Howes wrote: > > 1) Thank you to whoever makes these available. > > 2) I have a problem with the SRPMS, they will not --rebuild on a RedHat > 6.2 system. Can anyone help me to get this to build here? You probably want to do: rpm --rebuild --define ?static_libcrypto 1? openssh-3.0.1p1-1.src.rpm -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From djm at mindrot.org Sat Nov 17 16:51:58 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Nov 2001 16:51:58 +1100 (EST) Subject: Portable SSH SRPMS problem / RH 6.X In-Reply-To: <20011116234409.K27072@HiWAAY.net> Message-ID: On Fri, 16 Nov 2001, Chris Adams wrote: > BTW: I'm using rpm4 on a Tru64 5.1A system here. I had to make a few > changes to the contrib/redhat/openssh.spec file for Tru64 to work; is > there any interest in a patch for the official OpenSSH source? Tru64 > uses rpm for the "Open Source" collection CDs (although they use rpm3 > and I had to upgrade to rpm4 for a lot of .spec files to work). Send them in - If the diffs are generic enough, I will merge them. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From sxw at dcs.ed.ac.uk Sat Nov 17 22:40:51 2001 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Sat, 17 Nov 2001 11:40:51 GMT Subject: [PATCH] Re: Kerberos support for portable In-Reply-To: Vern Staats's message of Fri, 16 Nov 2001 18:23:54 -0500 Message-ID: <200111171140.LAA00508@canna.dcs.ed.ac.uk> > FWIW, here are further patches which allow openssh-3.0p1 to work > with paleo-MIT Kerberos5 1.0.6, more or less (more with tickets > and less with the auth_krb5_password {get,verify}_init_creds stuff). Thanks for these. Unfortunately, your vrs patches seem to be based on an earlier version of my patch than the one you're bundling. In particular, your patch adds back in the incorrect replay cache code (it uses the wrong cache name), and takes out the use_uid calls that are necessary to make verify_init_creds() work correctly. It also adds back in the xfree() calls in auth1.c that I removed - these have to be removed to make it work reliably. Finally there are a couple of patches to the rijandel code that don't seem related? I am right in thinking that the basic change that is required is to conditionally remove auth_krb5_password (or just make it a stub that does nothing useful) if built against old MIT Kerberoses? Cheers, Simon. From markus at openbsd.org Sun Nov 18 00:07:27 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 17 Nov 2001 14:07:27 +0100 Subject: ssh -2 and hostbasedauth In-Reply-To: <01Nov16.121613edt.453150-10639@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Fri, Nov 16, 2001 at 12:16:10PM -0500 References: <20011116171643.B19606@faui02.informatik.uni-erlangen.de> <01Nov16.121613edt.453150-10639@jane.cs.toronto.edu> Message-ID: <20011117140727.A4911@folly> On Fri, Nov 16, 2001 at 12:16:10PM -0500, Dan Astoorian wrote: > I think that if this is done, it might be worth considering (if this > isn't already what you had in mind) setting it up such that if the > client requests it, debug messages--at least the ones which disclose > questionable information--are produced and logged on the server side, > but _not_ sent back to the client. too complicated, would need a protocol change. -m From markus at openbsd.org Sun Nov 18 00:12:51 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 17 Nov 2001 14:12:51 +0100 Subject: auth.c:secure_filename() ownership test continues past home directory In-Reply-To: <200111162211.RAA23588@makai.watson.ibm.com>; from dje@watson.ibm.com on Fri, Nov 16, 2001 at 05:11:11PM -0500 References: <200111162211.RAA23588@makai.watson.ibm.com> Message-ID: <20011117141251.C4911@folly> On Fri, Nov 16, 2001 at 05:11:11PM -0500, David Edelsohn wrote: > My colleagues and I believe we have found a problem in the > auth.c:secure_filename() code which causes it to be more aggressive than > intended. We first noticed the problem in OpenSSH-2.9.9. thanks, this has been fixed in newer releases. -m From djast at cs.toronto.edu Sun Nov 18 05:14:47 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Sat, 17 Nov 2001 13:14:47 -0500 Subject: ssh -2 and hostbasedauth In-Reply-To: Message from Markus Friedl of "Sat, 17 Nov 2001 08:07:27 EST." <20011117140727.A4911@folly> Message-ID: <01Nov17.131451edt.453147-12382@jane.cs.toronto.edu> On Sat, 17 Nov 2001 08:07:27 EST, Markus Friedl writes: > On Fri, Nov 16, 2001 at 12:16:10PM -0500, Dan Astoorian wrote: > > I think that if this is done, it might be worth considering (if this > > isn't already what you had in mind) setting it up such that if the > > client requests it, debug messages--at least the ones which disclose > > questionable information--are produced and logged on the server side, > > but _not_ sent back to the client. > > too complicated, would need a protocol change. Sorry. I hadn't realized that SSH[2]_MSG_DEBUG messages were sent unconditionally, and only displayed if the client was in verbose mode; I had assumed the client solicited the debugging messages. You're right: extending the protocol for this would be a bad idea. Can I at least recommend that, at least by default, any authentication-related debugging be recorded via local (syslog/stderr) interfaces only (e.g., verbose() or debug()), and not disclosed via packet_send_debug()? Moreover, perhaps existing instances of packet_send_debug()--such as the "accepted by .shosts" message previously discussed--be reevaluated for the appropriateness and necessity of the information they disclose. Thanks, -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From kefren at tin.it Sun Nov 18 05:27:00 2001 From: kefren at tin.it (Tommaso Cucinotta) Date: Sat, 17 Nov 2001 19:27:00 +0100 Subject: Muscle Card Edge with OpenSSH Message-ID: <3BF6ABF4.6B29E023@tin.it> Hi all, a modified version of the OpenSSH client programs has been released on the Smart Sign Web Site http://smartsign.sourceforge.net that uses Muscle Card Edge technology. It directly generates an OpenSSH private key on to a JavaCard 2.1.1 compliant smart card (using CardEdge key generation facility) and uses it from the card itself. Private key can never get compromised after generation ! The code has been integrated into OpenSSH sources so to allow normal OpenSSH behaviour. Smartcards are used only if required by the user using special command line options. This package has been compiled and tested on Win2K platform, too (using CygWin). Feedback is welcome ! Details follow. Bye, Tommaso. ---------- SUMMARY OF CHANGES: - Requires PCSC-Lite, a PCSC reader driver and MuscleCard API Toolkit (it also requires a smart card reader and its driver for PCSC-Lite and a JavaCard-2.1.1 compliant smart card with the Card Edge Applet already pre-loaded). - Enabling Card Edge module during configuration ./configure --with-musclecard=path (defaults to /usr/local) - Building modified programs . make ssh-agent . make ssh-add . make ssh-keygen (you can also try a single make) ** DO NOT TRY TO BUILD OTHER OPEN-SSH PROGRAMS, PLEASE ** ** On Windows, type make ssh-agent.exe, ... - ssh-agent . Launch as usual, here you don't need anything special - ssh-add . Launch with the '-sc' option to add the smartcard identity: you will be prompted with smartcard PIN . Launch as usual to add other (file) identities . Use 'ssh-add -L' to view all the loaded identities (also the SC) . After adding the identity, use the NORMAL ssh client to connect to a remote server using the smartcard - ssh-keygen . Launch with the '-t rsa-sc' option to generate a keypair and store it on the smartcard. Please, note that after key generation the program will fail, but key generation/storing process would be fine. Try a 'eval `./ssh-agent`; ssh-add -L' to view new identity public information . Launch as usual to generate file-based key pairs. . Sorry, this is really unfinished, yet. I couldn't figure out how to embed the key generation process in the OpenSSH framework... - Customizing behaviour This module uses card PIN and public and private key numbers as specified in the file rsa_sc.c, under the "Customization options" section. You can change their values if you need it. - Note This module does not use any certificates for key management. - For further information, please, refer to the SmartSign mailing list: smartsign-users at lists.sourceforge.net -- /------------------------------------------------\ | Dr. Tommaso Cucinotta | +------------------------------------------------+ | Scuola Superiore di Studi Universitari | | e Perfezionamento S.Anna | | Pisa Italy | \------------------------------------------------/ From bugzilla-daemon at mindrot.org Sun Nov 18 06:14:34 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 18 Nov 2001 06:14:34 +1100 (EST) Subject: [Bug 9] SGI compiler produces warnings Message-ID: <20011117191434.10DF22DF3F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=9 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From stevesk at pobox.com 2001-11-18 06:14 ------- i have made enum/int type cleanups where it made sense to do so. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From markus at openbsd.org Sun Nov 18 06:24:02 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 17 Nov 2001 20:24:02 +0100 Subject: Muscle Card Edge with OpenSSH In-Reply-To: <3BF6ABF4.6B29E023@tin.it>; from kefren@tin.it on Sat, Nov 17, 2001 at 07:27:00PM +0100 References: <3BF6ABF4.6B29E023@tin.it> Message-ID: <20011117202402.A25403@folly> On Sat, Nov 17, 2001 at 07:27:00PM +0100, Tommaso Cucinotta wrote: > Hi all, > > a modified version of the OpenSSH client programs > has been released on the Smart Sign Web Site > has this been integrated with openssh's smartcard support? From cucinotta at sssup.it Sun Nov 18 06:36:10 2001 From: cucinotta at sssup.it (Tommaso Cucinotta) Date: Sat, 17 Nov 2001 20:36:10 +0100 Subject: Muscle Card Edge with OpenSSH References: <3BF6ABF4.6B29E023@tin.it> <20011117202402.A25403@folly> Message-ID: <3BF6BC2A.4855E653@sssup.it> Markus Friedl wrote: > > On Sat, Nov 17, 2001 at 07:27:00PM +0100, Tommaso Cucinotta wrote: > > Hi all, > > > > a modified version of the OpenSSH client programs > > has been released on the Smart Sign Web Site > > > > has this been integrated with openssh's smartcard support? What do you mean with openssh's smartcard support ? Mine is based upon openssh-2.9p2, that is not the latest, so I don't know if a smartcard support was added to OpenSSH. This is a kind of "proof of concept", even if seems to be almost stable, in that the agent doesn't crash, like my pervious variation based upon SSP-Lite. I'd like to integrate this into the OpenSSH project in the best way that is possible. Bye, Tommaso. -- /------------------------------------------------\ | Dr. Tommaso Cucinotta | +------------------------------------------------+ | Scuola Superiore di Studi Universitari | | e Perfezionamento S.Anna | | Pisa Italy | \------------------------------------------------/ From markus at openbsd.org Sun Nov 18 06:37:52 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 17 Nov 2001 20:37:52 +0100 Subject: Muscle Card Edge with OpenSSH In-Reply-To: <3BF6BC2A.4855E653@sssup.it>; from cucinotta@sssup.it on Sat, Nov 17, 2001 at 08:36:10PM +0100 References: <3BF6ABF4.6B29E023@tin.it> <20011117202402.A25403@folly> <3BF6BC2A.4855E653@sssup.it> Message-ID: <20011117203752.A28378@faui02.informatik.uni-erlangen.de> On Sat, Nov 17, 2001 at 08:36:10PM +0100, Tommaso Cucinotta wrote: > Markus Friedl wrote: > > > > On Sat, Nov 17, 2001 at 07:27:00PM +0100, Tommaso Cucinotta wrote: > > > Hi all, > > > > > > a modified version of the OpenSSH client programs > > > has been released on the Smart Sign Web Site > > > > > > > has this been integrated with openssh's smartcard support? > > What do you mean with openssh's smartcard support ? > Mine is based upon openssh-2.9p2, that is not the latest, > so I don't know if a smartcard support was added to > OpenSSH. OpenSSH 2.9.9 and later contain Smartcard support based on work done by CITI -m From bugzilla-daemon at mindrot.org Sun Nov 18 06:51:44 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Sun, 18 Nov 2001 06:51:44 +1100 (EST) Subject: [Bug 19] scp - file size limit on file to be transferred via scp Message-ID: <20011117195144.BE4592DF3F@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=19 stevesk at pobox.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From stevesk at pobox.com 2001-11-18 06:51 ------- closing as dup of 20, which will be used for sftp/scp largefile problem. *** This bug has been marked as a duplicate of 20 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From mogul at gelatinous.com Sun Nov 18 09:00:31 2001 From: mogul at gelatinous.com (Bret Mogilefsky) Date: Sat, 17 Nov 2001 14:00:31 -0800 Subject: Updated chroot patch Message-ID: <20011117140031.A24807@gelatinous.com> Howdy folks, The chroot patch in the contrib directory had gotten stale and didn't apply cleanly, so I've updated it... The attached patch works fine with 3.0p1. Is there any reason this patch stays in the contrib directory rather than being applied to the source? I find it incredibly useful. Thanks for your hard work on OpenSSH! Bret PS: Please cc me with any responses as I'm not subscribed to the dev list. -- Bret Mogilefsky * Mgr. SCEA Developer Support * mogul at gelatinous.com -------------- next part -------------- --- session.c Sun Sep 16 15:17:15 2001 +++ session.c.patched Sat Oct 6 11:23:19 2001 @@ -92,6 +92,8 @@ # include #endif +#define CHROOT + /* types */ #define TTYSZ 64 @@ -1028,6 +1030,11 @@ extern char **environ; struct stat st; char *argv[10]; +#ifdef CHROOT + char *user_dir; + char *new_root; +#endif /* CHROOT */ + int do_xauth; #ifdef WITH_IRIX_PROJECT prid_t projid; @@ -1102,6 +1109,28 @@ if (setlogin(pw->pw_name) < 0) error("setlogin failed: %s", strerror(errno)); + +#ifdef CHROOT + user_dir = xstrdup(pw->pw_dir); + new_root = user_dir + 1; + + while((new_root = strchr(new_root, '.')) != NULL) { + new_root--; + if(strncmp(new_root, "/./", 3) == 0) { + *new_root = '\0'; + new_root += 2; + + if(chroot(user_dir) != 0) + fatal("Couldn't chroot to user directory %s", user_dir); + + pw->pw_dir = new_root; + break; + } + new_root += 2; + } +#endif /* CHROOT */ + + if (setgid(pw->pw_gid) < 0) { perror("setgid"); exit(1); From jclonguet at free.fr Sun Nov 18 10:03:54 2001 From: jclonguet at free.fr (Jean-Charles Longuet) Date: Sun, 18 Nov 2001 00:03:54 +0100 Subject: [PATCH] Connect timeout Message-ID: <3BF6ECDA.693026E6@free.fr> The attached patch adds a new 'ConnectTimeout' option (man page updated in patch) to avoid wasting time when the target host is down. I needed that because I was using rsync/rdist over ssh for massive files update and the default connect() took too long for my purpose. The patch was tested on Linux only, but I used a similar one for ssh 1.2.XX on Linux, Solaris and HP-UX without problems. The patch can also be found on: http://charts.free.fr/openssh-3.0.1p1-timeout.patch Can someone tell we if such a patch can be included in the main tree ? PS: I did not suscribe to the list, so please cc: me regarding this patch -- Jean-Charles Longuet -------------- next part -------------- --- openssh-3.0.1p1/ssh.1.ORIG Sat Nov 17 23:07:02 2001 +++ openssh-3.0.1p1/ssh.1 Sat Nov 17 23:09:39 2001 @@ -804,6 +804,12 @@ The argument must be an integer. This may be useful in scripts if the connection sometimes fails. The default is 1. +.It Cm ConnectTimeout +Specifies the timeout (in seconds) used when connecting to the ssh +server, instead of using default system values. This value is used +only when the target is down or really unreachable, not when it +refuses the connection. This may be usefull for tools using ssh +for communication, as it avoid long waits. .It Cm DynamicForward Specifies that a TCP/IP port on the local machine be forwarded over the secure channel, and the application --- openssh-3.0.1p1/includes.h.ORIG Sat Nov 17 22:49:09 2001 +++ openssh-3.0.1p1/includes.h Sat Nov 17 22:49:47 2001 @@ -44,6 +44,8 @@ #include #include #include +#include +#include #ifdef HAVE_LIMITS_H # include --- openssh-3.0.1p1/readconf.c.ORIG Sat Nov 17 22:49:09 2001 +++ openssh-3.0.1p1/readconf.c Sat Nov 17 22:49:47 2001 @@ -115,7 +115,8 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings, oNoHostAuthenticationForLocalhost + oClearAllForwardings, oNoHostAuthenticationForLocalhost, + oConnectTimeout } OpCodes; /* Textual representations of the tokens. */ @@ -187,6 +188,7 @@ { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "connecttimeout", oConnectTimeout }, { NULL, 0 } }; @@ -294,6 +296,11 @@ /* don't panic, but count bad options */ return -1; /* NOTREACHED */ + + case oConnectTimeout: + intptr = &options->connection_timeout; + goto parse_int; + case oForwardAgent: intptr = &options->forward_agent; parse_flag: @@ -775,6 +782,7 @@ options->compression_level = -1; options->port = -1; options->connection_attempts = -1; + options->connection_timeout = -1; options->number_of_password_prompts = -1; options->cipher = -1; options->ciphers = NULL; --- openssh-3.0.1p1/readconf.h.ORIG Sat Nov 17 22:49:09 2001 +++ openssh-3.0.1p1/readconf.h Sat Nov 17 22:49:47 2001 @@ -68,6 +68,8 @@ int port; /* Port to connect. */ int connection_attempts; /* Max attempts (seconds) before * giving up */ + int connection_timeout; /* Max time (seconds) before + * aborting connection attempt */ int number_of_password_prompts; /* Max number of password * prompts. */ int cipher; /* Cipher to use. */ --- openssh-3.0.1p1/ssh.c.ORIG Sat Nov 17 22:49:09 2001 +++ openssh-3.0.1p1/ssh.c Sat Nov 17 22:49:47 2001 @@ -674,7 +674,7 @@ /* Open a connection to the remote host. */ cerr = ssh_connect(host, &hostaddr, options.port, IPv4or6, - options.connection_attempts, + options.connection_attempts, options.connection_timeout, original_effective_uid != 0 || !options.use_privileged_port, pw, options.proxy_command); --- openssh-3.0.1p1/sshconnect.c.ORIG Sat Nov 17 22:49:09 2001 +++ openssh-3.0.1p1/sshconnect.c Sat Nov 17 23:02:27 2001 @@ -35,6 +35,8 @@ char *client_version_string = NULL; char *server_version_string = NULL; +static jmp_buf jmpenv; + extern Options options; extern char *__progname; @@ -221,6 +223,43 @@ return sock; } +/* for alarm() */ +static void +timeout_sigh(int dummy) +{ + errno = ETIMEDOUT; + longjmp(jmpenv, !0); +} + +int +timeout_connect(int sockfd, const struct sockaddr *serv_addr, + socklen_t addrlen, int timeout) +{ + void (*sigh)(int); + int rc; + + if (timeout <= 0) + return(connect(sockfd, serv_addr, addrlen)); + + if (setjmp(jmpenv) == 0) + { + debug("ssh: setting connect() timeout to %d s.", + timeout); + sigh = signal(SIGALRM, timeout_sigh); + if (sigh == SIG_ERR) + sigh = SIG_IGN; /* For further restore */ + (void) alarm((unsigned int) timeout); + rc = connect(sockfd, serv_addr, addrlen); + /* restore previous behaviour */ + (void) alarm((unsigned int) 0); + (void) signal(SIGALRM, sigh); + return rc; + } else { + errno = ETIMEDOUT; + return -1; + } +} + /* * Opens a TCP/IP connection to the remote server on the given host. * The address of the remote host will be returned in hostaddr. @@ -240,7 +279,7 @@ */ int ssh_connect(const char *host, struct sockaddr_storage * hostaddr, - u_short port, int family, int connection_attempts, + u_short port, int family, int connection_attempts, int connection_timeout, int anonymous, struct passwd *pw, const char *proxy_command) { int gaierr; @@ -322,7 +361,8 @@ * the remote uid as root. */ temporarily_use_uid(pw); - if (connect(sock, ai->ai_addr, ai->ai_addrlen) >= 0) { + if (timeout_connect(sock, ai->ai_addr, ai->ai_addrlen, + connection_timeout) >= 0) { /* Successful connection. */ memcpy(hostaddr, ai->ai_addr, ai->ai_addrlen); restore_uid(); --- openssh-3.0.1p1/sshconnect.h.ORIG Sat Nov 17 22:49:09 2001 +++ openssh-3.0.1p1/sshconnect.h Sat Nov 17 22:49:47 2001 @@ -28,7 +28,7 @@ int ssh_connect(const char *, struct sockaddr_storage *, u_short, int, int, - int, struct passwd *, const char *); + int, int, struct passwd *, const char *); void ssh_login(Key **, int, const char *, struct sockaddr *, struct passwd *); From CLAD at chevrontexaco.com Sun Nov 18 10:16:03 2001 From: CLAD at chevrontexaco.com (Ladner, Eric (CLAD)) Date: Sat, 17 Nov 2001 15:16:03 -0800 Subject: passphrase quality Message-ID: <8F88657F29DFD11189ED0008C728C6B0078AAA2C@nor935-msx6.nor.chevron.com> I think the responses to the original email are missing his topic as he stated it. He was asking for ssh to comment on the quality of your passphrase when you create it, i.e something like this (fictionalized) $ ssh-keygen Enter passphrase: My1Big2$Long3_Passphrase ssh: on a scale of 1 to 10, your phassprhase ranks a 10! (it's got capitals, special chars, numbers, lowercase, etc..) $ ssh-keygen Enter passphrase: short ssh: on a scale of 1 to 10, your passphrase ranks a 2! (dictinoary word) -----Original Message----- From: Steve VanDevender [mailto:stevev at darkwing.uoregon.edu] Sent: Friday, November 16, 2001 4:36 PM To: Darren Moffat Cc: mouring at etoh.eviladmin.org; openssh-unix-dev at mindrot.org Subject: Re: passphrase quality Darren Moffat writes: > >No. ssh-keygen should never be pamifed. It is worthless to do so. > > > >If we are going to enforce passphrase quality it should be for all OSes. > >The world does not revolve around Linux. No matter what the press may > >think. > > The Linux community didn't invent PAM, Sun did. Many more systems > than Linux have PAM, Solaris, HP-UX some BSDs for a start. > > Having said that I agree with the comment ssh-keygen shouldn't be pamified, > what you might want to do though is follow the pam model and have a > pluggable set of rules that guide a user into choosing a good passphrase. It occurs to me that hooking cracklib into ssh-keygen might be a more generically useful approach, as it could be done even on systems that don't have PAM and cracklib seems to be reasonably portable and flexible. From gert at greenie.muc.de Sun Nov 18 11:28:23 2001 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 18 Nov 2001 01:28:23 +0100 Subject: ssh -2 and hostbasedauth In-Reply-To: <01Nov17.131451edt.453147-12382@jane.cs.toronto.edu>; from Dan Astoorian on Sat, Nov 17, 2001 at 01:14:47PM -0500 References: <01Nov17.131451edt.453147-12382@jane.cs.toronto.edu> Message-ID: <20011118012823.B10229@greenie.muc.de> Hi, On Sat, Nov 17, 2001 at 01:14:47PM -0500, Dan Astoorian wrote: > Moreover, perhaps existing instances of packet_send_debug()--such as the > "accepted by .shosts" message previously discussed--be reevaluated for > the appropriateness and necessity of the information they disclose. I find it VERY useful to see why things are not working as expected. There are too many things that can be wrong if ".shosts doesn't work" (hostbased auth off, rhosts being ignored, key not known, key not known with full host name, wrong protocol being used for known key (RSA/DSA) etc). I can see the argument about disclosing information (which not-to-do is one of the mantras of security), but I'm not really sure why this would give a hacker advantage, unless he has already access to the box, like write-access-over-NFS-on-$HOME or so. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de From djast at cs.toronto.edu Mon Nov 19 02:55:13 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Sun, 18 Nov 2001 10:55:13 -0500 Subject: ssh -2 and hostbasedauth In-Reply-To: Your message of "Sat, 17 Nov 2001 19:28:23 EST." <20011118012823.B10229@greenie.muc.de> Message-ID: <01Nov18.105515edt.453155-12382@jane.cs.toronto.edu> On Sat, 17 Nov 2001 19:28:23 EST, Gert Doering writes: > > I can see the argument about disclosing information (which not-to-do is > one of the mantras of security), but I'm not really sure why this would > give a hacker advantage, unless he has already access to the box, like > write-access-over-NFS-on-$HOME or so. Verifying which hosts are in a user's .shosts file might give a potential attacker hints about which host(s) to concentrate efforts on. Suppose I'm targeting your account specifically, and I'm in a position to sniff traffic and spoof at the IP level (which, unlike NFS-on-$HOME, is an attack vector SSH is specifically designed to be a countermeasure against). I might watch a couple of thousand different hosts making SSH connections to "greenie.muc.de," a few of which might be for "gert at greenie.muc.de," but most of which (let's say) are from other users of the machine. If I can find out via IP spoofing that your account trusts user "gert" (or "gdoering," or any other username I might be able to predict) on one of those hosts in particular--say, "gert at example.org", I might spend more time trying to get root on example.org, or to find some other way to acquire its host key. (In the specific case of .shosts, I'm not certain how much information can already be deduced at the protocol level: if it's the case that the server doesn't even issue the host key challenge unless an shosts.equiv or .shosts check has succeeded--and I admit I haven't yet investigated whether this is or should be the case--then the client would already have this information with or without the debug message.) -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From benefit at egyptcat.com Mon Nov 19 10:09:05 2001 From: benefit at egyptcat.com (Solutions.Net) Date: Mon, 19 Nov 2001 01:09:05 +0200 Subject: super pc ofeer Message-ID: <01c801c17086$8c4efd40$0100007f@hisham> Take Advantage of this very special offer and contact us NOW! TEL: +2 (02) 3047526 / 3452788 +2 (012) 313 5814 (012) 390 0007 Email: benefit at egyptcat.com Solutions Dot Net : ????? ????? ????????? : ????? ????? ????????? : ??? ??? 12 ????: ????? ?????? ?????? ????? ????????? : ????? ?????? ????? ??? ???????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011119/117eb2a9/attachment.html From sturle.sunde at usit.uio.no Mon Nov 19 14:26:59 2001 From: sturle.sunde at usit.uio.no (Sturle Sunde) Date: 19 Nov 2001 04:26:59 +0100 Subject: X11 cookies and forwarding (fwd) In-Reply-To: <01Nov15.172011edt.453144-10639@jane.cs.toronto.edu> References: <01Nov15.172011edt.453144-10639@jane.cs.toronto.edu> Message-ID: Dan Astoorian writes: > If the NFS traffic for $HOME can be sniffed, it can probably be spoofed, > and an attacker can simply write his own keys into > $HOME/.ssh/authorized_keys, $HOME/.shosts, or a similar sensitive > location, or to steal the (_hopefully_ password-protected) private key > file and attack the passphrase with brute force. It was not > unreasonable for OpenSSH to make the simplifying assumption that > $HOME/.ssh can be trusted. I agree on the assumption that $HOME must be trusted. I also agree that NFS should _not_ be trusted. But there are lots of hosts out there which I trust, that don't mount user $HOMEs. Either because I don't trust the network path between them enough to use NFS, or because the machine isn't intended for general use. Is there an easy way to get secure X11-Forwarding between a workstation and a host without a writeable $HOME? Idealy this should be simpler than "xhost +", because a very common kind of users (one born every minute) always choose the easiest solution. -- Sturle All eyes were on Ford Prefect. Some of them were on stalks. ~~~~~~ -- Douglas Adams, So long, and thanks for all the fish From jmknoble at pobox.com Mon Nov 19 17:14:20 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 19 Nov 2001 01:14:20 -0500 Subject: Did i miss the 3.0.1p1 announcement? Message-ID: <20011119011420.B32236@zax.half.pint-stowp.cx> ... or am i just not subscribed to the right mailing list? http://freshmeat.net/releases/62461/ -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 262 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011119/5528a0b4/attachment.bin From jaysonh at oanet.com Mon Nov 19 19:56:19 2001 From: jaysonh at oanet.com (Jayson Henkel) Date: 19 Nov 2001 01:56:19 -0700 Subject: Explanation of this data Message-ID: <1006160180.640.2.camel@xerxes> Could someone explain the relevance this might have? I found this file as part of a root kit coupled with a modified version of either luckscan or its ancestor the statd scanner. The scanner calls a mysterious progam called x. It is scanning port 22. The file was called targets and obviously looks to be at least header information. The hex is what I'm not sure of. Handshaking data? I'd like someone to comment asap. Thank you, -=Jayson=- here is the contents of targets pardon the word wrap there's only 3 lines to the file. Small - SSH-1.5-1.2.27,0x08070000,0x08184000,0x00000004,0x00010004,0x00000000,0x 08400000,0x7a,0x0805,0 Small - SSH-1.99-OpenSSH_2.2.0p1,0x08180000,0x08184000,0x00000004,0x00010004,0x0 0000000,0x08400000,0x96,0x0805,0 Big - SSH-1.99-OpenSSH_2.2.0p1,0x080b0000,0x08184000,0x37f8c00c,0x4011000c,0x401 1000c,0x4019000c,0x96,0x0805,1 From openssh at openbsd.org Tue Nov 20 03:13:02 2001 From: openssh at openbsd.org (openssh at openbsd.org) Date: Mon, 19 Nov 2001 17:13:02 +0100 Subject: OpenSSH 3.0.1 Message-ID: <20011119171302.A28270@folly> OpenSSH 3.0.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== A security hole that may allow an attacker to authenticate if -- and only if -- the administrator has enabled KerberosV. By default, OpenSSH KerberosV support only becomes active after KerberosV has been properly configured. An excessive memory clearing bug (which we believe to be unexploitable) also exists, but since this may cause daemon crashes, we are providing a fix as well. Various other non-critical fixes (~& support and more). OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From openssh at openbsd.org Tue Nov 20 03:13:02 2001 From: openssh at openbsd.org (openssh at openbsd.org) Date: Mon, 19 Nov 2001 11:13:02 -0500 Subject: OpenSSH 3.0.1 Message-ID: <20011119171302.A28270@folly> OpenSSH 3.0.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support and encouragement. Important Changes: ================== A security hole that may allow an attacker to authenticate if -- and only if -- the administrator has enabled KerberosV. By default, OpenSSH KerberosV support only becomes active after KerberosV has been properly configured. An excessive memory clearing bug (which we believe to be unexploitable) also exists, but since this may cause daemon crashes, we are providing a fix as well. Various other non-critical fixes (~& support and more). OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From scott.burch at camberwind.com Tue Nov 20 04:01:01 2001 From: scott.burch at camberwind.com (Scott Burch) Date: Mon, 19 Nov 2001 11:01:01 -0600 Subject: openssh password expiration problem References: <139EE72D26C0D411845F00508BF9398E02B4F2B0@msxg2mtl1.hydro.qc.ca> Message-ID: <001a01c1711b$c6b941d0$f24318ac@ent.core.medtronic.com> openssh password expiration problemPatrick, Indeed password aging does not work with OpenSSH 3.0.1p1 on Solaris 2.6. >From what I can tell something is different with Solaris 2.6 and Solaris 2.8. I know that password expiration doesn't cause a problem on Solaris8. I'm unclear as to whether the problem is with OpenSSH code or Solaris. All I know is that the latest PAM patches are not what fix the problem, even on Solaris8. As I said before I did not have the latest PAM patches on my Solaris 8 compile box and password aging worked fine. I am not clear as to what on Solaris 8 allows this to work. So, in summary, there has not been a resolution to this problem....at least not one that works without mucking with the shadow file, etc. -Scott ----- Original Message ----- From: Gilbert.Patrick at hydro.qc.ca To: scott.burch at camberwind.com Sent: Monday, November 19, 2001 10:28 AM Subject: openssh password expiration problem Hi scott, I've been following your thread for the problem with expired passwords and openssh 3.0.1p1. We are in the same boat. Seems it's broken on 2.6, I haven't gotten it to work. Have you had any luck whatsoever? Cheers, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011119/5fcdf26f/attachment.html From sxw at dcs.ed.ac.uk Tue Nov 20 04:01:13 2001 From: sxw at dcs.ed.ac.uk (Simon Wilkinson) Date: Mon, 19 Nov 2001 17:01:13 GMT Subject: Kerberos V patches for OpenSSH Message-ID: <200111191701.RAA21220@canna.dcs.ed.ac.uk> Is there any interest in integrating the set of patches I recently posted to enable the Kerberos V support for protocol version 1? Cheers, Simon. From ed at UDel.Edu Tue Nov 20 04:20:39 2001 From: ed at UDel.Edu (Ed Phillips) Date: Mon, 19 Nov 2001 12:20:39 -0500 (EST) Subject: openssh password expiration problem In-Reply-To: <001a01c1711b$c6b941d0$f24318ac@ent.core.medtronic.com> Message-ID: On Mon, 19 Nov 2001, Scott Burch wrote: > Date: Mon, 19 Nov 2001 11:01:01 -0600 > From: Scott Burch > To: Gilbert.Patrick at hydro.qc.ca > Cc: OpenSSH Development > Subject: Re: openssh password expiration problem > > openssh password expiration problemPatrick, > > Indeed password aging does not work with OpenSSH 3.0.1p1 on Solaris > 2.6. >From what I can tell something is different with Solaris 2.6 and > Solaris 2.8. I know that password expiration doesn't cause a problem > on Solaris8. I'm unclear as to whether the problem is with OpenSSH > code or Solaris. All I know is that the latest PAM patches are not > what fix the problem, even on Solaris8. As I said before I did not > have the latest PAM patches on my Solaris 8 compile box and password > aging worked fine. I am not clear as to what on Solaris 8 allows this > to work. So, in summary, there has not been a resolution to this > problem....at least not one that works without mucking with the shadow > file, etc. It would seem that we need someone to help us who knows what is different with pam_unix.so and/or libpam.so between Sol2.6 and Sol8. The expired password problem on 2.6, I'd guess, is a result of fixes in Sol8 that never got back-ported to 2.6. I'll keep looking, but I still haven't found anything that would solve the problem... Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From tim at mcgarry.ch Tue Nov 20 06:29:14 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Mon, 19 Nov 2001 20:29:14 +0100 Subject: passphrase quality References: <8F88657F29DFD11189ED0008C728C6B0078AAA2C@nor935-msx6.nor.chevron.com> Message-ID: <002f01c17130$7a2e2d20$c802a8c0@cablecom.ch> This is exactly what I want, obviously anybody can build there passphases, on another ssh version, and I can't stop that. I'm assuming that if they've got enough noodles to do that, then they probably understand the importance of a good pass-phrase. I just want some sort of prompt for novice ssh users that says as in the example below. $ ssh-keygen Enter passphrase: short ssh: your password quality your passphrase quality is 60%, would you like to re-enter a different passphrase (Y/n) Enter passphase: BitBetter your passphrase quality is 80%, would you like to re-enter a different passphrase (Y/n) Enter passphase: VielB Esserm Ultil Ingual your passphrase quality is 95%, would you like to re-enter a different passphrase (Y/n) Re-Enter passphase: VielB Esserm Ultil Ingual I dont really see the need to use crack or any other dictionary lookups, I just want to stop users choosing simple one word passphrases without being warned, of the dangers. Obviously, this sort of check is not for everyone, it should probably be either fixed at compile time or in ssh_config, or (perhaps a flag) My preferred choice would be to make it available as a flag in ssh_config. WeakPassPhrase={ALLOW|WARN|DENY} Once the quality is over 90% the default choice should be to accept it, obviously there's no point in annoying people by reading the pass-phrase a second time until the quality level has been accepted. Tim McGarry ----- Original Message ----- From: "Ladner, Eric (CLAD)" To: Sent: Sunday, November 18, 2001 12:16 AM Subject: RE: passphrase quality > I think the responses to the original email are missing his topic > as he stated it. > > He was asking for ssh to comment on the quality of your passphrase > when you create it, i.e something like this (fictionalized) > > $ ssh-keygen > Enter passphrase: My1Big2$Long3_Passphrase > ssh: on a scale of 1 to 10, your phassprhase ranks a 10! > (it's got capitals, special chars, numbers, lowercase, etc..) > > $ ssh-keygen > Enter passphrase: short > ssh: on a scale of 1 to 10, your passphrase ranks a 2! > (dictinoary word) > > > > -----Original Message----- > From: Steve VanDevender [mailto:stevev at darkwing.uoregon.edu] > Sent: Friday, November 16, 2001 4:36 PM > To: Darren Moffat > Cc: mouring at etoh.eviladmin.org; openssh-unix-dev at mindrot.org > Subject: Re: passphrase quality > > > Darren Moffat writes: > > >No. ssh-keygen should never be pamifed. It is worthless to do so. > > > > > >If we are going to enforce passphrase quality it should be for all OSes. > > >The world does not revolve around Linux. No matter what the press may > > >think. > > > > The Linux community didn't invent PAM, Sun did. Many more systems > > than Linux have PAM, Solaris, HP-UX some BSDs for a start. > > > > Having said that I agree with the comment ssh-keygen shouldn't be > pamified, > > what you might want to do though is follow the pam model and have a > > pluggable set of rules that guide a user into choosing a good passphrase. > > It occurs to me that hooking cracklib into ssh-keygen might be a more > generically useful approach, as it could be done even on systems that > don't have PAM and cracklib seems to be reasonably portable and flexible. > > From djm at mindrot.org Tue Nov 20 09:29:45 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Nov 2001 09:29:45 +1100 (EST) Subject: passphrase quality In-Reply-To: <002f01c17130$7a2e2d20$c802a8c0@cablecom.ch> Message-ID: On Mon, 19 Nov 2001, Tim McGarry wrote: > This is exactly what I want, obviously anybody can build there passphases, > on another ssh version, and I can't stop that. I'm assuming that if they've > got enough noodles to do that, then they probably understand the importance > of a good pass-phrase. I just want some sort of > prompt for novice ssh users that says as in the example below. > > $ ssh-keygen > Enter passphrase: short > ssh: your password quality > your passphrase quality is 60%, would you like to re-enter a different A couple of problems: 1. Any "percentage" measure is going to be subjective and misleading, what you need is an estimate of entropy. 2. Estimating entropy is hard - you can pretty easily get an upper bound on how much entropy is in an arbitrary string of bits (using statistical tests), but is is practically impossible to get a lower bound - which is what you want. 3. This bloats OpenSSH. 4. If you are really interested in protecting your private keys - check out OpenSSH's smartcard support :) -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From josb at cncdsl.com Tue Nov 20 12:01:58 2001 From: josb at cncdsl.com (Jos Backus) Date: Mon, 19 Nov 2001 17:00:58 -0801 Subject: Patch: 3.0.1p1: rename a conflicting variable Message-ID: <20011120010120.GC25291@lizzy.bugworks.com> These patches are against 3.0.1p1. I need them because I have a local mod which needs access to the ServerOptions struct named ``options'', hence the rename. --- auth-rsa.c.orig Mon Nov 19 16:54:01 2001 +++ auth-rsa.c Mon Nov 19 16:56:18 2001 @@ -180,8 +180,7 @@ * user really has the corresponding private key. */ while (fgets(line, sizeof(line), f)) { - char *cp; - char *options; + char *cp, *optionsp; linenum++; @@ -199,7 +198,7 @@ */ if (*cp < '0' || *cp > '9') { int quoted = 0; - options = cp; + optionsp = cp; for (; *cp && (quoted || (*cp != ' ' && *cp != '\t')); cp++) { if (*cp == '\\' && cp[1] == '"') cp++; /* Skip both */ @@ -207,7 +206,7 @@ quoted = !quoted; } } else - options = NULL; + optionsp = NULL; /* Parse the key from the line. */ if (!auth_rsa_read_key(&cp, &bits, pk->e, pk->n)) { @@ -232,7 +231,7 @@ * If our options do not allow this key to be used, * do not send challenge. */ - if (!auth_parse_options(pw, options, file, linenum)) + if (!auth_parse_options(pw, optionsp, file, linenum)) continue; /* Perform the challenge-response dialog for this key. */ --- auth2.c.orig Mon Nov 19 16:54:10 2001 +++ auth2.c Mon Nov 19 16:55:18 2001 @@ -691,7 +691,7 @@ found = key_new(key->type); while (fgets(line, sizeof(line), f)) { - char *cp, *options = NULL; + char *cp, *optionsp = NULL; linenum++; /* Skip leading whitespace, empty and comment lines. */ for (cp = line; *cp == ' ' || *cp == '\t'; cp++) @@ -703,7 +703,7 @@ /* no key? check if there are options for this key */ int quoted = 0; debug2("user_key_allowed: check options: '%s'", cp); - options = cp; + optionsp = cp; for (; *cp && (quoted || (*cp != ' ' && *cp != '\t')); cp++) { if (*cp == '\\' && cp[1] == '"') cp++; /* Skip both */ @@ -720,7 +720,7 @@ } } if (key_equal(found, key) && - auth_parse_options(pw, options, file, linenum) == 1) { + auth_parse_options(pw, optionsp, file, linenum) == 1) { found_key = 1; debug("matching key found: file %s, line %lu", file, linenum); Thanks, -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; From dnewman at maraudingpirates.org Tue Nov 20 12:04:50 2001 From: dnewman at maraudingpirates.org (David F. Newman) Date: Mon, 19 Nov 2001 20:04:50 -0500 (EST) Subject: solaris and Remote Port Forwarding Message-ID: Hello, I just upgraded from 2.9p2 to 3.0.1p1 and good news. I don't have to patch channels.c to get Remote Port Forwarding to work. That is fantastic. It appears, however, that -g still doesn't work. I checked the archives and it doesn't look like anyone has mentioned it yet. What does work is if I ssh to a machine I can telnet to localhost on the forwarded port, but connecting to the remote host on the forwarded port from another host doesn't work. netstat -a reveils: localhost.4000 *.* 0 0 0 0 LISTEN so it is still just binding to localhost instead of INADDR_ANY. p.s. This first test was on Solaris 2.6 sparc, and I am about to rebuild on Solaris 7 and 8, but I don't expect different results. -- David F. Newman UNIX Administrator dnewman at maraudingpirates.org From austin at coremetrics.com Tue Nov 20 12:15:00 2001 From: austin at coremetrics.com (Austin Gonyou) Date: 19 Nov 2001 19:15:00 -0600 Subject: solaris and Remote Port Forwarding In-Reply-To: References: Message-ID: <1006218900.17324.5.camel@UberGeek> As far as I understand it, that behaviour is correct. On Mon, 2001-11-19 at 19:04, David F. Newman wrote: > Hello, > I just upgraded from 2.9p2 to 3.0.1p1 and good news. I don't have to > patch channels.c to get Remote Port Forwarding to work. That is > fantastic. > > It appears, however, that -g still doesn't work. I checked the archives > and it doesn't look like anyone has mentioned it yet. > > What does work is if I ssh to a machine I can telnet to localhost on > the forwarded port, but connecting to the remote host on the forwarded > port from another host doesn't work. > > netstat -a reveils: > localhost.4000 *.* 0 0 0 0 > LISTEN > > so it is still just binding to localhost instead of INADDR_ANY. > > p.s. This first test was on Solaris 2.6 sparc, and I am about to rebuild > on Solaris 7 and 8, but I don't expect different results. > > -- > David F. Newman > UNIX Administrator > dnewman at maraudingpirates.org > -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-796-9023 email: austin at coremetrics.com From stevesk at pobox.com Tue Nov 20 12:42:13 2001 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 19 Nov 2001 17:42:13 -0800 (PST) Subject: solaris and Remote Port Forwarding In-Reply-To: Message-ID: On Mon, 19 Nov 2001, David F. Newman wrote: :I just upgraded from 2.9p2 to 3.0.1p1 and good news. I don't have to :patch channels.c to get Remote Port Forwarding to work. That is :fantastic. : :It appears, however, that -g still doesn't work. I checked the archives :and it doesn't look like anyone has mentioned it yet. ssh -g is for local forwards. look at sshd GatewayPorts. the documentation was clarified for 2.9.9/3.0: GatewayPorts Specifies whether remote hosts are allowed to connect to ports forwarded for the client. By default, sshd binds remote port forwardings to the loopback addresss. This prevents other remote hosts from connecting to forwarded ports. GatewayPorts can be used to specify that sshd should bind remote port forwardings to the wildcard address, thus allowing remote hosts to connect to forwarded ports. The argument must be ``yes'' or ``no''. The de- fault is ``no''. From dnewman at maraudingpirates.org Tue Nov 20 14:48:09 2001 From: dnewman at maraudingpirates.org (David F. Newman) Date: Mon, 19 Nov 2001 22:48:09 -0500 (EST) Subject: solaris and Remote Port Forwarding In-Reply-To: Message-ID: On Mon, 19 Nov 2001, Kevin Steves wrote: > ssh -g is for local forwards. > > look at sshd GatewayPorts. the documentation was clarified for 2.9.9/3.0: > Ahhh, I see. I actually read that as local to the side that was doing the port forwarding, as opposed to strictly the ssh client side. Cool beans. -Dave From holger.trapp at hrz.tu-chemnitz.de Tue Nov 20 18:19:08 2001 From: holger.trapp at hrz.tu-chemnitz.de (Holger Trapp) Date: Tue, 20 Nov 2001 08:19:08 +0100 (MET) Subject: problem with AFS token forwarding Message-ID: Hello, I came across an interoperability problem in OpenSSH 3.0p1 and 3.0.1p1 concerning the AFS token forwarding. That means that the new versions are not able to exchange AFS tokens (and Kerberos TGTs) with older OpenSSH releases (including 2.9p2) and with the old SSH 1.2.2x. In my opinion this problem already existed in Openssh 2.9.9p1, but I have never used this version (I only looked at the source code when trying to find the reason for the problem). I already reported this problem to Markus Friedl (in German) and he gave me the advice to report it to openssh-unix-dev at mindrot.org. The reason for the problem is a reorganization of the source code. In older OpenSSH versions the token was forwarded after the server had authenticated to the client but BEFORE any user authentication. And I think this is OK. The client knows that the server is authentic and can send all tokens it has. This has the advantage that the server can use these tokens and can access files in the AFS home directory of the user on the server. In the latest OpenSSH releases the token is only forwarded AFTER a successful user authentication. That means that the older servers are in function do_authenticated1() when the message of type 65 (SSH_CMSG_HAVE_AFS_TOKEN) arrives. This message is no longer accepted at this point. Therefore the error message Unknown packet type received after authentication: 65 is to be found in the server logs. It would be very helpful for us if the next OpenSSH release would solve this interoperability problem because we still have some older SSH installations. And as I wrote above we think it is the right way to forward the token before the user authentication so that OpenSSH can e.g. access $HOME/.ssh/authorized_keys in an AFS home directory. Additionally I'd like to ask a question. Is it planned for future OpenSSH releases to make AFS token and Kerberos TGT forwarding available for version 2 of the SSH protocol as well? At least for our site (where AFS is used very heavily) this would be a very helpful feature. Cheers, Holger From serge.droz at psi.ch Tue Nov 20 18:31:43 2001 From: serge.droz at psi.ch (Serge Droz) Date: Tue, 20 Nov 2001 08:31:43 +0100 Subject: problem with AFS token forwarding References: Message-ID: <3BFA06DF.9A4AD658@psi.ch> The attached patch solves this problem. It addes the option AFSPassTokenBeforeAuth to the sshd_config and ssh_config files which reintroduced the old behaviour when set to yes (It's off by default). There seems to be some disagreement on when tokens should be passed, I guess with both sides having valid points. With this option the admin can choose when to pass them. Unfortunately the patch dosen't seem to make it's way into the distribution. Anyway, here it is. Regards Serge -- Serge Droz Paul Scherrer Institut mailto:serge.droz at psi.ch CH-5232 Villigen PSI Phone: ++41 56 310 3637 Fax: ++41 56 310 3649 -------------- next part -------------- diff -Nur openssh-3.0.1p1.orig/auth1.c openssh-3.0.1p1/auth1.c --- openssh-3.0.1p1.orig/auth1.c Tue Nov 13 13:46:19 2001 +++ openssh-3.0.1p1/auth1.c Mon Nov 19 10:02:32 2001 @@ -114,6 +114,24 @@ /* Process the packet. */ switch (type) { +#ifdef AFS + case SSH_CMSG_HAVE_AFS_TOKEN: + if ( options.afs_pass_token_before_auth ) { + if (!options.afs_token_passing || !k_hasafs()) { + verbose("AFS token passing disabled."); + break; + } else { + /* Accept AFS token. */ + char *token_string = packet_get_string(&dlen); + packet_integrity_check(plen, 4 + dlen, type); + if (!auth_afs_token(authctxt, token_string)) + verbose("AFS token REFUSED for %.100s", authctxt->user); + xfree(token_string); + } + } else packet_send_debug("AFS token passing disabled before authentication."); + break; +#endif /* AFS */ + #if defined(KRB4) || defined(KRB5) case SSH_CMSG_AUTH_KERBEROS: if (!options.kerberos_authentication) { @@ -162,11 +180,11 @@ case SSH_CMSG_HAVE_KERBEROS_TGT: packet_send_debug("Kerberos TGT passing disabled before authentication."); break; -#ifdef AFS - case SSH_CMSG_HAVE_AFS_TOKEN: - packet_send_debug("AFS token passing disabled before authentication."); - break; -#endif /* AFS */ +//#ifdef AFS +// case SSH_CMSG_HAVE_AFS_TOKEN: +// packet_send_debug("AFS token passing disabled before authentication."); +// break; +//#endif /* AFS */ #endif /* AFS || KRB5 */ case SSH_CMSG_AUTH_RHOSTS: diff -Nur openssh-3.0.1p1.orig/auth1.c.orig openssh-3.0.1p1/auth1.c.orig --- openssh-3.0.1p1.orig/auth1.c.orig Thu Jan 1 01:00:00 1970 +++ openssh-3.0.1p1/auth1.c.orig Tue Nov 13 13:46:19 2001 @@ -0,0 +1,429 @@ +/* + * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland + * All rights reserved + * + * As far as I am concerned, the code I have written for this software + * can be used freely for any purpose. Any derived versions of this + * software must be clearly marked as such, and if the derived work is + * incompatible with the protocol description in the RFC file, it must be + * called by a name other than "ssh" or "Secure Shell". + */ + +#include "includes.h" +RCSID("$OpenBSD: auth1.c,v 1.25 2001/06/26 16:15:23 dugsong Exp $"); + +#include "xmalloc.h" +#include "rsa.h" +#include "ssh1.h" +#include "packet.h" +#include "buffer.h" +#include "mpaux.h" +#include "log.h" +#include "servconf.h" +#include "compat.h" +#include "auth.h" +#include "session.h" +#include "misc.h" +#include "uidswap.h" + +/* import */ +extern ServerOptions options; + +/* + * convert ssh auth msg type into description + */ +static char * +get_authname(int type) +{ + static char buf[1024]; + switch (type) { + case SSH_CMSG_AUTH_PASSWORD: + return "password"; + case SSH_CMSG_AUTH_RSA: + return "rsa"; + case SSH_CMSG_AUTH_RHOSTS_RSA: + return "rhosts-rsa"; + case SSH_CMSG_AUTH_RHOSTS: + return "rhosts"; + case SSH_CMSG_AUTH_TIS: + case SSH_CMSG_AUTH_TIS_RESPONSE: + return "challenge-response"; +#if defined(KRB4) || defined(KRB5) + case SSH_CMSG_AUTH_KERBEROS: + return "kerberos"; +#endif + } + snprintf(buf, sizeof buf, "bad-auth-msg-%d", type); + return buf; +} + +/* + * read packets, try to authenticate the user and + * return only if authentication is successful + */ +static void +do_authloop(Authctxt *authctxt) +{ + int authenticated = 0; + u_int bits; + RSA *client_host_key; + BIGNUM *n; + char *client_user, *password; + char info[1024]; + u_int dlen; + int plen, nlen, elen; + u_int ulen; + int type = 0; + struct passwd *pw = authctxt->pw; + + debug("Attempting authentication for %s%.100s.", + authctxt->valid ? "" : "illegal user ", authctxt->user); + + /* If the user has no password, accept authentication immediately. */ + if (options.password_authentication && +#if defined(KRB4) || defined(KRB5) + (!options.kerberos_authentication || options.kerberos_or_local_passwd) && +#endif +#ifdef USE_PAM + auth_pam_password(pw, "")) { +#elif defined(HAVE_OSF_SIA) + 0) { +#else + auth_password(authctxt, "")) { +#endif + auth_log(authctxt, 1, "without authentication", ""); + return; + } + + /* Indicate that authentication is needed. */ + packet_start(SSH_SMSG_FAILURE); + packet_send(); + packet_write_wait(); + + client_user = NULL; + + for (;;) { + /* default to fail */ + authenticated = 0; + + info[0] = '\0'; + + /* Get a packet from the client. */ + type = packet_read(&plen); + + /* Process the packet. */ + switch (type) { + +#if defined(KRB4) || defined(KRB5) + case SSH_CMSG_AUTH_KERBEROS: + if (!options.kerberos_authentication) { + verbose("Kerberos authentication disabled."); + } else { + char *kdata = packet_get_string(&dlen); + + packet_integrity_check(plen, 4 + dlen, type); + + if (kdata[0] == 4) { /* KRB_PROT_VERSION */ +#ifdef KRB4 + KTEXT_ST tkt; + + tkt.length = dlen; + if (tkt.length < MAX_KTXT_LEN) + memcpy(tkt.dat, kdata, tkt.length); + + if (auth_krb4(authctxt, &tkt, &client_user)) { + authenticated = 1; + snprintf(info, sizeof(info), + " tktuser %.100s", + client_user); + } +#endif /* KRB4 */ + } else { +#ifdef KRB5 + krb5_data tkt; + tkt.length = dlen; + tkt.data = kdata; + + if (auth_krb5(authctxt, &tkt, &client_user)) { + authenticated = 1; + snprintf(info, sizeof(info), + " tktuser %.100s", + client_user); + } +#endif /* KRB5 */ + } + xfree(kdata); + } + break; +#endif /* KRB4 || KRB5 */ + +#if defined(AFS) || defined(KRB5) + /* XXX - punt on backward compatibility here. */ + case SSH_CMSG_HAVE_KERBEROS_TGT: + packet_send_debug("Kerberos TGT passing disabled before authentication."); + break; +#ifdef AFS + case SSH_CMSG_HAVE_AFS_TOKEN: + packet_send_debug("AFS token passing disabled before authentication."); + break; +#endif /* AFS */ +#endif /* AFS || KRB5 */ + + case SSH_CMSG_AUTH_RHOSTS: + if (!options.rhosts_authentication) { + verbose("Rhosts authentication disabled."); + break; + } + /* + * Get client user name. Note that we just have to + * trust the client; this is one reason why rhosts + * authentication is insecure. (Another is + * IP-spoofing on a local network.) + */ + client_user = packet_get_string(&ulen); + packet_integrity_check(plen, 4 + ulen, type); + + /* Try to authenticate using /etc/hosts.equiv and .rhosts. */ + authenticated = auth_rhosts(pw, client_user); + + snprintf(info, sizeof info, " ruser %.100s", client_user); + break; + + case SSH_CMSG_AUTH_RHOSTS_RSA: + if (!options.rhosts_rsa_authentication) { + verbose("Rhosts with RSA authentication disabled."); + break; + } + /* + * Get client user name. Note that we just have to + * trust the client; root on the client machine can + * claim to be any user. + */ + client_user = packet_get_string(&ulen); + + /* Get the client host key. */ + client_host_key = RSA_new(); + if (client_host_key == NULL) + fatal("RSA_new failed"); + client_host_key->e = BN_new(); + client_host_key->n = BN_new(); + if (client_host_key->e == NULL || client_host_key->n == NULL) + fatal("BN_new failed"); + bits = packet_get_int(); + packet_get_bignum(client_host_key->e, &elen); + packet_get_bignum(client_host_key->n, &nlen); + + if (bits != BN_num_bits(client_host_key->n)) + verbose("Warning: keysize mismatch for client_host_key: " + "actual %d, announced %d", BN_num_bits(client_host_key->n), bits); + packet_integrity_check(plen, (4 + ulen) + 4 + elen + nlen, type); + + authenticated = auth_rhosts_rsa(pw, client_user, client_host_key); + RSA_free(client_host_key); + + snprintf(info, sizeof info, " ruser %.100s", client_user); + break; + + case SSH_CMSG_AUTH_RSA: + if (!options.rsa_authentication) { + verbose("RSA authentication disabled."); + break; + } + /* RSA authentication requested. */ + n = BN_new(); + packet_get_bignum(n, &nlen); + packet_integrity_check(plen, nlen, type); + authenticated = auth_rsa(pw, n); + BN_clear_free(n); + break; + + case SSH_CMSG_AUTH_PASSWORD: + if (!options.password_authentication) { + verbose("Password authentication disabled."); + break; + } + /* + * Read user password. It is in plain text, but was + * transmitted over the encrypted channel so it is + * not visible to an outside observer. + */ + password = packet_get_string(&dlen); + packet_integrity_check(plen, 4 + dlen, type); + +#ifdef USE_PAM + /* Do PAM auth with password */ + authenticated = auth_pam_password(pw, password); +#elif defined(HAVE_OSF_SIA) + /* Do SIA auth with password */ + authenticated = auth_sia_password(authctxt->user, + password); +#else /* !USE_PAM && !HAVE_OSF_SIA */ + /* Try authentication with the password. */ + authenticated = auth_password(authctxt, password); +#endif /* USE_PAM */ + + memset(password, 0, strlen(password)); + xfree(password); + break; + + case SSH_CMSG_AUTH_TIS: + debug("rcvd SSH_CMSG_AUTH_TIS"); + if (options.challenge_response_authentication == 1) { + char *challenge = get_challenge(authctxt); + if (challenge != NULL) { + debug("sending challenge '%s'", challenge); + packet_start(SSH_SMSG_AUTH_TIS_CHALLENGE); + packet_put_cstring(challenge); + xfree(challenge); + packet_send(); + packet_write_wait(); + continue; + } + } + break; + case SSH_CMSG_AUTH_TIS_RESPONSE: + debug("rcvd SSH_CMSG_AUTH_TIS_RESPONSE"); + if (options.challenge_response_authentication == 1) { + char *response = packet_get_string(&dlen); + debug("got response '%s'", response); + packet_integrity_check(plen, 4 + dlen, type); + authenticated = verify_response(authctxt, response); + memset(response, 'r', dlen); + xfree(response); + } + break; + + default: + /* + * Any unknown messages will be ignored (and failure + * returned) during authentication. + */ + log("Unknown message during authentication: type %d", type); + break; + } +#ifdef BSD_AUTH + if (authctxt->as) { + auth_close(authctxt->as); + authctxt->as = NULL; + } +#endif + if (!authctxt->valid && authenticated) + fatal("INTERNAL ERROR: authenticated invalid user %s", + authctxt->user); + +#ifdef HAVE_CYGWIN + if (authenticated && + !check_nt_auth(type == SSH_CMSG_AUTH_PASSWORD,pw->pw_uid)) { + packet_disconnect("Authentication rejected for uid %d.", + (int)pw->pw_uid); + authenticated = 0; + } +#else + /* Special handling for root */ + if (authenticated && authctxt->pw->pw_uid == 0 && + !auth_root_allowed(get_authname(type))) + authenticated = 0; +#endif +#ifdef USE_PAM + if (authenticated && !do_pam_account(pw->pw_name, client_user)) + authenticated = 0; +#endif + + /* Log before sending the reply */ + auth_log(authctxt, authenticated, get_authname(type), info); + + if (client_user != NULL) { + xfree(client_user); + client_user = NULL; + } + + if (authenticated) + return; + + if (authctxt->failures++ > AUTH_FAIL_MAX) { +#ifdef WITH_AIXAUTHENTICATE + loginfailed(authctxt->user, + get_canonical_hostname(options.reverse_mapping_check), + "ssh"); +#endif /* WITH_AIXAUTHENTICATE */ + packet_disconnect(AUTH_FAIL_MSG, authctxt->user); + } + + packet_start(SSH_SMSG_FAILURE); + packet_send(); + packet_write_wait(); + } +} + +/* + * Performs authentication of an incoming connection. Session key has already + * been exchanged and encryption is enabled. + */ +void +do_authentication() +{ + Authctxt *authctxt; + struct passwd *pw; + int plen; + u_int ulen; + char *p, *user, *style = NULL; + + /* Get the name of the user that we wish to log in as. */ + packet_read_expect(&plen, SSH_CMSG_USER); + + /* Get the user name. */ + user = packet_get_string(&ulen); + packet_integrity_check(plen, (4 + ulen), SSH_CMSG_USER); + + if ((style = strchr(user, ':')) != NULL) + *style++ = '\0'; + + /* XXX - SSH.com Kerberos v5 braindeath. */ + if ((p = strchr(user, '@')) != NULL) + *p = '\0'; + + authctxt = authctxt_new(); + authctxt->user = user; + authctxt->style = style; + + /* Verify that the user is a valid user. */ + pw = getpwnam(user); + if (pw && allowed_user(pw)) { + authctxt->valid = 1; + pw = pwcopy(pw); + } else { + debug("do_authentication: illegal user %s", user); + pw = NULL; + } + authctxt->pw = pw; + + setproctitle("%s", pw ? user : "unknown"); + +#ifdef USE_PAM + if (pw) + start_pam(user); +#endif + + /* + * If we are not running as root, the user must have the same uid as + * the server. (Unless you are running Windows) + */ +#ifndef HAVE_CYGWIN + if (getuid() != 0 && pw && pw->pw_uid != getuid()) + packet_disconnect("Cannot change user when server not running as root."); +#endif + + /* + * Loop until the user has been authenticated or the connection is + * closed, do_authloop() returns only if authentication is successful + */ + do_authloop(authctxt); + + /* The user has been authenticated and accepted. */ + packet_start(SSH_SMSG_SUCCESS); + packet_send(); + packet_write_wait(); + + /* Perform session preparation. */ + do_authenticated(authctxt); +} diff -Nur openssh-3.0.1p1.orig/readconf.c openssh-3.0.1p1/readconf.c --- openssh-3.0.1p1.orig/readconf.c Wed Oct 3 19:39:39 2001 +++ openssh-3.0.1p1/readconf.c Mon Nov 19 10:02:32 2001 @@ -103,7 +103,7 @@ oKerberosTgtPassing, #endif #ifdef AFS - oAFSTokenPassing, + oAFSTokenPassing,oAFSPassTokenBeforeAuth, #endif oIdentityFile, oHostName, oPort, oCipher, oRemoteForward, oLocalForward, oUser, oHost, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand, @@ -149,6 +149,7 @@ #endif #ifdef AFS { "afstokenpassing", oAFSTokenPassing }, + { "afspasstokenbeforeauth", oAFSPassTokenBeforeAuth}, #endif { "fallbacktorsh", oFallBackToRsh }, { "usersh", oUseRsh }, @@ -372,6 +373,9 @@ case oAFSTokenPassing: intptr = &options->afs_token_passing; goto parse_flag; + case oAFSPassTokenBeforeAuth: + intptr = &options->afs_pass_token_before_auth; + goto parse_flag; #endif case oFallBackToRsh: intptr = &options->fallback_to_rsh; @@ -759,6 +763,7 @@ #endif #ifdef AFS options->afs_token_passing = -1; + options->afs_pass_token_before_auth = -1; #endif options->password_authentication = -1; options->kbd_interactive_authentication = -1; @@ -842,6 +847,8 @@ #ifdef AFS if (options->afs_token_passing == -1) options->afs_token_passing = 1; + if (options->afs_pass_token_before_auth == -1) + options->afs_pass_token_before_auth = 0; #endif if (options->password_authentication == -1) options->password_authentication = 1; diff -Nur openssh-3.0.1p1.orig/readconf.h openssh-3.0.1p1/readconf.h --- openssh-3.0.1p1.orig/readconf.h Wed Oct 3 19:39:39 2001 +++ openssh-3.0.1p1/readconf.h Mon Nov 19 10:02:32 2001 @@ -49,6 +49,7 @@ #endif #ifdef AFS int afs_token_passing; /* Try AFS token passing. */ + int afs_pass_token_before_auth; /* Pass Token before Auth. */ #endif int password_authentication; /* Try password * authentication. */ diff -Nur openssh-3.0.1p1.orig/servconf.c openssh-3.0.1p1/servconf.c --- openssh-3.0.1p1.orig/servconf.c Tue Nov 13 14:03:15 2001 +++ openssh-3.0.1p1/servconf.c Mon Nov 19 10:02:32 2001 @@ -84,6 +84,7 @@ #endif #ifdef AFS options->afs_token_passing = -1; + options->afs_pass_token_before_auth = -1; #endif options->password_authentication = -1; options->kbd_interactive_authentication = -1; @@ -193,6 +194,8 @@ #ifdef AFS if (options->afs_token_passing == -1) options->afs_token_passing = k_hasafs(); + if (options->afs_pass_token_before_auth == -1) + options->afs_pass_token_before_auth = 0; #endif if (options->password_authentication == -1) options->password_authentication = 1; @@ -248,6 +251,7 @@ #endif #ifdef AFS sAFSTokenPassing, + sAFSPassTokenBeforeAuth, #endif sChallengeResponseAuthentication, sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress, @@ -299,6 +303,7 @@ #endif #ifdef AFS { "afstokenpassing", sAFSTokenPassing }, + { "afspasstokenbeforeauth", sAFSPassTokenBeforeAuth }, #endif { "passwordauthentication", sPasswordAuthentication }, { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, @@ -635,6 +640,9 @@ #ifdef AFS case sAFSTokenPassing: intptr = &options->afs_token_passing; + goto parse_flag; + case sAFSPassTokenBeforeAuth: + intptr = &options->afs_pass_token_before_auth; goto parse_flag; #endif diff -Nur openssh-3.0.1p1.orig/servconf.c.orig openssh-3.0.1p1/servconf.c.orig --- openssh-3.0.1p1.orig/servconf.c.orig Thu Jan 1 01:00:00 1970 +++ openssh-3.0.1p1/servconf.c.orig Tue Nov 13 14:03:15 2001 @@ -0,0 +1,881 @@ +/* + * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland + * All rights reserved + * + * As far as I am concerned, the code I have written for this software + * can be used freely for any purpose. Any derived versions of this + * software must be clearly marked as such, and if the derived work is + * incompatible with the protocol description in the RFC file, it must be + * called by a name other than "ssh" or "Secure Shell". + */ + +#include "includes.h" +RCSID("$OpenBSD: servconf.c,v 1.91 2001/11/12 18:17:07 markus Exp $"); + +#if defined(KRB4) || defined(KRB5) +#include +#endif +#ifdef AFS +#include +#endif + +#include "ssh.h" +#include "log.h" +#include "servconf.h" +#include "xmalloc.h" +#include "compat.h" +#include "pathnames.h" +#include "tildexpand.h" +#include "misc.h" +#include "cipher.h" +#include "kex.h" +#include "mac.h" + +static void add_listen_addr(ServerOptions *, char *, u_short); +static void add_one_listen_addr(ServerOptions *, char *, u_short); + +/* AF_UNSPEC or AF_INET or AF_INET6 */ +extern int IPv4or6; + +/* Initializes the server options to their default values. */ + +void +initialize_server_options(ServerOptions *options) +{ + memset(options, 0, sizeof(*options)); + + /* Portable-specific options */ + options->pam_authentication_via_kbd_int = -1; + + /* Standard Options */ + options->num_ports = 0; + options->ports_from_cmdline = 0; + options->listen_addrs = NULL; + options->num_host_key_files = 0; + options->pid_file = NULL; + options->server_key_bits = -1; + options->login_grace_time = -1; + options->key_regeneration_time = -1; + options->permit_root_login = PERMIT_NOT_SET; + options->ignore_rhosts = -1; + options->ignore_user_known_hosts = -1; + options->print_motd = -1; + options->print_lastlog = -1; + options->x11_forwarding = -1; + options->x11_display_offset = -1; + options->xauth_location = NULL; + options->strict_modes = -1; + options->keepalives = -1; + options->log_facility = (SyslogFacility) - 1; + options->log_level = (LogLevel) - 1; + options->rhosts_authentication = -1; + options->rhosts_rsa_authentication = -1; + options->hostbased_authentication = -1; + options->hostbased_uses_name_from_packet_only = -1; + options->rsa_authentication = -1; + options->pubkey_authentication = -1; +#if defined(KRB4) || defined(KRB5) + options->kerberos_authentication = -1; + options->kerberos_or_local_passwd = -1; + options->kerberos_ticket_cleanup = -1; +#endif +#if defined(AFS) || defined(KRB5) + options->kerberos_tgt_passing = -1; +#endif +#ifdef AFS + options->afs_token_passing = -1; +#endif + options->password_authentication = -1; + options->kbd_interactive_authentication = -1; + options->challenge_response_authentication = -1; + options->permit_empty_passwd = -1; + options->use_login = -1; + options->allow_tcp_forwarding = -1; + options->num_allow_users = 0; + options->num_deny_users = 0; + options->num_allow_groups = 0; + options->num_deny_groups = 0; + options->ciphers = NULL; + options->macs = NULL; + options->protocol = SSH_PROTO_UNKNOWN; + options->gateway_ports = -1; + options->num_subsystems = 0; + options->max_startups_begin = -1; + options->max_startups_rate = -1; + options->max_startups = -1; + options->banner = NULL; + options->reverse_mapping_check = -1; + options->client_alive_interval = -1; + options->client_alive_count_max = -1; + options->authorized_keys_file = NULL; + options->authorized_keys_file2 = NULL; +} + +void +fill_default_server_options(ServerOptions *options) +{ + /* Portable-specific options */ + if (options->pam_authentication_via_kbd_int == -1) + options->pam_authentication_via_kbd_int = 0; + + /* Standard Options */ + if (options->protocol == SSH_PROTO_UNKNOWN) + options->protocol = SSH_PROTO_1|SSH_PROTO_2; + if (options->num_host_key_files == 0) { + /* fill default hostkeys for protocols */ + if (options->protocol & SSH_PROTO_1) + options->host_key_files[options->num_host_key_files++] = _PATH_HOST_KEY_FILE; + if (options->protocol & SSH_PROTO_2) + options->host_key_files[options->num_host_key_files++] = _PATH_HOST_DSA_KEY_FILE; + } + if (options->num_ports == 0) + options->ports[options->num_ports++] = SSH_DEFAULT_PORT; + if (options->listen_addrs == NULL) + add_listen_addr(options, NULL, 0); + if (options->pid_file == NULL) + options->pid_file = _PATH_SSH_DAEMON_PID_FILE; + if (options->server_key_bits == -1) + options->server_key_bits = 768; + if (options->login_grace_time == -1) + options->login_grace_time = 600; + if (options->key_regeneration_time == -1) + options->key_regeneration_time = 3600; + if (options->permit_root_login == PERMIT_NOT_SET) + options->permit_root_login = PERMIT_YES; + if (options->ignore_rhosts == -1) + options->ignore_rhosts = 1; + if (options->ignore_user_known_hosts == -1) + options->ignore_user_known_hosts = 0; + if (options->print_motd == -1) + options->print_motd = 1; + if (options->print_lastlog == -1) + options->print_lastlog = 1; + if (options->x11_forwarding == -1) + options->x11_forwarding = 0; + if (options->x11_display_offset == -1) + options->x11_display_offset = 10; +#ifdef _PATH_XAUTH + if (options->xauth_location == NULL) + options->xauth_location = _PATH_XAUTH; +#endif + if (options->strict_modes == -1) + options->strict_modes = 1; + if (options->keepalives == -1) + options->keepalives = 1; + if (options->log_facility == (SyslogFacility) (-1)) + options->log_facility = SYSLOG_FACILITY_AUTH; + if (options->log_level == (LogLevel) (-1)) + options->log_level = SYSLOG_LEVEL_INFO; + if (options->rhosts_authentication == -1) + options->rhosts_authentication = 0; + if (options->rhosts_rsa_authentication == -1) + options->rhosts_rsa_authentication = 0; + if (options->hostbased_authentication == -1) + options->hostbased_authentication = 0; + if (options->hostbased_uses_name_from_packet_only == -1) + options->hostbased_uses_name_from_packet_only = 0; + if (options->rsa_authentication == -1) + options->rsa_authentication = 1; + if (options->pubkey_authentication == -1) + options->pubkey_authentication = 1; +#if defined(KRB4) || defined(KRB5) + if (options->kerberos_authentication == -1) + options->kerberos_authentication = (access(KEYFILE, R_OK) == 0); + if (options->kerberos_or_local_passwd == -1) + options->kerberos_or_local_passwd = 1; + if (options->kerberos_ticket_cleanup == -1) + options->kerberos_ticket_cleanup = 1; +#endif +#if defined(AFS) || defined(KRB5) + if (options->kerberos_tgt_passing == -1) + options->kerberos_tgt_passing = 0; +#endif +#ifdef AFS + if (options->afs_token_passing == -1) + options->afs_token_passing = k_hasafs(); +#endif + if (options->password_authentication == -1) + options->password_authentication = 1; + if (options->kbd_interactive_authentication == -1) + options->kbd_interactive_authentication = 0; + if (options->challenge_response_authentication == -1) + options->challenge_response_authentication = 1; + if (options->permit_empty_passwd == -1) + options->permit_empty_passwd = 0; + if (options->use_login == -1) + options->use_login = 0; + if (options->allow_tcp_forwarding == -1) + options->allow_tcp_forwarding = 1; + if (options->gateway_ports == -1) + options->gateway_ports = 0; + if (options->max_startups == -1) + options->max_startups = 10; + if (options->max_startups_rate == -1) + options->max_startups_rate = 100; /* 100% */ + if (options->max_startups_begin == -1) + options->max_startups_begin = options->max_startups; + if (options->reverse_mapping_check == -1) + options->reverse_mapping_check = 0; + if (options->client_alive_interval == -1) + options->client_alive_interval = 0; + if (options->client_alive_count_max == -1) + options->client_alive_count_max = 3; + if (options->authorized_keys_file2 == NULL) { + /* authorized_keys_file2 falls back to authorized_keys_file */ + if (options->authorized_keys_file != NULL) + options->authorized_keys_file2 = options->authorized_keys_file; + else + options->authorized_keys_file2 = _PATH_SSH_USER_PERMITTED_KEYS2; + } + if (options->authorized_keys_file == NULL) + options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; +} + +/* Keyword tokens. */ +typedef enum { + sBadOption, /* == unknown option */ + /* Portable-specific options */ + sPAMAuthenticationViaKbdInt, + /* Standard Options */ + sPort, sHostKeyFile, sServerKeyBits, sLoginGraceTime, sKeyRegenerationTime, + sPermitRootLogin, sLogFacility, sLogLevel, + sRhostsAuthentication, sRhostsRSAAuthentication, sRSAAuthentication, +#if defined(KRB4) || defined(KRB5) + sKerberosAuthentication, sKerberosOrLocalPasswd, sKerberosTicketCleanup, +#endif +#if defined(AFS) || defined(KRB5) + sKerberosTgtPassing, +#endif +#ifdef AFS + sAFSTokenPassing, +#endif + sChallengeResponseAuthentication, + sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress, + sPrintMotd, sPrintLastLog, sIgnoreRhosts, + sX11Forwarding, sX11DisplayOffset, + sStrictModes, sEmptyPasswd, sKeepAlives, + sUseLogin, sAllowTcpForwarding, + sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, + sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, + sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, + sBanner, sReverseMappingCheck, sHostbasedAuthentication, + sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, + sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, + sDeprecated +} ServerOpCodes; + +/* Textual representation of the tokens. */ +static struct { + const char *name; + ServerOpCodes opcode; +} keywords[] = { + /* Portable-specific options */ + { "PAMAuthenticationViaKbdInt", sPAMAuthenticationViaKbdInt }, + /* Standard Options */ + { "port", sPort }, + { "hostkey", sHostKeyFile }, + { "hostdsakey", sHostKeyFile }, /* alias */ + { "pidfile", sPidFile }, + { "serverkeybits", sServerKeyBits }, + { "logingracetime", sLoginGraceTime }, + { "keyregenerationinterval", sKeyRegenerationTime }, + { "permitrootlogin", sPermitRootLogin }, + { "syslogfacility", sLogFacility }, + { "loglevel", sLogLevel }, + { "rhostsauthentication", sRhostsAuthentication }, + { "rhostsrsaauthentication", sRhostsRSAAuthentication }, + { "hostbasedauthentication", sHostbasedAuthentication }, + { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly }, + { "rsaauthentication", sRSAAuthentication }, + { "pubkeyauthentication", sPubkeyAuthentication }, + { "dsaauthentication", sPubkeyAuthentication }, /* alias */ +#if defined(KRB4) || defined(KRB5) + { "kerberosauthentication", sKerberosAuthentication }, + { "kerberosorlocalpasswd", sKerberosOrLocalPasswd }, + { "kerberosticketcleanup", sKerberosTicketCleanup }, +#endif +#if defined(AFS) || defined(KRB5) + { "kerberostgtpassing", sKerberosTgtPassing }, +#endif +#ifdef AFS + { "afstokenpassing", sAFSTokenPassing }, +#endif + { "passwordauthentication", sPasswordAuthentication }, + { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, + { "challengeresponseauthentication", sChallengeResponseAuthentication }, + { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ + { "checkmail", sDeprecated }, + { "listenaddress", sListenAddress }, + { "printmotd", sPrintMotd }, + { "printlastlog", sPrintLastLog }, + { "ignorerhosts", sIgnoreRhosts }, + { "ignoreuserknownhosts", sIgnoreUserKnownHosts }, + { "x11forwarding", sX11Forwarding }, + { "x11displayoffset", sX11DisplayOffset }, + { "xauthlocation", sXAuthLocation }, + { "strictmodes", sStrictModes }, + { "permitemptypasswords", sEmptyPasswd }, + { "uselogin", sUseLogin }, + { "keepalive", sKeepAlives }, + { "allowtcpforwarding", sAllowTcpForwarding }, + { "allowusers", sAllowUsers }, + { "denyusers", sDenyUsers }, + { "allowgroups", sAllowGroups }, + { "denygroups", sDenyGroups }, + { "ciphers", sCiphers }, + { "macs", sMacs }, + { "protocol", sProtocol }, + { "gatewayports", sGatewayPorts }, + { "subsystem", sSubsystem }, + { "maxstartups", sMaxStartups }, + { "banner", sBanner }, + { "reversemappingcheck", sReverseMappingCheck }, + { "clientaliveinterval", sClientAliveInterval }, + { "clientalivecountmax", sClientAliveCountMax }, + { "authorizedkeysfile", sAuthorizedKeysFile }, + { "authorizedkeysfile2", sAuthorizedKeysFile2 }, + { NULL, 0 } +}; + +/* + * Returns the number of the token pointed to by cp or sBadOption. + */ + +static ServerOpCodes +parse_token(const char *cp, const char *filename, + int linenum) +{ + u_int i; + + for (i = 0; keywords[i].name; i++) + if (strcasecmp(cp, keywords[i].name) == 0) + return keywords[i].opcode; + + error("%s: line %d: Bad configuration option: %s", + filename, linenum, cp); + return sBadOption; +} + +static void +add_listen_addr(ServerOptions *options, char *addr, u_short port) +{ + int i; + + if (options->num_ports == 0) + options->ports[options->num_ports++] = SSH_DEFAULT_PORT; + if (port == 0) + for (i = 0; i < options->num_ports; i++) + add_one_listen_addr(options, addr, options->ports[i]); + else + add_one_listen_addr(options, addr, port); +} + +static void +add_one_listen_addr(ServerOptions *options, char *addr, u_short port) +{ + struct addrinfo hints, *ai, *aitop; + char strport[NI_MAXSERV]; + int gaierr; + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = IPv4or6; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = (addr == NULL) ? AI_PASSIVE : 0; + snprintf(strport, sizeof strport, "%d", port); + if ((gaierr = getaddrinfo(addr, strport, &hints, &aitop)) != 0) + fatal("bad addr or host: %s (%s)", + addr ? addr : "", + gai_strerror(gaierr)); + for (ai = aitop; ai->ai_next; ai = ai->ai_next) + ; + ai->ai_next = options->listen_addrs; + options->listen_addrs = aitop; +} + +/* Reads the server configuration file. */ + +void +read_server_config(ServerOptions *options, const char *filename) +{ + FILE *f; + char line[1024]; + char *cp, **charptr, *arg, *p; + int linenum, *intptr, value; + int bad_options = 0; + ServerOpCodes opcode; + int i, n; + + f = fopen(filename, "r"); + if (!f) { + perror(filename); + exit(1); + } + linenum = 0; + while (fgets(line, sizeof(line), f)) { + linenum++; + cp = line; + arg = strdelim(&cp); + /* Ignore leading whitespace */ + if (*arg == '\0') + arg = strdelim(&cp); + if (!arg || !*arg || *arg == '#') + continue; + intptr = NULL; + charptr = NULL; + opcode = parse_token(arg, filename, linenum); + switch (opcode) { + case sBadOption: + bad_options++; + continue; + + /* Portable-specific options */ + case sPAMAuthenticationViaKbdInt: + intptr = &options->pam_authentication_via_kbd_int; + goto parse_flag; + + /* Standard Options */ + case sPort: + /* ignore ports from configfile if cmdline specifies ports */ + if (options->ports_from_cmdline) + continue; + if (options->listen_addrs != NULL) + fatal("%s line %d: ports must be specified before " + "ListenAdress.", filename, linenum); + if (options->num_ports >= MAX_PORTS) + fatal("%s line %d: too many ports.", + filename, linenum); + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing port number.", + filename, linenum); + options->ports[options->num_ports++] = a2port(arg); + if (options->ports[options->num_ports-1] == 0) + fatal("%s line %d: Badly formatted port number.", + filename, linenum); + break; + + case sServerKeyBits: + intptr = &options->server_key_bits; +parse_int: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing integer value.", + filename, linenum); + value = atoi(arg); + if (*intptr == -1) + *intptr = value; + break; + + case sLoginGraceTime: + intptr = &options->login_grace_time; +parse_time: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing time value.", + filename, linenum); + if ((value = convtime(arg)) == -1) + fatal("%s line %d: invalid time value.", + filename, linenum); + if (*intptr == -1) + *intptr = value; + break; + + case sKeyRegenerationTime: + intptr = &options->key_regeneration_time; + goto parse_time; + + case sListenAddress: + arg = strdelim(&cp); + if (!arg || *arg == '\0' || strncmp(arg, "[]", 2) == 0) + fatal("%s line %d: missing inet addr.", + filename, linenum); + if (*arg == '[') { + if ((p = strchr(arg, ']')) == NULL) + fatal("%s line %d: bad ipv6 inet addr usage.", + filename, linenum); + arg++; + memmove(p, p+1, strlen(p+1)+1); + } else if (((p = strchr(arg, ':')) == NULL) || + (strchr(p+1, ':') != NULL)) { + add_listen_addr(options, arg, 0); + break; + } + if (*p == ':') { + u_short port; + + p++; + if (*p == '\0') + fatal("%s line %d: bad inet addr:port usage.", + filename, linenum); + else { + *(p-1) = '\0'; + if ((port = a2port(p)) == 0) + fatal("%s line %d: bad port number.", + filename, linenum); + add_listen_addr(options, arg, port); + } + } else if (*p == '\0') + add_listen_addr(options, arg, 0); + else + fatal("%s line %d: bad inet addr usage.", + filename, linenum); + break; + + case sHostKeyFile: + intptr = &options->num_host_key_files; + if (*intptr >= MAX_HOSTKEYS) + fatal("%s line %d: too many host keys specified (max %d).", + filename, linenum, MAX_HOSTKEYS); + charptr = &options->host_key_files[*intptr]; +parse_filename: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing file name.", + filename, linenum); + if (*charptr == NULL) { + *charptr = tilde_expand_filename(arg, getuid()); + /* increase optional counter */ + if (intptr != NULL) + *intptr = *intptr + 1; + } + break; + + case sPidFile: + charptr = &options->pid_file; + goto parse_filename; + + case sPermitRootLogin: + intptr = &options->permit_root_login; + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing yes/" + "without-password/forced-commands-only/no " + "argument.", filename, linenum); + value = 0; /* silence compiler */ + if (strcmp(arg, "without-password") == 0) + value = PERMIT_NO_PASSWD; + else if (strcmp(arg, "forced-commands-only") == 0) + value = PERMIT_FORCED_ONLY; + else if (strcmp(arg, "yes") == 0) + value = PERMIT_YES; + else if (strcmp(arg, "no") == 0) + value = PERMIT_NO; + else + fatal("%s line %d: Bad yes/" + "without-password/forced-commands-only/no " + "argument: %s", filename, linenum, arg); + if (*intptr == -1) + *intptr = value; + break; + + case sIgnoreRhosts: + intptr = &options->ignore_rhosts; +parse_flag: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing yes/no argument.", + filename, linenum); + value = 0; /* silence compiler */ + if (strcmp(arg, "yes") == 0) + value = 1; + else if (strcmp(arg, "no") == 0) + value = 0; + else + fatal("%s line %d: Bad yes/no argument: %s", + filename, linenum, arg); + if (*intptr == -1) + *intptr = value; + break; + + case sIgnoreUserKnownHosts: + intptr = &options->ignore_user_known_hosts; + goto parse_flag; + + case sRhostsAuthentication: + intptr = &options->rhosts_authentication; + goto parse_flag; + + case sRhostsRSAAuthentication: + intptr = &options->rhosts_rsa_authentication; + goto parse_flag; + + case sHostbasedAuthentication: + intptr = &options->hostbased_authentication; + goto parse_flag; + + case sHostbasedUsesNameFromPacketOnly: + intptr = &options->hostbased_uses_name_from_packet_only; + goto parse_flag; + + case sRSAAuthentication: + intptr = &options->rsa_authentication; + goto parse_flag; + + case sPubkeyAuthentication: + intptr = &options->pubkey_authentication; + goto parse_flag; +#if defined(KRB4) || defined(KRB5) + case sKerberosAuthentication: + intptr = &options->kerberos_authentication; + goto parse_flag; + + case sKerberosOrLocalPasswd: + intptr = &options->kerberos_or_local_passwd; + goto parse_flag; + + case sKerberosTicketCleanup: + intptr = &options->kerberos_ticket_cleanup; + goto parse_flag; +#endif +#if defined(AFS) || defined(KRB5) + case sKerberosTgtPassing: + intptr = &options->kerberos_tgt_passing; + goto parse_flag; +#endif +#ifdef AFS + case sAFSTokenPassing: + intptr = &options->afs_token_passing; + goto parse_flag; +#endif + + case sPasswordAuthentication: + intptr = &options->password_authentication; + goto parse_flag; + + case sKbdInteractiveAuthentication: + intptr = &options->kbd_interactive_authentication; + goto parse_flag; + + case sChallengeResponseAuthentication: + intptr = &options->challenge_response_authentication; + goto parse_flag; + + case sPrintMotd: + intptr = &options->print_motd; + goto parse_flag; + + case sPrintLastLog: + intptr = &options->print_lastlog; + goto parse_flag; + + case sX11Forwarding: + intptr = &options->x11_forwarding; + goto parse_flag; + + case sX11DisplayOffset: + intptr = &options->x11_display_offset; + goto parse_int; + + case sXAuthLocation: + charptr = &options->xauth_location; + goto parse_filename; + + case sStrictModes: + intptr = &options->strict_modes; + goto parse_flag; + + case sKeepAlives: + intptr = &options->keepalives; + goto parse_flag; + + case sEmptyPasswd: + intptr = &options->permit_empty_passwd; + goto parse_flag; + + case sUseLogin: + intptr = &options->use_login; + goto parse_flag; + + case sGatewayPorts: + intptr = &options->gateway_ports; + goto parse_flag; + + case sReverseMappingCheck: + intptr = &options->reverse_mapping_check; + goto parse_flag; + + case sLogFacility: + intptr = (int *) &options->log_facility; + arg = strdelim(&cp); + value = log_facility_number(arg); + if (value == (SyslogFacility) - 1) + fatal("%.200s line %d: unsupported log facility '%s'", + filename, linenum, arg ? arg : ""); + if (*intptr == -1) + *intptr = (SyslogFacility) value; + break; + + case sLogLevel: + intptr = (int *) &options->log_level; + arg = strdelim(&cp); + value = log_level_number(arg); + if (value == (LogLevel) - 1) + fatal("%.200s line %d: unsupported log level '%s'", + filename, linenum, arg ? arg : ""); + if (*intptr == -1) + *intptr = (LogLevel) value; + break; + + case sAllowTcpForwarding: + intptr = &options->allow_tcp_forwarding; + goto parse_flag; + + case sAllowUsers: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_allow_users >= MAX_ALLOW_USERS) + fatal("%s line %d: too many allow users.", + filename, linenum); + options->allow_users[options->num_allow_users++] = xstrdup(arg); + } + break; + + case sDenyUsers: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_deny_users >= MAX_DENY_USERS) + fatal( "%s line %d: too many deny users.", + filename, linenum); + options->deny_users[options->num_deny_users++] = xstrdup(arg); + } + break; + + case sAllowGroups: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_allow_groups >= MAX_ALLOW_GROUPS) + fatal("%s line %d: too many allow groups.", + filename, linenum); + options->allow_groups[options->num_allow_groups++] = xstrdup(arg); + } + break; + + case sDenyGroups: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_deny_groups >= MAX_DENY_GROUPS) + fatal("%s line %d: too many deny groups.", + filename, linenum); + options->deny_groups[options->num_deny_groups++] = xstrdup(arg); + } + break; + + case sCiphers: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing argument.", filename, linenum); + if (!ciphers_valid(arg)) + fatal("%s line %d: Bad SSH2 cipher spec '%s'.", + filename, linenum, arg ? arg : ""); + if (options->ciphers == NULL) + options->ciphers = xstrdup(arg); + break; + + case sMacs: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing argument.", filename, linenum); + if (!mac_valid(arg)) + fatal("%s line %d: Bad SSH2 mac spec '%s'.", + filename, linenum, arg ? arg : ""); + if (options->macs == NULL) + options->macs = xstrdup(arg); + break; + + case sProtocol: + intptr = &options->protocol; + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing argument.", filename, linenum); + value = proto_spec(arg); + if (value == SSH_PROTO_UNKNOWN) + fatal("%s line %d: Bad protocol spec '%s'.", + filename, linenum, arg ? arg : ""); + if (*intptr == SSH_PROTO_UNKNOWN) + *intptr = value; + break; + + case sSubsystem: + if(options->num_subsystems >= MAX_SUBSYSTEMS) { + fatal("%s line %d: too many subsystems defined.", + filename, linenum); + } + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing subsystem name.", + filename, linenum); + for (i = 0; i < options->num_subsystems; i++) + if(strcmp(arg, options->subsystem_name[i]) == 0) + fatal("%s line %d: Subsystem '%s' already defined.", + filename, linenum, arg); + options->subsystem_name[options->num_subsystems] = xstrdup(arg); + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing subsystem command.", + filename, linenum); + options->subsystem_command[options->num_subsystems] = xstrdup(arg); + options->num_subsystems++; + break; + + case sMaxStartups: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: Missing MaxStartups spec.", + filename, linenum); + if ((n = sscanf(arg, "%d:%d:%d", + &options->max_startups_begin, + &options->max_startups_rate, + &options->max_startups)) == 3) { + if (options->max_startups_begin > + options->max_startups || + options->max_startups_rate > 100 || + options->max_startups_rate < 1) + fatal("%s line %d: Illegal MaxStartups spec.", + filename, linenum); + } else if (n != 1) + fatal("%s line %d: Illegal MaxStartups spec.", + filename, linenum); + else + options->max_startups = options->max_startups_begin; + break; + + case sBanner: + charptr = &options->banner; + goto parse_filename; + /* + * These options can contain %X options expanded at + * connect time, so that you can specify paths like: + * + * AuthorizedKeysFile /etc/ssh_keys/%u + */ + case sAuthorizedKeysFile: + case sAuthorizedKeysFile2: + charptr = (opcode == sAuthorizedKeysFile ) ? + &options->authorized_keys_file : + &options->authorized_keys_file2; + goto parse_filename; + + case sClientAliveInterval: + intptr = &options->client_alive_interval; + goto parse_time; + + case sClientAliveCountMax: + intptr = &options->client_alive_count_max; + goto parse_int; + + case sDeprecated: + log("%s line %d: Deprecated option %s", + filename, linenum, arg); + while(arg) + arg = strdelim(&cp); + break; + + default: + fatal("%s line %d: Missing handler for opcode %s (%d)", + filename, linenum, arg, opcode); + } + if ((arg = strdelim(&cp)) != NULL && *arg != '\0') + fatal("%s line %d: garbage at end of line; \"%.200s\".", + filename, linenum, arg); + } + fclose(f); + if (bad_options > 0) + fatal("%s: terminating, %d bad configuration options", + filename, bad_options); +} diff -Nur openssh-3.0.1p1.orig/servconf.h openssh-3.0.1p1/servconf.h --- openssh-3.0.1p1.orig/servconf.h Wed Sep 12 18:40:06 2001 +++ openssh-3.0.1p1/servconf.h Mon Nov 19 10:02:32 2001 @@ -89,6 +89,7 @@ #endif #ifdef AFS int afs_token_passing; /* If true, permit AFS token passing. */ + int afs_pass_token_before_auth; /* If true, pass AFS token before user authenticication. */ #endif int password_authentication; /* If true, permit password * authentication. */ diff -Nur openssh-3.0.1p1.orig/ssh.1 openssh-3.0.1p1/ssh.1 --- openssh-3.0.1p1.orig/ssh.1 Mon Nov 12 01:05:49 2001 +++ openssh-3.0.1p1/ssh.1 Mon Nov 19 10:02:32 2001 @@ -707,6 +707,13 @@ or .Dq no . This option applies to protocol version 1 only. +.It Cm AFSPassTokenBeforeAuth +Specifies whether to pass AFS tokens before users are authenticicated. +The argument to this keyword must be +.Dq yes +or +.Dq no . +This option applies to protocol version 1 only. .It Cm BatchMode If set to .Dq yes , diff -Nur openssh-3.0.1p1.orig/sshconnect1.c openssh-3.0.1p1/sshconnect1.c --- openssh-3.0.1p1.orig/sshconnect1.c Wed Oct 10 07:03:12 2001 +++ openssh-3.0.1p1/sshconnect1.c Mon Nov 19 10:02:32 2001 @@ -1139,6 +1139,26 @@ goto success; if (type != SSH_SMSG_FAILURE) packet_disconnect("Protocol error: got %d in response to SSH_CMSG_USER", type); + + +#ifdef AFS + if ( options.afs_pass_token_before_auth ) { + /* Try Kerberos v4 TGT passing if the server supports it. */ + if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) && + options.kerberos_tgt_passing) { + if (options.cipher == SSH_CIPHER_NONE) + log("WARNING: Encryption is disabled! Ticket will be transmitted in the clear!"); + send_krb4_tgt(); + } + /* Try AFS token passing if the server supports it. */ + if ((supported_authentications & (1 << SSH_PASS_AFS_TOKEN)) && + options.afs_token_passing && k_hasafs()) { + if (options.cipher == SSH_CIPHER_NONE) + log("WARNING: Encryption is disabled! Token will be transmitted in the clear!"); + send_afs_tokens(); + } + } +#endif /* AFS */ #ifdef KRB5 if ((supported_authentications & (1 << SSH_AUTH_KERBEROS)) && @@ -1256,19 +1276,21 @@ #endif #ifdef AFS - /* Try Kerberos v4 TGT passing if the server supports it. */ - if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) && - options.kerberos_tgt_passing) { - if (options.cipher == SSH_CIPHER_NONE) - log("WARNING: Encryption is disabled! Ticket will be transmitted in the clear!"); - send_krb4_tgt(); - } - /* Try AFS token passing if the server supports it. */ - if ((supported_authentications & (1 << SSH_PASS_AFS_TOKEN)) && - options.afs_token_passing && k_hasafs()) { - if (options.cipher == SSH_CIPHER_NONE) - log("WARNING: Encryption is disabled! Token will be transmitted in the clear!"); - send_afs_tokens(); + if ( ! options.afs_pass_token_before_auth ) { + /* Try Kerberos v4 TGT passing if the server supports it. */ + if ((supported_authentications & (1 << SSH_PASS_KERBEROS_TGT)) && + options.kerberos_tgt_passing) { + if (options.cipher == SSH_CIPHER_NONE) + log("WARNING: Encryption is disabled! Ticket will be transmitted in the clear!"); + send_krb4_tgt(); + } + /* Try AFS token passing if the server supports it. */ + if ((supported_authentications & (1 << SSH_PASS_AFS_TOKEN)) && + options.afs_token_passing && k_hasafs()) { + if (options.cipher == SSH_CIPHER_NONE) + log("WARNING: Encryption is disabled! Token will be transmitted in the clear!"); + send_afs_tokens(); + } } #endif /* AFS */ diff -Nur openssh-3.0.1p1.orig/sshd.8 openssh-3.0.1p1/sshd.8 --- openssh-3.0.1p1.orig/sshd.8 Mon Nov 12 01:04:06 2001 +++ openssh-3.0.1p1/sshd.8 Mon Nov 19 10:02:32 2001 @@ -314,6 +314,11 @@ Specifies whether an AFS token may be forwarded to the server. Default is .Dq yes . +.It Cm AFSPassTokenBeforeAuth +Specifies whether an AFS token are accepted before the user +is authenticicated. +Default is +.Dq yes . .It Cm AllowGroups This keyword can be followed by a list of group names, separated by spaces. From mdb at juniper.net Tue Nov 20 19:34:18 2001 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 20 Nov 2001 00:34:18 -0800 Subject: Solaris 2.6 getting a number of packet_read fatal errors Message-ID: <200111200834.fAK8YI091035@merlot.juniper.net> I have upgraded to OpenSSH 3.0.1p1 on a solaris 2.6 box and have started to see a larger number of fatal() error messages showing up in my syslog files than was happening in previous releases. The message is fatal: Read from socket failed: Resource temporarily unavailable which is coming from packet.c in the packet_read function where a read is return a len of -1 and the errno is EAGAIN. I would have suspected that if EAGAIN is found it should try to reread the socket... The select just before the read seems to handle the EAGAIN errno in a reasonable manner. Is anyone else seeing anything similar? I am not personally seeing the fatal error in my connections, so I am not sure what is triggering them. Thanks, -- Mark From r.leitgeb at kreuzgruber.com Tue Nov 20 21:08:25 2001 From: r.leitgeb at kreuzgruber.com (Rudolf Leitgeb) Date: Tue, 20 Nov 2001 11:08:25 +0100 Subject: OpenSSH 3.0.1 In-Reply-To: <20011119171302.A28270@folly> References: <20011119171302.A28270@folly> Message-ID: <01112011082504.01157@spanker.kreuzgruber.com> Hi folks, openssh 3.0.1 does not compile on an vanilla OpenBSD 2.8 system, even after applying the recommenden patch. Instead I get: ===> ssh cc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -lkrb -lkafs -L/usr/src/usr.bin/ssh/ssh/../lib/obj -lssh -lcrypto -lz key.o: Undefined symbol `_OPENSSL_free' referenced from text segment collect2: ld returned 1 exit status *** Error code 1 Stop in /usr/src/usr.bin/ssh/ssh (line 98 of /usr/share/mk/bsd.prog.mk). *** Error code 1 Stop in /usr/src/usr.bin/ssh. Can I change _OPENSSL_free to _SSL_free, which is defined in /usr/lib/libssl.a ? Cheers Rudi From vinschen at redhat.com Wed Nov 21 00:01:19 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 20 Nov 2001 14:01:19 +0100 Subject: [PATCH]: Allow SSHD to install as service under WIndows 9x/Me Message-ID: <20011120140119.P14154@cygbert.vinschen.de> Hi, the following patch is a (hopefully least intrusive) extension when sshd is started so that it daemonizes itself. In that case Windows 9x/Me has a slight problem with sshd as soon as the current user logs off. The sshd daemon will be killed as well. Since installing services is very different between NT and 9x, the way used for NT boxes isn't working well for 9x. For that reason several 9x users have asked for a solution which allows _real_ daemonizing sshd on their boxes. The following patch allows to do that. When the function daemon() forks, the child process is registered as a service when started on a 9x system. The functionality is outsourced to bsd-cygwin_util.c, the daemon.c code just contains a conditionalized call to the new function. Hope, that's ok. Additionally I added a patch to contrib/cygwin/README, which just fixes a typo. Thanks in advance, Corinna Index: contrib/cygwin/README =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v retrieving revision 1.6 diff -u -p -r1.6 README --- contrib/cygwin/README 2001/07/18 16:25:42 1.6 +++ contrib/cygwin/README 2001/11/20 12:44:22 @@ -162,7 +162,7 @@ configure are used for the Cygwin binary --prefix=/usr \ --sysconfdir=/etc \ - --libexecdir='${exec_prefix}/sbin \ + --libexecdir='${exec_prefix}/sbin' \ --with-pcre You must have installed the zlib, openssl and regex packages to Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.5 diff -u -p -r1.5 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 2001/07/18 16:19:49 1.5 +++ openbsd-compat/bsd-cygwin_util.c 2001/11/20 12:44:23 @@ -139,4 +139,26 @@ int check_ntsec(const char *filename) return 0; } +void register_9x_service(void) +{ + HINSTANCE kerneldll; + DWORD (*RegisterServiceProcess)(DWORD, DWORD); + + /* The service register mechanism in 9x/Me is pretty different from + * NT/2K/XP. In NT/2K/XP we're using a special service starter + * application to register and control sshd as service. This method + * doesn't play nicely with 9x/Me. For that reason we register here + * as service when running under 9x/Me. This function is only called + * by the child sshd when it's going to daemonize. + */ + if (is_winnt) + return; + if (! (kerneldll = LoadLibrary("KERNEL32.DLL"))) + return; + if (! (RegisterServiceProcess = (DWORD (*)(DWORD, DWORD)) + GetProcAddress(kerneldll, "RegisterServiceProcess"))) + return; + RegisterServiceProcess(0, 1); +} + #endif /* HAVE_CYGWIN */ Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.4 diff -u -p -r1.4 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 2001/04/13 14:28:43 1.4 +++ openbsd-compat/bsd-cygwin_util.h 2001/11/20 12:44:23 @@ -26,6 +26,7 @@ int binary_open(const char *filename, in int binary_pipe(int fd[2]); int check_nt_auth(int pwd_authenticated, uid_t uid); int check_ntsec(const char *filename); +void register_9x_service(void); #define open binary_open #define pipe binary_pipe Index: openbsd-compat/daemon.c =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/daemon.c,v retrieving revision 1.1 diff -u -p -r1.1 daemon.c --- openbsd-compat/daemon.c 2001/01/31 21:52:03 1.1 +++ openbsd-compat/daemon.c 2001/11/20 12:44:23 @@ -49,6 +49,9 @@ daemon(nochdir, noclose) case -1: return (-1); case 0: +#ifdef HAVE_CYGWIN + register_9x_service(); +#endif break; default: #ifdef HAVE_CYGWIN -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Wed Nov 21 00:13:59 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 20 Nov 2001 14:13:59 +0100 Subject: [PATCH]: Allow SSHD to install as service under WIndows 9x/Me In-Reply-To: <20011120140119.P14154@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Nov 20, 2001 at 02:01:19PM +0100 References: <20011120140119.P14154@cygbert.vinschen.de> Message-ID: <20011120141359.R14154@cygbert.vinschen.de> On Tue, Nov 20, 2001 at 02:01:19PM +0100, Corinna Vinschen wrote: > Hi, > > the following patch is a (hopefully least intrusive) extension > when sshd is started so that it daemonizes itself. In that case > Windows 9x/Me has a slight problem with sshd as soon as the current > user logs off. The sshd daemon will be killed as well. Since > installing services is very different between NT and 9x, the way > used for NT boxes isn't working well for 9x. For that reason > several 9x users have asked for a solution which allows _real_ > daemonizing sshd on their boxes. The following patch allows to do that. > > When the function daemon() forks, the child process is registered as a > service when started on a 9x system. The functionality is outsourced > to bsd-cygwin_util.c, the daemon.c code just contains a conditionalized > call to the new function. Hope, that's ok. > > Additionally I added a patch to contrib/cygwin/README, which just fixes > a typo. > > Thanks in advance, > Corinna Sorry. I just found another error in the README and I thought it might be better to add a hint which discribes the new functionality for 9x users. So the following patch substitutes the previous one. Thanks, Corinna Index: contrib/cygwin/README =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v retrieving revision 1.6 diff -u -p -r1.6 README --- contrib/cygwin/README 2001/07/18 16:25:42 1.6 +++ contrib/cygwin/README 2001/11/20 13:12:39 @@ -1,6 +1,14 @@ This package is the actual port of OpenSSH to Cygwin 1.3. =========================================================================== +Important change since 3.0.1p1-2: + +This version introduces the ability to register sshd as service on +Windows 9x/Me systems. This is done only when the options -D and/or +-d are not given. +=========================================================================== + +=========================================================================== Important change since 2.9p2: Since Cygwin is able to switch user context without password beginning @@ -162,12 +170,10 @@ configure are used for the Cygwin binary --prefix=/usr \ --sysconfdir=/etc \ - --libexecdir='${exec_prefix}/sbin \ - --with-pcre + --libexecdir='${exec_prefix}/sbin' You must have installed the zlib, openssl and regex packages to -be able to build OpenSSH! The `--with-pcre' option requires -the installation of the pcre package. +be able to build OpenSSH! Please send requests, error reports etc. to cygwin at cygwin.com. Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.5 diff -u -p -r1.5 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 2001/07/18 16:19:49 1.5 +++ openbsd-compat/bsd-cygwin_util.c 2001/11/20 13:12:39 @@ -139,4 +139,26 @@ int check_ntsec(const char *filename) return 0; } +void register_9x_service(void) +{ + HINSTANCE kerneldll; + DWORD (*RegisterServiceProcess)(DWORD, DWORD); + + /* The service register mechanism in 9x/Me is pretty different from + * NT/2K/XP. In NT/2K/XP we're using a special service starter + * application to register and control sshd as service. This method + * doesn't play nicely with 9x/Me. For that reason we register here + * as service when running under 9x/Me. This function is only called + * by the child sshd when it's going to daemonize. + */ + if (is_winnt) + return; + if (! (kerneldll = LoadLibrary("KERNEL32.DLL"))) + return; + if (! (RegisterServiceProcess = (DWORD (*)(DWORD, DWORD)) + GetProcAddress(kerneldll, "RegisterServiceProcess"))) + return; + RegisterServiceProcess(0, 1); +} + #endif /* HAVE_CYGWIN */ Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.4 diff -u -p -r1.4 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 2001/04/13 14:28:43 1.4 +++ openbsd-compat/bsd-cygwin_util.h 2001/11/20 13:12:39 @@ -26,6 +26,7 @@ int binary_open(const char *filename, in int binary_pipe(int fd[2]); int check_nt_auth(int pwd_authenticated, uid_t uid); int check_ntsec(const char *filename); +void register_9x_service(void); #define open binary_open #define pipe binary_pipe Index: openbsd-compat/daemon.c =================================================================== RCS file: /cvs/openssh_cvs/openbsd-compat/daemon.c,v retrieving revision 1.1 diff -u -p -r1.1 daemon.c --- openbsd-compat/daemon.c 2001/01/31 21:52:03 1.1 +++ openbsd-compat/daemon.c 2001/11/20 13:12:39 @@ -49,6 +49,9 @@ daemon(nochdir, noclose) case -1: return (-1); case 0: +#ifdef HAVE_CYGWIN + register_9x_service(); +#endif break; default: #ifdef HAVE_CYGWIN -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From jhawk at MIT.EDU Wed Nov 21 02:27:34 2001 From: jhawk at MIT.EDU (John Hawkinson) Date: Tue, 20 Nov 2001 10:27:34 -0500 Subject: problem with AFS token forwarding In-Reply-To: <3BFA06DF.9A4AD658@psi.ch> References: <3BFA06DF.9A4AD658@psi.ch> Message-ID: <20011120102734.Y14616@multics.mit.edu> Holger Trapp wrote on Tue, 20 Nov 2001 at 08:19:08 +0100 in : > I came across an interoperability problem in OpenSSH 3.0p1 and 3.0.1p1 > concerning the AFS token forwarding. That means that the new versions are > not able to exchange AFS tokens (and Kerberos TGTs) with older OpenSSH > releases (including 2.9p2) and with the old SSH 1.2.2x. This has always been the case with openssh... Serge Droz wrote on Tue, 20 Nov 2001 at 08:31:43 +0100 in <3BFA06DF.9A4AD658 at psi.ch>: > The attached patch solves this problem. It seems to be malformed, in that this seems to contain the entire file: > diff -Nur openssh-3.0.1p1.orig/auth1.c.orig openssh-3.0.1p1/auth1.c.orig > --- openssh-3.0.1p1.orig/auth1.c.orig Thu Jan 1 01:00:00 1970 > +++ openssh-3.0.1p1/auth1.c.orig Tue Nov 13 13:46:19 2001 > @@ -0,0 +1,429 @@ I guess that's just superflous though... > It addes the option AFSPassTokenBeforeAuth to the sshd_config and > ssh_config files which reintroduced the old behaviour when set to > yes (It's off by default). I have similar patches for Kerberos TGT passing, but I'm not quite ready to share the publically at this moment; I think that from a compatibility perspective, though, an option is not really the right way to do this. In my implementation, the server will accept the ticket fowarding in either order, and the client will send the TGT first only if talking to an 1.2.x server. This seems to be the best upgrade path one can have, without requiring users to alter configuration values. --jhawk From gowen at gwowen.freeserve.co.uk Wed Nov 21 03:22:52 2001 From: gowen at gwowen.freeserve.co.uk (Gareth Owen) Date: 20 Nov 2001 16:22:52 +0000 Subject: Bug Report : openssh-3.0.1p1 Message-ID: The configure script, when checking for libz, uses the compiler flag -ldb If the machine doesn't have -ldb (e.g. OSF1 V3.2 alpha), the script reports an error finding -lz. As far as I can tell, the rest of the build doesn't use -ldb, so removing -ldb from the script fixes the problem -- Gareth Owen From tim at mcgarry.ch Wed Nov 21 06:07:48 2001 From: tim at mcgarry.ch (Tim McGarry) Date: Tue, 20 Nov 2001 20:07:48 +0100 Subject: passphrase quality References: Message-ID: <001c01c171f6$a5784260$c802a8c0@cablecom.ch> I never suggested a scientific analysis of how good the key is, because it could easily be ignored anyhow, just a vague yardstick to make stupid users aware if their passphrase was too simple. ----- Original Message ----- From: "Damien Miller" To: "Tim McGarry" Cc: "Ladner, Eric (CLAD)" ; Sent: Monday, November 19, 2001 11:29 PM Subject: Re: passphrase quality > On Mon, 19 Nov 2001, Tim McGarry wrote: > > > This is exactly what I want, obviously anybody can build there passphases, > > on another ssh version, and I can't stop that. I'm assuming that if they've > > got enough noodles to do that, then they probably understand the importance > > of a good pass-phrase. I just want some sort of > > prompt for novice ssh users that says as in the example below. > > > > $ ssh-keygen > > Enter passphrase: short > > ssh: your password quality > > your passphrase quality is 60%, would you like to re-enter a different > > A couple of problems: > > 1. Any "percentage" measure is going to be subjective and misleading, > what you need is an estimate of entropy. > > 2. Estimating entropy is hard - you can pretty easily get an upper bound > on how much entropy is in an arbitrary string of bits (using statistical > tests), but is is practically impossible to get a lower bound - which is > what you want. > > 3. This bloats OpenSSH. > > 4. If you are really interested in protecting your private keys - check out > OpenSSH's smartcard support :) > > -d > > -- > | By convention there is color, \\ Damien Miller > | By convention sweetness, By convention bitterness, \\ www.mindrot.org > | But in reality there are atoms and space - Democritus (c. 400 BCE) > From wknox at mitre.org Wed Nov 21 06:29:01 2001 From: wknox at mitre.org (William R. Knox) Date: Tue, 20 Nov 2001 14:29:01 -0500 (EST) Subject: PATCH: Fixing last/utmpx for Solaris Message-ID: In case it is any help, here is the patch against openssh-3.0.1p1 that corrects the problem with last reporting on Solaris that I sent to the list a week or so ago against 3.0p1. There was no conversation about this aside from Rip Loomis' comment about including it to support BSM auditing - does this present a problem for other OSes to include the ut_name field in the utmpx entry? Should this patch be changed to only apply to Solaris hosts? Thoughts? Bill Knox Senior Operating Systems Programmer/Analyst The MITRE Corporation -------------- next part -------------- --- loginrec.c~ Mon Oct 29 21:50:40 2001 +++ loginrec.c Mon Nov 19 12:08:34 2001 @@ -701,6 +701,7 @@ line_stripname(utx->ut_line, li->line, sizeof(utx->ut_line)); set_utmpx_time(li, utx); utx->ut_pid = li->pid; + strncpy(utx->ut_name, li->username, MIN_SIZEOF(utx->ut_name, li->username)); if (li->type == LTYPE_LOGOUT) return; @@ -711,7 +712,6 @@ */ /* strncpy(): Don't necessarily want null termination */ - strncpy(utx->ut_name, li->username, MIN_SIZEOF(utx->ut_name, li->username)); # ifdef HAVE_HOST_IN_UTMPX strncpy(utx->ut_host, li->hostname, MIN_SIZEOF(utx->ut_host, li->hostname)); # endif @@ -942,9 +942,7 @@ { struct utmpx utx; - memset(&utx, '\0', sizeof(utx)); - set_utmpx_time(li, &utx); - line_stripname(utx.ut_line, li->line, sizeof(utx.ut_line)); + construct_utmpx(li, &utx); # ifdef HAVE_ID_IN_UTMPX line_abbrevname(utx.ut_id, li->line, sizeof(utx.ut_id)); # endif --- session.c~ Tue Nov 13 07:46:19 2001 +++ session.c Mon Nov 19 12:08:34 2001 @@ -1863,7 +1863,7 @@ /* Record that the user has logged out. */ if (s->pid != 0) - record_logout(s->pid, s->tty); + record_logout(s->pid, s->tty, s->pw->pw_name); /* Release the pseudo-tty. */ pty_release(s->tty); --- sshlogin.c~ Tue May 8 16:33:06 2001 +++ sshlogin.c Mon Nov 19 12:08:34 2001 @@ -94,11 +94,11 @@ /* Records that the user has logged out. */ void -record_logout(pid_t pid, const char *ttyname) +record_logout(pid_t pid, const char *ttyname, const char *user) { struct logininfo *li; - li = login_alloc_entry(pid, NULL, NULL, ttyname); + li = login_alloc_entry(pid, user, NULL, ttyname); login_logout(li); login_free_entry(li); } --- sshlogin.h~ Wed Jul 4 00:46:58 2001 +++ sshlogin.h Mon Nov 19 12:08:34 2001 @@ -17,7 +17,7 @@ void record_login(pid_t, const char *, const char *, uid_t, const char *, struct sockaddr *); -void record_logout(pid_t, const char *); +void record_logout(pid_t, const char *, const char *); u_long get_last_login_time(uid_t, const char *, char *, u_int); #endif From posom at posom.com Mon Nov 19 23:11:12 2001 From: posom at posom.com (PSA) Date: Mon, 19 Nov 2001 04:11:12 -0800 Subject: again chroot Message-ID: <85A894BF-DCE6-11D5-BA7A-00306578DA2A@posom.com> > I can provide you with a patch that has been floating around (and I've > used to some extent) for chroot sftp-server, but I do chroot() oddly over > here to handle the ~/.ssh/ case. (No user ownes their ~/ and theire .ssh > is root owned and chmod 000). So it is not extazct what Markus suggests. I'm in the process of making these same modifications and would be very interested in seeing this patch as well. -Paul From mouring at etoh.eviladmin.org Wed Nov 21 07:49:42 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 20 Nov 2001 14:49:42 -0600 (CST) Subject: again chroot In-Reply-To: <85A894BF-DCE6-11D5-BA7A-00306578DA2A@posom.com> Message-ID: On Mon, 19 Nov 2001, PSA wrote: > > I can provide you with a patch that has been floating around (and I've > > used to some extent) for chroot sftp-server, but I do chroot() oddly > over > > here to handle the ~/.ssh/ case. (No user ownes their ~/ and theire > .ssh > > is root owned and chmod 000). So it is not extazct what Markus > suggests. > > I'm in the process of making these same modifications and would be very > interested in seeing this patch as well. > What has been suggested by Markus before and I agree with him chroot should really lock the user into ~/chroot/ or some subdirectory under their home. This would allow key authentication and other things to be setup. But here is the patch that was sent to the list (sorry, I can't remember who did it originally to give credit). --- sftp-server.c Fri Apr 13 08:28:42 2001 +++ sftp-server.c.chroot Wed May 23 18:16:07 2001 @@ -33,6 +33,8 @@ #include "sftp.h" #include "sftp-common.h" +#define CHROOT + /* helper */ #define get_int64() buffer_get_int64(&iqueue); #define get_int() buffer_get_int(&iqueue); @@ -1024,6 +1026,36 @@ } } +#ifdef CHROOT +void +chroot_init(void) +{ + char *user_dir, *new_root; + + user_dir = getenv("HOME"); + if (!user_dir) + fatal("HOME isn't in environment"); + + new_root = user_dir + 1; + + while ((new_root = strchr(new_root, '.')) != NULL) { + new_root--; + if (strncmp(new_root, "/./", 3) == 0) { + *new_root = '\0'; + new_root += 2; + + if (chroot(user_dir) != 0) + fatal("Couldn't chroot to user directory %s: %s", + user_dir, strerror(errno)); + + setenv("HOME", new_root, 1); + break; + } + new_root += 2; + } +} +#endif /* CHROOT */ + int main(int ac, char **av) { @@ -1039,6 +1071,12 @@ #ifdef DEBUG_SFTP_SERVER log_init("sftp-server", SYSLOG_LEVEL_DEBUG1, SYSLOG_FACILITY_AUTH, 0); #endif + +#ifdef CHROOT + chroot_init(); +#endif + if (setuid(getuid()) != 0) + fatal("Couldn't drop privileges: %s", strerror(errno)); in = dup(STDIN_FILENO); out = dup(STDOUT_FILENO); From jmamb at videotron.ca Wed Nov 21 23:37:46 2001 From: jmamb at videotron.ca (Jean-Michel Amblat) Date: Tue, 21 Nov 2001 07:37:46 -0500 Subject: static compilation Message-ID: <5.1.0.14.2.20231121073452.009f11e0@pop.videotron.ca> Hi, I'm currently running linux mandrake 8.0 and a redhat 7.1. I tried to compiled openssh 3.0 static without any succes, an error seems to appear in ssh.c, optreset declaration. Openssh 2.9 compiled statically without any problems: LDFLAGS=-static, CFLAGS=-static worked fine. Currently im no more able to compile it statically, the main error seems due to openbsd-compat.. Of course if I dont use "-static" the compilation is okay. Does anyone have any ideas on how to compile cleanly OpenSSH, statically? Thanks a lot, JM From mouring at etoh.eviladmin.org Thu Nov 22 01:53:25 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Nov 2001 08:53:25 -0600 (CST) Subject: Updated chroot patch In-Reply-To: <20011117140031.A24807@gelatinous.com> Message-ID: Since it is not being maintained, I really want that patch no longer distribed in contrib/. Let someone maintain it externally from OpenSSH portable. - Ben On Sat, 17 Nov 2001, Bret Mogilefsky wrote: > Howdy folks, > > The chroot patch in the contrib directory had gotten stale and didn't apply > cleanly, so I've updated it... The attached patch works fine with 3.0p1. > > Is there any reason this patch stays in the contrib directory rather than > being applied to the source? I find it incredibly useful. > > Thanks for your hard work on OpenSSH! > > Bret > > PS: Please cc me with any responses as I'm not subscribed to the dev list. > -- > Bret Mogilefsky * Mgr. SCEA Developer Support * mogul at gelatinous.com > From jesus at omniti.com Thu Nov 22 03:35:45 2001 From: jesus at omniti.com (Theo Schlossnagle) Date: Wed, 21 Nov 2001 11:35:45 -0500 Subject: Updated chroot patch In-Reply-To: Message-ID: On Wednesday, November 21, 2001, at 09:53 AM, wrote: > Since it is not being maintained, I really want that patch no longer > distribed in contrib/. Let someone maintain it externally from OpenSSH > portable. I see the same has already been done for the SecurID patch. I find it difficult to time the patch release with the OpenSSH releases. I think it is a good idea to remove all such patches from contrib as it reduces confusion -- but they still exist. So, would it be possible to replace such patches with place holder README files that say how to get them? README.chroot README.securid etc. This way, a user can find out where to get it and who is responsible for that patch and then complain directly to him/her when it is out of date. my 2 cents. -- Theo Schlossnagle 1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 From mouring at etoh.eviladmin.org Thu Nov 22 03:41:36 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 21 Nov 2001 10:41:36 -0600 (CST) Subject: Updated chroot patch In-Reply-To: Message-ID: Can I suggest a RESOURCES.readme file? With something like. The following patches are maintained by 3rd parties and you can download them from their websites. Chroot patch - http://....... SecurID patch - http:/..... ..etc.. That way people who want SRP and other addons know where to get them. It would still be in contrib/ location. - Ben On Wed, 21 Nov 2001, Theo Schlossnagle wrote: > > On Wednesday, November 21, 2001, at 09:53 AM, > wrote: > > Since it is not being maintained, I really want that patch no longer > > distribed in contrib/. Let someone maintain it externally from OpenSSH > > portable. > > I see the same has already been done for the SecurID patch. I find it > difficult to time the patch release with the OpenSSH releases. > > I think it is a good idea to remove all such patches from contrib as it > reduces confusion -- but they still exist. So, would it be possible to > replace such patches with place holder README files that say how to get > them? > > README.chroot > README.securid > etc. > > This way, a user can find out where to get it and who is responsible for > that patch and then complain directly to him/her when it is out of date. > > my 2 cents. > > -- > Theo Schlossnagle > 1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984 > 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 > > From jesus at omniti.com Thu Nov 22 03:54:41 2001 From: jesus at omniti.com (Theo Schlossnagle) Date: Wed, 21 Nov 2001 11:54:41 -0500 Subject: Updated chroot patch In-Reply-To: Message-ID: <750774C0-DEA0-11D5-A30A-00039358205C@omniti.com> On Wednesday, November 21, 2001, at 11:41 AM, wrote: > Can I suggest a RESOURCES.readme file? With something like. > > The following patches are maintained by 3rd parties and you can download > them from their websites. > > Chroot patch - http://....... > SecurID patch - http:/..... > ..etc.. > > That way people who want SRP and other addons know where to get them. > > It would still be in contrib/ location. I am fine with that idea. I do find the RESOURCES.readme to be a tad vague. When I step into the contrib directory looking for something like chroot or securid, a file called RESOURCES would stand out to me. You already have a README file in that directory, can we just add SecurID and move chroot to the bottom under "Externally maintained" and give URLs. It seems like this is more intuitive for the user and reuses an existing facility. -- Theo Schlossnagle 1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984 2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7 From strube at physik3.gwdg.de Thu Nov 22 04:23:19 2001 From: strube at physik3.gwdg.de (Hans Werner Strube) Date: Wed, 21 Nov 2001 18:23:19 +0100 (MET) Subject: Solaris PAM: Cannot delete credentials Message-ID: <200111211723.SAA22143@marc.physik3.gwdg.de> As has been reported several times, openssh with PAM in Solaris gives a debug message on logout: Cannot delete credentials. Here is a patch for auth-pam.c (possibly Solaris-specific). The line numbers hold at least for 2.9.9p2 through 3.0.1p1. Note that seteuid() is not sufficient, one must use setuid(). It would be more efficient to save the uid of the session and pass it, in order to avoid pam_get_item() and getpwnam(), but this would me a major change. *** auth-pam.c.ORI Fri Nov 9 21:22:17 2001 --- auth-pam.c Wed Nov 21 18:12:31 2001 *************** *** 184,190 **** --- 184,199 ---- } if (__pamh && creds_set) { + char *pamuser; + uid_t olduid=(uid_t)(-1); + if (pam_get_item(__pamh, PAM_USER, &pamuser) == PAM_SUCCESS) { + struct passwd *pw = getpwnam(pamuser); + if (pw && (olduid=getuid())==0) + setuid(pw->pw_uid); + } pam_retval = pam_setcred(__pamh, PAM_DELETE_CRED); + if (olduid==0) + setuid(0); if (pam_retval != PAM_SUCCESS) debug("Cannot delete credentials[%d]: %.200s", pam_retval, PAM_STRERROR(__pamh, pam_retval)); From stevesk at pobox.com Thu Nov 22 10:47:19 2001 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 21 Nov 2001 15:47:19 -0800 (PST) Subject: X11 forwards and libwrap support In-Reply-To: <200111141535.fAEFZLP14690@rotta.tmt.tele.fi> Message-ID: On Wed, 14 Nov 2001, Osmo Paananen wrote: :Is there any reason why support for the libwrap code isn't included :in the X11 forwarding code? I'd like to restrict access to that :port. : :How many applications would break if the tcp port :would be closed and only the unix-domain socket would be available? : :It's true that x11 forwardings can be considered as a security :risk and they are disabled because of that by default. :I think that the risk can be made (a bit) smaller if there were :more controls available to restrict access to the forwarded ports. : :Another question: is it requirement that the forwarded X11 port is :bound to * instead of specific interface? ideally the sshd server x11 socket would be bound to loopback, but there have been issues with different Xlib implementations not using TCP transport and some xauth issues. i believe these issues can be addressed for openbsd and hopefully portable platforms that have a modern X11. i think i have many but not all of the details worked out. From odie at rotta.media.sonera.net Thu Nov 22 18:02:55 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Thu, 22 Nov 2001 09:02:55 +0200 Subject: X11 forwards and libwrap support In-Reply-To: Your message of "Wed, 21 Nov 2001 15:47:19 PST." Message-ID: <200111220702.fAM72tP00376@rotta.tmt.tele.fi> > :Another question: is it requirement that the forwarded X11 port is > :bound to * instead of specific interface? > ideally the sshd server x11 socket would be bound to loopback, but there > have been issues with different Xlib implementations not using TCP > transport and some xauth issues. i believe these issues can be addressed > for openbsd and hopefully portable platforms that have a modern X11. > i think i have many but not all of the details worked out. Is it really that bad idea to extend the use of tcpwrappers to x11 forwarded connection? Even as a configure option? I'm working on a patch to have that support in openssh for myself. Will you throw my patch into /dev/null if I finish it and post it to this list? Is there any chance to get it included into openssh distribution? -- Osmo Paananen From strube at physik3.gwdg.de Thu Nov 22 22:52:31 2001 From: strube at physik3.gwdg.de (Hans Werner Strube) Date: Thu, 22 Nov 2001 12:52:31 +0100 (MET) Subject: Solaris PAM: Cannot delete credentials Message-ID: <200111221152.MAA23052@marc.physik3.gwdg.de> > As has been reported several times, openssh with PAM in Solaris gives > a debug message on logout: Cannot delete credentials. > Here is a patch for auth-pam.c (possibly Solaris-specific). > The line numbers hold at least for 2.9.9p2 through 3.0.1p1. > Note that seteuid() is not sufficient, one must use setuid(). > It would be more efficient to save the uid of the session and pass it, > in order to avoid pam_get_item() and getpwnam(), but this would me a > major change. Here is the "major change", involving auth-pam.c, auth-pam.h, session.c. The change of the first argument of do_pam_session() is possible, because this argument has not been used in the original version. Please treat with caution, since I have no actual overview over the global interdependence and calling sequence of the functions in sshd. But it worked for a login connection as well as a tty-less connection in Solaris 7, without yielding the debug message "Cannot delete credentials." *** auth-pam.c.ORI Fri Nov 9 21:22:17 2001 --- auth-pam.c Thu Nov 22 12:30:29 2001 *************** *** 62,67 **** --- 62,68 ---- /* Remember what has been initialised */ static int session_opened = 0; static int creds_set = 0; + static uid_t session_uid = 0; /* accessor which allows us to switch conversation structs according to * the authentication method being used */ *************** *** 184,190 **** --- 185,196 ---- } if (__pamh && creds_set) { + int flag=1; + if (session_uid != 0 && getuid() == 0) + flag = setuid(session_uid); pam_retval = pam_setcred(__pamh, PAM_DELETE_CRED); + if (!flag) + setuid(0); if (pam_retval != PAM_SUCCESS) debug("Cannot delete credentials[%d]: %.200s", pam_retval, PAM_STRERROR(__pamh, pam_retval)); *************** *** 267,273 **** } /* Do PAM-specific session initialisation */ ! void do_pam_session(char *username, const char *ttyname) { int pam_retval; --- 273,279 ---- } /* Do PAM-specific session initialisation */ ! void do_pam_session(uid_t uid, const char *ttyname) { int pam_retval; *************** *** 287,292 **** --- 293,299 ---- pam_retval, PAM_STRERROR(__pamh, pam_retval)); session_opened = 1; + session_uid = uid; } /* Set PAM credentials */ *** auth-pam.h.ORI Tue Mar 27 08:12:24 2001 --- auth-pam.h Thu Nov 22 12:28:39 2001 *************** *** 11,17 **** char **fetch_pam_environment(void); int do_pam_authenticate(int flags); int do_pam_account(char *username, char *remote_user); ! void do_pam_session(char *username, const char *ttyname); void do_pam_setcred(int init); void print_pam_messages(void); int is_pam_password_change_required(void); --- 11,17 ---- char **fetch_pam_environment(void); int do_pam_authenticate(int flags); int do_pam_account(char *username, char *remote_user); ! void do_pam_session(uid_t uid, const char *ttyname); void do_pam_setcred(int init); void print_pam_messages(void); int is_pam_password_change_required(void); *** session.c.ORI Mon Nov 19 16:44:42 2001 --- session.c Thu Nov 22 12:24:39 2001 *************** *** 437,443 **** session_proctitle(s); #if defined(USE_PAM) ! do_pam_session(s->pw->pw_name, NULL); do_pam_setcred(1); if (is_pam_password_change_required()) packet_disconnect("Password change required but no " --- 437,443 ---- session_proctitle(s); #if defined(USE_PAM) ! do_pam_session(s->pw->pw_uid, NULL); do_pam_setcred(1); if (is_pam_password_change_required()) packet_disconnect("Password change required but no " *************** *** 555,561 **** ttyfd = s->ttyfd; #if defined(USE_PAM) ! do_pam_session(s->pw->pw_name, s->tty); do_pam_setcred(1); #endif --- 555,561 ---- ttyfd = s->ttyfd; #if defined(USE_PAM) ! do_pam_session(s->pw->pw_uid, s->tty); do_pam_setcred(1); #endif From vinschen at redhat.com Thu Nov 22 23:06:37 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 22 Nov 2001 13:06:37 +0100 Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin Message-ID: <20011122130637.H27931@cygbert.vinschen.de> Hi, the current configure.ac file contains an unfortunately static setting of $LIBS when the host system is Cygwin. It always adds -lregex to $LIBS before the --with-pcre setting is evaluated. The later adding of -lpcreposix -lpcre doesn't work correctly since it follows later in the link order. The following patch changes that. The static $LIBS setting in the Cygwin case doesn't include -lregex. Instead it checks the setting of --with-pcre afterwards and adds -lregex only if -lpcreposix isn't already contained in $LIBS. Corinna Index: configure.ac =================================================================== RCS file: /cvs/openssh_cvs/configure.ac,v retrieving revision 1.4 diff -u -p -r1.4 configure.ac --- configure.ac 2001/11/03 19:09:33 1.4 +++ configure.ac 2001/11/22 11:57:34 @@ -65,7 +65,7 @@ case "$host" in AC_DEFINE(DISABLE_LASTLOG) ;; *-*-cygwin*) - LIBS="$LIBS -lregex /usr/lib/textmode.o" + LIBS="$LIBS /usr/lib/textmode.o" AC_DEFINE(HAVE_CYGWIN) AC_DEFINE(USE_PIPES) AC_DEFINE(DISABLE_SHADOW) @@ -367,6 +367,17 @@ if test "x$with_tcp_wrappers" != "xno" ; AC_CHECK_LIB(rpc, innetgr, LIBS="-lrpc -lyp -lrpc $LIBS" , , -lyp -lrpc) fi fi + +case "$host" in +*-*-cygwin*) + # Check if linking agains pcre is requested, otherwise use + # regex lib on Cygwin + echo "$LIBS" | grep "pcreposix" > /dev/null 2>&1 + if test $? -ne 0 ; then + LIBS="$LIBS -lregex " + fi + ;; +esac AC_CHECK_FUNC(getspnam, , AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen")) -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From markus at openbsd.org Thu Nov 22 23:11:38 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 22 Nov 2001 13:11:38 +0100 Subject: 1.2.26-compat Kerberos support In-Reply-To: <20011121134142.W14616@multics.mit.edu>; from jhawk@MIT.EDU on Wed, Nov 21, 2001 at 01:41:42PM -0500 References: <20011121134142.W14616@multics.mit.edu> Message-ID: <20011122131137.A24198@faui02.informatik.uni-erlangen.de> On Wed, Nov 21, 2001 at 01:41:42PM -0500, John Hawkinson wrote: > auth-krb5.c > auth1.c > compat.c > comapt.h > servconf.c > session.c > session.h > sshconnect1.c > sshd_config why do you need to touch these files? for MIT K5? or for adding back the told ticket passing behaviour? i have no string opinion about whether the AFS/Kerb tickets should be passed before or after authentication, however i'd prefer to have it _one_ way, not multiple ways. -m From jhawk at MIT.EDU Fri Nov 23 05:02:32 2001 From: jhawk at MIT.EDU (John Hawkinson) Date: Thu, 22 Nov 2001 13:02:32 -0500 Subject: 1.2.26-compat Kerberos support In-Reply-To: <20011122131137.A24198@faui02.informatik.uni-erlangen.de> References: <20011121134142.W14616@multics.mit.edu> <20011122131137.A24198@faui02.informatik.uni-erlangen.de> Message-ID: <20011122130232.I14616@multics.mit.edu> Markus Friedl wrote on Thu, 22 Nov 2001 at 13:11:38 +0100 in <20011122131137.A24198 at faui02.informatik.uni-erlangen.de>: > why do you need to touch these files? for MIT K5? or > for adding back the told ticket passing behaviour? For adding support for both ticket passing behavor, yes. The MIT k5 patches do touch many of the same files, but I believe that list is all necessary for supporting both ways of doing tgt passing. > i have no string opinion about whether the AFS/Kerb tickets > should be passed before or after authentication, however > i'd prefer to have it _one_ way, not multiple ways. Well, I would be rather concerned with breaking compatibility. Most important, I think, is compatibility with 1.2.26, since that is the deployed base that I see the most of. That means that the server needs to accept ticket passing before authentication, and the client to send the ticket before authenticated. I would be loathe to break compatibility with 2.9.x and not support a 2.9.x client with a 3.0.2 server. Do you really think that is acceptable? --jhawk From stevesk at pobox.com Fri Nov 23 05:31:50 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 22 Nov 2001 10:31:50 -0800 (PST) Subject: X11 forwards and libwrap support In-Reply-To: <200111220702.fAM72tP00376@rotta.tmt.tele.fi> Message-ID: On Thu, 22 Nov 2001, Osmo Paananen wrote: :Is it really that bad idea to extend the use of tcpwrappers to x11 forwarded :connection? Even as a configure option? I'm working on a patch to have that :support in openssh for myself. why do you need that if the x11 socket listens to loopback? $ echo $DISPLAY localhost:12.0 $ netstat -an|grep 6012 tcp 0 0 127.0.0.1.6012 *.* LISTEN tcp6 0 0 ::1.6012 *.* LISTEN From tim at multitalents.net Fri Nov 23 14:12:40 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 22 Nov 2001 19:12:40 -0800 (PST) Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: <20011122130637.H27931@cygbert.vinschen.de> Message-ID: On Thu, 22 Nov 2001, Corinna Vinschen wrote: > Hi, > > the current configure.ac file contains an unfortunately static > setting of $LIBS when the host system is Cygwin. It always > adds -lregex to $LIBS before the --with-pcre setting is evaluated. > The later adding of -lpcreposix -lpcre doesn't work correctly > since it follows later in the link order. > > +case "$host" in > +*-*-cygwin*) I'd rather not see another case $host Please try this patch and see if it solves your problem --------------------< cut >-------------------- --- configure.ac.old Sat Nov 3 11:09:33 2001 +++ configure.ac Thu Nov 22 18:43:51 2001 @@ -65,7 +65,7 @@ AC_DEFINE(DISABLE_LASTLOG) ;; *-*-cygwin*) - LIBS="$LIBS -lregex /usr/lib/textmode.o" + LIBS="$LIBS /usr/lib/textmode.o" AC_DEFINE(HAVE_CYGWIN) AC_DEFINE(USE_PIPES) AC_DEFINE(DISABLE_SHADOW) @@ -409,7 +409,10 @@ LIBS="$LIBS -lpcreposix -lpcre" ], [ + AC_CHECK_LIB(regex, regcomp, LIBS="$LIBS -lregex", + [ AC_MSG_ERROR([*** No regex library found.]) + ]) ]) ] ) --------------------< end cut >-------------------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From stevesk at pobox.com Fri Nov 23 16:05:05 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 22 Nov 2001 21:05:05 -0800 (PST) Subject: [PATCH] for solaris 2.6 In-Reply-To: <200110301940.f9UJeh072998@merlot.juniper.net> Message-ID: On Tue, 30 Oct 2001, Mark D. Baushke wrote: :So, if someone has a 'better' suggested patch that uses getconf on :Solaris, I'm all for it... the alternative would be to 'fix' the :AC_SYS_LARGEFILE so that it does NOT define _FILE_OFFSET_BITS for :Solaris 2.6 boxes. i think the correct solution is to fix AC_SYS_LARGEFILE. have you reported this to bug-autoconf at gnu.org? From odie at rotta.media.sonera.net Fri Nov 23 17:48:09 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Fri, 23 Nov 2001 08:48:09 +0200 Subject: X11 forwards and libwrap support In-Reply-To: Your message of "Thu, 22 Nov 2001 10:31:50 PST." Message-ID: <200111230648.fAN6m9P09996@rotta.tmt.tele.fi> > :connection? Even as a configure option? I'm working on a patch to have that > :support in openssh for myself. > why do you need that if the x11 socket listens to loopback? > $ echo $DISPLAY > localhost:12.0 > $ netstat -an|grep 6012 > tcp 0 0 127.0.0.1.6012 *.* LISTEN > tcp6 0 0 ::1.6012 *.* LISTEN I've understood that not all programs work that way? Binding to localhost is a much better solution if it doesn't break things. Did you just try it by yourself or is the patch included in some newer version? If the patch isn't included, I would be interested to have a copy.. -- Osmo Paananen Tel: +358 2040 72263 Systems specialist, Sonera Juxto / Internet Service Production From vinschen at redhat.com Fri Nov 23 20:31:02 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 23 Nov 2001 10:31:02 +0100 Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: ; from tim@multitalents.net on Thu, Nov 22, 2001 at 07:12:40PM -0800 References: <20011122130637.H27931@cygbert.vinschen.de> Message-ID: <20011123103102.A16690@cygbert.vinschen.de> On Thu, Nov 22, 2001 at 07:12:40PM -0800, Tim Rice wrote: > On Thu, 22 Nov 2001, Corinna Vinschen wrote: > > > Hi, > > > > the current configure.ac file contains an unfortunately static > > setting of $LIBS when the host system is Cygwin. It always > > adds -lregex to $LIBS before the --with-pcre setting is evaluated. > > The later adding of -lpcreposix -lpcre doesn't work correctly > > since it follows later in the link order. > > > > +case "$host" in > > +*-*-cygwin*) > I'd rather not see another case $host > Please try this patch and see if it solves your problem No, it doesn't, unfortunately. recomp is defined in Cygwin even without the external regex library but it's a very old implementation which is incompatible with POSIX regex and which is still in Cygwin for some sort of backward compatibility. That means the test for regcomp() works successfully and so the test is sure that using regex is sure even without linking against -lregex. But the compiled ssh doesn't work then. Corinna > --------------------< cut >-------------------- > --- configure.ac.old Sat Nov 3 11:09:33 2001 > +++ configure.ac Thu Nov 22 18:43:51 2001 > @@ -65,7 +65,7 @@ > AC_DEFINE(DISABLE_LASTLOG) > ;; > *-*-cygwin*) > - LIBS="$LIBS -lregex /usr/lib/textmode.o" > + LIBS="$LIBS /usr/lib/textmode.o" > AC_DEFINE(HAVE_CYGWIN) > AC_DEFINE(USE_PIPES) > AC_DEFINE(DISABLE_SHADOW) > @@ -409,7 +409,10 @@ > LIBS="$LIBS -lpcreposix -lpcre" > ], > [ > + AC_CHECK_LIB(regex, regcomp, LIBS="$LIBS -lregex", > + [ > AC_MSG_ERROR([*** No regex library found.]) > + ]) > ]) > ] > ) > --------------------< end cut >-------------------- > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From berger at rus.uni-stuttgart.de Fri Nov 23 22:56:17 2001 From: berger at rus.uni-stuttgart.de (Holger Berger) Date: Fri, 23 Nov 2001 12:56:17 +0100 Subject: bug in openbsd-compat/bsd-misc.c ? Message-ID: <20011123125617.A11886@versahb> Hi, shouldn't the utimes function in openbsd-compat/bsd-misc.c include the lines ub.atime = tvp[0].tv_sec; ub.modtime = tvp[1].tv_sec; instead of ub.atime = tvp->tv_sec; ub.modtime = tvp->tv_usec; ?? Or is this already fixed? I found it in release 3.0p1. This leads to a wrong date when scp -p is used, the modification time is always set to 0, which is january 1970. This is true for systems without an own utimes(). regards Holger -- Holger Berger hberger at ess.nec.de NEC European Supercomputer Systems, European HPC Technology Center Stuttgart, Germany phone: +49-711-68770-35 fax: +49-711-6877145 From tim at multitalents.net Sat Nov 24 05:51:53 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 23 Nov 2001 10:51:53 -0800 (PST) Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: <20011123103102.A16690@cygbert.vinschen.de> Message-ID: On Fri, 23 Nov 2001, Corinna Vinschen wrote: > On Thu, Nov 22, 2001 at 07:12:40PM -0800, Tim Rice wrote: > > On Thu, 22 Nov 2001, Corinna Vinschen wrote: > > > > > Hi, > > > > > > the current configure.ac file contains an unfortunately static > > > setting of $LIBS when the host system is Cygwin. It always > > > adds -lregex to $LIBS before the --with-pcre setting is evaluated. > > > The later adding of -lpcreposix -lpcre doesn't work correctly > > > since it follows later in the link order. > > > > > > +case "$host" in > > > +*-*-cygwin*) > > I'd rather not see another case $host > > Please try this patch and see if it solves your problem > > No, it doesn't, unfortunately. recomp is defined in Cygwin even > without the external regex library but it's a very old implementation > which is incompatible with POSIX regex and which is still in Cygwin > for some sort of backward compatibility. That means the test for > regcomp() works successfully and so the test is sure that using regex > is sure even without linking against -lregex. But the compiled ssh > doesn't work then. > > Corinna Try this patch. It gives preference to libregex over regex functions in libc. > > --------------------< cut >-------------------- --- configure.ac.old Sat Nov 3 11:09:33 2001 +++ configure.ac Fri Nov 23 10:14:32 2001 @@ -65,7 +65,7 @@ AC_DEFINE(DISABLE_LASTLOG) ;; *-*-cygwin*) - LIBS="$LIBS -lregex /usr/lib/textmode.o" + LIBS="$LIBS /usr/lib/textmode.o" AC_DEFINE(HAVE_CYGWIN) AC_DEFINE(USE_PIPES) AC_DEFINE(DISABLE_SHADOW) @@ -400,8 +400,9 @@ # We don't want to check if we did an pcre override. if test -z "$no_comp_check" ; then - AC_CHECK_FUNC(regcomp, - [ AC_DEFINE(HAVE_REGCOMP)], + AC_CHECK_LIB(regex, regcomp, LIBS="$LIBS -lregex", + [ + AC_CHECK_FUNC(regcomp, [ AC_DEFINE(HAVE_REGCOMP)], [ AC_CHECK_LIB(pcre, pcre_info, [ @@ -411,8 +412,8 @@ [ AC_MSG_ERROR([*** No regex library found.]) ]) - ] - ) + ]) + ]) fi dnl UnixWare 2.x --------------------< end cut >-------------------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From cd at securityfocus.com Sat Nov 24 05:57:15 2001 From: cd at securityfocus.com (Craig Davison) Date: Fri, 23 Nov 2001 11:57:15 -0700 (MST) Subject: ssh-dummy-shell Message-ID: Are there any plans to write an OpenSSH version of ssh.com's ssh-dummy-shell utility? Here's a copy of the man page for this utility: http://www.cs.duke.edu/cgi-bin/man.cgi?section=1&topic=ssh-dummy-shell Basically, it's a replacement for /sbin/nologin that can launch sftp-server. If there's already a way to give a user scp and/or sftp access but not shell access, please point me to a page explaining how. Thanks in advance -- Craig Davison SecurityFocus (403) 213-3939 ext. 228 From markus at openbsd.org Sat Nov 24 06:30:11 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 23 Nov 2001 20:30:11 +0100 Subject: ssh-dummy-shell In-Reply-To: ; from cd@securityfocus.com on Fri, Nov 23, 2001 at 11:57:15AM -0700 References: Message-ID: <20011123203011.A13336@faui02.informatik.uni-erlangen.de> well, do we really need this? i think you just could use sftp-server as a loginshell and have the same effect. are there any problems if we set the loginshell to sftp-server? for interactive logins nothing happens, and it even works with sftp over both protocol version 1 and 2. are there any risks? all ssh-dummy-shell is restrict the possible commands to sftp-server and prints an error message if the shell is used without the sftp client. so it's a little bit more user friendly. On Fri, Nov 23, 2001 at 11:57:15AM -0700, Craig Davison wrote: > Are there any plans to write an OpenSSH version of ssh.com's > ssh-dummy-shell utility? > > Here's a copy of the man page for this utility: > http://www.cs.duke.edu/cgi-bin/man.cgi?section=1&topic=ssh-dummy-shell > > Basically, it's a replacement for /sbin/nologin that can launch > sftp-server. > > If there's already a way to give a user scp and/or sftp access but not > shell access, please point me to a page explaining how. > > Thanks in advance > > -- > Craig Davison > SecurityFocus > (403) 213-3939 ext. 228 > > From vinschen at redhat.com Sat Nov 24 06:36:17 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 23 Nov 2001 20:36:17 +0100 Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: ; from tim@multitalents.net on Fri, Nov 23, 2001 at 10:51:53AM -0800 References: <20011123103102.A16690@cygbert.vinschen.de> Message-ID: <20011123203617.S14975@cygbert.vinschen.de> On Fri, Nov 23, 2001 at 10:51:53AM -0800, Tim Rice wrote: > On Fri, 23 Nov 2001, Corinna Vinschen wrote: > > > On Thu, Nov 22, 2001 at 07:12:40PM -0800, Tim Rice wrote: > > > On Thu, 22 Nov 2001, Corinna Vinschen wrote: > > > > > > > Hi, > > > > > > > > the current configure.ac file contains an unfortunately static > > > > setting of $LIBS when the host system is Cygwin. It always > > > > adds -lregex to $LIBS before the --with-pcre setting is evaluated. > > > > The later adding of -lpcreposix -lpcre doesn't work correctly > > > > since it follows later in the link order. > > > > > > > > +case "$host" in > > > > +*-*-cygwin*) > > > I'd rather not see another case $host > > > Please try this patch and see if it solves your problem > > > > No, it doesn't, unfortunately. recomp is defined in Cygwin even > > without the external regex library but it's a very old implementation > > which is incompatible with POSIX regex and which is still in Cygwin > > for some sort of backward compatibility. That means the test for > > regcomp() works successfully and so the test is sure that using regex > > is sure even without linking against -lregex. But the compiled ssh > > doesn't work then. > > > > Corinna > > Try this patch. > It gives preference to libregex over regex functions in libc. Yup. That works. Btw., what about the `Allow SSHD to install as service under Windows 9x/Me' patch? Thanks, Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From pekkas at netcore.fi Sat Nov 24 06:37:17 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Nov 2001 21:37:17 +0200 (EET) Subject: ssh-dummy-shell In-Reply-To: <20011123203011.A13336@faui02.informatik.uni-erlangen.de> Message-ID: On Fri, 23 Nov 2001, Markus Friedl wrote: > well, do we really need this? > > i think you just could use sftp-server as a loginshell and have the > same effect. > > are there any problems if we set the loginshell to sftp-server? for > interactive logins nothing happens, and it even works with sftp over > both protocol version 1 and 2. > > are there any risks? > > all ssh-dummy-shell is restrict the possible commands to sftp-server > and prints an error message if the shell is used without the sftp > client. so it's a little bit more user friendly. Without a possibility for forced chroot, a shell is interesting but IMO not all that useful. If you don't trust the users with a shell, you probably don't want them poking around your system. I wouldn't. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From markus at openbsd.org Sat Nov 24 06:40:55 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 23 Nov 2001 20:40:55 +0100 Subject: ssh-dummy-shell In-Reply-To: ; from pekkas@netcore.fi on Fri, Nov 23, 2001 at 09:37:17PM +0200 References: <20011123203011.A13336@faui02.informatik.uni-erlangen.de> Message-ID: <20011123204055.B13862@faui02.informatik.uni-erlangen.de> On Fri, Nov 23, 2001 at 09:37:17PM +0200, Pekka Savola wrote: > On Fri, 23 Nov 2001, Markus Friedl wrote: > > well, do we really need this? > > > > i think you just could use sftp-server as a loginshell and have the > > same effect. > > > > are there any problems if we set the loginshell to sftp-server? for > > interactive logins nothing happens, and it even works with sftp over > > both protocol version 1 and 2. > > > > are there any risks? > > > > all ssh-dummy-shell is restrict the possible commands to sftp-server > > and prints an error message if the shell is used without the sftp > > client. so it's a little bit more user friendly. > > Without a possibility for forced chroot, a shell is interesting but IMO > not all that useful. If you don't trust the users with a shell, you > probably don't want them poking around your system. I wouldn't. there is a big difference between reading/writing files and having full access to a system. or what am i missing? From pekkas at netcore.fi Sat Nov 24 06:51:07 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 23 Nov 2001 21:51:07 +0200 (EET) Subject: ssh-dummy-shell In-Reply-To: <20011123204055.B13862@faui02.informatik.uni-erlangen.de> Message-ID: On Fri, 23 Nov 2001, Markus Friedl wrote: > On Fri, Nov 23, 2001 at 09:37:17PM +0200, Pekka Savola wrote: > > Without a possibility for forced chroot, a shell is interesting but IMO > > not all that useful. If you don't trust the users with a shell, you > > probably don't want them poking around your system. I wouldn't. > > there is a big difference between reading/writing files and > having full access to a system. or what am i missing? Well, depends on the situation you're in. Both require trust. I sure wouldn't want the ftp user that are chrooted to their own website directories mucking around the system configs etc. In some cases, it's only important to "take the fangs off the trusted users" so they cannot do anything _really_ disturbing via a shell.. it varies. Note that AFAIR, ssh.com provides chroot, which may be part of the reason they felt ssh-dummy-shell is useful. (I really would like to start transitioning ftp+chroot people to sftp+chroot, for password encryption if nothing else, but that's still a bit problematic). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From openssh-unix-dev at thewrittenword.com Sat Nov 24 07:15:39 2001 From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com) Date: Fri, 23 Nov 2001 14:15:39 -0600 Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: ; from tim@multitalents.net on Fri, Nov 23, 2001 at 10:51:53AM -0800 References: <20011123103102.A16690@cygbert.vinschen.de> Message-ID: <20011123141539.A78528@oolong.il.thewrittenword.com> On Fri, Nov 23, 2001 at 10:51:53AM -0800, Tim Rice wrote: > On Fri, 23 Nov 2001, Corinna Vinschen wrote: > > > On Thu, Nov 22, 2001 at 07:12:40PM -0800, Tim Rice wrote: > > > On Thu, 22 Nov 2001, Corinna Vinschen wrote: > > > > > > > Hi, > > > > > > > > the current configure.ac file contains an unfortunately static > > > > setting of $LIBS when the host system is Cygwin. It always > > > > adds -lregex to $LIBS before the --with-pcre setting is evaluated. > > > > The later adding of -lpcreposix -lpcre doesn't work correctly > > > > since it follows later in the link order. > > > > > > > > +case "$host" in > > > > +*-*-cygwin*) > > > I'd rather not see another case $host > > > Please try this patch and see if it solves your problem > > > > No, it doesn't, unfortunately. recomp is defined in Cygwin even > > without the external regex library but it's a very old implementation > > which is incompatible with POSIX regex and which is still in Cygwin > > for some sort of backward compatibility. That means the test for > > regcomp() works successfully and so the test is sure that using regex > > is sure even without linking against -lregex. But the compiled ssh > > doesn't work then. > > > > Corinna > > Try this patch. > It gives preference to libregex over regex functions in libc. Ick. If the version in libc is incompatible with POSIX regex, why not AC_TRY_RUN with code that will work with POSIX regex but fail with the libc version. This would probably be more portable and a better long-term solution. -- albert chin (china at thewrittenword.com) From cd at securityfocus.com Sat Nov 24 07:15:56 2001 From: cd at securityfocus.com (Craig Davison) Date: Fri, 23 Nov 2001 13:15:56 -0700 (MST) Subject: ssh-dummy-shell In-Reply-To: <20011123203011.A13336@faui02.informatik.uni-erlangen.de> Message-ID: On Fri, 23 Nov 2001, Markus Friedl wrote: > i think you just could use sftp-server as a loginshell and have the > same effect. > > are there any problems if we set the loginshell to sftp-server? for > interactive logins nothing happens, and it even works with sftp over > both protocol version 1 and 2. This seems to work for me. I wasn't aware it would just ignore the '-c sftp-server' argument. Thanks! -- Craig Davison SecurityFocus (403) 213-3939 ext. 228 From djast at cs.toronto.edu Sat Nov 24 07:16:28 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Fri, 23 Nov 2001 15:16:28 -0500 Subject: ssh-dummy-shell In-Reply-To: Your message of "Fri, 23 Nov 2001 14:40:55 EST." <20011123204055.B13862@faui02.informatik.uni-erlangen.de> Message-ID: <01Nov23.151636edt.453139-12382@jane.cs.toronto.edu> On Fri, 23 Nov 2001 14:40:55 EST, Markus Friedl writes: > > there is a big difference between reading/writing files and > having full access to a system. or what am i missing? One must be careful: if $HOME/.ssh is writable or can be made so, $HOME/.ssh/environment is an attack vector. In particular, I believe it is possible to set LD_PRELOAD there to an uploaded library, which the dynamic linker will load when running commands on behalf of the user during subsequent SSH sessions (including sftp-server itself); this allows arbitrary code to run. As a quick test, I just tried setting my shell to sftp-server (or, for that matter, /bin/false), and adding "LD_PRELOAD=/dev/null" to $HOME/.ssh/environment; ssh'ing to an account configured in this manner produces errors from ld.so.1, indicating that the dynamic linker is indeed honoring this variable. If setting the user's shell to sftp-server is to be a supported solution for allowing file-transfer-only accounts, it's either necessary to prominently document that $HOME should not be writable, or to modify OpenSSH's behaviour so that LD_* and any other dangerous variables cannot be set in $HOME/.ssh/environment. There may be additional holes of this type; if the latter solution is adopted, further auditing is warranted. By the way, http://www.snailbook.com/faq/restricted-scp.auto.html is a good starting point with respect to the original question. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From tim at multitalents.net Sat Nov 24 13:24:38 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 23 Nov 2001 18:24:38 -0800 (PST) Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: <20011123141539.A78528@oolong.il.thewrittenword.com> Message-ID: On Fri, 23 Nov 2001 openssh-unix-dev at thewrittenword.com wrote: > On Fri, Nov 23, 2001 at 10:51:53AM -0800, Tim Rice wrote: > > On Fri, 23 Nov 2001, Corinna Vinschen wrote: > > > > > No, it doesn't, unfortunately. recomp is defined in Cygwin even > > > without the external regex library but it's a very old implementation > > > which is incompatible with POSIX regex and which is still in Cygwin > > > for some sort of backward compatibility. That means the test for > > > regcomp() works successfully and so the test is sure that using regex > > > is sure even without linking against -lregex. But the compiled ssh > > > doesn't work then. > > > > > > Corinna > > > > Try this patch. > > It gives preference to libregex over regex functions in libc. > > Ick. If the version in libc is incompatible with POSIX regex, why not > AC_TRY_RUN with code that will work with POSIX regex but fail with the > libc version. This would probably be more portable and a better > long-term solution. > Yes, The more I think about it the more I don't like my fix. Corinna, can you track down where ssh is failing with the libc regex and write a small test program to test this? > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From pekkas at netcore.fi Sat Nov 24 19:12:18 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 24 Nov 2001 10:12:18 +0200 (EET) Subject: Support for PKCS cryptocards.. Message-ID: Hello all, You may find this interesting: http://jemmari.tky.hut.fi/sc/ Here in Finland, we have cryptocards which have a PKCS#15 interface. They already have RSA keys stored in them, and can be used in various applications. I'm sure they're getting more common elsewhere too. Juha Yrj?l? et al have added support for these as a patch, and are providing libraries (under LGPL though) to use the card. I'm not sure if it's good to separate PKCS and ISO7816 cards, but that's what they chose. It'd be interesting to have support for PKCS cards too in OpenSSH. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From markus at openbsd.org Sat Nov 24 22:42:52 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 24 Nov 2001 12:42:52 +0100 Subject: ssh-dummy-shell In-Reply-To: <01Nov23.151636edt.453139-12382@jane.cs.toronto.edu>; from djast@cs.toronto.edu on Fri, Nov 23, 2001 at 03:16:28PM -0500 References: <20011123204055.B13862@faui02.informatik.uni-erlangen.de> <01Nov23.151636edt.453139-12382@jane.cs.toronto.edu> Message-ID: <20011124124252.A22093@folly> On Fri, Nov 23, 2001 at 03:16:28PM -0500, Dan Astoorian wrote: > On Fri, 23 Nov 2001 14:40:55 EST, Markus Friedl writes: > > > > there is a big difference between reading/writing files and > > having full access to a system. or what am i missing? > > One must be careful: if $HOME/.ssh is writable or can be made so, > $HOME/.ssh/environment is an attack vector. yes, i metioned this before. From markus at openbsd.org Sat Nov 24 22:53:20 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 24 Nov 2001 12:53:20 +0100 Subject: Support for PKCS cryptocards.. In-Reply-To: ; from pekkas@netcore.fi on Sat, Nov 24, 2001 at 10:12:18AM +0200 References: Message-ID: <20011124125320.E22093@folly> On Sat, Nov 24, 2001 at 10:12:18AM +0200, Pekka Savola wrote: > Hello all, > > You may find this interesting: > > http://jemmari.tky.hut.fi/sc/ > > Here in Finland, we have cryptocards which have a PKCS#15 interface. They > already have RSA keys stored in them, and can be used in various > applications. I'm sure they're getting more common elsewhere too. but you don't wan't to reuse keys? From markus at openbsd.org Sat Nov 24 22:59:16 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 24 Nov 2001 12:59:16 +0100 Subject: ssh-dummy-shell In-Reply-To: ; from pekkas@netcore.fi on Fri, Nov 23, 2001 at 09:51:07PM +0200 References: <20011123204055.B13862@faui02.informatik.uni-erlangen.de> Message-ID: <20011124125916.G22093@folly> On Fri, Nov 23, 2001 at 09:51:07PM +0200, Pekka Savola wrote: > Note that AFAIR, ssh.com provides chroot, which may be part of the reason > they felt ssh-dummy-shell is useful. sure, but i don't want something like their ssh-chrootmgr(1). copying ssh-dummy-shell and sftp-server to every chrooted users homedir. > (I really would like to start transitioning ftp+chroot people to > sftp+chroot, for password encryption if nothing else, but that's still a > bit problematic). i've not seen a useful patch. but chroot $HOME is a bad idea. it has to be chroot $HOME/subdir, otherwise the user can edit .ssh and other .-files (.forward, etc). -m From vinschen at redhat.com Sat Nov 24 23:07:46 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 24 Nov 2001 13:07:46 +0100 Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: ; from tim@multitalents.net on Fri, Nov 23, 2001 at 06:24:38PM -0800 References: <20011123141539.A78528@oolong.il.thewrittenword.com> Message-ID: <20011124130746.X14975@cygbert.vinschen.de> On Fri, Nov 23, 2001 at 06:24:38PM -0800, Tim Rice wrote: > > On Fri, 23 Nov 2001 openssh-unix-dev at thewrittenword.com wrote: > > > On Fri, Nov 23, 2001 at 10:51:53AM -0800, Tim Rice wrote: > > > On Fri, 23 Nov 2001, Corinna Vinschen wrote: > > > > > > > No, it doesn't, unfortunately. recomp is defined in Cygwin even > > > > without the external regex library but it's a very old implementation > > > > which is incompatible with POSIX regex and which is still in Cygwin > > > > for some sort of backward compatibility. That means the test for > > > > regcomp() works successfully and so the test is sure that using regex > > > > is sure even without linking against -lregex. But the compiled ssh > > > > doesn't work then. > > > > > > > > Corinna > > > > > > Try this patch. > > > It gives preference to libregex over regex functions in libc. > > > > Ick. If the version in libc is incompatible with POSIX regex, why not > > AC_TRY_RUN with code that will work with POSIX regex but fail with the > > libc version. This would probably be more portable and a better > > long-term solution. > > > > Yes, The more I think about it the more I don't like my fix. > Corinna, can you track down where ssh is failing with the libc regex > and write a small test program to test this? Testing for regfree() or regex.h would be sufficient. The old V8 implementation doesn't have regfree() and the header is regexp.h. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From cmadams at hiwaay.net Sun Nov 25 04:21:23 2001 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 24 Nov 2001 11:21:23 -0600 Subject: ssh-dummy-shell In-Reply-To: <20011124125916.G22093@folly>; from markus@openbsd.org on Sat, Nov 24, 2001 at 12:59:16PM +0100 References: <20011123204055.B13862@faui02.informatik.uni-erlangen.de> <20011124125916.G22093@folly> Message-ID: <20011124112123.L676@HiWAAY.net> Once upon a time, Markus Friedl said: > but chroot $HOME is a bad idea. it has to be chroot $HOME/subdir, > otherwise the user can edit .ssh and other .-files (.forward, etc). You could make $HOME owner by someone other than the user. That would keep them from creating arbitrary files and/or directories. They would only be able to modify files under directories that are created for them. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Paul_Fisher at DarkHorseMed.com Sun Nov 25 06:12:37 2001 From: Paul_Fisher at DarkHorseMed.com (Paul E. Fisher) Date: Sat, 24 Nov 2001 15:12:37 -0400 Subject: stuck Message-ID: Hello, Upon doing: #./configure checking for gcc... gcc checking for C compiler default output... configure: error: C compiler cannot create executables I have attached the logfile. Any help would be appreciated. Thank you in advance, -Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: %config.log Type: application/applefile Size: 120 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011124/291ec70b/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 2550 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011124/291ec70b/attachment.obj From tim at multitalents.net Sun Nov 25 08:11:05 2001 From: tim at multitalents.net (Tim Rice) Date: Sat, 24 Nov 2001 13:11:05 -0800 (PST) Subject: stuck In-Reply-To: Message-ID: On Sat, 24 Nov 2001, Paul E. Fisher wrote: > Hello, > > Upon doing: > #./configure > checking for gcc... gcc > checking for C compiler default output... configure: error: C compiler > cannot create executables > > I have attached the logfile. Any help would be appreciated. > > Thank you in advance, > -Paul configure:1373: checking for C compiler default output configure:1376: gcc conftest.c >&5 gcc: installation problem, cannot exec cpp: No such file or directory ^^^^^^^^^^^^^^^ Looks like cpp is not in your search path. Try adding /usr/ccs/bin to your path. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vader at conflict.net Sun Nov 25 19:23:19 2001 From: vader at conflict.net (Jim Breton) Date: Sun, 25 Nov 2001 08:23:19 +0000 Subject: No open channels after timeout Message-ID: <20011125082319090274.425@conflict.net> Howdy. Trying to set up a persistent SSH connection from a remote host, to my own machine with a LocalForward. I am running the ssh process in the foreground so it can be maintained by djb's daemontools to ensure that the connection stays open at all times. But, I am having a problem with the following command (even when run manually from a shell): ssh -N tarkin where in ~/.ssh/config I have the following: Host tarkin User username Protocol 2 LocalForward 466 localhost:25 IdentityFile /home/username/.ssh/id_dsa This works fine without the -N option.. I can log into "tarkin" and get a shell. Using -N, this works only for a short period of time. I can use the locally-forwarded socket and the tunnel is successful. But after a few minutes pass, the connection closes and I get this message in syslog (on the server): sshd[28006]: Disconnecting: No open channels after timeout! The client is FreeBSD-4.4 running OpenSSH 3.0.1p1, the server is OpenBSD 2.9 running OpenSSH 3.0.1. Is there any way to keep a foreground SSH connection open like this? I am also having a secondary issue with this connection but I believe it's unrelated: the _first_ time I connect through the ssh tunnel, I get the following in syslog: sshd[16357]: error: socket: Protocol not supported All following connections through the tunnel do not cause that error to appear. At first I thought perhaps it was a lack of IPv6 support but I tried "telnet -4" on the client system and it didn't make any difference, so I am assuming there is another problem. Any ideas? Not critical, but just a nuisance and possibly a small bug. -- Jim B. vader at conflict.net From jim at bucc.buu.ac.th Sun Nov 25 20:11:06 2001 From: jim at bucc.buu.ac.th (jim at bucc.buu.ac.th) Date: Sun, 25 Nov 2001 16:11:06 +0700 (ICT) Subject: displaying identity key comment string in passphrase prompt Message-ID: <200111250911.fAP9B6K04680@bucc.buu.ac.th> A Feature Request for OpenSSH 3.x: In version 2.x, when prompting for the passphrase ssh would print a prompt including the comment string from an RSA key, like: Enter passphrase for RSA key 'Your Dog's Name': The comment string was a useful way to remind the user what the passphrase was (i didn't use hints quite this easy :-). In Openssh 3.0, ssh prompts using the filename: Enter passphrase for RSA key '/home/staff/jim/.ssh/identity': Could you add an option to let the user choose which style prompt he wants? I.e. prompt by filename or prompt by comment. If there is no comment, then prompt using the filename. Below are the mods to the openssh-3.0p1 source to do this. The option name I used (for the ~/.ssh/config file) is: DisplayCommentString [yes|no] Default: no You can choose whatever name for this option you think is appropriate. Will you consider adding this prompting option? thanks, Jim Brucker Modifications: ============== Here are explanations of the changes and diffs. The "BUCC" comments are used by me -- feel free to delete them. ============== readconf.h - add (int) display_comment_str to the Options struct. diff: 104a105,106 > > int display_comment_str; /* display comment string in prompts */ ============== readconf.c - in global section, add to the end of "typedef enum": - in global section, "static struct { ... keywords[] = ", add near the end of the keywords[] array: - in initialize_options(), initialize the display_comment_str option to -1. - in fill_default_options(), if the display_comment_str option hasn't been set (-1) then set it to 0 ("no"). - in process_config_line() just before the 'default' case, add a case to process the oDisplayCommentStr option. diff: 118c118,119 < oClearAllForwardings, oNoHostAuthenticationForLocalhost --- > oClearAllForwardings, oNoHostAuthenticationForLocalhost, > oDisplayCommentStr 189a191 > { "displaycommentstring", oDisplayCommentStr }, 680a683,686 > case oDisplayCommentStr: > intptr = &options->display_comment_str; > goto parse_flag; > 801a808 > options->display_comment_str = -1; 926a934,935 > if (options->display_comment_str == -1) > options->display_comment_str = 0; =============== sshconnect1.c - in try_rsa_authentication() add a keycomment pointer and a few lines to print the keycomment string if requested and the comment string exists. diff: 212a213 > char *keycomment; //BUCC: key comment string 259c260,267 < private = key_load_private_type(KEY_RSA1, authfile, "", NULL); --- > { > //BUCC, change: private = key_load_private_type(KEY_RSA1, authfile, "", NULL); > //BUCC, to: > private = key_load_private_type(KEY_RSA1, authfile, "", &keycomment); > if (options.display_comment_str && keycomment && *keycomment) > comment = keycomment; > } > =============== sshconnect2.c - in load_identity_file() add a comment string pointer and a few lines to print the key comment if requested and the comment string exists. diff: 603a604,605 > // added: > char *comment; 611c613,622 < private = key_load_private_type(KEY_UNSPEC, filename, "", NULL); --- > > comment = NULL; > > debug("load_identity_file: loading private key from %s", filename); > > // private = key_load_private_type(KEY_UNSPEC, filename, "", NULL); > private = key_load_private_type(KEY_UNSPEC, filename, "", &comment); > if (comment && *comment) > debug("load_identity_file: private key comment is %s", comment); > 616c631,635 < "Enter passphrase for key '%.100s': ", filename); --- > // "Enter passphrase for key '%.100s': ", filename); > "Enter passphrase for key '%.100s': ", > (options.display_comment_str && comment && *comment) ? > comment : filename); From pejn at uow.edu.au Sun Nov 25 14:57:49 2001 From: pejn at uow.edu.au (Paul Nulsen) Date: Sun, 25 Nov 2001 14:57:49 +1100 (EST) Subject: Bug openssh-3.0.1p1 + openssl-0.9.6b build Message-ID: <200111250357.OAA20165@wumpus.its.uow.edu.au> Apologies for not using bugzilla, but time is short: Trying to configure openssh-3.0.1p1 from source on a Linux Mandrake system with a freshly built openssl-engine-0.9.6b, using the command ./configure --with-ipv4-default --with-md5-passwords fails with the error message "Could not find working OpenSSL library." The config.log shows that the problem is due to unresolved references to dlopen, etc. from libcrypto.a. Adding -ldl to -lcrypto in the configure script fixes this for me. Note that the problem does not occur if you configure --with-pam, since that adds -ldl already. Paul Nulsen From vader at conflict.net Mon Nov 26 04:03:01 2001 From: vader at conflict.net (Jim Breton) Date: Sun, 25 Nov 2001 17:03:01 +0000 Subject: No open channels after timeout In-Reply-To: <20011125082319090274.425@conflict.net>; from vader@conflict.net on Sun, Nov 25, 2001 at 08:23:19AM +0000 References: <20011125082319090274.425@conflict.net> Message-ID: <20011125170301901300.425@conflict.net> On Sun, Nov 25, 2001 at 08:23:19AM +0000, Jim Breton wrote: > I am also having a secondary issue with this connection but I believe > it's unrelated: the _first_ time I connect through the ssh tunnel, I get > the following in syslog: > > sshd[16357]: error: socket: Protocol not supported > > All following connections through the tunnel do not cause that error to > appear. At first I thought perhaps it was a lack of IPv6 support but I > tried "telnet -4" on the client system and it didn't make any > difference, so I am assuming there is another problem. Any ideas? Not > critical, but just a nuisance and possibly a small bug. Correction: this _does_ happen every time (not just the first). I hadn't noticed it because syslogd was collating the errors into one of its "last message repeated n times" messages. This is really very annoying and unusable now, because I have the auth logs going to a printer. ;) Any help with this? Thanks. -- Jim B. vader at conflict.net From postspisok1 at yahoo.com Mon Nov 26 15:19:17 2001 From: postspisok1 at yahoo.com (GoodNews) Date: Sun, 25 Nov 2001 20:19:17 -0800 (PST) Subject: No subject Message-ID: <20011126041917.76647.qmail@web20202.mail.yahoo.com> ??????? ????! ??????, ??? ??????? ???? ????? ?? ?????? ??????? ????????,??? ??? ?? ??? ?????? ?? ??????????? ????????? ???????? ? ?????????? ??????,?? ? ???????, ??? ????????? ????? ???????????? ??????? ?????? ?????????, ???? ?? ???????? ???????? ???? ?????? ?? ?????????? ???? ????????????????. ???????????? ? ????? ???????? ???? ?????! ? ??? ????? ????????????? ?????????, ??????? ???????????, ? ????????? ????????????? ?????????? ??????, ???????? ?? ??? ?? ????? ??????? ??????. ???? ????? ????????? ????? ?? ????? ???? ????????? ?? 100%, ????? ??????, ??? ??????. ?? ??????? ?????????? ????? 1.000.000 ?????? ? ??????????? 90 ????. ??? ?? ?????? ??????, ? ???????? ????????? ??????????? ?????????? ??????. ?? ????????? ???????, ???????????? ? ???????????? ??????????, ? ????? ? ???????????? ??????? ??? ???! ?????? ?????? ?????? ? ??? ?? ???? ????? ???? ???????????? ???, ?????? ? ??? ?? ??????????. ?? ???? ? ??? ??????? ? ?????? ??????, ?? ??????????, ???? ??? ???????? ?????? ? ?? ???,????????? ?? ????? ????????? ??????? ?????, ?????? ???? ????????????? ??????. ???? ??? ??? ?????????????? ? ?? ??????? ?????? ?????? ? ?????? ???????????? ?????????, ?? ?????? ????????? ?????? ????????? ??????? ? ???????? "More", ??? ?? ? ??????? ??? ????????? ???????? ?????? ??????? ?? ?????? ???????, ? ?? ???????? ???? ????? ? ?? ??????? ???? ?????? ?? ????????? ?????????? ?????????. ???????????? ??? ?????? ??????? ?????? ?????, ??? ?? ????????? ?????????????, ???????? ??? ?????????. ?? ???? ?? ?????? ?????????? ? ????????? ???, ?? ?????????? :-) ???????, ??? ?????? ????? :-) ??? ??? ????????, ??? ??????? ???? ?????. ??????? ??? ? ????????? ????! __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 From markus at openbsd.org Mon Nov 26 19:58:46 2001 From: markus at openbsd.org (Markus Friedl) Date: Mon, 26 Nov 2001 09:58:46 +0100 Subject: displaying identity key comment string in passphrase prompt In-Reply-To: <200111250911.fAP9B6K04680@bucc.buu.ac.th>; from jim@bucc.buu.ac.th on Sun, Nov 25, 2001 at 04:11:06PM +0700 References: <200111250911.fAP9B6K04680@bucc.buu.ac.th> Message-ID: <20011126095846.G25182@faui02.informatik.uni-erlangen.de> On Sun, Nov 25, 2001 at 04:11:06PM +0700, jim at bucc.buu.ac.th wrote: > Will you consider adding this prompting option? won't happen. there are no comments in private PEM keys. -m From markus at openbsd.org Mon Nov 26 20:00:28 2001 From: markus at openbsd.org (Markus Friedl) Date: Mon, 26 Nov 2001 10:00:28 +0100 Subject: displaying identity key comment string in passphrase prompt In-Reply-To: <200111250911.fAP9B6K04680@bucc.buu.ac.th>; from jim@bucc.buu.ac.th on Sun, Nov 25, 2001 at 04:11:06PM +0700 References: <200111250911.fAP9B6K04680@bucc.buu.ac.th> Message-ID: <20011126100028.H25182@faui02.informatik.uni-erlangen.de> On Sun, Nov 25, 2001 at 04:11:06PM +0700, jim at bucc.buu.ac.th wrote: > > //BUCC, change: private = key_load_private_type(KEY_RSA1, authfile, "", NULL); diff -u is much more readable, then you don't need embeded comments in the patch (i.e. remove is obvious from the diff output). From markus at openbsd.org Mon Nov 26 20:08:51 2001 From: markus at openbsd.org (Markus Friedl) Date: Mon, 26 Nov 2001 10:08:51 +0100 Subject: No open channels after timeout In-Reply-To: <20011125082319090274.425@conflict.net>; from vader@conflict.net on Sun, Nov 25, 2001 at 08:23:19AM +0000 References: <20011125082319090274.425@conflict.net> Message-ID: <20011126100851.I25182@faui02.informatik.uni-erlangen.de> On Sun, Nov 25, 2001 at 08:23:19AM +0000, Jim Breton wrote: > sshd[28006]: Disconnecting: No open channels after timeout! openssh does not print this. are you using a modified version of openssh? From vader at conflict.net Mon Nov 26 20:27:52 2001 From: vader at conflict.net (Jim Breton) Date: Mon, 26 Nov 2001 09:27:52 +0000 Subject: No open channels after timeout In-Reply-To: <20011126100851.I25182@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Mon, Nov 26, 2001 at 10:08:51AM +0100 References: <20011125082319090274.425@conflict.net> <20011126100851.I25182@faui02.informatik.uni-erlangen.de> Message-ID: <20011126092752301961.425@conflict.net> On Mon, Nov 26, 2001 at 10:08:51AM +0100, Markus Friedl wrote: > > sshd[28006]: Disconnecting: No open channels after timeout! > > openssh does not print this. are you using a modified > version of openssh? Nope, standard OpenSSH for OpenBSD 2.9. No modifications. I see the string in serverloop.c on line 174. -- Jim B. vader at conflict.net From markus at openbsd.org Mon Nov 26 20:47:10 2001 From: markus at openbsd.org (Markus Friedl) Date: Mon, 26 Nov 2001 10:47:10 +0100 Subject: No open channels after timeout In-Reply-To: <20011126092752301961.425@conflict.net>; from vader@conflict.net on Mon, Nov 26, 2001 at 09:27:52AM +0000 References: <20011125082319090274.425@conflict.net> <20011126100851.I25182@faui02.informatik.uni-erlangen.de> <20011126092752301961.425@conflict.net> Message-ID: <20011126104710.B1094@faui02.informatik.uni-erlangen.de> On Mon, Nov 26, 2001 at 09:27:52AM +0000, Jim Breton wrote: > On Mon, Nov 26, 2001 at 10:08:51AM +0100, Markus Friedl wrote: > > > sshd[28006]: Disconnecting: No open channels after timeout! > > > > openssh does not print this. are you using a modified > > version of openssh? > > Nope, standard OpenSSH for OpenBSD 2.9. No modifications. > > I see the string in serverloop.c on line 174. oh, sorry, yes, i see, but then the server requests this feature. the server has enabled the keep alive hack, and this conflicts with the -N client option. From vinschen at redhat.com Tue Nov 27 00:13:54 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 26 Nov 2001 14:13:54 +0100 Subject: [PATCH]: Allow SSHD to install as service under WIndows 9x/Me In-Reply-To: <20011120141359.R14154@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Nov 20, 2001 at 02:13:59PM +0100 References: <20011120140119.P14154@cygbert.vinschen.de> <20011120141359.R14154@cygbert.vinschen.de> Message-ID: <20011126141354.A14975@cygbert.vinschen.de> Hi, did anybody with CVS write access look into this patch? It would be nice to get that included with 3.0.1p2 or 3.0.2p1. Corinna On Tue, Nov 20, 2001 at 02:13:59PM +0100, Corinna Vinschen wrote: > On Tue, Nov 20, 2001 at 02:01:19PM +0100, Corinna Vinschen wrote: > > Hi, > > > > the following patch is a (hopefully least intrusive) extension > > when sshd is started so that it daemonizes itself. In that case > > Windows 9x/Me has a slight problem with sshd as soon as the current > > user logs off. The sshd daemon will be killed as well. Since > > installing services is very different between NT and 9x, the way > > used for NT boxes isn't working well for 9x. For that reason > > several 9x users have asked for a solution which allows _real_ > > daemonizing sshd on their boxes. The following patch allows to do that. > > > > When the function daemon() forks, the child process is registered as a > > service when started on a 9x system. The functionality is outsourced > > to bsd-cygwin_util.c, the daemon.c code just contains a conditionalized > > call to the new function. Hope, that's ok. > > > > Additionally I added a patch to contrib/cygwin/README, which just fixes > > a typo. > > > > Thanks in advance, > > Corinna > > Sorry. I just found another error in the README and I thought it > might be better to add a hint which discribes the new functionality > for 9x users. So the following patch substitutes the previous one. > > Thanks, > Corinna > > Index: contrib/cygwin/README > =================================================================== > RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v > retrieving revision 1.6 > diff -u -p -r1.6 README > --- contrib/cygwin/README 2001/07/18 16:25:42 1.6 > +++ contrib/cygwin/README 2001/11/20 13:12:39 > @@ -1,6 +1,14 @@ > This package is the actual port of OpenSSH to Cygwin 1.3. > > =========================================================================== > +Important change since 3.0.1p1-2: > + > +This version introduces the ability to register sshd as service on > +Windows 9x/Me systems. This is done only when the options -D and/or > +-d are not given. > +=========================================================================== > + > +=========================================================================== > Important change since 2.9p2: > > Since Cygwin is able to switch user context without password beginning > @@ -162,12 +170,10 @@ configure are used for the Cygwin binary > > --prefix=/usr \ > --sysconfdir=/etc \ > - --libexecdir='${exec_prefix}/sbin \ > - --with-pcre > + --libexecdir='${exec_prefix}/sbin' > > You must have installed the zlib, openssl and regex packages to > -be able to build OpenSSH! The `--with-pcre' option requires > -the installation of the pcre package. > +be able to build OpenSSH! > > Please send requests, error reports etc. to cygwin at cygwin.com. > > Index: openbsd-compat/bsd-cygwin_util.c > =================================================================== > RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.c,v > retrieving revision 1.5 > diff -u -p -r1.5 bsd-cygwin_util.c > --- openbsd-compat/bsd-cygwin_util.c 2001/07/18 16:19:49 1.5 > +++ openbsd-compat/bsd-cygwin_util.c 2001/11/20 13:12:39 > @@ -139,4 +139,26 @@ int check_ntsec(const char *filename) > return 0; > } > > +void register_9x_service(void) > +{ > + HINSTANCE kerneldll; > + DWORD (*RegisterServiceProcess)(DWORD, DWORD); > + > + /* The service register mechanism in 9x/Me is pretty different from > + * NT/2K/XP. In NT/2K/XP we're using a special service starter > + * application to register and control sshd as service. This method > + * doesn't play nicely with 9x/Me. For that reason we register here > + * as service when running under 9x/Me. This function is only called > + * by the child sshd when it's going to daemonize. > + */ > + if (is_winnt) > + return; > + if (! (kerneldll = LoadLibrary("KERNEL32.DLL"))) > + return; > + if (! (RegisterServiceProcess = (DWORD (*)(DWORD, DWORD)) > + GetProcAddress(kerneldll, "RegisterServiceProcess"))) > + return; > + RegisterServiceProcess(0, 1); > +} > + > #endif /* HAVE_CYGWIN */ > Index: openbsd-compat/bsd-cygwin_util.h > =================================================================== > RCS file: /cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.h,v > retrieving revision 1.4 > diff -u -p -r1.4 bsd-cygwin_util.h > --- openbsd-compat/bsd-cygwin_util.h 2001/04/13 14:28:43 1.4 > +++ openbsd-compat/bsd-cygwin_util.h 2001/11/20 13:12:39 > @@ -26,6 +26,7 @@ int binary_open(const char *filename, in > int binary_pipe(int fd[2]); > int check_nt_auth(int pwd_authenticated, uid_t uid); > int check_ntsec(const char *filename); > +void register_9x_service(void); > > #define open binary_open > #define pipe binary_pipe > Index: openbsd-compat/daemon.c > =================================================================== > RCS file: /cvs/openssh_cvs/openbsd-compat/daemon.c,v > retrieving revision 1.1 > diff -u -p -r1.1 daemon.c > --- openbsd-compat/daemon.c 2001/01/31 21:52:03 1.1 > +++ openbsd-compat/daemon.c 2001/11/20 13:12:39 > @@ -49,6 +49,9 @@ daemon(nochdir, noclose) > case -1: > return (-1); > case 0: > +#ifdef HAVE_CYGWIN > + register_9x_service(); > +#endif > break; > default: > #ifdef HAVE_CYGWIN > > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Tue Nov 27 01:28:53 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 26 Nov 2001 15:28:53 +0100 Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: <20011124130746.X14975@cygbert.vinschen.de>; from vinschen@redhat.com on Sat, Nov 24, 2001 at 01:07:46PM +0100 References: <20011123141539.A78528@oolong.il.thewrittenword.com> <20011124130746.X14975@cygbert.vinschen.de> Message-ID: <20011126152853.B14975@cygbert.vinschen.de> On Sat, Nov 24, 2001 at 01:07:46PM +0100, Corinna Vinschen wrote: > On Fri, Nov 23, 2001 at 06:24:38PM -0800, Tim Rice wrote: > > Yes, The more I think about it the more I don't like my fix. > > Corinna, can you track down where ssh is failing with the libc regex > > and write a small test program to test this? > > Testing for regfree() or regex.h would be sufficient. The old V8 > implementation doesn't have regfree() and the header is regexp.h. Aaargh! Somebody added a regfree stub into Cygwin back in 1997 and now we're stuck with that way. We could remove it from current Cygwin sources but that wouldn't help for older Cygwin versions, apparently. However, I think the following solution would help. It tests for regcomp() first and if regcomp() is available, it tests additionally for regsub() which is not defined in POSIX regex but in V8 regex. If regsub() is available, it assumes that the libc version is not usable and doesn't define HAVE_REGCOMP. Then, if HAVE_REGCOMP isn't defined, it checks for regcomp() in libregex and if that's also not available it eventually checks for libpcre. Is that ok? Corinna Index: configure.ac =================================================================== RCS file: /cvs/openssh_cvs/configure.ac,v retrieving revision 1.4 diff -u -p -r1.4 configure.ac --- configure.ac 2001/11/03 19:09:33 1.4 +++ configure.ac 2001/11/26 14:28:42 @@ -65,7 +65,7 @@ case "$host" in AC_DEFINE(DISABLE_LASTLOG) ;; *-*-cygwin*) - LIBS="$LIBS -lregex /usr/lib/textmode.o" + LIBS="$LIBS /usr/lib/textmode.o" AC_DEFINE(HAVE_CYGWIN) AC_DEFINE(USE_PIPES) AC_DEFINE(DISABLE_SHADOW) @@ -401,18 +401,43 @@ AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([ # We don't want to check if we did an pcre override. if test -z "$no_comp_check" ; then AC_CHECK_FUNC(regcomp, - [ AC_DEFINE(HAVE_REGCOMP)], [ - AC_CHECK_LIB(pcre, pcre_info, + AC_CHECK_FUNC(regsub, + [ + has_regcomp=no + ], + [ + AC_DEFINE(HAVE_REGCOMP) + has_regcomp=yes + ] + ) + ], + [ + has_regcomp=no + ] + ) + # Either regcomp wasn't defined or regsub is defined (which means + # that the libc regex is probably an old non-POSIX implementation. + # Now check for -lregex and -lpcreposix to find some usable regex + # implementation. + if test "$has_regcomp" = "no" ; then + AC_CHECK_LIB(regex, regcomp, [ - AC_DEFINE(HAVE_LIBPCRE) - LIBS="$LIBS -lpcreposix -lpcre" + AC_DEFINE(HAVE_REGCOMP) + LIBS="$LIBS -lregex" ], [ - AC_MSG_ERROR([*** No regex library found.]) - ]) - ] - ) + AC_CHECK_LIB(pcre, pcre_info, + [ + AC_DEFINE(HAVE_LIBPCRE) + LIBS="$LIBS -lpcreposix -lpcre" + ], + [ + AC_MSG_ERROR([*** No regex library found.]) + ]) + ] + ) + fi fi dnl UnixWare 2.x -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From dan at doxpara.com Tue Nov 27 01:42:49 2001 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 26 Nov 2001 06:42:49 -0800 Subject: [PATCH]: Allow SSHD to install as service under WIndows 9x/Me References: <20011120140119.P14154@cygbert.vinschen.de> <20011120141359.R14154@cygbert.vinschen.de> <20011126141354.A14975@cygbert.vinschen.de> Message-ID: <004d01c17688$9f295340$1701000a@effugas> > Hi, > > did anybody with CVS write access look into this patch? It would > be nice to get that included with 3.0.1p2 or 3.0.2p1. For what it's worth, I'd *very* much like to see this go in. FTP needs to die, and I am really starting to see SFTP as its heir apparent. The more platforms can easily support SFTP, the quicker the changeover will happen. Network effects and all that. --Dan From djast at cs.toronto.edu Tue Nov 27 03:41:26 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Mon, 26 Nov 2001 11:41:26 -0500 Subject: ssh-dummy-shell In-Reply-To: Your message of "Sat, 24 Nov 2001 06:42:52 EST." <20011124124252.A22093@folly> Message-ID: <01Nov26.114132edt.453144-19376@jane.cs.toronto.edu> On Sat, 24 Nov 2001 06:42:52 EST, Markus Friedl writes: > > > > One must be careful: if $HOME/.ssh is writable or can be made so, > > $HOME/.ssh/environment is an attack vector. > > yes, i metioned this before. If I were to submit a simple patch for sftp-server that would cause it to exit with an error if get_progname(pw->pw_shell) matched get_progname(argv[0]) AND either pw->pw_dir or (pw->pw_dir)/.ssh was writable by the user, would such a patch be likely to be accepted? This would not prevent $LD_PRELOAD from being honoured from $HOME/.ssh/environment, but it would make it more difficult for the user to upload the files needed to exploit such a setup; more importantly, it would make the misconfiguration more visible to the administrator. I'm presuming that pw->pw_shell and argv[0] having the same basename is a pretty unambiguous indication that the sysadmin intended the account to be sftp-only. It would not cover the case where sftp-server was being run by a wrapper script like ssh-dummy-shell, however: I can't think of a simple or reliable way to detect that. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From mouring at etoh.eviladmin.org Tue Nov 27 05:37:32 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 26 Nov 2001 12:37:32 -0600 (CST) Subject: ssh-dummy-shell In-Reply-To: <01Nov26.114132edt.453144-19376@jane.cs.toronto.edu> Message-ID: On Mon, 26 Nov 2001, Dan Astoorian wrote: > On Sat, 24 Nov 2001 06:42:52 EST, Markus Friedl writes: > > > > > > One must be careful: if $HOME/.ssh is writable or can be made so, > > > $HOME/.ssh/environment is an attack vector. > > > > yes, i metioned this before. > > If I were to submit a simple patch for sftp-server that would cause it > to exit with an error if get_progname(pw->pw_shell) matched > get_progname(argv[0]) AND either pw->pw_dir or (pw->pw_dir)/.ssh was > writable by the user, would such a patch be likely to be accepted? > Doubtfully. I'm in favour (and once I move into my house it is high on my priority list since I need the functonality) of supporting: subsystem sftp /path/to/sftp-server -c %{HOME_OF_USER}/subdir/ - Ben From vader at conflict.net Tue Nov 27 07:22:35 2001 From: vader at conflict.net (Jim Breton) Date: Mon, 26 Nov 2001 20:22:35 +0000 Subject: No open channels after timeout In-Reply-To: <20011126104710.B1094@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Mon, Nov 26, 2001 at 10:47:10AM +0100 References: <20011125082319090274.425@conflict.net> <20011126100851.I25182@faui02.informatik.uni-erlangen.de> <20011126092752301961.425@conflict.net> <20011126104710.B1094@faui02.informatik.uni-erlangen.de> Message-ID: <20011126202235436707.425@conflict.net> On Mon, Nov 26, 2001 at 10:47:10AM +0100, Markus Friedl wrote: > the server has enabled the keep alive hack, and this > conflicts with the -N client option. Ahh. OK, thank you. Is there a work-around for this? Looks like the client can turn KeepAlive on and off, but I don't see any way for the client to turn off ClientAlive? Running the following seems to work but is a "Crude Hack" (TM): ssh -T tarkin > /dev/null 2>&1 As for the other problem I mentioned ("error: socket: Protocol not supported"), I cleared this up by running sshd with the -4 switch. Thanks. -- Jim B. vader at conflict.net From staatsvr at asc.hpc.mil Tue Nov 27 07:45:06 2001 From: staatsvr at asc.hpc.mil (Vern Staats) Date: Mon, 26 Nov 2001 15:45:06 -0500 Subject: [PATCH] Re: Kerberos support for portable In-Reply-To: <200111171140.LAA00508@canna.dcs.ed.ac.uk>; from sxw@dcs.ed.ac.uk on Sat, Nov 17, 2001 at 11:40:51AM +0000 References: <200111171140.LAA00508@canna.dcs.ed.ac.uk> Message-ID: <20011126154506.A12741@sw4.asc.hpc.mil> On Sat, Nov 17, 2001 at 11:40:51AM +0000, Simon Wilkinson wrote: > [...] > Thanks for these. Unfortunately, your vrs patches seem to be based on > an earlier version of my patch than the one you're bundling. In particular, > your patch adds back in the incorrect replay cache code (it uses the wrong > cache name), and takes out the use_uid calls that are necessary to make > verify_init_creds() work correctly. It also adds back in the xfree() calls > in auth1.c that I removed - these have to be removed to make it work reliably. I'm sorry not to have responded before now - I took last week off. It looks like you're right. I had intended to combine your later krb5 patch with your auth1.c patch, and then #ifdef out the parts that couldn't be easily reconciled with krb5 1.0.6. > I am right in thinking that the basic change that is required is to > conditionally remove auth_krb5_password (or just make it a stub that > does nothing useful) if built against old MIT Kerberoses? Yes, because auth_krb5_password needs get_, verify_init_creds(), which are missing in krb5 1.0.6. > Finally there are a couple of patches to the rijandel code that don't seem > related? Some time back I had problems with the u8/u16/u32 unsigned typedefs in openssl rijndael/rd_fst.h getting redefined. I think this only happened in the openssl applications (some subset of lynx, w3m, curl, and stunnel)... and looking at my application patches all I see is stunnel. So why didn't I just patch stunnel instead of mucking with the main code? I'm not sure, but I think there was a reason. I'm overdue to update the kssl patches. I should probably revert to the original rd_fst.h and revisit this. -- "My company prefers to have that kind of decision made by uninformed executives. We call it "Empowerment". --Dilbert staatsvr at asc.hpc.mil Vern Staats, ASC/HPTS, WPAFB OH 45433, 937-255-1616x449 From tim at multitalents.net Tue Nov 27 12:26:03 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 26 Nov 2001 17:26:03 -0800 (PST) Subject: [PATCH]: Fix configure.ac to allow linking against PCRE on Cygwin In-Reply-To: <20011126152853.B14975@cygbert.vinschen.de> Message-ID: Commited. Thanks. On Mon, 26 Nov 2001, Corinna Vinschen wrote: > On Sat, Nov 24, 2001 at 01:07:46PM +0100, Corinna Vinschen wrote: > > On Fri, Nov 23, 2001 at 06:24:38PM -0800, Tim Rice wrote: > > > Yes, The more I think about it the more I don't like my fix. > > > Corinna, can you track down where ssh is failing with the libc regex > > > and write a small test program to test this? > > > > Testing for regfree() or regex.h would be sufficient. The old V8 > > implementation doesn't have regfree() and the header is regexp.h. > > Aaargh! Somebody added a regfree stub into Cygwin back in 1997 and > now we're stuck with that way. We could remove it from current Cygwin > sources but that wouldn't help for older Cygwin versions, apparently. > > However, I think the following solution would help. It tests for > regcomp() first and if regcomp() is available, it tests additionally > for regsub() which is not defined in POSIX regex but in V8 regex. > If regsub() is available, it assumes that the libc version is not > usable and doesn't define HAVE_REGCOMP. > > Then, if HAVE_REGCOMP isn't defined, it checks for regcomp() in > libregex and if that's also not available it eventually checks > for libpcre. > > Is that ok? > > Corinna > [patch snipped] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From tim at multitalents.net Tue Nov 27 12:27:58 2001 From: tim at multitalents.net (Tim Rice) Date: Mon, 26 Nov 2001 17:27:58 -0800 (PST) Subject: [PATCH]: Allow SSHD to install as service under WIndows 9x/Me In-Reply-To: <20011126141354.A14975@cygbert.vinschen.de> Message-ID: On Mon, 26 Nov 2001, Corinna Vinschen wrote: > Hi, > > did anybody with CVS write access look into this patch? It would > be nice to get that included with 3.0.1p2 or 3.0.2p1. Commited. > > Corinna > > On Tue, Nov 20, 2001 at 02:13:59PM +0100, Corinna Vinschen wrote: > > On Tue, Nov 20, 2001 at 02:01:19PM +0100, Corinna Vinschen wrote: > > > Hi, > > > > > > the following patch is a (hopefully least intrusive) extension > > > when sshd is started so that it daemonizes itself. In that case > > > Windows 9x/Me has a slight problem with sshd as soon as the current > > > user logs off. The sshd daemon will be killed as well. Since > > > installing services is very different between NT and 9x, the way > > > used for NT boxes isn't working well for 9x. For that reason > > > several 9x users have asked for a solution which allows _real_ > > > daemonizing sshd on their boxes. The following patch allows to do that. > > > > > > When the function daemon() forks, the child process is registered as a > > > service when started on a 9x system. The functionality is outsourced > > > to bsd-cygwin_util.c, the daemon.c code just contains a conditionalized > > > call to the new function. Hope, that's ok. > > > > > > Additionally I added a patch to contrib/cygwin/README, which just fixes > > > a typo. > > > > > > Thanks in advance, > > > Corinna > > [patch sniped] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From michael at moria.de Tue Nov 27 13:35:36 2001 From: michael at moria.de (michael at moria.de) Date: 27 Nov 2001 02:35:36 -0000 Subject: 3.0.1p1 losing tty modes? Message-ID: <20011127023536.463.qmail@palantir.moria.de> Hello, openssh-3.0.1p1 appears to transmit and parse tty modes correctly, but later in the code it uses vhangup() to close all tty references and reset the tty to default modes. I don't think that vhangup() should be needed on Unix98 ptys, possibly not even on BSD ptys, and I am probably wrong, so please tell me where. Of course vhangup() clears all tty modes, so you need to save them before and restore them to the newly opened tty afterwards. This is on Linux 2.4.14, but the problem looks quite portable to me for all systems that have vhangup(). This patch shows my solution, but it's only a hack to me until I know why vhangup() is needed: --- sshpty.c.orig Tue Nov 27 02:32:50 2001 +++ sshpty.c Tue Nov 27 02:33:45 2001 @@ -252,6 +252,7 @@ int fd; #ifdef USE_VHANGUP void *old; + struct termios tio; #endif /* USE_VHANGUP */ #ifdef _CRAY @@ -310,6 +311,7 @@ #endif /* HAVE_NEWS4 */ #ifdef USE_VHANGUP old = mysignal(SIGHUP, SIG_IGN); + tcgetattr(*ttyfd,&tio); vhangup(); mysignal(SIGHUP, old); #endif /* USE_VHANGUP */ @@ -320,6 +322,7 @@ #ifdef USE_VHANGUP close(*ttyfd); *ttyfd = fd; + tcsetattr(*ttyfd,TCSANOW,&tio); #else /* USE_VHANGUP */ close(fd); #endif /* USE_VHANGUP */ I am not subscribed to the list, so please cc: to me. Michael From odie at rotta.media.sonera.net Tue Nov 27 18:46:40 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Tue, 27 Nov 2001 09:46:40 +0200 Subject: [PATCH] tcp-wrappers support extended to x11 forwards Message-ID: <200111270746.fAR7keP05642@rotta.tmt.tele.fi> Hi! Here is the patch to support tcp wrappers with x11-forwarded connections. The patch is for openssh-3.0.1p1 but it works fine with 2.9.9p2 too. I've understood that this will not be included in the official version because it adds complexity (?!) to openssh. Binding the forwarded port to localhost doesn't solve all problems. I've understood that you should also implement forwarding for x11 unix domain sockets. Therefore I would ask you to reconsider of putting something like my patch here into official version of openssh. After all, it uses tcp wrappers only if they are enabled as configure option. There is a reason why port 22 has support for tcp-wrappers. I think that same reason applies to x11 forwarded ports. If the forwarded port can be bound to localhost and it doesn't cause any additional problems then this patch is obsolete. Since there is no working solution to the localhost display would you please consider this patch? All comments are wellcome. -- Osmo Paananen -------------- next part -------------- diff -u openssh-3.0.1p1/channels.c openssh-modified/channels.c --- openssh-3.0.1p1/channels.c Fri Oct 12 04:35:05 2001 +++ openssh-modified/channels.c Mon Nov 26 15:53:04 2001 @@ -55,6 +55,12 @@ #include "key.h" #include "authfd.h" +#ifdef LIBWRAP +#include +#include +extern int allow_severity; +extern int deny_severity; +#endif /* LIBWRAP */ /* -- channel core */ @@ -1006,6 +1012,25 @@ error("accept: %.100s", strerror(errno)); return; } +#ifdef LIBWRAP + /* XXX LIBWRAP noes not know about IPv6 */ + { + struct request_info req; + + request_init(&req, RQ_DAEMON, "sshdfwd-X11", RQ_FILE, newsock, 0); + fromhost(&req); + + if (!hosts_access(&req)) { + syslog(deny_severity, "refused fwd-X11 connect from %s", eval_client(&req)); + close(newsock); + + return; + } + syslog(allow_severity, "fwd-X11 connect from %s", eval_client(&req)); + + } +#endif /* LIBWRAP */ + remote_ipaddr = get_peer_ipaddr(newsock); remote_port = get_peer_port(newsock); snprintf(buf, sizeof buf, "X11 connection from %.200s port %d", diff -u openssh-3.0.1p1/ssh-keyscan.c openssh-modified/ssh-keyscan.c --- openssh-3.0.1p1/ssh-keyscan.c Wed Nov 14 23:40:45 2001 +++ openssh-modified/ssh-keyscan.c Mon Nov 26 14:04:42 2001 @@ -34,6 +34,13 @@ #include "atomicio.h" #include "misc.h" +#ifdef LIBWRAP +#include +#include +int allow_severity = LOG_INFO; +int deny_severity = LOG_WARNING; +#endif /* LIBWRAP */ + /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. Default value is AF_UNSPEC means both IPv4 and IPv6. */ #ifdef IPV4_DEFAULT diff -u openssh-3.0.1p1/ssh.c openssh-modified/ssh.c --- openssh-3.0.1p1/ssh.c Mon Nov 12 01:52:04 2001 +++ openssh-modified/ssh.c Mon Nov 26 14:04:42 2001 @@ -80,6 +80,15 @@ char *__progname; #endif +#ifdef LIBWRAP +#include +#include +int allow_severity = LOG_INFO; +int deny_severity = LOG_WARNING; +#endif /* LIBWRAP */ + + + /* Flag indicating whether IPv4 or IPv6. This can be set on the command line. Default value is AF_UNSPEC means both IPv4 and IPv6. */ #ifdef IPV4_DEFAULT From cihlar at suse.cz Tue Nov 27 19:37:07 2001 From: cihlar at suse.cz (Jan Cihlar) Date: Tue, 27 Nov 2001 09:37:07 +0100 Subject: patch for problem with "Bind to port 22 on 0.0.0.0 failed: Address already in use." Message-ID: <200111270838.fAR8c6007434@chimera.suse.cz> Hi, there is a cosmetic problem in openssh (all versions AFAIK): When you start sshd with no "ListenAddress" lines in sshd_config, it tries to bind address "::" (successfuly) and then "0.0.0.0" and it fails with "Address already in use". Moreover it can happen that "0.0.0.0" is in addr list sooner than "::" so sshd than will listen only on ipv4 address "0.0.0.0". I have prepared patch for 3.0.1p1 which should solve both problems - I go throught the list and when there are both "0.0.0.0" and "::" on the same port, I remove "0.0.0.0" from the list. I have also removed condition from 'error("Bind to ....")'. When you have two "ListenAddress" lines in sshd_config, one is wrong and the wrong one is tested before the good one, no error is logged. Can you look on it and maybe include it to next version, please? Thanks -- Mgr. Jan Cihlar developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: cihlar at suse.cz Drahobejlova 27 tel:+420 2 96542 373 190 00 Praha 9 fax:+420 2 96542 374 Ceska republika http://www.suse.cz --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-3.0.1p1-addrlist.dif Type: text/x-diff Size: 2503 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011127/bdf097fb/attachment.bin From pekkas at netcore.fi Tue Nov 27 23:37:57 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 27 Nov 2001 14:37:57 +0200 (EET) Subject: patch for problem with "Bind to port 22 on 0.0.0.0 failed: Address already in use." In-Reply-To: <200111270838.fAR8c6007434@chimera.suse.cz> Message-ID: On Tue, 27 Nov 2001, Jan Cihlar wrote: > there is a cosmetic problem in openssh (all versions AFAIK): > > When you start sshd with no "ListenAddress" lines in sshd_config, it > tries to bind address "::" (successfuly) and then "0.0.0.0" and it fails > with "Address already in use". Moreover it can happen that "0.0.0.0" is in > addr list sooner than "::" so sshd than will listen only on ipv4 address > "0.0.0.0". This is a Linuxism; binding with standard kernel to both '::' and '0.0.0.0' will fail. This is because '::' already accepts IPv4 connections though mapped addresses. Double-binding is not possible as with IPv6. Just work around this by listening to :: only, if you have to. It's best to leave ListenAddress empty. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From ed at UDel.Edu Wed Nov 28 02:02:58 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 27 Nov 2001 10:02:58 -0500 (EST) Subject: Problem connecting to v2.9.9p2 on Solaris 8 Message-ID: I ran into a weird problem yesterday where Putty can't connect to my OpenSSH/Sol box (and still can't ever since). On the Putty side I get the error message: "internal fault: chaos in SSH 2 transport layer" I've attached the "sshd -d -d -d" syslog output. Any ideas what's going wrong here? From a layman's point of view, it would appear that Putty and OpenSSH can't decide on key algorithms... but why would this happen? I use Putty to connect to other OpenSSH2.9.9p2/Sol8 installs (the same compiled code) and it works fine... Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key -------------- next part -------------- Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.info] Connection from 128.175.13.182 port 1096 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.info] Connection from 128.175.13.182 port 1096 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5641]: [ID 800047 local4.debug] debug1: Forked child 5848. Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: Client protocol version 2.0; client software version PuTTY Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: no match: PuTTY Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.info] Enabling compatibility mode for protocol 2.0 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.info] Enabling compatibility mode for protocol 2.0 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: Local version string SSH-1.99-OpenSSH_2.9.9p2 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: Rhosts Authentication disabled, originating port not trusted. Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: list_hostkey_types: ssh-rsa Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEXINIT sent Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: SSH2_MSG_KEXINIT received Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: ssh-rsa Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se Nov 27 09:51:03 polycut.nss.udel.edu last message repeated 1 time Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 Nov 27 09:51:03 polycut.nss.udel.edu last message repeated 1 time Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: none,zlib Nov 27 09:51:03 polycut.nss.udel.edu last message repeated 1 time Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: Nov 27 09:51:03 polycut.nss.udel.edu last message repeated 1 time Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: first_kex_follows 0 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: reserved 0 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: ssh-dss Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,3des-cbc Nov 27 09:51:03 polycut.nss.udel.edu last message repeated 1 time Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,none Nov 27 09:51:03 polycut.nss.udel.edu last message repeated 1 time Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: none,zlib,none Nov 27 09:51:03 polycut.nss.udel.edu last message repeated 1 time Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: Nov 27 09:51:03 polycut.nss.udel.edu last message repeated 1 time Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: first_kex_follows 0 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: kex_parse_kexinit: reserved 0 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: mac_init: found hmac-sha1 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: kex: client->server 3des-cbc hmac-sha1 none Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug2: mac_init: found hmac-sha1 Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: kex: server->client 3des-cbc hmac-sha1 none Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.crit] fatal: no hostkey alg Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.crit] fatal: no hostkey alg Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.crit] fatal: no hostkey alg Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: Calling cleanup 0x5e4f8(0x0) Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: Calling cleanup 0x67ec0(0x0) Nov 27 09:51:03 polycut.nss.udel.edu sshd[5848]: [ID 800047 local4.debug] debug1: writing PRNG seed to file //.ssh/prng_seed From peter_m_boyd at yahoo.co.uk Wed Nov 28 01:59:35 2001 From: peter_m_boyd at yahoo.co.uk (=?iso-8859-1?q?Peter=20M=20Boyd?=) Date: Tue, 27 Nov 2001 14:59:35 +0000 (GMT) Subject: SSH cannot do all DOS Commands and actions Message-ID: <20011127145935.15101.qmail@web14402.mail.yahoo.com> Hi!, can you tell me why OpenSSH cannot support full access to the DOS Prompt and all its capabilities. If I set up to connect into CMD.EXE on the target system using OpenSSH, I cannot run the functionality of EDLIN to edit files with data insertion and insert termination with CTRL&Z/C. CTRL&C not actioned for break-out of long running functions. Browse a file using 'type "filename" | more' ( where | means pipe ) does implement the 'more' function. Please tell me why? Peter M Boyd __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From markus at openbsd.org Wed Nov 28 02:16:41 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 27 Nov 2001 16:16:41 +0100 Subject: Problem connecting to v2.9.9p2 on Solaris 8 In-Reply-To: References: Message-ID: <20011127161641.F18303@faui02> On Tue, Nov 27, 2001 at 10:02:58AM -0500, Ed Phillips wrote: > I ran into a weird problem yesterday where Putty can't connect to my > OpenSSH/Sol box (and still can't ever since). On the Putty side I get the > error message: > > "internal fault: chaos in SSH 2 transport layer" > > I've attached the "sshd -d -d -d" syslog output. > > Any ideas what's going wrong here? From a layman's point of view, it > would appear that Putty and OpenSSH can't decide on key algorithms... but > why would this happen? I use Putty to connect to other > OpenSSH2.9.9p2/Sol8 installs (the same compiled code) and it works fine... the sshd offers a ssh v2 RSA hostkey, putty says it can only understand ssh v2 DSA hostkeys, so they cannot agree. i suggest to generate a SSH v2 DSA hostkey, too. From ed at UDel.Edu Wed Nov 28 02:47:03 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 27 Nov 2001 10:47:03 -0500 (EST) Subject: Problem connecting to v2.9.9p2 on Solaris 8 In-Reply-To: <20011127161641.F18303@faui02> Message-ID: On Tue, 27 Nov 2001, Markus Friedl wrote: > Date: Tue, 27 Nov 2001 16:16:41 +0100 > From: Markus Friedl > To: Ed Phillips > Cc: OpenSSH Development > Subject: Re: Problem connecting to v2.9.9p2 on Solaris 8 > > On Tue, Nov 27, 2001 at 10:02:58AM -0500, Ed Phillips wrote: > > I ran into a weird problem yesterday where Putty can't connect to my > > OpenSSH/Sol box (and still can't ever since). On the Putty side I get the > > error message: > > > > "internal fault: chaos in SSH 2 transport layer" > > > > I've attached the "sshd -d -d -d" syslog output. > > > > Any ideas what's going wrong here? From a layman's point of view, it > > would appear that Putty and OpenSSH can't decide on key algorithms... but > > why would this happen? I use Putty to connect to other > > OpenSSH2.9.9p2/Sol8 installs (the same compiled code) and it works fine... > > the sshd offers a ssh v2 RSA hostkey, > putty says it can only understand ssh v2 DSA hostkeys, > so they cannot agree. > > i suggest to generate a SSH v2 DSA hostkey, too. That's it! Thanks! I wasn't aware that Putty only supported DSA in v2... oh well... ;-) Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From mouring at etoh.eviladmin.org Wed Nov 28 02:56:31 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 27 Nov 2001 09:56:31 -0600 (CST) Subject: Problem connecting to v2.9.9p2 on Solaris 8 In-Reply-To: Message-ID: [..] > > > Any ideas what's going wrong here? From a layman's point of view, it > > > would appear that Putty and OpenSSH can't decide on key algorithms... but > > > why would this happen? I use Putty to connect to other > > > OpenSSH2.9.9p2/Sol8 installs (the same compiled code) and it works fine... > > > > the sshd offers a ssh v2 RSA hostkey, > > putty says it can only understand ssh v2 DSA hostkeys, > > so they cannot agree. > > > > i suggest to generate a SSH v2 DSA hostkey, too. > > That's it! Thanks! I wasn't aware that Putty only supported DSA in v2... > oh well... ;-) > As of 0.51 it supports both RSA and DSA.. Which is kinda funny since the author originally railed against DSA and shouted at the top of his lungs that he would never support DSA due to the fact it sucks up too my entropy to be reliable. Rather abrubt 180.. [quote from FAQ] A.7.3 How come PuTTY now supports DSA, when the website used to say how insecure it was? DSA has a major weakness if badly implemented: it relies on a random number generator to far too great an extent. If the random number generator produces a number an attacker can predict, the DSA private key is exposed - meaning that the attacker can log in as you on all systems that accept that key. The PuTTY policy changed because the developers were informed of ways to implement DSA which do not suffer nearly as badly from this weakness, and indeed which don't need to rely on random numbers at all. For this reason we now believe PuTTY's DSA implementation is probably OK. However, if you have the choice, we still recommend you use RSA instead. - Ben From markus at openbsd.org Wed Nov 28 02:58:39 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 27 Nov 2001 16:58:39 +0100 Subject: Problem connecting to v2.9.9p2 on Solaris 8 In-Reply-To: References: <20011127161641.F18303@faui02> Message-ID: <20011127165839.A8252@faui02> On Tue, Nov 27, 2001 at 10:47:03AM -0500, Ed Phillips wrote: > > i suggest to generate a SSH v2 DSA hostkey, too. > > That's it! Thanks! I wasn't aware that Putty only supported DSA in v2... > oh well... ;-) depends on the version of putty. From ed at UDel.Edu Wed Nov 28 03:11:22 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 27 Nov 2001 11:11:22 -0500 (EST) Subject: Problem connecting to v2.9.9p2 on Solaris 8 In-Reply-To: Message-ID: On Tue, 27 Nov 2001 mouring at etoh.eviladmin.org wrote: > Date: Tue, 27 Nov 2001 09:56:31 -0600 (CST) > From: mouring at etoh.eviladmin.org > To: Ed Phillips > Cc: Markus Friedl , > OpenSSH Development > Subject: Re: Problem connecting to v2.9.9p2 on Solaris 8 > > > [..] > > > > Any ideas what's going wrong here? From a layman's point of view, it > > > > would appear that Putty and OpenSSH can't decide on key algorithms... but > > > > why would this happen? I use Putty to connect to other > > > > OpenSSH2.9.9p2/Sol8 installs (the same compiled code) and it works fine... > > > > > > the sshd offers a ssh v2 RSA hostkey, > > > putty says it can only understand ssh v2 DSA hostkeys, > > > so they cannot agree. > > > > > > i suggest to generate a SSH v2 DSA hostkey, too. > > > > That's it! Thanks! I wasn't aware that Putty only supported DSA in v2... > > oh well... ;-) > > > > As of 0.51 it supports both RSA and DSA.. Which is kinda funny since the > author originally railed against DSA and shouted at the top of his lungs > that he would never support DSA due to the fact it sucks up too my entropy > to be reliable. That's strange... I'm using Putty 0.51. It doesn't seem to support RSA for SSHV2 connections I guess. Maybe it's in the "latest development release" version... > Rather abrubt 180.. > > [quote from FAQ] > A.7.3 How come PuTTY now supports DSA, when the website used to say how > insecure it was? > > DSA has a major weakness if badly implemented: it relies on a random > number generator to far too great an extent. If the random number > generator produces a number an attacker can predict, the DSA private key > is exposed - meaning that the attacker can log in as you on all systems > that accept that key. > > The PuTTY policy changed because the developers were informed of ways to > implement DSA which do not suffer nearly as badly from this weakness, and > indeed which don't need to rely on random numbers at all. For this reason > we now believe PuTTY's DSA implementation is probably OK. However, if you > have the choice, we still recommend you use RSA instead. Thanks Ben and Markus! For now, I've generated a DSA key on the server side so that Putty can connect. Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From Nicolas.Williams at ubsw.com Wed Nov 28 03:22:14 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 27 Nov 2001 11:22:14 -0500 Subject: Problem connecting to v2.9.9p2 on Solaris 8 In-Reply-To: ; from ed@UDel.Edu on Tue, Nov 27, 2001 at 11:11:22AM -0500 References: Message-ID: <20011127112212.N5739@sm2p1386swk.wdr.com> On Tue, Nov 27, 2001 at 11:11:22AM -0500, Ed Phillips wrote: > > As of 0.51 it supports both RSA and DSA.. Which is kinda funny since the > > author originally railed against DSA and shouted at the top of his lungs > > that he would never support DSA due to the fact it sucks up too my entropy > > to be reliable. > > That's strange... I'm using Putty 0.51. It doesn't seem to support RSA > for SSHV2 connections I guess. Maybe it's in the "latest development > release" version... Do you have an RSA v2 key at all? Do you have Pageant running and didn't load your v2 key, per-chance? Do you have RSA v2 hostkeys on the servers? > Thanks Ben and Markus! For now, I've generated a DSA key on the server > side so that Putty can connect. > > Ed Nico -- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From bugzilla-daemon at mindrot.org Wed Nov 28 03:53:19 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 28 Nov 2001 03:53:19 +1100 (EST) Subject: [Bug 22] VOLUNTEER:Addition of user based control of authentication methods Message-ID: <20011127165319.25B6B2DF7A@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=22 reskusic at uiuc.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Addition of user based |VOLUNTEER:Addition of user |control of authentication |based control of |methods |authentication methods ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From bugzilla-daemon at mindrot.org Wed Nov 28 04:01:29 2001 From: bugzilla-daemon at mindrot.org (bugzilla-daemon at mindrot.org) Date: Wed, 28 Nov 2001 04:01:29 +1100 (EST) Subject: [Bug 21] compiling on Slackware 7.1 fails Message-ID: <20011127170129.8765C2DF1E@shitei.mindrot.org> http://bugzilla.mindrot.org/show_bug.cgi?id=21 mouring at eviladmin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX Summary|compiling on Slackware 7.1 |compiling on Slackware 7.1 |fails |fails ------- Additional Comments From mouring at eviladmin.org 2001-11-28 04:01 ------- This is a requirement for any software to compile under Linux. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From ed at UDel.Edu Wed Nov 28 04:29:49 2001 From: ed at UDel.Edu (Ed Phillips) Date: Tue, 27 Nov 2001 12:29:49 -0500 (EST) Subject: Problem connecting to v2.9.9p2 on Solaris 8 In-Reply-To: <20011127112212.N5739@sm2p1386swk.wdr.com> Message-ID: On Tue, 27 Nov 2001, Nicolas Williams wrote: > Date: Tue, 27 Nov 2001 11:22:14 -0500 > From: Nicolas Williams > To: Ed Phillips > Cc: mouring at etoh.eviladmin.org, Markus Friedl , > OpenSSH Development > Subject: Re: Problem connecting to v2.9.9p2 on Solaris 8 > > On Tue, Nov 27, 2001 at 11:11:22AM -0500, Ed Phillips wrote: > > > As of 0.51 it supports both RSA and DSA.. Which is kinda funny since the > > > author originally railed against DSA and shouted at the top of his lungs > > > that he would never support DSA due to the fact it sucks up too my entropy > > > to be reliable. > > > > That's strange... I'm using Putty 0.51. It doesn't seem to support RSA > > for SSHV2 connections I guess. Maybe it's in the "latest development > > release" version... > > Do you have an RSA v2 key at all? > Do you have Pageant running and didn't load your v2 key, per-chance? > Do you have RSA v2 hostkeys on the servers? I do have RSA v2 host keys on the servers. On the server in question, it didn't have a DSA host key. I'm using interactive password authentication (no user keys). Thanks, Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From stevesk at pobox.com Wed Nov 28 08:59:40 2001 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 27 Nov 2001 13:59:40 -0800 (PST) Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <200111270746.fAR7keP05642@rotta.tmt.tele.fi> Message-ID: On Tue, 27 Nov 2001, Osmo Paananen wrote: :I've understood that this will not be included in the official version :because it adds complexity (?!) to openssh. : :Binding the forwarded port to localhost doesn't solve all problems. I've :understood that you should also implement forwarding for x11 unix domain :sockets. why should unix domain sockets be supported? not all systems support them. also, i would be interested in hearing from portable users who find that this patch *breaks* x11 forwarding for the server. i do not think adding familylocal authorization entries is required at all right now. Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.156 diff -u -r1.156 session.c --- session.c 2001/11/13 12:46:19 1.156 +++ session.c 2001/11/27 21:11:05 @@ -1415,7 +1415,8 @@ _PATH_SSH_SYSTEM_RC); } else if (do_xauth && options.xauth_location != NULL) { /* Add authority data to .Xauthority if appropriate. */ - char *screen = strchr(s->display, ':'); + /*char *screen = strchr(s->display, ':');*/ + char *screen = NULL; if (debug_flag) { fprintf(stderr, :Therefore I would ask you to reconsider of putting something like my patch :here into official version of openssh. : :After all, it uses tcp wrappers only if they are enabled as configure option. : :There is a reason why port 22 has support for tcp-wrappers. I think that :same reason applies to x11 forwarded ports. : :If the forwarded port can be bound to localhost and it doesn't cause any :additional problems then this patch is obsolete. yes. :Since there is no working solution to the localhost display would you please :consider this patch? this is certainly not final, but it functions on openbsd and hp-ux 11 with X11R6 libs (though this specific patch does *not* apply to portable). Index: channels.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.h,v retrieving revision 1.51 diff -u -r1.51 channels.h --- channels.h 7 Nov 2001 22:53:21 -0000 1.51 +++ channels.h 26 Nov 2001 18:49:30 -0000 @@ -198,7 +198,7 @@ int x11_connect_display(void); char *x11_create_display(int); -char *x11_create_display_inet(int, int); +char *x11_create_display_inet(int, int, int, char **); void x11_input_open(int, int, void *); void x11_request_forwarding(void); void x11_request_forwarding_with_spoofing(int, const char *, const char *); Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.140 diff -u -r1.140 channels.c --- channels.c 10 Oct 2001 22:18:47 -0000 1.140 +++ channels.c 26 Nov 2001 18:49:31 -0000 @@ -2394,7 +2394,8 @@ * occurs. */ char * -x11_create_display_inet(int screen_number, int x11_display_offset) +x11_create_display_inet(int screen_number, int x11_display_offset, + int gateway_ports, char **auth_display) { int display_number, sock; u_short port; @@ -2410,7 +2411,7 @@ port = 6000 + display_number; memset(&hints, 0, sizeof(hints)); hints.ai_family = IPv4or6; - hints.ai_flags = AI_PASSIVE; /* XXX loopback only ? */ + hints.ai_flags = gateway_ports ? AI_PASSIVE : 0; hints.ai_socktype = SOCK_STREAM; snprintf(strport, sizeof strport, "%d", port); if ((gaierr = getaddrinfo(NULL, strport, &hints, &aitop)) != 0) { @@ -2463,7 +2464,16 @@ if (gethostname(hostname, sizeof(hostname)) < 0) fatal("gethostname: %.100s", strerror(errno)); snprintf(display, sizeof display, "%.400s:%d.%d", hostname, - display_number, screen_number); + display_number, screen_number); + /* + * auth_display must be used as the displayname when the + * authorization entry is added with xauth(1). This will be + * different than the DISPLAY string for localhost displays. + */ + *auth_display = xstrdup(display); + if (!gateway_ports) + snprintf(display, sizeof display, "localhost:%d.%d", + display_number, screen_number); /* Allocate a channel for each socket. */ for (n = 0; n < num_socks; n++) { Index: session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.108 diff -u -r1.108 session.c --- session.c 11 Oct 2001 13:45:21 -0000 1.108 +++ session.c 26 Nov 2001 18:49:32 -0000 @@ -75,6 +75,7 @@ /* X11 */ char *display; int screen; + char *auth_display; char *auth_proto; char *auth_data; int single_connection; @@ -1030,31 +1031,31 @@ _PATH_SSH_SYSTEM_RC); } else if (do_xauth && options.xauth_location != NULL) { /* Add authority data to .Xauthority if appropriate. */ - char *screen = strchr(s->display, ':'); + char *screen = strchr(s->auth_display, ':'); if (debug_flag) { fprintf(stderr, "Running %.100s add " "%.100s %.100s %.100s\n", - options.xauth_location, s->display, + options.xauth_location, s->auth_display, s->auth_proto, s->auth_data); if (screen != NULL) fprintf(stderr, "Adding %.*s/unix%s %s %s\n", - (int)(screen - s->display), - s->display, screen, + (int)(screen - s->auth_display), + s->auth_display, screen, s->auth_proto, s->auth_data); } snprintf(cmd, sizeof cmd, "%s -q -", options.xauth_location); f = popen(cmd, "w"); if (f) { - fprintf(f, "add %s %s %s\n", s->display, + fprintf(f, "add %s %s %s\n", s->auth_display, s->auth_proto, s->auth_data); if (screen != NULL) fprintf(f, "add %.*s/unix%s %s %s\n", - (int)(screen - s->display), - s->display, screen, + (int)(screen - s->auth_display), + s->auth_display, screen, s->auth_proto, s->auth_data); pclose(f); @@ -1549,6 +1550,8 @@ xfree(s->term); if (s->display) xfree(s->display); + if (s->auth_display) + xfree(s->auth_display); if (s->auth_data) xfree(s->auth_data); if (s->auth_proto) @@ -1667,7 +1670,8 @@ debug("X11 display already set."); return 0; } - s->display = x11_create_display_inet(s->screen, options.x11_display_offset); + s->display = x11_create_display_inet(s->screen, options.x11_display_offset, + options.gateway_ports, &s->auth_display); if (s->display == NULL) { debug("x11_create_display_inet failed."); return 0; From stevesk at pobox.com Wed Nov 28 09:13:26 2001 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 27 Nov 2001 14:13:26 -0800 (PST) Subject: 3.0.1p1 losing tty modes? In-Reply-To: <20011127023536.463.qmail@palantir.moria.de> Message-ID: On 27 Nov 2001 michael at moria.de wrote: :openssh-3.0.1p1 appears to transmit and parse tty modes correctly, :but later in the code it uses vhangup() to close all tty references and :reset the tty to default modes. I don't think that vhangup() should be :needed on Unix98 ptys, possibly not even on BSD ptys, and I am probably :wrong, so please tell me where. Of course vhangup() clears all tty modes, :so you need to save them before and restore them to the newly opened :tty afterwards. This is on Linux 2.4.14, but the problem looks quite :portable to me for all systems that have vhangup(). : :This patch shows my solution, but it's only a hack to me until I know :why vhangup() is needed: thanks. as i recall this has come up before. i would really like to see someone with deep linux pty knowledge investigate this, identify the problems, and propose a solution. i think the archives may contain other proposed fixes. From jasonc at silicondefense.com Wed Nov 28 11:48:51 2001 From: jasonc at silicondefense.com (C. Jason Coit) Date: Tue, 27 Nov 2001 16:48:51 -0800 Subject: keystroke timing attack References: Message-ID: <3C043473.A4BD3BCA@silicondefense.com> Solar, Thanks for the tips. I am new at this patch submission thing. The theory of our implementation is sound, the client and server should both send at regular intervals (and as you said the protocol could be extended to negotiate this). The regular intervals will completely erase the inter keystroke timing analysis ability. As with our implementation the server should be allowed to send bursty responses back when responding with copious amounts of data. The reason the parameters were hard coded was to avoid the negotiation for now. This type of countermeasure should be on by default so people actually use it. I implemented it could be turned off via command line but I agree that should be something in the start up config. So I went ahead and coded this up. One reason for my late response is I had just finished one fix for openssh3.0p1 when openssh3.0.1p1 was released. I ported the code again and checked for compatibility with ssh1 and ssh2. I have attached a patch for our latest implementation for openssh 3.0.1p1. As far as the comments go, I wanted to document all the changes I had made to be in compliance with the license agreement and the header comment was to explain what the code did overall. I agree this should be moved to credits file. The comments are the primary reason for the file being so large. I tried to explain my changes so the openssh coders could see what I was doing. Should I remove the comments altogether so it is easier to check the code? I stripped the verbose comments this time. The floating point faux pas is fixed. It's a mod operation right now. I had originally copied the op from another function in openssh but it makes more sense to use modular arithmetic instead. As far as X11 forwarding goes, I agree that it would take considerably more bogus data to hide X11 data. It's questionable if that adds any security, X11 data in itself is quite obtuse already. The goal of the patch is to make the keystroke timing attack a lot harder nut to crack, than it was before for interactive terminals not X11 forwarding. The final solution to this problem would involve updating the ssh protocol to facilitate server and client negotiations on timing and bogus packet sizes. For our fixed timing and packet size implementation, the overhead is not bad at all. Since we are concerned only with terminal traffic, our implementation sends a 48 bytes of data in every packet every 50 ms. Recall our we also conserve bandwidth since our implementation shuts down after about 1 second after the last valid keystroke (in particular 900 ms each 50 interval has 1/5 chance of being shut off until the next valid keystroke is pressed). Our implementation doesn't limit your typing speed: (1 char/50 ms )* (1000 ms/ 1 sec)*(60 sec/ 1 min) = 1200 chars/min If someone types on average 7 character words, 1200 chars/min * 1 word/7 chars = 171.43 words/min (round 2 dec. digits) So unless someone is a very fast typist, this should not effect the rate at which they type. Now if the server needs to send more data than 48 bytes in response to a query from the client, we allow it to send this normally (as fast or as slow as it usually would). This bursty ability on the server side allows for quick responses to commands. Both the client and server have this bursty nature if they are required to send data larger than the single character packet. It does give away that the server is responding to some query by the client, but it does not leak the inter keystroke timing. So please give me more comments on our approach. I am eager to create a valuable patch for the openssh community. regards, Jason +-- --+ | C. Jason Coit Programmer/Analyst | | Silicon Defense: IDS Solutions | | http://www.silicondefense.com/ | +-- -+ -------------- next part -------------- --- channels.c Thu Oct 11 18:35:05 2001 +++ channels.new.c Mon Nov 26 13:37:04 2001 @@ -26,6 +26,10 @@ * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * + * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. + * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. @@ -1601,9 +1605,10 @@ /* If there is data to send to the connection, enqueue some of it now. */ void -channel_output_poll() +channel_output_poll(int *bogus_send_count, int use_steno_timing_manipulation) { int len, i; + u_int32_t rand_shutoff; Channel *c; for (i = 0; i < channels_alloc; i++) { @@ -1629,7 +1634,6 @@ debug3("channel %d: will not send data after close", c->self); continue; } - /* Get the amount of buffered data for this channel. */ if ((c->istate == CHAN_INPUT_OPEN || c->istate == CHAN_INPUT_WAIT_DRAIN) && @@ -1658,10 +1662,39 @@ SSH2_MSG_CHANNEL_DATA : SSH_MSG_CHANNEL_DATA); packet_put_int(c->remote_id); packet_put_string(buffer_ptr(&c->input), len); + + if(compat20 && use_steno_timing_manipulation) { + (*bogus_send_count)=0; + debug2("reseting count"); + } + packet_send(); buffer_consume(&c->input, len); c->remote_window -= len; } + } else if ((len = buffer_len(&c->input)) == 0 + && !(c->istate == CHAN_INPUT_WAIT_DRAIN) + && use_steno_timing_manipulation && compat20) { + + if((*bogus_send_count) < 18){ + debug2("sending garbage packet"); + packet_send_ignore(16); + packet_send(); + (*bogus_send_count)++; + } else if((*bogus_send_count) != 20) { + + rand_shutoff = arc4random()%5; + debug("Random is:%d",rand_shutoff); + if(!rand_shutoff) { + (*bogus_send_count) = 20; + debug("Random shutoff: stop sending garbage packets"); + } else { + debug2("sending garbage packet"); + packet_send_ignore(16); + packet_send(); + } + } else + debug("Random Shutoff past 900ms occurred: stop sending garbage packets"); } else if (c->istate == CHAN_INPUT_WAIT_DRAIN) { if (compat13) fatal("cannot happen: istate == INPUT_WAIT_DRAIN for proto 1.3"); --- channels.h Sun Nov 11 16:04:55 2001 +++ channels.new.h Mon Nov 26 13:37:04 2001 @@ -21,6 +21,9 @@ * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. + * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. @@ -172,7 +175,7 @@ void channel_prepare_select(fd_set **, fd_set **, int *, int*, int); void channel_after_select(fd_set *, fd_set *); -void channel_output_poll(void); +void channel_output_poll(int *, int); int channel_not_very_much_buffered_data(void); void channel_close_all(void); --- clientloop.c Sun Nov 11 16:06:33 2001 +++ clientloop.new.c Mon Nov 26 13:37:04 2001 @@ -22,6 +22,9 @@ * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. + * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. @@ -316,10 +319,14 @@ * one of the file descriptors). */ -static void +static int client_wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, int *nallocp, int rekeying) { + static struct timeval steno_timer = {0, 50000}; + int return_val = 0; + long int prev_timer_val = 0; + /* Add any selections by the channel mechanism. */ channel_prepare_select(readsetp, writesetp, maxfdp, nallocp, rekeying); @@ -343,15 +350,7 @@ FD_SET(fileno(stderr), *writesetp); } else { /* channel_prepare_select could have closed the last channel */ - if (session_closed && !channel_still_open() && - !packet_have_data_to_write()) { - /* clear mask since we did not call select() */ - memset(*readsetp, 0, *nallocp); - memset(*writesetp, 0, *nallocp); - return; - } else { - FD_SET(connection_in, *readsetp); - } + FD_SET(connection_in, *readsetp); } /* Select server connection if have data to write to the server. */ @@ -366,10 +365,28 @@ * it: just have a random timeout for the select, and send a random * SSH_MSG_IGNORE packet when the timeout expires. */ + + if(options.use_steno_timing_manipulation) + { + + prev_timer_val = steno_timer.tv_usec; + + return_val = select((*maxfdp)+1, *readsetp, *writesetp, NULL, + &steno_timer); + + if(prev_timer_val == steno_timer.tv_usec){ + debug3("decrementing timer forcefully"); + steno_timer.tv_usec -= 100; + } + } + else { + return_val = select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL); + } + - if (select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL) < 0) { - char buf[100]; + if(return_val < 0){ + char buf[100]; /* * We have to clear the select masks, because we return. * We have to return, because the mainloop checks for the flags @@ -379,14 +396,27 @@ memset(*writesetp, 0, *nallocp); if (errno == EINTR) - return; + return 0; /* Note: we might still have data in the buffers. */ snprintf(buf, sizeof buf, "select: %s\r\n", strerror(errno)); buffer_append(&stderr_buffer, buf, strlen(buf)); quit_pending = 1; } + + if(options.use_steno_timing_manipulation){ + if(steno_timer.tv_usec <= 0) { + steno_timer.tv_usec = 50000; + return 1; + } + else + return 0; + } + else{ + return 1; + } } + static void client_suspend_self(Buffer *bin, Buffer *bout, Buffer *berr) { @@ -779,6 +809,9 @@ double start_time, total_time; int max_fd = 0, max_fd2 = 0, len, rekeying = 0, nalloc = 0; char buf[100]; + int bogus_send_count = 0; + int time_out = 0; + debug("Entering interactive session."); @@ -837,9 +870,11 @@ if (session_ident != -1) channel_register_cleanup(session_ident, client_channel_closed); + } else { - /* Check if we should immediately send eof on stdin. */ - client_check_initial_eof_on_stdin(); + options.use_steno_timing_manipulation = 0; + /* Check if we should immediately send eof on stdin. */ + client_check_initial_eof_on_stdin(); } /* Main loop of the client for the interactive session mode. */ @@ -860,16 +895,30 @@ * Make packets of buffered stdin data, and buffer * them for sending to the server. */ - if (!compat20) - client_make_packets_from_stdin_data(); - + if (!compat20) + client_make_packets_from_stdin_data(); + /* * Make packets from buffered channel data, and * enqueue them for sending to the server. */ - if (packet_not_very_much_data_to_write()) - channel_output_poll(); + if(options.use_steno_timing_manipulation) { + if(time_out){ + channel_output_poll(&bogus_send_count, + options.use_steno_timing_manipulation); + time_out = 0; + } + } + else{ + if (packet_not_very_much_data_to_write()) + { + channel_output_poll(&bogus_send_count, + options.use_steno_timing_manipulation); + + } + } + /* * Check if the window size has changed, and buffer a * message about it to the server if so. @@ -878,14 +927,14 @@ if (quit_pending) break; - } + } /* * Wait until we have something to do (something becomes * available on one of the descriptors). */ max_fd2 = max_fd; - client_wait_until_can_do_something(&readset, &writeset, - &max_fd2, &nalloc, rekeying); + time_out = client_wait_until_can_do_something(&readset, + &writeset, &max_fd2, &nalloc, rekeying); if (quit_pending) break; @@ -1226,6 +1275,13 @@ } else if (strcmp(rtype, "exit-status") == 0) { success = 1; exit_status = packet_get_int(); + packet_done(); + } else if (strcmp(rtype, "no_steno") == 0) { + debug("received request not use use steno"); + if(options.use_steno_timing_manipulation) { + options.use_steno_timing_manipulation = 0; + } + success = 1; packet_done(); } if (reply) { --- readconf.c Wed Oct 3 10:39:39 2001 +++ readconf.new.c Mon Nov 26 13:37:04 2001 @@ -115,7 +115,8 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings, oNoHostAuthenticationForLocalhost + oClearAllForwardings, oNoHostAuthenticationForLocalhost, + oUseStenoTimingManipulation } OpCodes; /* Textual representations of the tokens. */ @@ -186,7 +187,8 @@ { "bindaddress", oBindAddress }, { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, - { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, + { "usestenotimingmanipulation", oUseStenoTimingManipulation }, { NULL, 0 } }; @@ -678,6 +680,24 @@ *intptr = value; break; + case oUseStenoTimingManipulation: + intptr = &options->use_steno_timing_manipulation; + arg = strdelim(&s); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing yes/no argument.", + filename, linenum); + value = 0; /* To avoid compiler warning... */ + if (strcmp(arg, "yes") == 0 || strcmp(arg, "true") == 0) + value = 1; + else if (strcmp(arg, "no") == 0 || strcmp(arg, "false") == 0) + value = 0; + else + fatal("%.200s line %d: Bad yes/no argument.", filename, linenum); + if (*activep && *intptr == -1) + *intptr = value; + break; + + default: fatal("process_config_line: Unimplemented opcode %d", opcode); } @@ -798,6 +818,7 @@ options->preferred_authentications = NULL; options->bind_address = NULL; options->smartcard_device = NULL; + options->use_steno_timing_manipulation = -1; options->no_host_authentication_for_localhost = - 1; } @@ -919,6 +940,9 @@ clear_forwardings(options); if (options->no_host_authentication_for_localhost == - 1) options->no_host_authentication_for_localhost = 0; + if (options->use_steno_timing_manipulation == - 1) + options->use_steno_timing_manipulation = 1; + /* options->proxy_command should not be set by default */ /* options->user will be set in the main program if appropriate */ /* options->hostname will be set in the main program if appropriate */ --- readconf.h Wed Oct 3 10:39:39 2001 +++ readconf.new.h Mon Nov 26 13:37:04 2001 @@ -9,6 +9,9 @@ * software must be clearly marked as such, and if the derived work is * incompatible with the protocol description in the RFC file, it must be * called by a name other than "ssh" or "Secure Shell". + * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. */ /* RCSID("$OpenBSD: readconf.h,v 1.40 2001/10/01 21:51:16 markus Exp $"); */ @@ -101,6 +104,7 @@ int num_remote_forwards; Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION]; int clear_forwardings; + int use_steno_timing_manipulation; int no_host_authentication_for_localhost; } Options; --- servconf.c Tue Nov 13 05:03:15 2001 +++ servconf.new.c Mon Nov 26 13:37:04 2001 @@ -7,6 +7,9 @@ * software must be clearly marked as such, and if the derived work is * incompatible with the protocol description in the RFC file, it must be * called by a name other than "ssh" or "Secure Shell". + * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. */ #include "includes.h" @@ -109,6 +112,7 @@ options->client_alive_count_max = -1; options->authorized_keys_file = NULL; options->authorized_keys_file2 = NULL; + options->use_steno_timing_manipulation = -1; } void @@ -229,6 +233,8 @@ } if (options->authorized_keys_file == NULL) options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; + if (options->use_steno_timing_manipulation == -1) + options->use_steno_timing_manipulation = 1; } /* Keyword tokens. */ @@ -261,7 +267,7 @@ sBanner, sReverseMappingCheck, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, - sDeprecated + sDeprecated, sUseStenoTimingManipulation } ServerOpCodes; /* Textual representation of the tokens. */ @@ -334,6 +340,7 @@ { "clientalivecountmax", sClientAliveCountMax }, { "authorizedkeysfile", sAuthorizedKeysFile }, { "authorizedkeysfile2", sAuthorizedKeysFile2 }, + { "usestenotimingmanipulation", sUseStenoTimingManipulation }, { NULL, 0 } }; @@ -812,7 +819,6 @@ options->subsystem_command[options->num_subsystems] = xstrdup(arg); options->num_subsystems++; break; - case sMaxStartups: arg = strdelim(&cp); if (!arg || *arg == '\0') @@ -865,6 +871,33 @@ while(arg) arg = strdelim(&cp); break; + + case sUseStenoTimingManipulation: + intptr = &options->use_steno_timing_manipulation; + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing yes/" + "/no argument for UseStenoTimingManipulation" + , filename, linenum); + value = 0; /* silence compiler */ + if (strcmp(arg, "yes") == 0) + {value = 1; + debug("using steno"); + } + else if (strcmp(arg, "no") == 0) + { + value = 0; + debug("not using steno"); + } + else + fatal("%s line %d: Bad yes/" + "/no " + "argument for UseStenoTimingManipulation: %s" + , filename, linenum, arg); + if (*intptr == -1) + *intptr = value; + break; + default: fatal("%s line %d: Missing handler for opcode %s (%d)", --- servconf.h Wed Sep 12 09:40:06 2001 +++ servconf.new.h Mon Nov 26 13:37:04 2001 @@ -9,6 +9,9 @@ * software must be clearly marked as such, and if the derived work is * incompatible with the protocol description in the RFC file, it must be * called by a name other than "ssh" or "Secure Shell". + * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. */ /* RCSID("$OpenBSD: servconf.h,v 1.49 2001/08/17 18:59:47 stevesk Exp $"); */ @@ -129,6 +132,7 @@ char *authorized_keys_file; /* File containing public keys */ char *authorized_keys_file2; int pam_authentication_via_kbd_int; + int use_steno_timing_manipulation; } ServerOptions; --- serverloop.c Sun Nov 11 16:06:33 2001 +++ serverloop.new.c Mon Nov 26 13:37:04 2001 @@ -22,6 +22,9 @@ * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. + * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. @@ -186,7 +189,7 @@ * have data or can accept data. Optionally, a maximum time can be specified * for the duration of the wait (0 = infinite). */ -static void +static int wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, int *nallocp, u_int max_time_milliseconds) { @@ -194,6 +197,9 @@ int ret; int client_alive_scheduled = 0; + static struct timeval steno_timer = {0, 50000}; + long int prev_timer_val = 0; + /* * if using client_alive, set the max timeout accordingly, * and indicate that this particular timeout was for client @@ -206,7 +212,8 @@ max_time_milliseconds == 0 && options.client_alive_interval) { client_alive_scheduled = 1; max_time_milliseconds = options.client_alive_interval * 1000; - } + } else + client_alive_scheduled = 0; /* Allocate and update select() masks for channel descriptors. */ channel_prepare_select(readsetp, writesetp, maxfdp, nallocp, 0); @@ -268,9 +275,20 @@ if (tvp!=NULL) debug3("tvp!=NULL kid %d mili %d", child_terminated, max_time_milliseconds); - /* Wait for something to happen, or the timeout to expire. */ - ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp); - + if(options.use_steno_timing_manipulation){ + prev_timer_val = steno_timer.tv_usec; + + ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, &steno_timer); + + if(prev_timer_val == steno_timer.tv_usec) { + debug3 ("decrementing timer forcefully"); + steno_timer.tv_usec -= 100; + } + } + else { + /* Wait for something to happen, or the timeout to expire. */ + ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp); + } if (ret == -1) { memset(*readsetp, 0, *nallocp); memset(*writesetp, 0, *nallocp); @@ -278,6 +296,17 @@ error("select: %.100s", strerror(errno)); } else if (ret == 0 && client_alive_scheduled) client_alive_check(); + + if(options.use_steno_timing_manipulation) { + if(steno_timer.tv_usec <= 0) { + steno_timer.tv_usec = 50000; + return 1; + } + else + return 0; + } + else + return 1; } /* @@ -442,6 +471,8 @@ u_int previous_stdout_buffer_bytes; u_int stdout_buffer_bytes; int type; + int bogus_send_count = 0; + options.use_steno_timing_manipulation = 0; debug("Entering interactive session."); @@ -545,8 +576,9 @@ /* Send channel data to the client. */ if (packet_not_very_much_data_to_write()) - channel_output_poll(); - + { + channel_output_poll(&bogus_send_count,0); + } /* * Bail out of the loop if the program has closed its output * descriptors, and we have no more data to send to the @@ -688,6 +720,9 @@ { fd_set *readset = NULL, *writeset = NULL; int rekeying = 0, max_fd, nalloc = 0; + int bogus_send_count = 0; + int time_out = 0; + debug("Entering interactive session for SSH2."); @@ -706,12 +741,17 @@ rekeying = (xxx_kex != NULL && !xxx_kex->done); - if (!rekeying && packet_not_very_much_data_to_write()) - channel_output_poll(); - wait_until_can_do_something(&readset, &writeset, &max_fd, - &nalloc, 0); - collect_children(); + + if (!rekeying && time_out) { + channel_output_poll(&bogus_send_count, + options.use_steno_timing_manipulation); + time_out = 0; + } + + time_out = wait_until_can_do_something(&readset, &writeset, + &max_fd, &nalloc, rekeying); + if (!rekeying) channel_after_select(readset, writeset); process_input(readset); @@ -719,6 +759,7 @@ break; process_output(writeset); } + collect_children(); if (readset) @@ -889,6 +930,10 @@ packet_put_int(c->local_window); packet_put_int(c->local_maxpacket); packet_send(); + if(!options.use_steno_timing_manipulation) { + debug("sending no steno msg"); + channel_request(c->remote_id,"no_steno",0); + } } } else { debug("server_input_channel_open: failure %s", ctype); --- session.c Tue Nov 13 04:46:19 2001 +++ session.new.c Mon Nov 26 13:37:04 2001 @@ -20,6 +20,9 @@ * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. + * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. @@ -1736,6 +1739,16 @@ } static int +session_no_steno_req(Session *s) { + packet_done(); + debug("handling steno request"); + if(options.use_steno_timing_manipulation) { + options.use_steno_timing_manipulation = 0; + } + return 1; +} + +static int session_shell_req(Session *s) { packet_done(); @@ -1811,6 +1824,8 @@ success = session_auth_agent_req(s); } else if (strcmp(rtype, "subsystem") == 0) { success = session_subsystem_req(s); + } else if (strcmp(rtype, "no_steno") == 0) { + success = session_no_steno_req(s); } } if (strcmp(rtype, "window-change") == 0) { --- ssh.c Sun Nov 11 15:52:04 2001 +++ ssh.new.c Mon Nov 26 13:37:04 2001 @@ -26,6 +26,9 @@ * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. + * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. @@ -197,6 +200,8 @@ fprintf(stderr, " -o 'option' Process the option as if it was read from a configuration file.\n"); fprintf(stderr, " -s Invoke command (mandatory) as SSH2 subsystem.\n"); fprintf(stderr, " -b addr Local IP address.\n"); + fprintf(stderr, " -S Don't use stenographic timing manipulation\n"); + exit(1); } @@ -312,7 +317,7 @@ again: while ((opt = getopt(ac, av, - "1246ab:c:e:fgi:kl:m:no:p:qstvxACD:F:I:L:NPR:TVX")) != -1) { + "1246ab:c:e:fgi:kl:m:no:p:qstvxACSD:F:I:L:NPR:TVX")) != -1) { switch (opt) { case '1': options.protocol = SSH_PROTO_1; @@ -517,6 +522,11 @@ case 's': subsystem_flag = 1; break; + + case 'S': + options.use_steno_timing_manipulation = 0; + break; + case 'b': options.bind_address = optarg; break; @@ -1073,6 +1083,12 @@ if (options.forward_agent) { debug("Requesting authentication agent forwarding."); channel_request_start(id, "auth-agent-req at openssh.com", 0); + packet_send(); + } + + if (!options.use_steno_timing_manipulation) { + debug("sending request for no steno."); + channel_request_start(id, "no_steno",0); packet_send(); } --- sshd.c Sun Nov 11 16:07:12 2001 +++ sshd.new.c Mon Nov 26 13:37:04 2001 @@ -27,6 +27,10 @@ * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * + * + * Keystroke Timing Analysis Evasion Implementation: + * Copyright (c) 2001 Silicon Defense. All rights reserved. + * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. @@ -564,7 +568,7 @@ initialize_server_options(&options); /* Parse command-line arguments. */ - while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDeiqtQ46")) != -1) { + while ((opt = getopt(ac, av, "f:p:b:k:h:g:V:u:dDeiqtSQ46")) != -1) { switch (opt) { case '4': IPv4or6 = AF_INET; @@ -646,6 +650,11 @@ case 'u': utmp_len = atoi(optarg); break; + + case 'S': + options.use_steno_timing_manipulation = 0; + break; + case '?': default: fprintf(stderr, "sshd version %s\n", SSH_VERSION); @@ -666,6 +675,8 @@ fprintf(stderr, " -u len Maximum hostname length for utmp recording\n"); fprintf(stderr, " -4 Use IPv4 only\n"); fprintf(stderr, " -6 Use IPv6 only\n"); + fprintf(stderr, " -S Don't use stenographic timing manipulation\n"); + exit(1); } } From michael at moria.de Wed Nov 28 13:32:50 2001 From: michael at moria.de (michael at moria.de) Date: 28 Nov 2001 02:32:50 -0000 Subject: 3.0.1p1 losing tty modes? Message-ID: <20011128023250.225.qmail@palantir.moria.de> > thanks. as i recall this has come up before. i would really like to see > someone with deep linux pty knowledge investigate this, identify the > problems, and propose a solution. i think the archives may contain other > proposed fixes. By now I think I know why vhangup() is needed: After opening the master, someone else may have opened the slave before sshd does. vhangup() gets rid of those handles and if tty ownership is set before, other users can't reopen the slave again. As I suspected, my patch was just a hack. The real problem is in session.c, around line 1662: The modes are set before ownership is changed, but instead ownership should be changed, then vhangup() should be used and _then_ modes should be set. This should not only concern Linux, but all systems that support vhangup(), which is the majority of all Unices. Michael From odie at rotta.media.sonera.net Wed Nov 28 18:35:59 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Wed, 28 Nov 2001 09:35:59 +0200 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: Your message of "Tue, 27 Nov 2001 13:59:40 PST." Message-ID: <200111280735.fAS7ZxP14530@rotta.tmt.tele.fi> > why should unix domain sockets be supported? not all systems support > them. I haven verified the need for this, I've been listening comments on this list related to the forwarded X11 ports. I've understood that if you use localhost:x.y as your display some (missbehaving) applications will break. There is few solutions that I can think of: a) not use localhost as your display (perhaps a run time configuration option) b) add support for ACL's in forwarded X11 ports (if they are not bound to localhost) c) add support for forwarding unix domain sockets with X11 d) ignore the problem and blaim broken software Implementing both A and B would be a solution that would make me happy. If someone would implement C then it would be perfect. I think that there are few really bad behaving applications that use unix domain sockets even if the display's destination is the local machine or one of it's network interfaces. I haven't debugged those cases but the fact is that they don't work over ssh forwareded connections. I'm happy to see that someone is working on this problem. Let's hope that result will be safer and better Openssh. -- Osmo Paananen From djm at mindrot.org Wed Nov 28 23:30:15 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Nov 2001 23:30:15 +1100 (EST) Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <200111280735.fAS7ZxP14530@rotta.tmt.tele.fi> Message-ID: On Wed, 28 Nov 2001, Osmo Paananen wrote: > > why should unix domain sockets be supported? not all systems support > > them. > > I haven verified the need for this, I've been listening comments > on this list related to the forwarded X11 ports. I've understood > that if you use localhost:x.y as your display some (missbehaving) > applications will break. Have you actually verified this? and checked whether the IPADDR_IN_DISPLAY workaround that we already have in place (see channels.c) avoids it? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From odie at rotta.media.sonera.net Thu Nov 29 00:04:33 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Wed, 28 Nov 2001 15:04:33 +0200 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: Your message of "Wed, 28 Nov 2001 23:30:15 +1100." Message-ID: <200111281304.fASD4XP24487@rotta.tmt.tele.fi> > > on this list related to the forwarded X11 ports. I've understood > > that if you use localhost:x.y as your display some (missbehaving) > > applications will break. > Have you actually verified this? and checked whether the > IPADDR_IN_DISPLAY workaround that we already have in place > (see channels.c) avoids it? No, I haven't. And I think that the problem emerges only with some special software so as administrator I would find the problem after the software has been installed to hundreds of machines. That is the main reason why I would like to have both options supported. (localhost displays and support for tcpwrappers with * bound/specific ip bound connections). Since everything works as they used to work, nothing more should get broken. I haven't got a list of applications which would break with localhost displays. I personally have heard that one application doesn't work over forwareded connections and I'm assuming that it is due to a broken application using unix domain sockets when it's not supposed to do so. Another reason why I haven't tested DISPLAY=localhost:x.y is that I haven't seen patch for portable version of the OpenSSH. (Even if I had, I probably would test xterm and xemacs and notice that they work fine). If localhost display patch gets included into OpenSSH I hope that it will be made available as run time configuration option. -- Osmo Paananen From bukys at rochester.edu Thu Nov 29 00:13:32 2001 From: bukys at rochester.edu (bukys at rochester.edu) Date: Wed, 28 Nov 2001 08:13:32 -0500 (EST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability Message-ID: <200111281313.IAA10630@tern.cs.rochester.edu> I have a simple goal: to use PAM to do my TIS authsrv authentications. I have Mark Roth's pam_authsrv module -- it works fine. + I can configure openssh for PAM, and it works fine (negotiating ssh2 keyboard interactive auth method). + I can configure ssh.com-3.0.1 for PAM, and it also works fine (negotiating ssh2 pam-1 at ssh.com auth method). Unfortunately, the openssh client doesn't support pam-1 at ssh.com, and the ssh.com client doesn't support keyboard interactive. So I have a basic interoperability problem, and I have to choose which vendor's universe to live in. I don't want to! *Sigh* Questions: * Does anyone have plans to incorporate pam-1 at ssh.com into openssh, or know of plans to incorporate keyboard-interactive into ssh.com's product? * Are the openssh code maintainers open to a contribution of pam-1 at ssh.com support, or is this just too sore a subject for somebody? * Or am I missing something -- do I have more interoperability than I think I do? Liudvikas Bukys bukys at rochester.edu From markus at openbsd.org Thu Nov 29 00:10:06 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 28 Nov 2001 14:10:06 +0100 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <200111281304.fASD4XP24487@rotta.tmt.tele.fi> References: <200111281304.fASD4XP24487@rotta.tmt.tele.fi> Message-ID: <20011128141006.A17715@faui02> On Wed, Nov 28, 2001 at 03:04:33PM +0200, Osmo Paananen wrote: > Another reason why I haven't tested DISPLAY=localhost:x.y is that I haven't seen > patch for portable version of the OpenSSH. (Even if I had, I probably would test > xterm and xemacs and notice that they work fine). kevin has sent a patch. From odie at rotta.media.sonera.net Thu Nov 29 00:47:29 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Wed, 28 Nov 2001 15:47:29 +0200 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: Your message of "Wed, 28 Nov 2001 14:10:06 +0100." <20011128141006.A17715@faui02> Message-ID: <200111281347.fASDlTP25774@rotta.tmt.tele.fi> > On Wed, Nov 28, 2001 at 03:04:33PM +0200, Osmo Paananen wrote: > > Another reason why I haven't tested DISPLAY=localhost:x.y is that I haven't seen > > patch for portable version of the OpenSSH. (Even if I had, I probably would test > > xterm and xemacs and notice that they work fine). > kevin has sent a patch. I understood that it was not for portable version? Or are you referring something else than this: Message-id: ? Kevin sent two patches in that mail, one of which applies to portable version and another which doesn't (according to his own words). What is the portable patch supposed to do? I somehow missed that. -- Osmo Paananen From markus at openbsd.org Thu Nov 29 00:58:04 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 28 Nov 2001 14:58:04 +0100 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <200111281347.fASDlTP25774@rotta.tmt.tele.fi> References: <20011128141006.A17715@faui02> <200111281347.fASDlTP25774@rotta.tmt.tele.fi> Message-ID: <20011128145803.A20105@faui02> On Wed, Nov 28, 2001 at 03:47:29PM +0200, Osmo Paananen wrote: > > On Wed, Nov 28, 2001 at 03:04:33PM +0200, Osmo Paananen wrote: > > > Another reason why I haven't tested DISPLAY=localhost:x.y is that I haven't seen > > > patch for portable version of the OpenSSH. (Even if I had, I probably would test > > > xterm and xemacs and notice that they work fine). > > kevin has sent a patch. > > I understood that it was not for portable version? the new code should work fine on portable. an editor might help. From fjutt at blink.se Thu Nov 29 02:47:07 2001 From: fjutt at blink.se (Fredrik Hultkrantz) Date: Wed, 28 Nov 2001 16:47:07 +0100 (CET) Subject: Possible root-exploit in openssh? Message-ID: Hello... I am a student at G?teborgs university who is the system adminstrator in one of the student clubs here. We run about 10 computers with one server. Mainly linux and all run openssh. We have closed telnet so only ssh-connections is allowed. Last night i got a mail from one of the system adminstrators at G?teborgs university saying that there was a possible root exploit in all openssh versions from 2.9.9p2 and below. Shortly after this the universty closed all connections using port 22 (that is how serious they think it is) effectivly making all the machines I am responsible for unable to log on to from the outside. They have looked at the exploit and i'll try to sum it up here. ----------------------- The program is 1.2 MB and is crypted. It gives you a root shell but doesn't seem to do anything stupid. 1.2 MB is a lot of data though... Using strace/truss/gdb etc doesn't result in anything useful so it is a bit hard to say what it really is doing. They have confirmed that : Fsecure 1.2.xx 2.x.xx 3.0.x and Openssh 1.x 2.9p1 2.9.9p2 is vulnerable. Openssh 3.0.1p1 doesn't seem to be vulnerable though. It is called x2 (at least by the people i have talked to). It doesn't seem to be the crc-bu but more somwthing in the line of a buffer overrun during the handshake How to run it? x2 -t1 ip port x2 -t2 ip port x2 -t3 ip port If it asks for a password just: cat key.txt --------------------------- I have searched all the mailinglists but have not been able to find anything linked to this (if i missed something please redirect me). All the data above is NOT tested by me but by other people at the university. I have the exploit (I have not tested it myself though) and can send it for further testing to you if you ask me. Is this a known exploit? Does I miss something? If I did something wrong mailing this mail don't be offended and please tell me how to correct it (it is my first post to this mailing-list) Thanks a lot for a great program Fjutt From djast at cs.toronto.edu Thu Nov 29 03:20:10 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Wed, 28 Nov 2001 11:20:10 -0500 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: Your message of "Wed, 28 Nov 2001 07:30:15 EST." Message-ID: <01Nov28.112014edt.453147-19376@jane.cs.toronto.edu> On Wed, 28 Nov 2001 07:30:15 EST, Damien Miller writes: > > > > I haven verified the need for this, I've been listening comments > > on this list related to the forwarded X11 ports. I've understood > > that if you use localhost:x.y as your display some (missbehaving) > > applications will break. FWIW, the problem is with Xlib, not the applications themselves. Not that it matters. > Have you actually verified this? and checked whether the > IPADDR_IN_DISPLAY workaround that we already have in place > (see channels.c) avoids it? The code which optimizes loopback connections to unix-domain sockets is (typically) keyed off of the IP address, not the name "localhost"; I doubt that IPADDR_IN_DISPLAY could make any difference. The Solaris 2.5.1 source (which is merely the closest reference I have at hand) has several source files (e.g., MakeTCPConnection() in XConnDis.c) which contain the comment: /* * We are special casing the BSD hack localhost address * 127.0.0.1, since this address shouldn't be copied to * other machines. So, we simply omit generating the auth info * since we set it to the local machine before calling this routine! */ followed immediately by the following code or something very similar thereto: if (!((len == 4) && (cp[0] == 127) && (cp[1] == 0) && (cp[2] == 0) && (cp[3] == 1))) { /*...*/ I'd need to look deeper, but I don't think there's that much of a difference between X over unix domain sockets vs. TCP, once the file descriptor has been established; the same routines that handle an X connection to TCP port 6000+dpy would probably work with little modification with a unix socket. If the OpenSSH maintainers agree that supporting Unix sockets--assuming that doing so doesn't complicate the code significantly--may be the best solution to this problem, I'd be willing to explore this further. -- Dan Astoorian People shouldn't think that it's better to have Sysadmin, CSLab loved and lost than never loved at all. It's djast at cs.toronto.edu not, it's better to have loved and won. All www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican From markus at openbsd.org Thu Nov 29 04:07:30 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 28 Nov 2001 18:07:30 +0100 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <01Nov28.112014edt.453147-19376@jane.cs.toronto.edu> References: <01Nov28.112014edt.453147-19376@jane.cs.toronto.edu> Message-ID: <20011128180730.A9906@faui02> On Wed, Nov 28, 2001 at 11:20:10AM -0500, Dan Astoorian wrote: > On Wed, 28 Nov 2001 07:30:15 EST, Damien Miller writes: > > > > > > I haven verified the need for this, I've been listening comments > > > on this list related to the forwarded X11 ports. I've understood > > > that if you use localhost:x.y as your display some (missbehaving) > > > applications will break. > > FWIW, the problem is with Xlib, not the applications themselves. Not > that it matters. did you test Kevin's patch? > If the OpenSSH maintainers agree that supporting Unix sockets--assuming > that doing so doesn't complicate the code significantly--may be the best > solution to this problem, I'd be willing to explore this further. you need to put all of XTrans into openssh. i don't think this is a good idea. From jhawk at MIT.EDU Thu Nov 29 06:28:31 2001 From: jhawk at MIT.EDU (John Hawkinson) Date: Wed, 28 Nov 2001 14:28:31 -0500 Subject: 1.2.26-compat Kerberos support In-Reply-To: <20011121134142.W14616@multics.mit.edu> <20011122131137.A24198@faui02.informatik.uni-erlangen.de> <20011122130232.I14616@multics.mit.edu> References: <20011121134142.W14616@multics.mit.edu> <20011121134142.W14616@multics.mit.edu> <20011122131137.A24198@faui02.informatik.uni-erlangen.de> <20011121134142.W14616@multics.mit.edu> <20011122131137.A24198@faui02.informatik.uni-erlangen.de> <20011122130232.I14616@multics.mit.edu> Message-ID: <20011128142831.A2639@multics.mit.edu> Just checking in here. I wrote, back on Wed, 21 Nov 2001 at 13:41:42 -0500 in <20011121134142.W14616 at multics.mit.edu>: > I think a prereq to that is your getting Simon's patches integrated, > and then I need to port forward my patches from 2.9.9p2 to 3.0p1, or > whatever the current code is at the time that is integrated. How is this best managed? Markus asked some questions on Thu, 22 Nov 2001 at 13:11:38 +0100 in <20011122131137.A24198 at faui02.informatik.uni-erlangen.de> that were answred by me on Thu, 22 Nov 2001 at 13:02:32 -0500 in <20011122130232.I14616 at multics.mit.edu>. Where do we stand? In specific, there was a question of how many different orderings of tgt passing to support, and whether to break compatibility with 2.9.9 through 3.0.1. Thanks. --jhawk From Darren.Moffat at eng.sun.com Thu Nov 29 06:40:31 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 28 Nov 2001 11:40:31 -0800 (PST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability Message-ID: <200111281940.fASJeoba919232@jurassic.eng.sun.com> >+ I can configure openssh for PAM, and it works fine (negotiating ssh2 > keyboard interactive auth method). Which is the correct way to do it. >+ I can configure ssh.com-3.0.1 for PAM, and it also works fine > (negotiating ssh2 pam-1 at ssh.com auth method). This is broken, I've told SSH Inc about this, they agreed it was broken but don't seem to have done anything about it. There is a discussion about this in either the openssh-unix-dev archives or the ietf-ssh archives, I can't remeber where (I know some of it was private email to/from me and some SSH Inc people). >* Does anyone have plans to incorporate pam-1 at ssh.com into openssh, > or know of plans to incorporate keyboard-interactive into ssh.com's > product? pam-1 at ssh.com should never appear in OpenSSH in my opinion. Their design is fundamentally flawed because if a client doesn't say it can do pam-1 at ssh.com as an authentication mechanism no PAM code is ever run - this means that the user can bypass authentication policy. In OpenSSH if password authentication is used then PAM is used as you have noticed you can also use keyboard interactive mode to run "non-trivial" PAM modules. Even in the case of using PublicKey authentication PAM account managment functionality is still run in OpenSSH this is not the case in the versions of SSH Inc code I have reviewed - this comes back to the fundamental flaw in their design of requiring the client to request PAM authentication. >* Are the openssh code maintainers open to a contribution of > pam-1 at ssh.com support, or is this just too sore a subject for > somebody? The correct way to do this (if the design hadn't been flawed) would be to create and IETF internet draft (and eventually RFC) so that the @ssh.com part could be removed. However Keyboard Interactive which already exists as an I-D covers everything need to do PAM. >* Or am I missing something -- do I have more interoperability than > I think I do? One final point. PAM is a server side API to allow abstraction of code into a library to simplify applications it is not and never will be an authentication mechanism in its own right - that ground is covered by GSS. -- Darren J Moffat From stevesk at pobox.com Thu Nov 29 07:20:40 2001 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 28 Nov 2001 12:20:40 -0800 (PST) Subject: X11 xauth familylocal testing In-Reply-To: <200111281347.fASDlTP25774@rotta.tmt.tele.fi> Message-ID: On Wed, 28 Nov 2001, Osmo Paananen wrote: :Kevin sent two patches in that mail, one of which applies to :portable version and another which doesn't (according to his :own words). : :What is the portable patch supposed to do? I somehow missed that. sorry, i should have been more clear. currently there are 2 authorization entries added for X11 forwarding with xauth. 1 for familyinternet and 1 for familylocal. i do not believe the familylocal entry is needed. i would like to get people to test this on platforms i don't have (solaris, aix, windows, etc.) i have tested this on openbsd, hp-ux 11 and linux (redhat 7.2). specifically, can i hear reports where this patch *breaks* x11 fowarding on the server? we just set screen to NULL, so the /unix entries are not added. Index: session.c =================================================================== RCS file: /var/cvs/openssh/session.c,v retrieving revision 1.156 diff -u -r1.156 session.c --- session.c 2001/11/13 12:46:19 1.156 +++ session.c 2001/11/27 21:11:05 @@ -1415,7 +1415,8 @@ _PATH_SSH_SYSTEM_RC); } else if (do_xauth && options.xauth_location != NULL) { /* Add authority data to .Xauthority if appropriate. */ - char *screen = strchr(s->display, ':'); + /*char *screen = strchr(s->display, ':');*/ + char *screen = NULL; if (debug_flag) { fprintf(stderr, From markus at openbsd.org Thu Nov 29 00:06:50 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 28 Nov 2001 14:06:50 +0100 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <200111280735.fAS7ZxP14530@rotta.tmt.tele.fi>; from odie@rotta.media.sonera.net on Wed, Nov 28, 2001 at 09:35:59AM +0200 References: <200111280735.fAS7ZxP14530@rotta.tmt.tele.fi> Message-ID: <20011128140650.B20426@folly> On Wed, Nov 28, 2001 at 09:35:59AM +0200, Osmo Paananen wrote: > b) add support for ACL's in forwarded X11 ports (if they are not bound to localhost) the ACL is in the fake cookie. From markus at openbsd.org Thu Nov 29 00:02:21 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 28 Nov 2001 14:02:21 +0100 Subject: No open channels after timeout In-Reply-To: <20011126202235436707.425@conflict.net>; from vader@conflict.net on Mon, Nov 26, 2001 at 08:22:35PM +0000 References: <20011125082319090274.425@conflict.net> <20011126100851.I25182@faui02.informatik.uni-erlangen.de> <20011126092752301961.425@conflict.net> <20011126104710.B1094@faui02.informatik.uni-erlangen.de> <20011126202235436707.425@conflict.net> Message-ID: <20011128140221.A20426@folly> On Mon, Nov 26, 2001 at 08:22:35PM +0000, Jim Breton wrote: > On Mon, Nov 26, 2001 at 10:47:10AM +0100, Markus Friedl wrote: > > the server has enabled the keep alive hack, and this > > conflicts with the -N client option. > > Ahh. OK, thank you. Is there a work-around for this? Looks like the > client can turn KeepAlive on and off, but I don't see any way for the > client to turn off ClientAlive? > > Running the following seems to work but is a "Crude Hack" (TM): > > ssh -T tarkin > /dev/null 2>&1 i think you have to hack ssh.c and make sure that id = ssh_session2_open(); is allways called in ssh_session2() From stevesk at pobox.com Thu Nov 29 07:34:30 2001 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 28 Nov 2001 12:34:30 -0800 (PST) Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <20011128145803.A20105@faui02> Message-ID: On Wed, 28 Nov 2001, Markus Friedl wrote: :On Wed, Nov 28, 2001 at 03:47:29PM +0200, Osmo Paananen wrote: :> > On Wed, Nov 28, 2001 at 03:04:33PM +0200, Osmo Paananen wrote: :> > > Another reason why I haven't tested DISPLAY=localhost:x.y is that I haven't seen :> > > patch for portable version of the OpenSSH. (Even if I had, I probably would test :> > > xterm and xemacs and notice that they work fine). :> > kevin has sent a patch. :> :> I understood that it was not for portable version? : :the new code should work fine on portable. : :an editor might help. right, i'm not maintaining a portable version right now--we're still working on how to best structure this. it's easily applied to portable with patch and an editor :) it should work on platforms with modern X11 >=6.5.1 or perhaps others. it is runtime configurable, now thru gatewayports. some platforms may use uname for displayname, so if that's different than gethostname, it won't work right now. From bbense at networking.stanford.edu Thu Nov 29 08:11:12 2001 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Wed, 28 Nov 2001 13:11:12 -0800 (PST) Subject: Should auth_krb4_password read .klogin ? In-Reply-To: <20011128142831.A2639@multics.mit.edu> Message-ID: - One of Stanford's local oddities in it's kerberos deployment is that it supports using the password of a principal in the .klogin file to access an account. i.e. if bbogon at IR.STANFORD.EDU is listed in my .klogin file, the I can use bbogon's password to log in at the console to my bbense account. We support this where ever it makes sense ( or not...) Ssh k4 logins is one of those places. - Anyway, to make a long story short in the process of adding this into auth_krb4_password I noticed that it does not check that the created username principal is listed in the user's .klogin file. This is a potential problem if you have a username on your machine that is not the same person as the kerberos principal it maps to. Unfortunately, there is no kerberos library call that you can use at this point to access the .klogin file ( kuserok requires an auth_dat structure.) - At Stanford we turn this behaviour on/off with the prescence of a flag file which is called /etc/leland/noklogin for historical reasons. If it exists, then assume foo at IR.STANFORD.EDU is the same as the local acct with username foo. If it's absent check the .klogin file for the user before you grant access. - I'll be hacking this behaviour into a local version of ssh, but is there any interest in having these patches? The flag file is ugly, but perhaps it could be changed to an config option. - Booker C. Bense From stevesk at pobox.com Thu Nov 29 08:10:45 2001 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 28 Nov 2001 13:10:45 -0800 (PST) Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <01Nov28.112014edt.453147-19376@jane.cs.toronto.edu> Message-ID: On Wed, 28 Nov 2001, Dan Astoorian wrote: :> > I haven verified the need for this, I've been listening comments :> > on this list related to the forwarded X11 ports. I've understood :> > that if you use localhost:x.y as your display some (missbehaving) :> > applications will break. : :FWIW, the problem is with Xlib, not the applications themselves. Not :that it matters. well, it does matter, if you're pouring thru X11 code trying to figure out how to deal with this. :> Have you actually verified this? and checked whether the :> IPADDR_IN_DISPLAY workaround that we already have in place :> (see channels.c) avoids it? : :The code which optimizes loopback connections to unix-domain sockets is :(typically) keyed off of the IP address, not the name "localhost"; I :doubt that IPADDR_IN_DISPLAY could make any difference. IPADDR_IN_DISPLAY is i think, only used/needed on hp-ux and reliant unix. if there are others i'd like to know. :The Solaris 2.5.1 source (which is merely the closest reference I have :at hand) has several source files (e.g., MakeTCPConnection() in :XConnDis.c) which contain the comment: : : /* : * We are special casing the BSD hack localhost address : * 127.0.0.1, since this address shouldn't be copied to : * other machines. So, we simply omit generating the auth info : * since we set it to the local machine before calling this routine! : */ : :followed immediately by the following code or something very similar :thereto: : : if (!((len == 4) && (cp[0] == 127) && (cp[1] == 0) && : (cp[2] == 0) && (cp[3] == 1))) { : /*...*/ i don't have solaris code, but that is using a sockaddr i'd think, which is what "localhost" turns in to. :I'd need to look deeper, but I don't think there's that much of a :difference between X over unix domain sockets vs. TCP, once the file :descriptor has been established; the same routines that handle an X :connection to TCP port 6000+dpy would probably work with little :modification with a unix socket. : :If the OpenSSH maintainers agree that supporting Unix sockets--assuming :that doing so doesn't complicate the code significantly--may be the best :solution to this problem, I'd be willing to explore this further. i don't think we need to support unix domain sockets. the goal is that platforms/systems with modern and non-broken Xlib will use a loopback server, others will use the current method. here's a X11 diff that is pertinent. this appeared in R6.5.1. --- R6.4/xc/lib/X11/ConnDis.c Fri Feb 6 14:12:07 1998 +++ R6.5.1/xc/lib/X11/ConnDis.c Mon Aug 21 08:46:25 2000 @@ -1,4 +1,4 @@ -/* $TOG: ConnDis.c /main/115 1998/02/06 17:12:13 kaleb $ */ +/* $Xorg: ConnDis.c,v 1.7 2000/08/17 19:44:31 cpqbld Exp $ */ /* Copyright 1989, 1998 The Open Group @@ -117,6 +117,9 @@ int connect_stat; #ifdef LOCALCONN struct utsname sys; +#ifdef TCPCONN + char *tcphostname = NULL; /* A place to save hostname pointer */ +#endif #endif p = display_name; @@ -178,10 +181,20 @@ p = lastc; #ifdef LOCALCONN - /* check if phostname == localnodename */ - if (phostname && uname(&sys) >= 0 && - !strncmp(phostname, sys.nodename, strlen(sys.nodename))) + /* check if phostname == localnodename AND protocol not specified */ + if (!pprotocol && phostname && uname(&sys) >= 0 && + !strncmp(phostname, sys.nodename, + (strlen(sys.nodename) < strlen(phostname) ? + strlen(phostname) : strlen(sys.nodename)))) { +#ifdef TCPCONN + /* + * We'll first attempt to connect using the local transport. If + * this fails (which is the case if sshd X protocol forwarding is + * being used), retry using tcp and this hostname. + */ + tcphostname = copystring(phostname, strlen(phostname)); +#endif Xfree (phostname); phostname = copystring ("unix", 4); } @@ -271,6 +284,7 @@ } #endif + connect: /* * This seems kind of backwards, but we need to put the protocol, * host, and port back together to pass to _X11TransOpenCOTSClient(). @@ -385,6 +399,16 @@ if (saddr) free ((char *) saddr); if (pprotocol) Xfree (pprotocol); if (phostname) Xfree (phostname); + +#if defined(LOCALCONN) && defined(TCPCONN) + if (tcphostname) { + pprotocol = copystring("tcp", 3); + phostname = tcphostname; + tcphostname = NULL; + goto connect; + } +#endif + if (pdpynum) Xfree (pdpynum); if (pscrnum) Xfree (pscrnum); return NULL; @@ -1107,18 +1131,18 @@ } #endif if (saddr) free ((char *) saddr); - if (*auth_namelenp = auth_namelen) + if ((*auth_namelenp = auth_namelen)) { - if (*auth_namep = Xmalloc(auth_namelen)) + if ((*auth_namep = Xmalloc(auth_namelen))) memcpy(*auth_namep, auth_name, auth_namelen); else *auth_namelenp = 0; } else *auth_namep = NULL; - if (*auth_datalenp = auth_datalen) + if ((*auth_datalenp = auth_datalen)) { - if (*auth_datap = Xmalloc(auth_datalen)) + if ((*auth_datap = Xmalloc(auth_datalen))) memcpy(*auth_datap, auth_data, auth_datalen); else *auth_datalenp = 0; From markus at openbsd.org Thu Nov 29 08:13:13 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 28 Nov 2001 22:13:13 +0100 Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability In-Reply-To: <200111281313.IAA10630@tern.cs.rochester.edu>; from bukys@rochester.edu on Wed, Nov 28, 2001 at 08:13:32AM -0500 References: <200111281313.IAA10630@tern.cs.rochester.edu> Message-ID: <20011128221313.A26077@folly> On Wed, Nov 28, 2001 at 08:13:32AM -0500, bukys at rochester.edu wrote: > * Does anyone have plans to incorporate pam-1 at ssh.com into openssh, no, it's not documented. > or know of plans to incorporate keyboard-interactive into ssh.com's > product? i think they should :) From odie at rotta.media.sonera.net Thu Nov 29 08:29:48 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Wed, 28 Nov 2001 23:29:48 +0200 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: Your message of "Wed, 28 Nov 2001 14:06:50 +0100." <20011128140650.B20426@folly> Message-ID: <200111282129.fASLTmP07328@rotta.tmt.tele.fi> > On Wed, Nov 28, 2001 at 09:35:59AM +0200, Osmo Paananen wrote: > > b) add support for ACL's in forwarded X11 ports (if they are not bound to localhost) > the ACL is in the fake cookie. No. ACL controls the locations where the service can be accessed. The cookie is more like password, once you know it you are allowed to connect. -- Osmo Paananen From markus at openbsd.org Thu Nov 29 08:32:22 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 28 Nov 2001 22:32:22 +0100 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <200111282129.fASLTmP07328@rotta.tmt.tele.fi> References: <20011128140650.B20426@folly> <200111282129.fASLTmP07328@rotta.tmt.tele.fi> Message-ID: <20011128223222.A24431@faui02> On Wed, Nov 28, 2001 at 11:29:48PM +0200, Osmo Paananen wrote: > > On Wed, Nov 28, 2001 at 09:35:59AM +0200, Osmo Paananen wrote: > > > b) add support for ACL's in forwarded X11 ports (if they are not bound to localhost) > > the ACL is in the fake cookie. > > No. ACL controls the locations where the service can be accessed. > The cookie is more like password, once you know it you are allowed > to connect. oh, sorry, the cookie is a capability not an ACL. From jhawk at MIT.EDU Thu Nov 29 08:45:59 2001 From: jhawk at MIT.EDU (John Hawkinson) Date: Wed, 28 Nov 2001 16:45:59 -0500 Subject: Should auth_krb4_password read .klogin ? In-Reply-To: References: <20011128142831.A2639@multics.mit.edu> Message-ID: <20011128164559.E2639@multics.mit.edu> Booker C. Bense wrote on Wed, 28 Nov 2001 at 13:11:12 -0800 in : > - One of Stanford's local oddities in it's kerberos deployment > is that it supports using the password of a principal in the > .klogin file to access an account. ... > - I'll be hacking this behaviour into a local version of ssh, but > is there any interest in having these patches? The flag file > is ugly, but perhaps it could be changed to an config option. I don't think this is a good idea at all. In general, I think it's a bad idea to promote non-standard Kerberos features. Having options and special ways to do Kerberos differently will promote weird divergences, and people misunderstanding exactly how Kerberos works. It seems to me that if there are generic changes to the code (i.e. adding hooks) that make it noticably easier for you to maintain your patches, that would be a reasonable patch to see in openssh. Or pursuing having support for your .klogin/password kludge in Kerberos 5 implementations. Still yet a third option would be to put such patches in contrib/, but I think they are of sufficiently limitted appeal that they're better off not there at all... But perhaps I'm overreacting to changes to a familiar system and the changes would not be so disturbing. But I fear they'd have their own bizarro security problems N years down the line that don't justify their existance now, given the limitted appeal. --jhawk From maf at appgate.com Thu Nov 29 09:14:15 2001 From: maf at appgate.com (maf at appgate.com) Date: Wed, 28 Nov 2001 17:14:15 -0500 (EST) Subject: Possible root-exploit in openssh? In-Reply-To: Message-ID: <20011128221414.E1B496C007@shala.firedoor.se> On 28 Nov, Fredrik Hultkrantz wrote: > It doesn't seem to be the crc-bu but more somwthing in the line of a > buffer overrun during the handshake As far as I can see it is indeed the old bug in deattack.c they try to exploit. At least I could not get the exploit you sent me to report the sshd as vulnerable unless I backed out that old fix. /MaF From djm at mindrot.org Thu Nov 29 09:32:22 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Nov 2001 09:32:22 +1100 (EST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability In-Reply-To: <200111281313.IAA10630@tern.cs.rochester.edu> Message-ID: On Wed, 28 Nov 2001 bukys at rochester.edu wrote: > Questions: > > * Does anyone have plans to incorporate pam-1 at ssh.com into openssh, > or know of plans to incorporate keyboard-interactive into ssh.com's > product? Why do we want to introduce a proprietary exchange into our client to support a commercial vendor who won't implement the standard (kbd-interactive) way of doing such things? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From carl at bl.echidna.id.au Thu Nov 29 09:35:25 2001 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Thu, 29 Nov 2001 09:35:25 +1100 (EST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability Message-ID: <200111282235.fASMZPF0005407@rollcage.bl.echidna.id.au> > From: Damien Miller > > On Wed, 28 Nov 2001 bukys at rochester.edu wrote: > > > Questions: > > > > * Does anyone have plans to incorporate pam-1 at ssh.com into openssh, > > or know of plans to incorporate keyboard-interactive into ssh.com's > > product? > > Why do we want to introduce a proprietary exchange into our client > to support a commercial vendor who won't implement the standard > (kbd-interactive) way of doing such things? Because sometimes compromise is a good way to reach a goal. You're not supporting a commercial vendor, you're supporting your users. qf Samba et al Carl From djm at mindrot.org Thu Nov 29 09:40:04 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Nov 2001 09:40:04 +1100 (EST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability In-Reply-To: <200111282235.fASMZPF0005407@rollcage.bl.echidna.id.au> Message-ID: On Thu, 29 Nov 2001 carl at bl.echidna.id.au wrote: > > Why do we want to introduce a proprietary exchange into our client > > to support a commercial vendor who won't implement the standard > > (kbd-interactive) way of doing such things? > > Because sometimes compromise is a good way to reach a goal. You're > not supporting a commercial vendor, you're supporting your users. SSH.COM is not Microsoft and we are not Samba. The ssh.com's PAM support is broken anyway (cf. Darren's message) and there is a better _standard_ exchange for doing such things. If the users of said commerical vendor need better PAM support, they should switch to OpenSSH (cf Darren's message again). -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From stevesk at pobox.com Thu Nov 29 09:46:25 2001 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 28 Nov 2001 14:46:25 -0800 (PST) Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <200111282129.fASLTmP07328@rotta.tmt.tele.fi> Message-ID: On Wed, 28 Nov 2001, Osmo Paananen wrote: :> On Wed, Nov 28, 2001 at 09:35:59AM +0200, Osmo Paananen wrote: :> > b) add support for ACL's in forwarded X11 ports (if they are not bound to localhost) :> the ACL is in the fake cookie. : :No. ACL controls the locations where the service can be accessed. :The cookie is more like password, once you know it you are allowed :to connect. it's an authentication secret. but i'm confused. are you performing X to the sshd fake X11 socket from remote hosts? can you explain exactly what security feature you are looking for and why you want it? From carl at bl.echidna.id.au Thu Nov 29 10:06:50 2001 From: carl at bl.echidna.id.au (carl at bl.echidna.id.au) Date: Thu, 29 Nov 2001 10:06:50 +1100 (EST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability Message-ID: <200111282306.fASN6owa005550@rollcage.bl.echidna.id.au> > From: Damien Miller > > On Thu, 29 Nov 2001 carl at bl.echidna.id.au wrote: > > > > Why do we want to introduce a proprietary exchange into our client > > > to support a commercial vendor who won't implement the standard > > > (kbd-interactive) way of doing such things? > > > > Because sometimes compromise is a good way to reach a goal. You're > > not supporting a commercial vendor, you're supporting your users. > > SSH.COM is not Microsoft and we are not Samba. True :) > The ssh.com's PAM support > is broken anyway (cf. Darren's message) and there is a better _standard_ > exchange for doing such things. Again, True. NFS was a (arguably better) standard a long time before there was SMB too. But, you're not doing Samba, and SSH.COM isn't Microshaft, the compromises that that team do to interoperate with a hostile vendor don't apply, because OpenSSH doesn't have to interoperate with anyone :) Least of all someone who was there first, and who you took the original code from! Remember that SSH.COM was there first, and started the whole thing. > If the users of said commerical vendor need better PAM support, they > should switch to OpenSSH (cf Darren's message again). In an ideal world, sure, everyone would use OpenSSH (or FreSSH or whatever ...). But, this isn't an ideal world. For the sake of interoperability (and thus, supporting users who must live in the real world :) ), sometimes it's ok to compromise an ideal to reach a goal. You don't have to, it's your baby, but you don't need to can the idea if it's mentioned. The strength of UNIX is that it's flexible and can talk to anything, that's not a bad claim to fame. Where would we be if Eric Allman didn't make sendmail interact better with M$'s broken SMTP AUTH? If Apache insisted on only supporting "proper" HTTP? If Mozilla only parsed 100% legal HTML (if anyone can define that anyway?). If your resolver library rejected A records with _'s in them? The world's full of these compromises. It's how we get stuff done. OpenSSH is a tool to to a job. The job is secure, authenticated connections between computers. If a few compromises here and there get made to help it interact with other vendors (broken or otherwise), is that such a bad thing? Unless (and even if it does, qf sendmail and SMTP AUTH) it breaks a security requirement, and even then, it could/should warn, rather than forbid. Carl (not wanting to start any sort of religious war, and having made my point, not saying any more on the issue :) ) From Darren.Moffat at eng.sun.com Thu Nov 29 10:15:02 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 28 Nov 2001 15:15:02 -0800 (PST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability Message-ID: <200111282315.fASNFLba969014@jurassic.eng.sun.com> >from! Remember that SSH.COM was there first, and started the whole >thing. OpenSSH did not take SSH protocol v2 code from SSH Inc. SSH Inc even wrote the draft for keyboard interactive that they fail to use. In this case they have a fundamental misunderstanding of a technology called PAM (that Sun invented and dontated to X/Open), they have taken PAM to be what GSS actually is, PAM is not a network protocol it is an API. That misunderstanding has made its way into code. The correct way to resolve this is for people who care to lobby SSH Inc to do the correct thing, not for other implementations to introduce security weaknesses in the their code to give the illusion of interoperability with SSH Inc. -- Darren J Moffat From djm at mindrot.org Thu Nov 29 10:16:39 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Nov 2001 10:16:39 +1100 (EST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability In-Reply-To: <200111282306.fASN6owa005550@rollcage.bl.echidna.id.au> Message-ID: On Thu, 29 Nov 2001 carl at bl.echidna.id.au wrote: > Where would we be if Eric Allman didn't make sendmail > interact better with M$'s broken SMTP AUTH? If Apache > insisted on only supporting "proper" HTTP? If Mozilla only parsed > 100% legal HTML (if anyone can define that anyway?). If > your resolver library rejected A records with _'s in them? The world's > full of these compromises. We are not talking about a few tweaks necessary to implement the Robustness Principle (we have lots of those already) - we are talking about adding a whole protocol exchange. > It's how we get stuff done. OpenSSH > is a tool to to a job. The job is secure, authenticated > connections between computers. If a few compromises here and > there get made to help it interact with other vendors (broken > or otherwise), is that such a bad thing? Yes - it bloats OpenSSH, increases the divergence between OpenBSD and portable and make our code more difficult to audit. Why not spend this effort trying to get ssh.com to support kbd-interactive? Then everyone would be happy. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From Tariq.Lahyani at aa.com Thu Nov 29 10:32:18 2001 From: Tariq.Lahyani at aa.com (Tariq Lahyani) Date: Wed, 28 Nov 2001 17:32:18 -0600 Subject: scp Message-ID: Hello - I am trying to use scp (openssh_3.0), but every time I run it, I get the following error: stty: Not a typewriter When I run it with -v , it shows that authentication (pub key) succeeds, but it fails to read the file. If anybody has a clue as to what's going on here, any help will be appreciated. Thanks. Tariq tariq.lahyani at aa.com From djm at mindrot.org Thu Nov 29 10:41:03 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Nov 2001 10:41:03 +1100 (EST) Subject: scp In-Reply-To: Message-ID: On Wed, 28 Nov 2001, Tariq Lahyani wrote: > Hello - > > I am trying to use scp (openssh_3.0), but every time I run it, I get > the following error: > > stty: Not a typewriter Do you have .bashrc or similar scripts that are being run when non-login sessions are started? If so, fix them. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From bbense at networking.stanford.edu Thu Nov 29 11:11:59 2001 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Wed, 28 Nov 2001 16:11:59 -0800 (PST) Subject: Should auth_krb4_password read .klogin ? In-Reply-To: <20011128164559.E2639@multics.mit.edu> Message-ID: On Wed, 28 Nov 2001, John Hawkinson wrote: > Booker C. Bense wrote on Wed, 28 Nov 2001 > at 13:11:12 -0800 in : > > > > - One of Stanford's local oddities in it's kerberos deployment > > is that it supports using the password of a principal in the > > .klogin file to access an account. > ... > > - I'll be hacking this behaviour into a local version of ssh, but > > is there any interest in having these patches? The flag file > > is ugly, but perhaps it could be changed to an config option. > > I don't think this is a good idea at all. > > > But perhaps I'm overreacting to changes to a familiar system and the > changes would not be so disturbing. But I fear they'd have their own > bizarro security problems N years down the line that don't justify > their existance now, given the limitted appeal. > - You're misunderstanding what I'm offering. IMHO, it's a misfeature of openssh to ignore the .klogin entries when accepting kerberos logins via password. No other kerberos software does this. It's a useful hack to do this on systems that support AFS, but IMHO it should not be the default behaviour. Suppose I had the principal root at MY.DOMAIN, if ssh allowed root kerberos logins I would now have root access on all the machines in the domain. - This doesn't work in the current code, but for any local acct that has a non-zero uid it does. - I agree that reading .klogin for alternative login principals is wierd, but it's entrenched here and I have to support it. It's kind of consistant in that if you use a service tkt to login instead of a password you get the same behaviour. However, I am not offering those patches. - As far as contributing our local wierdnesses to MIT's k5 code, I have done quite a bit of that, but some things they just refuse to swallow. %-). - Booker C. Bense From jhawk at MIT.EDU Thu Nov 29 12:05:27 2001 From: jhawk at MIT.EDU (John Hawkinson) Date: Wed, 28 Nov 2001 20:05:27 -0500 Subject: Should auth_krb4_password read .klogin ? In-Reply-To: References: <20011128164559.E2639@multics.mit.edu> Message-ID: <20011128200527.G2639@multics.mit.edu> Booker C. Bense wrote on Wed, 28 Nov 2001 at 16:11:59 -0800 in : > - You're misunderstanding what I'm offering. IMHO, it's a misfeature > of openssh to ignore the .klogin entries when accepting kerberos > logins via password. Ah. Right, indeed, I thought you were referring to the alternate login principals thing. > No other kerberos software does this. Hmm. I guess I'm not under this impression. My reading of, for instance, the kth-krb4 login program doesn't show me any sign of this checking of password entries against the .klogin file. Orally inquiring of somebody else, he suggests that this feature might be present in Derrick Brashear's krb4 PAM support. But of this regardless, I agree it makes sense, otherwise a local machine's administrator has no way to prevent a kerberos administrator from logging into any account on his machine. > - This doesn't work in the current code, but for any local acct > that has a non-zero uid it does. *nod*. > - I agree that reading .klogin for alternative login principals ... > However, I am not offering those patches. OK. Sorry about the confusion. > - As far as contributing our local wierdnesses to MIT's k5 code, > I have done quite a bit of that, but some things they just refuse > to swallow. %-). Umm, yeah. Isn't this an issue for krb5, too, though, in ssh? I don't see a call to krb5_kuserok() in auth_krb5_password(), and since there's no requirement for anything other than a krb5_context, it should be pretty easy. And we should fix it at the same time. No? It seems that this is a problem with the sample stuff in MIT krb5, e.g. appl/bsd/login.c; nor does Heimdal deal with it in appl/login/login.c. Eww. Who wants to take this up with them? --jhawk From maf at appgate.com Thu Nov 29 14:02:32 2001 From: maf at appgate.com (maf at appgate.com) Date: Wed, 28 Nov 2001 22:02:32 -0500 (EST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability In-Reply-To: <200111282315.fASNFLba969014@jurassic.eng.sun.com> Message-ID: <20011129030221.9B8CB6C007@shala.firedoor.se> On 28 Nov, Darren Moffat wrote: > SSH Inc even wrote the draft for keyboard interactive that they fail > to use. Just to set the record straight here. I and Frank Cusack wrote the keyboard-interactive draft and neither of us has, AFAIK, ever been employed by SSH (Inc/OY). That said the reason we did keyboard-interactive was just to avoid having to add support in the client end for each new authmethod the server chooses to implement. /MaF From slade at shore.net Thu Nov 29 14:38:21 2001 From: slade at shore.net (Richard E. Silverman) Date: Wed, 28 Nov 2001 22:38:21 -0500 Subject: keystroke timing attack Message-ID: <200111290338.WAA15293@syrinx.oankali.net> A couple observations: 1) The original poster (Jason) referred to the O'Reilly article on the timing attack, but confused timing user session data with SSH password authentication. Jason: the distinction is actually carefully made in the article; see the first section under "Common Misconceptions." 2) In this thread, it is proposed to send dummy packets at either pseudo-random or fixed intervals. Both of these are of questionable value, as is pointed out both in the article and in the Song et al. paper, as well as in Solar's paper. The fixed-gap packets will show up as a tall spike in a frequency domain analysis of the timing data, and are easily filtered out. Similarly, pseudo-random noise can be filtered, since the user typing data is *not* random. This is especially true if one can gather repeated examples to average out the noise -- and people often type their passwords quite a lot. -- Richard Silverman slade at shore.net [disclosure: I wrote the O'Reilly article] From maf at appgate.com Thu Nov 29 15:41:18 2001 From: maf at appgate.com (maf at appgate.com) Date: Wed, 28 Nov 2001 23:41:18 -0500 (EST) Subject: keystroke timing attack In-Reply-To: <200111290338.WAA15293@syrinx.oankali.net> Message-ID: <20011129044108.D6CDE6C007@shala.firedoor.se> On 28 Nov, Richard E. Silverman wrote: > 2) In this thread, it is proposed to send dummy packets at either > pseudo-random or fixed intervals. Both of these are of > questionable value, as is pointed out both in the article and in > the Song et al. paper, as well as in Solar's paper. The fixed-gap > packets will show up as a tall spike in a frequency domain analysis > of the timing data, and are easily filtered out. The idea behind the fixed-packet stream is that all packets are part of it. That is the server doesn't send key-presses immediately when the occur but rather wait for the next time it should send a packet, according to the interval, and send the keystroke then instead of the normal dummy packet. The attacker will only see an even stream of packets, with the same length, at regular intervals. There is no way for him to distinguish between the dummy packets and the real ones. To word it differently we do not add a stream of fixed packets, instead we integrate the key presses into the fixed-stream. /MaF From Darren.Moffat at eng.sun.com Thu Nov 29 16:19:42 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 28 Nov 2001 21:19:42 -0800 (PST) Subject: PAM, keyboard interactive, pam-1@ssh.com, interoperability Message-ID: <200111290520.fAT5K0Eu114621@jurassic.eng.sun.com> >On 28 Nov, Darren Moffat wrote: >> SSH Inc even wrote the draft for keyboard interactive that they fail >> to use. > >Just to set the record straight here. I and Frank Cusack wrote the >keyboard-interactive draft and neither of us has, AFAIK, ever been >employed by SSH (Inc/OY). Thanks, bad memory on my part I should have checked the drafts before posting - Kevin had correctly me privately (I just hadn't got around to sending my own correction). >That said the reason we did keyboard-interactive was just to avoid >having to add support in the client end for each new authmethod the >server chooses to implement. and thank you I think keyboard-interactive is great! -- Darren J Moffat From pin at stredo.com Thu Nov 29 18:07:24 2001 From: pin at stredo.com (Pin Lu) Date: Thu, 29 Nov 2001 02:07:24 -0500 Subject: openssh 2.9p2 release 8.7 security alert!!! Message-ID: <002c01c178a4$7f6241c0$6501a8c0@pureview.com> Hi, everyone: My system was compromised a few days ago. The cracker attacked the system through openssh 2.9p2 release 8.7. I attached part of the log file. Thanks. Pin Lu (pin at stredo.com) Nov 25 11:33:05 ns sshd[10627]: Disconnecting: Corrupted check bytes on input. Nov 25 11:33:36 ns named[10478]: Lame server on '55.254.58.211.in-addr.arpa' (in '254.58.211.in-addr.arpa'?): [210.180.98.69].53 'ns2.hananet.net' Nov 25 11:33:36 ns named[10478]: Lame server on '55.254.58.211.in-addr.arpa' (in '254.58.211.in-addr.arpa'?): [210.94.0.7].53 'ns.hananet.net' Nov 25 11:33:36 ns named[10478]: ns_forw: query(55.254.58.211.in-addr.arpa) All possible A RR's lame Nov 25 11:33:45 ns sshd[10689]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:45 ns sshd[10690]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:46 ns sshd[10691]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:46 ns sshd[10692]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:47 ns sshd[10693]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:48 ns sshd[10694]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:49 ns sshd[10696]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:50 ns sshd[10698]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:50 ns sshd[10700]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:51 ns sshd[10701]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:51 ns sshd[10702]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:52 ns sshd[10703]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:33:59 ns sshd[10714]: Disconnecting: Corrupted check bytes on input. Nov 25 11:34:00 ns sshd[10715]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:01 ns sshd[10716]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:02 ns sshd[10717]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:02 ns sshd[10718]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:03 ns sshd[10719]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:03 ns sshd[10720]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:05 ns sshd[10722]: Disconnecting: Corrupted check bytes on input. Nov 25 11:34:05 ns sshd[10723]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:06 ns sshd[10724]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:06 ns sshd[10725]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:07 ns sshd[10726]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:08 ns sshd[10727]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:08 ns sshd[10728]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:34:40 ns sshd[10771]: Disconnecting: Corrupted check bytes on input. Nov 25 11:35:21 ns sshd[10832]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:21 ns sshd[10833]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:22 ns sshd[10834]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:22 ns sshd[10835]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:23 ns sshd[10836]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:24 ns sshd[10837]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:24 ns sshd[10838]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:25 ns sshd[10840]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:26 ns sshd[10841]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:27 ns sshd[10842]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:34 ns sshd[10854]: Disconnecting: Corrupted check bytes on input. Nov 25 11:35:35 ns sshd[10855]: Disconnecting: Corrupted check bytes on input. Nov 25 11:35:36 ns sshd[10856]: Disconnecting: Corrupted check bytes on input. Nov 25 11:35:36 ns sshd[10857]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:37 ns sshd[10858]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:37 ns sshd[10859]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:38 ns sshd[10860]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:45 ns sshd[10871]: Disconnecting: Corrupted check bytes on input. Nov 25 11:35:46 ns sshd[10872]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:46 ns sshd[10873]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:47 ns sshd[10874]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:48 ns sshd[10875]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:48 ns sshd[10876]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:49 ns sshd[10877]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:50 ns sshd[10878]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:50 ns sshd[10879]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:51 ns sshd[10881]: Disconnecting: Corrupted check bytes on input. Nov 25 11:35:52 ns sshd[10882]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:53 ns sshd[10883]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:53 ns sshd[10884]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:35:54 ns sshd[10885]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:36:25 ns named[10478]: denied update from [24.184.45.120].3015 for "echasqui.com" Nov 25 11:36:49 ns sshd[10914]: Disconnecting: Corrupted check bytes on input. Nov 25 11:37:28 ns sshd[10975]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:29 ns sshd[10976]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:30 ns sshd[10977]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:30 ns sshd[10978]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:31 ns sshd[10979]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:32 ns sshd[10980]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:32 ns sshd[10981]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:33 ns sshd[10982]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:33 ns sshd[10983]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:35 ns sshd[10985]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:35 ns sshd[10986]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:36 ns sshd[10987]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:37 ns sshd[10988]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:37 ns sshd[10989]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:38 ns sshd[10990]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:38 ns sshd[10991]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:39 ns sshd[10992]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:40 ns sshd[10993]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:40 ns sshd[10994]: Disconnecting: crc32 compensation attack: network attack detected Nov 25 11:37:48 ns sshd[11006]: Disconnecting: Corrupted check bytes on input. Nov 25 11:37:53 ns sshd[11013]: Disconnecting: Corrupted check bytes on input. Nov 25 11:37:54 ns sshd[11014]: Disconnecting: Corrupted check bytes on input. Nov 25 11:40:00 ns CROND[11022]: (root) CMD ( /sbin/rmmod -as) Nov 25 11:40:08 ns adduser[11023]: new group: name=mattanl, gid=528 Nov 25 11:40:08 ns adduser[11023]: new user: name=mattanl, uid=528, gid=528, home=/home/mattanl, shell=/bin/bash Nov 25 11:40:27 ns adduser[11027]: new group: name=mattan, gid=529 Nov 25 11:40:27 ns adduser[11027]: new user: name=mattan, uid=0, gid=529, home=/home/mattan, shell=/bin/bash Nov 25 11:40:52 ns PAM_unix[11032]: (system-auth) session opened for user mattanl by (uid=0) Nov 25 11:40:52 ns -- mattanl[11032]: LOGIN ON pts/1 BY mattanl FROM PT712079.bezeqint.net Nov 25 11:41:49 ns PAM_unix[11054]: (system-auth) session opened for user mattan by mattanl(uid=528) Nov 25 11:43:08 ns sshd[577]: Generating new 768 bit RSA key. Nov 25 11:43:08 ns sshd[577]: RSA key generation complete. Nov 25 11:44:09 ns PAM_unix[11054]: (system-auth) session closed for user mattan Nov 25 11:44:10 ns modprobe: modprobe: Can't locate module binfmt-0000 Nov 25 11:44:10 ns modprobe: modprobe: Can't locate module binfmt-0000 Nov 25 11:44:10 ns in.telnetd: PT712079.bezeqint.net [14364]: /bin/login: Exec format error Nov 25 11:45:01 ns PAM_unix[14367]: authentication failure; (uid=0) -> mattanl for system-auth service Nov 25 11:45:07 ns named[10478]: Lame server on '55.254.58.211.in-addr.arpa' (in '254.58.211.in-addr.arpa'?): [210.94.0.7].53 'ns.hananet.net' Nov 25 11:45:07 ns named[10478]: Lame server on '55.254.58.211.in-addr.arpa' (in '254.58.211.in-addr.arpa'?): [210.180.98.69].53 'ns2.hananet.net' Nov 25 11:45:07 ns named[10478]: ns_forw: query(55.254.58.211.in-addr.arpa) All possible A RR's lame Nov 25 11:45:07 ns sshd[14367]: Could not reverse map address 211.58.254.55. Nov 25 11:45:07 ns sshd[14367]: Accepted password for mattanl from 211.58.254.55 port 1023 ssh2 Nov 25 11:45:08 ns PAM_unix[14367]: (system-auth) session opened for user mattanl by (uid=0) Nov 25 11:46:19 ns PAM_unix[14384]: (system-auth) session opened for user mattan by mattanl(uid=528) Nov 25 11:47:06 ns PAM_unix[14367]: (system-auth) session closed for user mattanl Nov 25 11:47:07 ns PAM_unix[14384]: (system-auth) session closed for user mattan From djm at mindrot.org Thu Nov 29 18:59:11 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Nov 2001 18:59:11 +1100 (EST) Subject: openssh 2.9p2 release 8.7 security alert!!! In-Reply-To: <002c01c178a4$7f6241c0$6501a8c0@pureview.com> Message-ID: On Thu, 29 Nov 2001, Pin Lu wrote: > Hi, everyone: > > My system was compromised a few days ago. > The cracker attacked the system through openssh 2.9p2 release 8.7. > I attached part of the log file. What is release 8.7? What operating system? -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From wpilorz at bdk.pl Thu Nov 29 19:11:51 2001 From: wpilorz at bdk.pl (Wojtek Pilorz) Date: Thu, 29 Nov 2001 09:11:51 +0100 (CET) Subject: openssh 2.9p2 release 8.7 security alert!!! In-Reply-To: Message-ID: On Thu, 29 Nov 2001, Damien Miller wrote: > Date: Thu, 29 Nov 2001 18:59:11 +1100 (EST) > From: Damien Miller > To: Pin Lu > Cc: openssh-unix-dev at mindrot.org > Subject: Re: openssh 2.9p2 release 8.7 security alert!!! > > On Thu, 29 Nov 2001, Pin Lu wrote: > > > Hi, everyone: > > > > My system was compromised a few days ago. > > The cracker attacked the system through openssh 2.9p2 release 8.7. > > I attached part of the log file. > > What is release 8.7? What operating system? I guess this was RedHat Linux 7.0 or 7.1; ftp://updates.redhat.com contains 7.0/en/os/SRPMS/openssh-2.9p2-8.7.src.rpm and 7.1/en/os/SRPMS/openssh-2.9p2-8.7.src.rpm (which are identical) and resulting binary packages (also identical for 7.0 and 7.1, at least for x86) > > -d Best regards, Wojtek From odie at rotta.media.sonera.net Thu Nov 29 22:08:53 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Thu, 29 Nov 2001 13:08:53 +0200 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: Your message of "Wed, 28 Nov 2001 14:46:25 PST." Message-ID: <200111291108.fATB8rP30281@rotta.tmt.tele.fi> > it's an authentication secret. but i'm confused. are you performing X to > the sshd fake X11 socket from remote hosts? No. > can you explain exactly what > security feature you are looking for and why you want it? The reason is simply because there is a possibility to get access to my display from remote computer if attacker guesses the cookie of the fake server (and if he/she gets through my firewalls). I don't like possibilities like that especially when it can be prevented with a simple fix. I don't consider this flaw to be a big risk, but an futile one. Nothing will break if ACL is to be added. Nothing. If you don't do anything to close down this small hole, that's ok to me. I can apply my own patch to every new and great version of OpenSSH you make. -- Osmo Paananen From ed at UDel.Edu Fri Nov 30 02:04:09 2001 From: ed at UDel.Edu (Ed Phillips) Date: Thu, 29 Nov 2001 10:04:09 -0500 (EST) Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: <200111291108.fATB8rP30281@rotta.tmt.tele.fi> Message-ID: On Thu, 29 Nov 2001, Osmo Paananen wrote: > Date: Thu, 29 Nov 2001 13:08:53 +0200 > From: Osmo Paananen > To: Kevin Steves > Cc: openssh-unix-dev at mindrot.org > Subject: Re: [PATCH] tcp-wrappers support extended to x11 forwards > > > it's an authentication secret. but i'm confused. are you performing X to > > the sshd fake X11 socket from remote hosts? > > No. > > > can you explain exactly what > > security feature you are looking for and why you want it? > > The reason is simply because there is a possibility to get access > to my display from remote computer if attacker guesses the cookie > of the fake server (and if he/she gets through my firewalls). I you login to SystemB with X forwarding enabled to SystemA, then an attacker gets your fake cookie on SystemB, how do you propose to prevent him from running X programs and displaying on SystemA - even with the proposed X wrapper support? It doesn't seem stoppable, since you've enable forwarding for SystemB-to-SystemA, the attacker is logged into SystemB, and has your fake cookie... Sorry if I overly dense this morning... ;-) Ed Ed Phillips University of Delaware (302) 831-6082 Systems Programmer III, Network and Systems Services finger -l ed at polycut.nss.udel.edu for PGP public key From shaun.mccullagh at marviq.com Fri Nov 30 02:51:24 2001 From: shaun.mccullagh at marviq.com (Shaun McCullagh) Date: Thu, 29 Nov 2001 16:51:24 +0100 Subject: OPENssh (2.9p2) and keylogin in NIS+ on Solaris 7 with PAM Message-ID: <3C06597C.B1DDDE3D@marviq.com> Hi, I'm trying to make sshd perform a keylogin on a Solaris 7 NIS+ client with PAM. ssh connects and works fine but keyserv reports that it `can't encrypt the session key'. So I think the keylogin failed or did not happen when the user started an ssh session. The following message is logged in syslog. >sshd[489]: pam_setcred: error Permission denied >sshd[506]: keyserv_client: can't stat 10 I've double checked NIS+ is running correctly with telnet. keyserv works ok with this... I compiled OPENssh 2.9p2 (on Solaris 7) with configure --prefix=/usr/local --with-pam \ --with-tcp-wrappers --sysconfdir=/usr/local/etc \ --with-ssl-dir=/usr/local I added this line to /etc/pam.conf: sshd auth required /usr/lib/security/pam_unix.so.1 and set these parameters in sshd_config: PasswordAuthentication no PAMAuthenticationViaKdbInt yes I note that the sshd daemon is using PAM as it reports this when invoked with '-ddd' I'd really grateful for any suggestions/ideas TIA -- Shaun From markus at openbsd.org Fri Nov 30 06:15:46 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 29 Nov 2001 20:15:46 +0100 Subject: killpg(SIGHUP, loginshellpid) ? Message-ID: <20011129201546.A15704@folly> in ssh v2, if the connection is closed, should the server do a killpg(SIGHUP, loginshellpid) does this make sense? -markus Index: session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.108 diff -u -r1.108 session.c --- session.c 11 Oct 2001 13:45:21 -0000 1.108 +++ session.c 29 Nov 2001 19:13:40 -0000 @@ -1607,8 +1607,13 @@ int i; for(i = 0; i < MAX_SESSIONS; i++) { Session *s = &sessions[i]; - if (s->used) + if (s->used) { + if (s->pid != 0) { + debug3("killpg %d", s->pid); + killpg(SIGHUP, s->pid); + } session_close(s); + } } } From bbense at networking.stanford.edu Fri Nov 30 08:43:07 2001 From: bbense at networking.stanford.edu (Booker C. Bense) Date: Thu, 29 Nov 2001 13:43:07 -0800 (PST) Subject: Should auth_krb4_password read .klogin ? In-Reply-To: <20011128200527.G2639@multics.mit.edu> Message-ID: On Wed, 28 Nov 2001, John Hawkinson wrote: > Booker C. Bense wrote on Wed, 28 Nov 2001 > at 16:11:59 -0800 in : > > > > - You're misunderstanding what I'm offering. IMHO, it's a misfeature > > of openssh to ignore the .klogin entries when accepting kerberos > > logins via password. > > > But of this regardless, I agree it makes sense, otherwise a local > machine's administrator has no way to prevent a kerberos administrator > from logging into any account on his machine. - I've attached the patch for auth-krb4.c > > OK. Sorry about the confusion. > > > - As far as contributing our local wierdnesses to MIT's k5 code, > > I have done quite a bit of that, but some things they just refuse > > to swallow. %-). > > Umm, yeah. > > Isn't this an issue for krb5, too, though, in ssh? - From what I can see yes, it's a problem. The krb5 code that's in the latest release is heimdal only as far I can tell. Since the krb5 code not enabled and should really use Simon's patches I don't want to mess with it until I'm sure it's the right code. > > It seems that this is a problem with the sample stuff in MIT krb5, > e.g. appl/bsd/login.c; nor does Heimdal deal with it in > appl/login/login.c. > > Eww. Who wants to take this up with them? > - I have a bunch of login.c patches I've been meaning to send in. I'll make sure this gets on the list. - Booker C. Bense -------------- next part -------------- Index: auth-krb4.c =================================================================== RCS file: /afs/ir/dev/cvs/kerberos/openssh/auth-krb4.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 auth-krb4.c --- auth-krb4.c 2001/10/01 18:18:44 1.1.1.1 +++ auth-krb4.c 2001/11/29 00:16:58 @@ -164,6 +311,12 @@ KRB4_SERVICE_NAME, krb_err_txt[r]); goto failure; } + /* Now use adata to verify that user can login to acct */ + if (kuserok(&adata, pw->pw_name) != KSUCCESS) { + log("Kerberos v4 .klogin authorization failed for %s@%s to " + "account %s",adata.pname,adata.prealm , pw->pw_name); + goto failure ; + } } else if (r == KDC_PR_UNKNOWN) { /* * Disallow login if no rcmd service exists, and From irvant at ag.co.id Fri Nov 30 15:59:37 2001 From: irvant at ag.co.id (Irvant Martheen) Date: Fri, 30 Nov 2001 11:59:37 +0700 Subject: No subject Message-ID: <008901c1795b$cfae5c60$3801000a@doom.local> From res at shore.net Fri Nov 30 16:07:12 2001 From: res at shore.net (Richard E. Silverman) Date: Fri, 30 Nov 2001 00:07:12 -0500 (EST) Subject: keystroke timing attack In-Reply-To: <20011129044108.D6CDE6C007@shala.firedoor.se> Message-ID: On Wed, 28 Nov 2001 maf at appgate.com wrote: > The idea behind the fixed-packet stream is that all packets are part of > it... Ah! I see -- in fact, it was reasonably clear in the thread; I should have read more carefully. Thanks. -- Richard Silverman slade at shore.net From odie at rotta.media.sonera.net Fri Nov 30 18:16:13 2001 From: odie at rotta.media.sonera.net (Osmo Paananen) Date: Fri, 30 Nov 2001 09:16:13 +0200 Subject: [PATCH] tcp-wrappers support extended to x11 forwards In-Reply-To: Your message of "Thu, 29 Nov 2001 10:04:09 EST." Message-ID: <200111300716.fAU7GDP31905@rotta.tmt.tele.fi> > I you login to SystemB with X forwarding enabled to SystemA, then an > attacker gets your fake cookie on SystemB, how do you propose to prevent > him from running X programs and displaying on SystemA - even with the > proposed X wrapper support? It doesn't seem stoppable, since you've > enable forwarding for SystemB-to-SystemA, the attacker is logged into > SystemB, and has your fake cookie... ACL won't protect me in that case. But without ACL the attack can come from host C which is not related to A or B. The attacker doesn't have the fake cookie, but he may guess it (by trying several times). I don't know how possible values there are for the fake cookie. My guess is that there is a lot of them. That is why this is not a big security hole. Sure, the attack will be noisy and time consuming. But still the hole is there. And there is no reason for it to be there. -- Osmo Paananen From matthew at sel.cam.ac.uk Fri Nov 30 21:54:05 2001 From: matthew at sel.cam.ac.uk (Matthew Vernon) Date: Fri, 30 Nov 2001 10:54:05 +0000 Subject: Authentication response too long with protocol 2 and ssh 3.0.1p1 Message-ID: <15367.25933.558190.959265@rapun.sel.cam.ac.uk> Hi, I get the following, having built openssh 3.0.1p1 on a linux system - this is the result of trying to ssh to localhost. OpenSSH_3.0.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090601f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 1024 geteuid 0 anon 1 debug1: Connecting to ming [172.16.22.1] port 22. debug1: temporarily_use_uid: 1024/1024 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 1024/1024 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug2: key_type_from_name: unknown key type '1024' debug3: key_read: no key found debug1: identity file /home/matthew/.ssh/identity type -1 debug1: identity file /home/matthew/.ssh/id_rsa type 1 debug1: identity file /home/matthew/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.0.1p1 debug1: match: OpenSSH_3.0.1p1 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.0.1p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 127/256 debug1: bits set: 1569/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/matthew/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 2 debug3: check_host_in_hostfile: filename /home/matthew/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 2 debug1: Host 'ming' is known and matches the RSA host key. debug1: Found key in /home/matthew/.ssh/known_hosts2:2 debug1: bits set: 1594/3191 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: next auth method to try is publickey Authentication response too long: 1433299822 debug1: Calling cleanup 0x80633fc(0x0) -- Rapun.sel - outermost outpost of the Pick Empire http://www.pick.ucam.org From kent at unit.liu.se Fri Nov 30 22:56:29 2001 From: kent at unit.liu.se (Kent =?iso-8859-1?q?Engstr=F6m?=) Date: 30 Nov 2001 12:56:29 +0100 Subject: openssh 2.9p2 release 8.7 security alert!!! In-Reply-To: Pin Lu's message of "Thu, 29 Nov 2001 02:07:24 -0500" References: <002c01c178a4$7f6241c0$6501a8c0@pureview.com> Message-ID: Pin Lu writes: > Hi, everyone: > > My system was compromised a few days ago. > The cracker attacked the system through openssh 2.9p2 release 8.7. > I attached part of the log file. It would be very nice (though it would of course be even nicer to find out that it wasn't) to be more sure that 2.9p2 was actually up and running on port 22 of the computer in question. I have personally told people to upgrade, received "OK, done." and then still found them running the old version, because the SSH server was not restarted at upgrade time. Unfortunately, that information is not available in the log below. Perhaps version information could be included in some periodical messages (such as "Generating new 768 bit RSA key.") or in "security alert messages" such as "...crc32 compensation attack..." > > > Thanks. > > Pin Lu (pin at stredo.com) > > > Nov 25 11:33:05 ns sshd[10627]: Disconnecting: Corrupted check bytes on > input. > Nov 25 11:33:36 ns named[10478]: Lame server on '55.254.58.211.in-addr.arpa' > (in '254.58.211.in-addr.arpa'?): [210.180.98.69].53 'ns2.hananet.net' > Nov 25 11:33:36 ns named[10478]: Lame server on '55.254.58.211.in-addr.arpa' > (in '254.58.211.in-addr.arpa'?): [210.94.0.7].53 'ns.hananet.net' > Nov 25 11:33:36 ns named[10478]: ns_forw: query(55.254.58.211.in-addr.arpa) > All possible A RR's lame > Nov 25 11:33:45 ns sshd[10689]: Disconnecting: crc32 compensation attack: > network attack detected [...] -- Kent Engstr?m, Link?ping University Incident Response Team kent at unit.liu.se abuse at liu.se +46 13 28 1744 UNIT, Link?ping University; SE-581 83 LINK?PING; SWEDEN