From erik at xyzzy.net Sat Sep 1 23:14:09 2001 From: erik at xyzzy.net (Erik Benner) Date: Sat, 1 Sep 2001 09:14:09 -0400 Subject: bug in scp (OpenSSH) In-Reply-To: Message-ID: <006b01c132e7$fceb5580$cc64a8c0@home.xyzzy.net> >This has come up many times before, and the consensus of the developers >seems to be that they're not interested in fixing or adding features to >scp because they want to make scp just the secure version of rcp, and it's >not up to them to change rcp. With this in mind is it even worth trying to introduce even a small feature into scp? One thing I have missing from other versions is the throughput meter in the status bar. I have added it back in and was looking at trying to get the feature added into scp, but from what you have said this could become a very difficult and politically charged task? From koenig at tat.physik.uni-tuebingen.de Wed Sep 5 02:40:14 2001 From: koenig at tat.physik.uni-tuebingen.de (Harald Koenig) Date: Tue, 4 Sep 2001 18:40:14 +0200 Subject: bug in scp (OpenSSH) In-Reply-To: <20010831131846.A1399@folly>; from markus@openbsd.org on Fri, Aug 31, 2001 at 01:18:46PM +0200 References: <20010830131519.A13380@faui02.informatik.uni-erlangen.de> <20010831131846.A1399@folly> Message-ID: <20010904184014.A24477@turtle.tat.physik.uni-tuebingen.de> On Aug 31, Markus Friedl wrote: > On Fri, Aug 31, 2001 at 12:20:23PM +0200, Roman Drahtmueller wrote: > > Are you serious that you want to keep a bug because "this is how the rcp > > protocol works"? It is clearly flawed. > > should we really change the semantics of a 17 year old protocol, > if you can use sftp, rsync or tar instead? if behaviour is broken and it's not explicitly designed to be broken that way: yes. (and it _is_ broken). I tried "rcp" too and indeed, it does copy binary trash too. fortuneately, at least with my ~8 kbytes source file, no passwd entries show up in rcp buffers but only parts of /etc/services. but who knows what might show up for longer source files ?! > however, you can try to modify sink() to truncate the ofd if > response() returns an error. so the data will be sent but > discarded. i'm not sure whether i like the idea. it might > break other things. your 2nd patch below doesn't make any difference. destination file still gets filled with null bytes. > > > -m > > Index: scp.c > =================================================================== > RCS file: /home/markus/cvs/ssh/scp.c,v > retrieving revision 1.81 > diff -u -r1.81 scp.c > --- scp.c 2001/08/29 20:44:03 1.81 > +++ scp.c 2001/08/31 11:17:53 > @@ -853,11 +853,15 @@ > run_err("%s: set mode: %s", > np, strerror(errno)); > } > + if (response() < 0) { > + ftruncate(ofd, 0); > + wrerr = YES; > + wrerrno = EIO; > + } > if (close(ofd) == -1) { > wrerr = YES; > wrerrno = errno; > } > - (void) response(); > if (setimes && wrerr == NO) { > setimes = 0; > if (utimes(np, tv) < 0) { Harald -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig at tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ From marc at mbsi.ca Wed Sep 5 04:14:26 2001 From: marc at mbsi.ca (Marc Boucher) Date: Tue, 4 Sep 2001 14:14:26 -0400 Subject: openssh and multiple ports Message-ID: <20010904141426.A11255@opium.mbsi.ca> Hi, I must access several hosts through reverse masquerading gateways which are visible on the Internet under a single IP address, with different ports (2, 22, 222, 2222 etc..) forwarding to port 22 of various internal ssh servers, each with its own hostkey. This setup totally confuses the openssh client because it does not store the port numbers in the known_hosts* file, and thus falsely detects host key mismatches!! Is there any hope of resolving this situation soon? Also, how about supporting the "ssh user at host#port" number syntax, instead of requiring the -p option? Both issues are handled properly by the ssh.c*m proprietary implementation. Best regards Marc PS: Please Cc: any replies directly to me as I am not on the list. From johnh at aproposretail.com Wed Sep 5 04:24:29 2001 From: johnh at aproposretail.com (John Hardin) Date: Tue, 04 Sep 2001 11:24:29 -0700 Subject: openssh and multiple ports References: <20010904141426.A11255@opium.mbsi.ca> Message-ID: <3B951C5D.C6FDDA7@aproposretail.com> Marc Boucher wrote: > > Also, how about supporting the "ssh user at host#port" number syntax, instead > of requiring the -p option? I'd suggest user at host:port to be more in line with established conventions, unless the colon is already being used for something else... -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 From psor at afip.gov.ar Wed Sep 5 04:57:01 2001 From: psor at afip.gov.ar (Pablo Sor) Date: Tue, 04 Sep 2001 14:57:01 -0400 Subject: AIX Warning for expired password Message-ID: <3B9523FD.BF32BA53@afip.gov.ar> Hi, I have made a patch for AIX to report the number of days till a password expire and to prompt for a new one. This patch was made for openssh-SNAP-20010904.tar.gz (2.9p2) of the CVS repository. If you have any suggestion or question to submit, please cc to me, I'm not in the list. Bye -- Pablo Sor Departamento de Seguridad Informatica - AFIP psor at afip.gov.ar, psor at ccc.uba.ar -------------- next part -------------- --- session.c Tue Sep 4 13:16:07 2001 +++ session.c Tue Sep 4 13:16:10 2001 @@ -57,6 +57,10 @@ #include "canohost.h" #include "session.h" +#ifdef WITH_AIXAUTHENTICATE +#include "misc.h" +#endif /* WITH_AIXAUTHENTICATE */ + #ifdef WITH_IRIX_PROJECT #include #endif /* WITH_IRIX_PROJECT */ @@ -675,13 +679,14 @@ void do_login(Session *s, const char *command) { - char *time_string; + char *time_string,*msg; char hostname[MAXHOSTNAMELEN]; socklen_t fromlen; struct sockaddr_storage from; time_t last_login_time; struct passwd * pw = s->pw; pid_t pid = getpid(); + int retval; /* * Get IP address of client. If the connection is not a socket, let @@ -730,6 +735,44 @@ #ifdef WITH_AIXAUTHENTICATE if (aixloginmsg && *aixloginmsg) printf("%s\n", aixloginmsg); +#endif /* WITH_AIXAUTHENTICATE */ + +#ifdef WITH_AIXAUTHENTICATE + + retval = passwdexpired(pw->pw_name,&msg); + + if (msg && *msg) + printf("%s\n",msg); + + if (retval == 1) { + + pid_t pid; + int status; + mysig_t old_signal; + + old_signal = mysignal(SIGCHLD, SIG_DFL); + + if ((pid = fork()) == -1) + fatal("Couldn't fork: %s", strerror(errno)); + + if (pid == 0) { + setuid(pw->pw_uid); + execl("/usr/bin/passwd","passwd",pw->pw_name, + (char *)NULL); + } + + if (waitpid(pid, &status, 0) == -1) + fatal("Couldn't wait for child: %s", strerror(errno)); + + /* Passwd exited abnormally */ + + if (WEXITSTATUS(status)) + exit(1); + + mysignal(SIGCHLD, old_signal); + + } + #endif /* WITH_AIXAUTHENTICATE */ if (options.print_lastlog && last_login_time != 0) { From mouring at etoh.eviladmin.org Wed Sep 5 04:49:57 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 4 Sep 2001 13:49:57 -0500 (CDT) Subject: openssh and multiple ports In-Reply-To: <3B951C5D.C6FDDA7@aproposretail.com> Message-ID: What is wrong with using: HostKeyAlias Specifies an alias that should be used instead of the real host name when looking up or saving the host key in the host key database files. This option is useful for tunneling ssh connec- tions or if you have multiple servers running on a single host. from ssh.1 ? - Ben On Tue, 4 Sep 2001, John Hardin wrote: > Marc Boucher wrote: > > > > Also, how about supporting the "ssh user at host#port" number syntax, instead > > of requiring the -p option? > > I'd suggest user at host:port to be more in line with established > conventions, unless the colon is already being used for something > else... > > -- > John Hardin > Internal Systems Administrator voice: (425) 672-1304 > Apropos Retail Management Systems, Inc. fax: (425) 672-0192 > From GILBERT.R.LOOMIS at saic.com Wed Sep 5 05:09:43 2001 From: GILBERT.R.LOOMIS at saic.com (Loomis, Rip) Date: Tue, 4 Sep 2001 15:09:43 -0400 Subject: openssh and multiple ports Message-ID: <3C1E3607B37295439F7C409EFBA08E680E2680@col-581-exs01.cist.saic.com> John-- I agree that user at host:port would be more in line with other non-ssh uses, but the colon is already magic to scp with a different meaning. If one wants to scp a file to a remote system where ssh is running on an unusual port, then there could be confusion: scp filename username at host:port:/home/username To my knowledge, that's why the user at host#port syntax was used in that "other" ssh implementation. Having said that, I don't see that the -p port option is so onerous as to make it worth implementing the #port method. -- Rip Loomis Senior Systems Security Engineer SAIC Center for Information Security Technology > -----Original Message----- > From: John Hardin [mailto:johnh at aproposretail.com] > > Also, how about supporting the "ssh user at host#port" number > syntax, instead > > of requiring the -p option? > > I'd suggest user at host:port to be more in line with established > conventions, unless the colon is already being used for something > else... > From vinschen at redhat.com Wed Sep 5 05:25:59 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 4 Sep 2001 21:25:59 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue Message-ID: <20010904212559.F15127@cygbert.vinschen.de> Hi, I have a problem with a Linux box which I updated from 2.5.2p2 to 2.9p2 recently. It's running a tunnel started via inittab using a script which starts ssh -2 -N -o 'ConnectionAttempts 3600' -L $host This has run reliable with 2.5.2 over the last months. Now, after I have upgraded to 2.9p2, the tunnel is closed right after each attempt of an application to use the tunnel which is a cron job running each 5 minutes. So, now the tunnel is closed and restarted each 5 minutes :-( The message in the syslog is "Connection closed by foreign host". If that's of interest, 2.5.2p2 was compiled with OpenSSL 0.9.5, 2.9p2 is compiled using OpenSSL 0.9.6b. Does anybody know what's going on or what I did wrong? Or do I need to give more details? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From johnh at aproposretail.com Wed Sep 5 05:39:53 2001 From: johnh at aproposretail.com (John Hardin) Date: Tue, 04 Sep 2001 12:39:53 -0700 Subject: openssh and multiple ports References: <3C1E3607B37295439F7C409EFBA08E680E2680@col-581-exs01.cist.saic.com> Message-ID: <3B952E09.7FD4D3A7@aproposretail.com> "Loomis, Rip" wrote: > > John-- > I agree that user at host:port would be more in line with > other non-ssh uses, but the colon is already magic to scp with > a different meaning. I think the context of the suggestion was within the known_hosts file, not on the command line. -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 From adam-openssh at flounder.net Wed Sep 5 05:43:19 2001 From: adam-openssh at flounder.net (Adam McKenna) Date: Tue, 4 Sep 2001 12:43:19 -0700 Subject: Suggestion: Man page clarification Message-ID: <20010904124319.F9790@flounder.net> scp, when copying directories with the "-r" flag, uses the same "trailing slash" syntax as rsync, i.e., if a trailing slash is given on the source directory, it will copy the contents of that directory to the destination, instead of the directory itself. rsync has a special section in the man page that points out that this is actually expected behavior, it would be nice if scp also had this information in the man page. I've attached a patch for scp.1 which I believe addresses the issue. Thanks, --Adam -- Adam McKenna | http://flounder.net/publickey.html | GPG: 17A4 11F7 5E7E C2E7 08AA | What's up with my email address? 38B0 05D0 8BF7 2C6D 110A | http://software.libertine.org/tmda -------------- next part -------------- --- scp.1.orig Tue Sep 4 12:32:55 2001 +++ scp.1 Tue Sep 4 12:42:19 2001 @@ -71,7 +71,9 @@ Preserves modification times, access times, and modes from the original file. .It Fl r -Recursively copy entire directories. +Recursively copy entire directories. A trailing slash (/) on a source file +name means "copy the contents of this directory". Without a trailing slash +it means "copy the directory and all of its contents". .It Fl v Verbose mode. Causes From carson at taltos.org Wed Sep 5 06:12:07 2001 From: carson at taltos.org (Carson Gaspar) Date: Tue, 04 Sep 2001 13:12:07 -0700 Subject: openssh and multiple ports In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2680@col-581-exs01.cist.saic.com> References: <3C1E3607B37295439F7C409EFBA08E680E2680@col-581-exs01.cist.saic. com> Message-ID: <54763718.999609127@athyra> --On Tuesday, September 04, 2001 3:09 PM -0400 "Loomis, Rip" wrote: > Having said that, I don't see that the -p port option is > so onerous as to make it worth implementing the #port > method. It wouldn't be so bad is ssh and scp used the _same_ option for an alternate port, but they don't. -- Carson Gaspar - carson at taltos.org Queen Trapped in a Butch Body From marc at mbsi.ca Wed Sep 5 07:21:07 2001 From: marc at mbsi.ca (Marc Boucher) Date: Tue, 4 Sep 2001 17:21:07 -0400 Subject: openssh and multiple ports In-Reply-To: References: <3B951C5D.C6FDDA7@aproposretail.com> Message-ID: <20010904172107.A12003@opium.mbsi.ca> On Tue, Sep 04, 2001 at 01:49:57PM -0500, mouring at etoh.eviladmin.org wrote: > > What is wrong with using: > > HostKeyAlias > > from ssh.1 ? > it's an unnecessary kludge. The user shouldn't have to deal with this. Openssh should do the right thing and differentiate host keys with port numbers along names and addresses. > > - Ben > > On Tue, 4 Sep 2001, John Hardin wrote: > > > Marc Boucher wrote: > > > > > > Also, how about supporting the "ssh user at host#port" number syntax, instead > > > of requiring the -p option? > > > > I'd suggest user at host:port to be more in line with established > > conventions, unless the colon is already being used for something > > else... I think '#' is better, since it maintains compatibility with the other implementation, and besides, the ':' character is already used in IPv6 addresses. Marc From jason at shalott.net Wed Sep 5 09:37:59 2001 From: jason at shalott.net (Jason Stone) Date: Tue, 4 Sep 2001 16:37:59 -0700 (PDT) Subject: bug in scp (OpenSSH) In-Reply-To: <006b01c132e7$fceb5580$cc64a8c0@home.xyzzy.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >This has come up many times before, and the consensus of the developers > >seems to be that they're not interested in fixing or adding features to > >scp because they want to make scp just the secure version of rcp, and it's > >not up to them to change rcp. > > One thing I have missing from other versions is the throughput meter > in the status bar. Incidentally, at my last company, the progress bar was a source of breakage for legacy scripts that didn't expect rcp to be producing any output - so what's up with that? How does that fit into your model of being rsh/rcp compatible and not introducing extraneous features? Do you really think that breaking rcp compatibility with a status bar is a better idea than "breaking" it with, for example, a flag to allow atomic transfers? Don't you think that if the progress bar exists at all, it should at least be enabled via commandline option or environment variable, and not be the default? -Jason ----------------------------------------------------------------------- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE7lWXcswXMWWtptckRAgFMAJ4yMVLL21lLMdcEA/voCWYXF7DC0wCfV4Ta Vt1GGZ4jCc4gx2j7Tl0KJMM= =/RwG -----END PGP SIGNATURE----- From stevesk at pobox.com Wed Sep 5 09:42:34 2001 From: stevesk at pobox.com (Kevin Steves) Date: Tue, 4 Sep 2001 16:42:34 -0700 (PDT) Subject: openssh and multiple ports In-Reply-To: <20010904172107.A12003@opium.mbsi.ca> Message-ID: On Tue, 4 Sep 2001, Marc Boucher wrote: :it's an unnecessary kludge. The user shouldn't have to deal with this. :Openssh should do the right thing and differentiate host keys with port :numbers along names and addresses. i think most will agree, however no one has written the code to support this. it will happen at some point. :> > > Also, how about supporting the "ssh user at host#port" number syntax, instead :> > > of requiring the -p option? :> > :> > I'd suggest user at host:port to be more in line with established :> > conventions, unless the colon is already being used for something :> > else... : :I think '#' is better, since it maintains compatibility with the other :implementation, and besides, the ':' character is already used in IPv6 :addresses. i don't see a good reason to add another way to specify port on the ssh command line. From kevin at tgivan.com Wed Sep 5 09:46:12 2001 From: kevin at tgivan.com (Kevin Sindhu) Date: Tue, 04 Sep 2001 16:46:12 -0700 Subject: bug in scp (OpenSSH) References: Message-ID: <3B9567C4.B8A08C79@tgivan.com> Jason Stone wrote: > > Don't you think that if the progress bar exists at all, it should at least > be enabled via commandline option or environment variable, and not be the > default? How about a status bar in sftp? IIRC, the latest ssh 3.1.0 has it. Kinnda cool.. -Kevin From marc at mbsi.ca Wed Sep 5 10:33:31 2001 From: marc at mbsi.ca (Marc Boucher) Date: Tue, 4 Sep 2001 20:33:31 -0400 Subject: openssh and multiple ports In-Reply-To: References: <20010904172107.A12003@opium.mbsi.ca> Message-ID: <20010904203331.A12502@opium.mbsi.ca> On Tue, Sep 04, 2001 at 04:42:34PM -0700, Kevin Steves wrote: > On Tue, 4 Sep 2001, Marc Boucher wrote: > :it's an unnecessary kludge. The user shouldn't have to deal with this. > :Openssh should do the right thing and differentiate host keys with port > :numbers along names and addresses. > > i think most will agree, however no one has written the code to support > this. it will happen at some point. ok > :> > > Also, how about supporting the "ssh user at host#port" number syntax, instead > :> > > of requiring the -p option? > :> > > :> > I'd suggest user at host:port to be more in line with established > :> > conventions, unless the colon is already being used for something > :> > else... > : > :I think '#' is better, since it maintains compatibility with the other > :implementation, and besides, the ':' character is already used in IPv6 > :addresses. > > i don't see a good reason to add another way to specify port on the > ssh command line. I think it's a matter of taste (I personally find it much more practical and logical to do "scp marc at mbsi.ca#2:/tmp/file dest" than "scp -P 2 marc at mbsi.ca:/tmp/file", which requires that you remember an option letter that isn't even consistent between commands; as ssh uses lowercase '-p') and compatibility with ssh.com's implementation, which has supported this feature for a long time. Marc From ogi at fmi.uni-sofia.bg Wed Sep 5 23:53:05 2001 From: ogi at fmi.uni-sofia.bg (Ognyan Kulev) Date: Wed, 05 Sep 2001 16:53:05 +0300 Subject: pam_limits and OpenSSH Message-ID: <3B962E41.5090405@fmi.uni-sofia.bg> Hi, I have an account server with many users. It uses pam_limits module to limit memory usage etc. The problem is that sometimes SSH rejects connection after the password is entered. In syslog it prints something like "fork: Resource temporary unavailable". After killing some root processes it works perfectly. Perhaps the daemon first sets process limits and then switches to the user and/or fork(). But fork() cannot succeed because there is a process number limit to 40 that is applied to root. This is my hypothesis. I didn't look at sources. What you think about all this? Do you need more information? I use Debian GNU/Linux potato and OpenSSH 1.2.3-9.3. Regards -- Ognyan Kulev , "\"Programmer\"" From mouring at etoh.eviladmin.org Thu Sep 6 00:17:25 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 5 Sep 2001 09:17:25 -0500 (CDT) Subject: pam_limits and OpenSSH In-Reply-To: <3B962E41.5090405@fmi.uni-sofia.bg> Message-ID: I suggest you try OpenSSH 2.9p2 release - Ben On Wed, 5 Sep 2001, Ognyan Kulev wrote: > Hi, > > I have an account server with many users. It uses pam_limits module to > limit memory usage etc. The problem is that sometimes SSH rejects > connection after the password is entered. In syslog it prints something > like "fork: Resource temporary unavailable". After killing some root > processes it works perfectly. > > Perhaps the daemon first sets process limits and then switches to the > user and/or fork(). But fork() cannot succeed because there is a > process number limit to 40 that is applied to root. This is my > hypothesis. I didn't look at sources. What you think about all this? > Do you need more information? I use Debian GNU/Linux potato and OpenSSH > 1.2.3-9.3. > > Regards > -- > Ognyan Kulev , "\"Programmer\"" > > From adam-openssh at flounder.net Thu Sep 6 03:08:44 2001 From: adam-openssh at flounder.net (Adam McKenna) Date: Wed, 5 Sep 2001 10:08:44 -0700 Subject: pam_limits and OpenSSH In-Reply-To: References: <3B962E41.5090405@fmi.uni-sofia.bg> Message-ID: <20010905100844.A17@flounder.net> On Wed, Sep 05, 2001 at 09:17:25AM -0500, mouring at etoh.eviladmin.org wrote: > > I suggest you try OpenSSH 2.9p2 release This is still a problem with 2.9p2. If the user's nproc limit is set (in /etc/security/limits.conf) to less than around 35, they will not be able to login with SSH. --Adam From devon at admin2.gisnetworks.com Thu Sep 6 05:27:32 2001 From: devon at admin2.gisnetworks.com (Devon Bleak) Date: Wed, 5 Sep 2001 12:27:32 -0700 Subject: version.h Message-ID: <014501c13640$d8bc7200$1900a8c0@devn> i just updated my cvs tree, and (after compiling and checking the version reported) i noticed that version.h still says 2.9p1. is the anoncvs stuff no longer current, or did version.h just forget to be changed with the last release? the 2.9p2 tarball version.h says 2.9p2. devon From Nicolas.Williams at ubsw.com Thu Sep 6 05:18:20 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 5 Sep 2001 15:18:20 -0400 Subject: reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8) In-Reply-To: ; from darrenm@eng.sun.com on Tue, Aug 28, 2001 at 11:45:40AM -0700 References: <200108280440.OAA02504@debian.lib.monash.edu.au> Message-ID: <20010905151819.O5739@sm2p1386swk.wdr.com> [Cc'ing pam-list at redhat.com] On Tue, Aug 28, 2001 at 11:45:40AM -0700, Darren J Moffat wrote: > On Tue, 28 Aug 2001, Stuart Lamble wrote: > > > To clarify why we're using PAM: the system in question is set up to > > communicate with a Kerberos server, with all authentication being done > > using Kerberos. It's somewhat easier to do all of that with PAM than to > > try to replace login, etc. > > Are you using the pam_krb5 module shipped with Solaris ? > Does pam_krb5 work properly for you when used with dtlogin or /bin/login (ie > login at the console). Looking at our copy of Solaris 2.6 an 8 source code I can see that Sun's pam_krb5 treats PAM_REINITIALIZE_CREDS and PAM_REFRESH_CREDS as synonyms. Also, not one Sun app uses PAM_REINITIALIZE_CREDS (ok, I haven't checked dtlogin's source code -- I could). > > There's also been the question of whether do_pam_setcred() should be called > > before or after the uid has been set to the user's. Changing the code to > > call do_pam_setcred() after the call to permanently_set_uid(), however, > > seems to make no difference to the crashing. > > It has to before you give up root creds since there are assumptions in > some PAM modules that it can do things only root can do (making private > nfs system calls to pass creds down to the kernel for use by NFS). Neither the Sun PAM documentation nor the Linux-PAM documentation describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail. Could we please have a clarification on the semantics of PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS? My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means "make it so we can use your module's credentials as root" whereas PAM_REINITIALIZE_CREDS means "make it so we can use your module's credentials as pam_get_item(PAM_USER)." And, given what OpenSSH does, it seems that pam_setcred(PAM_REINITIALIZE_CREDS) should be called with (euid==0 || uid==0) and gid/egid/groups setup to be the PAM_USER's. But none of this is documented! As for PAM_KRB5, assuming my interpretation of PAM_REINITIALIZE_CREDS is correct, it should create a root-owned ccache when it's pam_sm_setcred() is called to PAM_CRED_ESTABLISH and it should create PAM_USER-owned ccache when it's pam_sm_setcred() is called to PAM_REINITIALIZE_CREDS. [...] > -- > Darren J Moffat The semantics of pam_setcred()'s flags must be documented, and possibly even agreed upon, before this problem can be closed. 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 adam-openssh at flounder.net Thu Sep 6 05:33:14 2001 From: adam-openssh at flounder.net (Adam McKenna) Date: Wed, 5 Sep 2001 12:33:14 -0700 Subject: pam_limits and OpenSSH In-Reply-To: <20010905100844.A17@flounder.net> References: <3B962E41.5090405@fmi.uni-sofia.bg> <20010905100844.A17@flounder.net> Message-ID: <20010905123314.F17@flounder.net> On Wed, Sep 05, 2001 at 10:08:44AM -0700, Adam McKenna wrote: > On Wed, Sep 05, 2001 at 09:17:25AM -0500, mouring at etoh.eviladmin.org wrote: > > > > I suggest you try OpenSSH 2.9p2 release > > This is still a problem with 2.9p2. If the user's nproc limit is set (in > /etc/security/limits.conf) to less than around 35, they will not be able to > login with SSH. Just checked on Debian unstable, if nproc (soft limit) is less than 53 this doesn't work with OpenSSH 2.9p2-3: adam at maguro:~$ grep adam2 /etc/security/limits.conf adam2 soft nproc 52 adam at maguro:~$ ssh adam2 at localhost adam2 at localhost's password: Received disconnect from 127.0.0.1: 2: fork failed: Resource temporarily unavailable adam at maguro:~$ grep adam2 /etc/security/limits.conf adam2 soft nproc 53 adam at maguro:~$ ssh adam2 at localhost adam2 at localhost's password: [motd] adam2 at maguro:~$ adam at maguro:~$ dpkg -l ssh ii ssh 2.9p2-5 Secure rlogin/rsh/rcp replacement (OpenSSH) adam at maguro:~$ ssh -V OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f The strace of the sshd process (strace -f -p ) is available at http://flounder.net/sshd.log Thanks, --Adam From mouring at etoh.eviladmin.org Thu Sep 6 05:59:59 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 5 Sep 2001 14:59:59 -0500 (CDT) Subject: version.h In-Reply-To: <014501c13640$d8bc7200$1900a8c0@devn> Message-ID: It's the correct version.h... =) The 2.9 branch is at p2... But the head branch (for whatever reason) was never updated.. I would almost perfer the -head branch of the portable tree have a unique version.h to report it is such a beast in the future. - Ben On Wed, 5 Sep 2001, Devon Bleak wrote: > i just updated my cvs tree, and (after compiling and checking the > version reported) i noticed that version.h still says 2.9p1. > > is the anoncvs stuff no longer current, or did version.h just forget to > be changed with the last release? > > the 2.9p2 tarball version.h says 2.9p2. > > devon > > From Darren.Moffat at eng.sun.com Thu Sep 6 06:18:57 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 5 Sep 2001 13:18:57 -0700 (PDT) Subject: reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8) Message-ID: <200109052018.f85KIv9d427589@jurassic.eng.sun.com> >Neither the Sun PAM documentation nor the Linux-PAM documentation >describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail. I would agree it is vague, but then that is also a problem with the XSSO document (http://www.opengroup.org/onlinepubs/008329799/) >Could we please have a clarification on the semantics of >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS? My interpretation is: You call PAM_ESTABLISH_CRED to create them You call PAM_REINITIALIZE_CRED to update creds that can expire over time, for example a kerberos ticket. >My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means >"make it so we can use your module's credentials as root" whereas >PAM_REINITIALIZE_CREDS means "make it so we can use your module's >credentials as pam_get_item(PAM_USER)." That is wrong and is one thing the XSSO doc is clear on: "The pam_setcred() function is used to establish, modify, or delete the credentials of the current user associated with the authentication handle, pamh. " The Solaris pam_setcred(3pam) man page is less clear - I'll file a man page bug for Solaris to get it clarified better. >And, given what OpenSSH does, it seems that >pam_setcred(PAM_REINITIALIZE_CREDS) should be called with >(euid==0 || uid==0) and gid/egid/groups setup to be the PAM_USER's. That depends and unfortunately the whole issue of what the uids should be in effect for the application calling any pam_* function is not specified. For Kerberos it will work just fine if called as the PAM_USER but for Secure RPC creds that get established in pam_unix on Solaris there are some times that the euid needs to be root. Also for doing getspnam lookups to statisfy pam_authenticate when using /etc/shadow. >But none of this is documented! Agreed the docs do not specify the level of privilege required by the application for calling pam_* functions. In someways I think it should be upto the modules to document what they need but I also think this could break the abstraction that PAM is supposed to provide. >As for PAM_KRB5, assuming my interpretation of PAM_REINITIALIZE_CREDS is >correct, it should create a root-owned ccache when it's pam_sm_setcred() >is called to PAM_CRED_ESTABLISH and it should create PAM_USER-owned >ccache when it's pam_sm_setcred() is called to PAM_REINITIALIZE_CREDS. That is not how pam_krb5 on Solaris is designed to work. If you call pam_setcred() with pam_krb5 on the stack it assumes that you have already called pam_authenticate to get the kerberos password and do the kerberos authentication. That is fine for the case that started this disucssion since pam_authenticate had been called since password authentication was used. It will always create a cred cache file owned by PAM_USER, the only way you could get the effect you describe above is if you called pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item to be - but this isn't what OpenSSH does (and it is wrong anyway). I'm not sure the call to pam_setcred with PAM_REINITIALIZE_CREDS is actually required in session.c. Why was it put there ? Is there a particular pam module that causes a problem ? -- Darren J Moffat From Nicolas.Williams at ubsw.com Thu Sep 6 06:43:58 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 5 Sep 2001 16:43:58 -0400 Subject: reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8) In-Reply-To: <200109052018.f85KIv9d427589@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Sep 05, 2001 at 01:18:57PM -0700 References: <200109052018.f85KIv9d427589@jurassic.eng.sun.com> Message-ID: <20010905164356.J3937@sm2p1386swk.wdr.com> Thanks. Inline. On Wed, Sep 05, 2001 at 01:18:57PM -0700, Darren Moffat wrote: > >Neither the Sun PAM documentation nor the Linux-PAM documentation > >describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail. > > I would agree it is vague, but then that is also a problem with the XSSO > document (http://www.opengroup.org/onlinepubs/008329799/) > > >Could we please have a clarification on the semantics of > >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS? > > My interpretation is: > > You call PAM_ESTABLISH_CRED to create them > You call PAM_REINITIALIZE_CRED to update creds that can expire over time, > for example a kerberos ticket. PAM_RENEW_CREDS is there for credential renewal (i.e., ticket renewal, in the Kerberos case). That's clear from its name. PAM_REINITIALIZE_CREDS is, well, completely undocumented (I'll recheck the XSSO docs). The OpenSSH interpretation is clear. And, IMO, as I think about it, the OpenSSH interpretation makes plenty of sense. Consider an app that will not fork() a child that runs as the PAM_USER (e.g., a web server) but which nonetheless needs the user's Kerberos creds -- why bother creating a user-owned ccache then? With the OpenSSH interpretation of PAM_REINITIALIZE_CREDS it is possible to have such apps. > >My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means > >"make it so we can use your module's credentials as root" whereas > >PAM_REINITIALIZE_CREDS means "make it so we can use your module's > >credentials as pam_get_item(PAM_USER)." > > That is wrong and is one thing the XSSO doc is clear on: > > "The pam_setcred() function is used to establish, modify, or delete the > credentials of the current user associated with the authentication handle, > pamh. " Why does that description not jive with my interpretation of the OpenSSH interpretation of the pam_setcred() flags' semantics? I mean, I don't see why. > The Solaris pam_setcred(3pam) man page is less clear - I'll file a man > page bug for Solaris to get it clarified better. > > >And, given what OpenSSH does, it seems that > >pam_setcred(PAM_REINITIALIZE_CREDS) should be called with > >(euid==0 || uid==0) and gid/egid/groups setup to be the PAM_USER's. > > That depends and unfortunately the whole issue of what the uids should > be in effect for the application calling any pam_* function is not > specified. > > For Kerberos it will work just fine if called as the PAM_USER but for > Secure RPC creds that get established in pam_unix on Solaris there are > some times that the euid needs to be root. Also for doing getspnam > lookups to statisfy pam_authenticate when using /etc/shadow. I agree that pam_setcred() should be called as root (if the caller app has such privs) for all pam_setcred() operations, save, except, possibly, PAM_RENEW_CREDS (well, from pam_krb5's point of view anyways). > >But none of this is documented! > > Agreed the docs do not specify the level of privilege required by > the application for calling pam_* functions. > > In someways I think it should be upto the modules to document what they > need but I also think this could break the abstraction that PAM is supposed > to provide. I think different modules will have different needs here, but one might not want to use pam_unix with a web server, say, so that one might not need to have the web server run as root at all -- whereas pam_unix's setcred() function must be called with root privs. > >As for PAM_KRB5, assuming my interpretation of PAM_REINITIALIZE_CREDS is > >correct, it should create a root-owned ccache when it's pam_sm_setcred() > >is called to PAM_CRED_ESTABLISH and it should create PAM_USER-owned > >ccache when it's pam_sm_setcred() is called to PAM_REINITIALIZE_CREDS. > > That is not how pam_krb5 on Solaris is designed to work. > > If you call pam_setcred() with pam_krb5 on the stack it assumes that > you have already called pam_authenticate to get the kerberos password > and do the kerberos authentication. That is fine for the case that > started this disucssion since pam_authenticate had been called since > password authentication was used. I've written parts of a PAM_KRB5 (based on Frank Cusack's original) which behaves slightly differently: its auth method saves the user's Kerberos creds in a memory ccache and stuffs that into the pam handle as pam data, and its setcred method actually creates the file ccache (and destroys the memory ccache). > It will always create a cred cache file owned by PAM_USER, the only > way you could get the effect you describe above is if you called > pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item > to be - but this isn't what OpenSSH does (and it is wrong anyway). This is silly -- why create a user-owned ccache *before* the account management part of PAM has been called and suceeded?? In fact, it seems clear to me that no user-owned ccache should be created outside pam_krb5:pam_sm_setcred(). > I'm not sure the call to pam_setcred with PAM_REINITIALIZE_CREDS is > actually required in session.c. Why was it put there ? Is there a > particular pam module that causes a problem ? See above about apps that don't fork() a process that runs as the PAM_USER. > -- > Darren J Moffat 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 Darren.Moffat at eng.sun.com Thu Sep 6 07:03:23 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 5 Sep 2001 14:03:23 -0700 (PDT) Subject: reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8) Message-ID: <200109052103.f85L3N9d435574@jurassic.eng.sun.com> >> >Could we please have a clarification on the semantics of >> >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS? >> >> My interpretation is: >> >> You call PAM_ESTABLISH_CRED to create them >> You call PAM_REINITIALIZE_CRED to update creds that can expire over time, >> for example a kerberos ticket. Oops. I meant PAM_REFRESH_CRED >PAM_RENEW_CREDS is there for credential renewal (i.e., ticket renewal, >in the Kerberos case). That's clear from its name. It is called PAM_REFRESH_CRED. >PAM_REINITIALIZE_CREDS is, well, completely undocumented (I'll recheck >the XSSO docs). The OpenSSH interpretation is clear. Agreed and it is very ambiquous. I think it is quite easy to make the assumption that ESTABLISH and REINITIALIZE care synonymous but both are different from REFRESH. >And, IMO, as I think about it, the OpenSSH interpretation makes plenty >of sense. Consider an app that will not fork() a child that runs as the >PAM_USER (e.g., a web server) but which nonetheless needs the user's >Kerberos creds -- why bother creating a user-owned ccache then? I can see that from a PAM view point but it won't really work from a Kerberos view point (it isn't how kerberos was designed to work). >> "The pam_setcred() function is used to establish, modify, or delete the >> credentials of the current user associated with the authentication handle, >> pamh. " > >Why does that description not jive with my interpretation of the OpenSSH >interpretation of the pam_setcred() flags' semantics? I mean, I don't >see why. I guess it does at the PAM level but at the level of Kerberos the creds are always placed in a cred file owned by that user since their is no concept of acting onbehalf of another. >I've written parts of a PAM_KRB5 (based on Frank Cusack's original) >which behaves slightly differently: its auth method saves the user's >Kerberos creds in a memory ccache and stuffs that into the pam handle as >pam data, and its setcred method actually creates the file ccache (and >destroys the memory ccache). The Solaris one does that as well, the ccache file is created as /tmp/krb5cc_ with permissions 600 and owner >> It will always create a cred cache file owned by PAM_USER, the only >> way you could get the effect you describe above is if you called >> pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item >> to be - but this isn't what OpenSSH does (and it is wrong anyway). > >This is silly -- why create a user-owned ccache *before* the account >management part of PAM has been called and suceeded?? Because you are supposed to call pam functions in this order: pam_start(pamh,...); pam_authenticate(pamh, ...); pam_acct_mgmt(pamh, pam_setcred(pamh, PAM_ESTABLISH_CRED) ... pam_setcred(pamh, PAM_DELETE_CRED); pam_end(pamh); This is quite clear from the Solaris man page for pam_setcred(3pam) " The pam_setcred() function is used to establish, modify, or delete user credentials. It is typically called after the user has been authenticated and after a session has been opened. See pam_authenticate(3PAM), pam_acct_mgmt(3PAM), and pam_open_session(3PAM). " >In fact, it seems clear to me that no user-owned ccache should be >created outside pam_krb5:pam_sm_setcred(). In Solaris it isn't. >> I'm not sure the call to pam_setcred with PAM_REINITIALIZE_CREDS is >> actually required in session.c. Why was it put there ? Is there a >> particular pam module that causes a problem ? > >See above about apps that don't fork() a process that runs as the >PAM_USER. I don't believe that is well defined for Kerberos and it isn't how pam_krb5 in Solaris is designed to work. -- Darren J Moffat From dwd at bell-labs.com Thu Sep 6 07:04:52 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Wed, 5 Sep 2001 16:04:52 -0500 Subject: bug in scp (OpenSSH) In-Reply-To: ; from jason@shalott.net on Tue, Sep 04, 2001 at 04:37:59PM -0700 References: <006b01c132e7$fceb5580$cc64a8c0@home.xyzzy.net> Message-ID: <20010905160452.A15208@lucent.com> On Tue, Sep 04, 2001 at 04:37:59PM -0700, Jason Stone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > >This has come up many times before, and the consensus of the developers > > >seems to be that they're not interested in fixing or adding features to > > >scp because they want to make scp just the secure version of rcp, and it's > > >not up to them to change rcp. > > > > One thing I have missing from other versions is the throughput meter > > in the status bar. > > Incidentally, at my last company, the progress bar was a source of > breakage for legacy scripts that didn't expect rcp to be producing any > output - so what's up with that? How does that fit into your model of > being rsh/rcp compatible and not introducing extraneous features? Do you > really think that breaking rcp compatibility with a status bar is a better > idea than "breaking" it with, for example, a flag to allow atomic > transfers? > > Don't you think that if the progress bar exists at all, it should at least > be enabled via commandline option or environment variable, and not be the > default? I agree. At least with ssh 1.2.27 there was a configure option to disable it, --disable-scp-stats. Showing those statistics by default are not in the Unix spirit. At least it won't show them if stderr is not a tty. - Dave Dykstra From nalin at redhat.com Thu Sep 6 07:31:10 2001 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 5 Sep 2001 17:31:10 -0400 Subject: pam_limits and OpenSSH In-Reply-To: <3B962E41.5090405@fmi.uni-sofia.bg>; from ogi@fmi.uni-sofia.bg on Wed, Sep 05, 2001 at 04:53:05PM +0300 References: <3B962E41.5090405@fmi.uni-sofia.bg> Message-ID: <20010905173110.A12809@redhat.com> On Wed, Sep 05, 2001 at 04:53:05PM +0300, Ognyan Kulev wrote: > Perhaps the daemon first sets process limits and then switches to the > user and/or fork(). But fork() cannot succeed because there is a > process number limit to 40 that is applied to root. This is my > hypothesis. I didn't look at sources. What you think about all this? > Do you need more information? I use Debian GNU/Linux potato and OpenSSH > 1.2.3-9.3. This is exactly the case. The process limit is set while the server is still running as the superuser, so it can't fork() to start the child (which would then do a setuid() to the user's ID). Opening the PAM session after performing the fork() and setuid() fixes this for pam_limits, but breaks other modules which expect to be running with superuser privileges when their pam_open_session() handlers are called. This was the crux of the whole pam_open_session mess from a few months ago -- my apologies for setting it in motion. Other process limits are going to have similar effects on sshd, and I don't see a clean way to handle process limits within PAM in this case. Hope this cleared things up a bit, Nalin From Nicolas.Williams at ubsw.com Thu Sep 6 07:33:48 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 5 Sep 2001 17:33:48 -0400 Subject: reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8) In-Reply-To: <200109052103.f85L3N9d435574@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Sep 05, 2001 at 02:03:23PM -0700 References: <200109052103.f85L3N9d435574@jurassic.eng.sun.com> Message-ID: <20010905173346.R5739@sm2p1386swk.wdr.com> On Wed, Sep 05, 2001 at 02:03:23PM -0700, Darren Moffat wrote: > >> >Could we please have a clarification on the semantics of > >> >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS? > >> > >> My interpretation is: > >> > >> You call PAM_ESTABLISH_CRED to create them > >> You call PAM_REINITIALIZE_CRED to update creds that can expire over time, > >> for example a kerberos ticket. > > Oops. I meant PAM_REFRESH_CRED > > >PAM_RENEW_CREDS is there for credential renewal (i.e., ticket renewal, > >in the Kerberos case). That's clear from its name. > > It is called PAM_REFRESH_CRED. Yes, sorry. > >PAM_REINITIALIZE_CREDS is, well, completely undocumented (I'll recheck > >the XSSO docs). The OpenSSH interpretation is clear. > > Agreed and it is very ambiquous. I think it is quite easy to make > the assumption that ESTABLISH and REINITIALIZE care synonymous but both > are different from REFRESH. Again, Sun treats REINITIALIZE as a synonym of REFRESH. > >And, IMO, as I think about it, the OpenSSH interpretation makes plenty > >of sense. Consider an app that will not fork() a child that runs as the > >PAM_USER (e.g., a web server) but which nonetheless needs the user's > >Kerberos creds -- why bother creating a user-owned ccache then? > > I can see that from a PAM view point but it won't really work from > a Kerberos view point (it isn't how kerberos was designed to work). Sure it can work from the Kerberos pov. Like this: take an app that doesn't fork, but which authenticates multiple users, and does not "become" them, and which impersonates each of those users, at times, using the per-user ccache -- as long as the app can read each per-user ccache and as long as it keeps track of whose is whose it can do this. > >> "The pam_setcred() function is used to establish, modify, or delete the > >> credentials of the current user associated with the authentication handle, > >> pamh. " > > > >Why does that description not jive with my interpretation of the OpenSSH > >interpretation of the pam_setcred() flags' semantics? I mean, I don't > >see why. > > I guess it does at the PAM level but at the level of Kerberos the creds > are always placed in a cred file owned by that user since their is no > concept of acting onbehalf of another. Wrong. See above. Applications can impersonate Kerberos principals, provided they have the creds for those principals. > >I've written parts of a PAM_KRB5 (based on Frank Cusack's original) > >which behaves slightly differently: its auth method saves the user's > >Kerberos creds in a memory ccache and stuffs that into the pam handle as > >pam data, and its setcred method actually creates the file ccache (and > >destroys the memory ccache). > > The Solaris one does that as well, the ccache file is created as > /tmp/krb5cc_ with permissions 600 and owner I'll double check. > >> It will always create a cred cache file owned by PAM_USER, the only > >> way you could get the effect you describe above is if you called > >> pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item > >> to be - but this isn't what OpenSSH does (and it is wrong anyway). > > > >This is silly -- why create a user-owned ccache *before* the account > >management part of PAM has been called and suceeded?? > > Because you are supposed to call pam functions in this order: > > pam_start(pamh,...); > pam_authenticate(pamh, ...); > pam_acct_mgmt(pamh, > pam_setcred(pamh, PAM_ESTABLISH_CRED) > ... > pam_setcred(pamh, PAM_DELETE_CRED); > pam_end(pamh); Clearly -- no disagreement there. I'm asking why create the user-owned ccache in pam_authenticate() (which is what you said Sun's pam_krb5 does). > >In fact, it seems clear to me that no user-owned ccache should be > >created outside pam_krb5:pam_sm_setcred(). > > In Solaris it isn't. You seem to be mis-interpreting the man page bit you quoted -- pam_krb5:pam_sm_authenticate() should not create the file ccache (an internal memory ccache is needed though to communicate the creds to the pam_krb5:pam_sm_setcred() function (via pam data)). > >> I'm not sure the call to pam_setcred with PAM_REINITIALIZE_CREDS is > >> actually required in session.c. Why was it put there ? Is there a > >> particular pam module that causes a problem ? > > > >See above about apps that don't fork() a process that runs as the > >PAM_USER. > > I don't believe that is well defined for Kerberos and it isn't how > pam_krb5 in Solaris is designed to work. Sure it is. An app can use multiple ccaches and creds no problem. As long as it keeps them straight. > -- > Darren J Moffat 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 erik at xyzzy.net Thu Sep 6 08:42:11 2001 From: erik at xyzzy.net (Erik Benner) Date: Wed, 5 Sep 2001 18:42:11 -0400 Subject: bug in scp (OpenSSH) In-Reply-To: <20010905160452.A15208@lucent.com> Message-ID: <00b101c1365c$00f2fc60$cc64a8c0@home.xyzzy.net> I like the command line option to turn it off, or better yet a compile option to toggle the default and a command line to toggle as well. Should the toggle be for the bar or the throughput update? -----Original Message----- From: owner-openssh-unix-dev at mindrot.org [mailto:owner-openssh-unix-dev at mindrot.org]On Behalf Of Dave Dykstra Sent: Wednesday, September 05, 2001 5:05 PM To: Jason Stone Cc: openssh-unix-dev at mindrot.org Subject: Re: bug in scp (OpenSSH) On Tue, Sep 04, 2001 at 04:37:59PM -0700, Jason Stone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > >This has come up many times before, and the consensus of the developers > > >seems to be that they're not interested in fixing or adding features to > > >scp because they want to make scp just the secure version of rcp, and it's > > >not up to them to change rcp. > > > > One thing I have missing from other versions is the throughput meter > > in the status bar. > > Incidentally, at my last company, the progress bar was a source of > breakage for legacy scripts that didn't expect rcp to be producing any > output - so what's up with that? How does that fit into your model of > being rsh/rcp compatible and not introducing extraneous features? Do you > really think that breaking rcp compatibility with a status bar is a better > idea than "breaking" it with, for example, a flag to allow atomic > transfers? > > Don't you think that if the progress bar exists at all, it should at least > be enabled via commandline option or environment variable, and not be the > default? I agree. At least with ssh 1.2.27 there was a configure option to disable it, --disable-scp-stats. Showing those statistics by default are not in the Unix spirit. At least it won't show them if stderr is not a tty. - Dave Dykstra From vorlon at netexpress.net Thu Sep 6 08:51:00 2001 From: vorlon at netexpress.net (Steve Langasek) Date: Wed, 5 Sep 2001 17:51:00 -0500 (CDT) Subject: reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8) In-Reply-To: <200109052018.f85KIv9d427589@jurassic.eng.sun.com> Message-ID: On Wed, 5 Sep 2001, Darren Moffat wrote: > >Neither the Sun PAM documentation nor the Linux-PAM documentation > >describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail. > I would agree it is vague, but then that is also a problem with the XSSO > document (http://www.opengroup.org/onlinepubs/008329799/) > >Could we please have a clarification on the semantics of > >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS? > My interpretation is: > You call PAM_ESTABLISH_CRED to create them > You call PAM_REINITIALIZE_CRED to update creds that can expire over time, > for example a kerberos ticket. Coming at this purely from a literalist POV, the terminology 'REINITIALIZE_CRED' implies to me that the credentials will be returned to an /initial/ state, i.e., this is somehow analogous to calling setcred(PAM_DELETE_CRED) followed by setcred(PAM_ESTABLISH_CRED). Practically speaking, I don't see where anything further than ESTABLISH, REFRESH, and DELETE is required; either REINITIALIZE is equivalent to one of the first three, in which case it should be deprecated to reduce confusion, or it has a meaning outside of the first three, in which case it should be clearly determined what that meaning is before people try to make use of it in code. > >My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means > >"make it so we can use your module's credentials as root" whereas > >PAM_REINITIALIZE_CREDS means "make it so we can use your module's > >credentials as pam_get_item(PAM_USER)." > That is wrong and is one thing the XSSO doc is clear on: > "The pam_setcred() function is used to establish, modify, or delete the > credentials of the current user associated with the authentication handle, > pamh. " Agreed; it's counter-intuitive that a simple application which needs the credentials for only a short period of time should need to do anything more than setcred(ESTABLISH) at the beginning and setcred(DELETE) when the credentials are no longer needed. > >But none of this is documented! > Agreed the docs do not specify the level of privilege required by > the application for calling pam_* functions. > In someways I think it should be upto the modules to document what they > need but I also think this could break the abstraction that PAM is supposed > to provide. I think it's important for abstraction that this be specified. This lack of specification has more than once caused problems for both module writers and application writers. > It will always create a cred cache file owned by PAM_USER, the only > way you could get the effect you describe above is if you called > pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item > to be - but this isn't what OpenSSH does (and it is wrong anyway). Does Solaris pam_krb5 fail gracefully if the calling application cannot setuid(PAM_USER)? As Nico rightly points out, PAM is not unique to applications that establish local Unix security contexts as the given user. Steve Langasek postmodern programmer From adam-dated-1000166272.76e24e at flounder.net Thu Sep 6 09:57:51 2001 From: adam-dated-1000166272.76e24e at flounder.net (Adam McKenna) Date: Wed, 5 Sep 2001 16:57:51 -0700 Subject: sshd hangs on logout -- is this a bug? Message-ID: <20010905165751.A2447@flounder.net> In the changelog, there is an entry: 20001129 - (djm) Back out all the serverloop.c hacks. sshd will now hang again if there are background children with open fds. Does this mean that this is regarded as expected (and correct) behavior, that should not change in the future, or does it mean that this behavior is a known problem that someone will eventually fix? --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010905/2f2229d2/attachment.bin From rachit at ensim.com Thu Sep 6 14:53:46 2001 From: rachit at ensim.com (Rachit Siamwalla) Date: Wed, 5 Sep 2001 21:53:46 -0700 Subject: openssh and multiple ports Message-ID: <9AC41B8C4781464695BB013F106FCA3102900C1F@nasdaq.ms.ensim.com> Btw, I believe the reason for the inconsistency -p and -P is because of compatability with ssh-rsh scp-rcp rcp uses -p for something else, so scp cannot use -p. -rchit -----Original Message----- From: Marc Boucher [mailto:marc at mbsi.ca] Sent: Tuesday, September 04, 2001 5:34 PM To: Kevin Steves Cc: openssh-unix-dev at mindrot.org Subject: Re: openssh and multiple ports On Tue, Sep 04, 2001 at 04:42:34PM -0700, Kevin Steves wrote: > On Tue, 4 Sep 2001, Marc Boucher wrote: > :it's an unnecessary kludge. The user shouldn't have to deal with this. > :Openssh should do the right thing and differentiate host keys with port > :numbers along names and addresses. > > i think most will agree, however no one has written the code to support > this. it will happen at some point. ok > :> > > Also, how about supporting the "ssh user at host#port" number syntax, instead > :> > > of requiring the -p option? > :> > > :> > I'd suggest user at host:port to be more in line with established > :> > conventions, unless the colon is already being used for something > :> > else... > : > :I think '#' is better, since it maintains compatibility with the other > :implementation, and besides, the ':' character is already used in IPv6 > :addresses. > > i don't see a good reason to add another way to specify port on the > ssh command line. I think it's a matter of taste (I personally find it much more practical and logical to do "scp marc at mbsi.ca#2:/tmp/file dest" than "scp -P 2 marc at mbsi.ca:/tmp/file", which requires that you remember an option letter that isn't even consistent between commands; as ssh uses lowercase '-p') and compatibility with ssh.com's implementation, which has supported this feature for a long time. Marc From adam-dated-1000197326.d36912 at flounder.net Thu Sep 6 18:35:26 2001 From: adam-dated-1000197326.d36912 at flounder.net (Adam McKenna) Date: Thu, 6 Sep 2001 01:35:26 -0700 Subject: openssh and multiple ports In-Reply-To: <54763718.999609127@athyra> References: <3C1E3607B37295439F7C409EFBA08E680E2680@col-581-exs01.cist.saic. <54763718.999609127@athyra> Message-ID: <20010906013526.K2447@flounder.net> On Tue, Sep 04, 2001 at 01:12:07PM -0700, Carson Gaspar wrote: > > > --On Tuesday, September 04, 2001 3:09 PM -0400 "Loomis, Rip" > wrote: > > >Having said that, I don't see that the -p port option is > >so onerous as to make it worth implementing the #port > >method. > > It wouldn't be so bad is ssh and scp used the _same_ option for an > alternate port, but they don't. Sorry to add more fuel to this fire, but since we're having the discussion anyway, it bears mentioning that SCP claims to support copying files between *two* remote machines. (i.e., using a third machine as an intermediate). This breaks if ssh is running on a different port on either machine. There should be a way to set the port for both source and destination. --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010906/b419dbe2/attachment.bin From mstone at cs.loyola.edu Thu Sep 6 22:16:52 2001 From: mstone at cs.loyola.edu (Michael Stone) Date: Thu, 6 Sep 2001 08:16:52 -0400 Subject: line_abbrevname patch Message-ID: <20010906081652.A23049@justice.loyola.edu> Once upon a time there were two places in the loginrec code that were ifdef'd sgi and which stripped the "tty" off the line along with the "dev" when recording utmp. (Specifically it was being done in line_stripname and line_abbrevname.) Doing that in line_stripname was wrong, because it broke things like wall that expected the ut_line to have the "tty" present. But I lost track of patches and also sent a patch to get it removed from line_abbrevname (which breaks interoperability with native xterms and other things that use pty's, as they use a ut_id which does *not* have the "tty", so you end up with a utmp that has multiple entries for each tty.) In thinking about putting it back it, it occurred to me that irix might not be the only platform to do use a ut_id of this form. So instead of making it ifdef sgi I made it a configure option. If the powers that be think this is more ugly rather than less ugly, the erroneous removal from line_abbrevname was between 2.5.1p1 and 2.5.1p2; I don't see a changelog entry relating to the removal of the ifdef sgi from line_stripname, so I don't know when that was done (although I know it was before 2.5.1p1.) --- openssh-2.9p2.orig/config.h.in Sun Jun 17 04:09:47 2001 +++ openssh-2.9p2/config.h.in Wed Sep 5 19:11:41 2001 @@ -102,6 +102,9 @@ /* Define if you want IRIX kernel jobs */ #undef WITH_IRIX_JOBS +/* Define if the tty id (abbreviated name) in *tmp strips tty */ +#undef WITH_NO_TTY_IN_UTMP_ID + /* Location of random number pool */ #undef RANDOM_POOL --- openssh-2.9p2.orig/configure.in Mon May 28 17:21:44 2001 +++ openssh-2.9p2/configure.in Wed Sep 5 19:13:06 2001 @@ -111,6 +111,7 @@ AC_DEFINE(WITH_IRIX_ARRAY) AC_DEFINE(WITH_IRIX_PROJECT) AC_DEFINE(WITH_IRIX_AUDIT) + AC_DEFINE(WITH_NO_TTY_IN_UTMP_ID) AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)]) no_libsocket=1 no_libnsl=1 --- openssh-2.9p2.orig/loginrec.c Tue May 8 20:34:33 2001 +++ openssh-2.9p2/loginrec.c Wed Sep 5 19:09:00 2001 @@ -563,6 +563,11 @@ if (strncmp(src, "/dev/", 5) == 0) src += 5; +#ifdef WITH_NO_TTY_IN_UTMP_ID + if (strncmp(src, "tty", 3) == 0) + src += 3; +#endif + len = strlen(src); if (len > 0) { -- Mike Stone From mouring at etoh.eviladmin.org Thu Sep 6 23:18:52 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 6 Sep 2001 08:18:52 -0500 (CDT) Subject: openssh and multiple ports In-Reply-To: <20010906013526.K2447@flounder.net> Message-ID: This is the first valid reason I've seen soo far for supporting a concept like 'user at host#port:file'... Even if I'm not sure I like the idea of using # as part of any command line due to it's implied meaning of 'comment' for all shells. I don't see them off hand, but I believe someone suggested in private mail using / as an alternate way of seperating IP from port. Mainly for ssh{d}_config files. - Ben On Thu, 6 Sep 2001, Adam McKenna wrote: > On Tue, Sep 04, 2001 at 01:12:07PM -0700, Carson Gaspar wrote: > > > > > > --On Tuesday, September 04, 2001 3:09 PM -0400 "Loomis, Rip" > > wrote: > > > > >Having said that, I don't see that the -p port option is > > >so onerous as to make it worth implementing the #port > > >method. > > > > It wouldn't be so bad is ssh and scp used the _same_ option for an > > alternate port, but they don't. > > Sorry to add more fuel to this fire, but since we're having the discussion > anyway, it bears mentioning that SCP claims to support copying files > between *two* remote machines. (i.e., using a third machine as an > intermediate). This breaks if ssh is running on a different port on either > machine. There should be a way to set the port for both source and > destination. > > --Adam > > -- > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A > From Nicolas.Williams at ubsw.com Thu Sep 6 23:59:15 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 6 Sep 2001 09:59:15 -0400 Subject: reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8) In-Reply-To: ; from vorlon@netexpress.net on Wed, Sep 05, 2001 at 05:51:00PM -0500 References: <200109052018.f85KIv9d427589@jurassic.eng.sun.com> Message-ID: <20010906095914.S5739@sm2p1386swk.wdr.com> On Wed, Sep 05, 2001 at 05:51:00PM -0500, Steve Langasek wrote: > On Wed, 5 Sep 2001, Darren Moffat wrote: > > > >Neither the Sun PAM documentation nor the Linux-PAM documentation > > >describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail. > > > I would agree it is vague, but then that is also a problem with the XSSO > > document (http://www.opengroup.org/onlinepubs/008329799/) > > > >Could we please have a clarification on the semantics of > > >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS? > > > My interpretation is: > > > You call PAM_ESTABLISH_CRED to create them > > You call PAM_REINITIALIZE_CRED to update creds that can expire over time, > > for example a kerberos ticket. > > Coming at this purely from a literalist POV, the terminology > 'REINITIALIZE_CRED' implies to me that the credentials will be returned to an > /initial/ state, i.e., this is somehow analogous to calling > setcred(PAM_DELETE_CRED) followed by setcred(PAM_ESTABLISH_CRED). >From a literalist POV, clearly, PAM_REFRESH_CRED coincides with the act of renewing a [renewable] Kerberos ticket. >From a literalist POV, clearly, PAM_ESTABLISH_CRED coincides with the act of creating a Kerberos ticket cache. And I accept Steve's literalist take on PAM_REINITIALIZE_CRED, which would coincide with the act of getting new Kerberos creds and updating an existing ccache with them (because the creds in that ccache might be expired, and therefore non-renewable). This means that PAM_KRB5's setcred() might have to prompt for a password when called to PAM_REINITIALIZE_CRED. This is quite different from what I was yesterday taking OpenSSH's interpretation of PAM_REINITIALIZE_CRED to mean. Why should OpenSSH bother calling pam_setcred(PAM_REINITIALIZE_CRED)? Here's the comment from the source: /* * PAM credentials may take the form of * supplementary groups. These will have been * wiped by the above initgroups() call. * Reestablish them here. */ Is this, then, in case one has a PAM module which implements its own initgroups()? What is, then, the correct behaviour for PAM_KRB5's setcred() when called to PAM_REINITIALIZE_CRED? Taking Steve's literalist approach one would think that should be: check for expired creds in the [default] ccache and, if there are expired creds then call krb5_get_init_creds_password() with a prompter function that uses the PAM conversation function to get new creds and store them in that ccache. > Practically speaking, I don't see where anything further than ESTABLISH, > REFRESH, and DELETE is required; either REINITIALIZE is equivalent to one of > the first three, in which case it should be deprecated to reduce confusion, or > it has a meaning outside of the first three, in which case it should be > clearly determined what that meaning is before people try to make use of it in > code. Well, see above. It might well be usefule to have a "check if the creds are expired and, if so, delete them then establish new ones." > > >My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means > > >"make it so we can use your module's credentials as root" whereas > > >PAM_REINITIALIZE_CREDS means "make it so we can use your module's > > >credentials as pam_get_item(PAM_USER)." > > > That is wrong and is one thing the XSSO doc is clear on: Yes, I see that now. Thanks Darren, Steve. > > "The pam_setcred() function is used to establish, modify, or delete the > > credentials of the current user associated with the authentication handle, > > pamh. " > > Agreed; it's counter-intuitive that a simple application which needs the > credentials for only a short period of time should need to do anything more > than setcred(ESTABLISH) at the beginning and setcred(DELETE) when the > credentials are no longer needed. Your literal interpretation of PAM_REINITIALIZE_CREDS has inspired me :) -- see above. > > >But none of this is documented! > > > Agreed the docs do not specify the level of privilege required by > > the application for calling pam_* functions. > > > In someways I think it should be upto the modules to document what they > > need but I also think this could break the abstraction that PAM is supposed > > to provide. > > I think it's important for abstraction that this be specified. This lack of > specification has more than once caused problems for both module writers and > application writers. I guess we could make it so the ccache is user-owned unless the calling app lacks the privs needed to do so, in which case the ccache should be euid-owned, yes? > > It will always create a cred cache file owned by PAM_USER, the only > > way you could get the effect you describe above is if you called > > pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item > > to be - but this isn't what OpenSSH does (and it is wrong anyway). > > Does Solaris pam_krb5 fail gracefully if the calling application cannot > setuid(PAM_USER)? As Nico rightly points out, PAM is not unique to > applications that establish local Unix security contexts as the given user. > > Steve Langasek > postmodern programmer 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 Nicolas.Williams at ubsw.com Fri Sep 7 01:00:28 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 6 Sep 2001 11:00:28 -0400 Subject: sshd hangs on logout -- is this a bug? In-Reply-To: <20010905165751.A2447@flounder.net>; from adam-dated-1000166272.76e24e@flounder.net on Wed, Sep 05, 2001 at 04:57:51PM -0700 References: <20010905165751.A2447@flounder.net> Message-ID: <20010906110026.T5739@sm2p1386swk.wdr.com> This is normal behaviour for RSH and is natural behaviour anyways. For example: when should "ssh somehost somecommand" exit? When 'somecommand' exits? or when it *and* all it's children have exited? And what if you were starting a daemon? But daemons *detach* from their current TTY, and *that* is key here. If 'somecommand' in the above example leaves background children processes when it exist and those children still have the ssh tty open then they may want to read/write from/to that tty -- and the ssh user might well expect to be able to interact with such background children processes. Thus this is normal behaviour. Just remember, when you don't want hanging rsh/ssh's do this: ssh -n somehost somecommand \> /dev/null 2\>\&1 It might be nice to have an option like -n but for stdout/stderr to avoid the need for quoting (and to be more portable, after all, that "\> /dev/null 2\>\&1" bit is Bourne Shell specific and can't be guaranteed to work with all ssh daemons (think Windows). Nico On Wed, Sep 05, 2001 at 04:57:51PM -0700, Adam McKenna wrote: > In the changelog, there is an entry: > > 20001129 > - (djm) Back out all the serverloop.c hacks. sshd will now hang again > if there are background children with open fds. > > Does this mean that this is regarded as expected (and correct) behavior, that > should not change in the future, or does it mean that this behavior is a > known problem that someone will eventually fix? > > --Adam > > -- > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A -- 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 mark-list at mentovai.com Fri Sep 7 02:16:08 2001 From: mark-list at mentovai.com (Mark Mentovai) Date: Thu, 6 Sep 2001 12:16:08 -0400 (EDT) Subject: lastlog on Solaris with PAM (patch included) Message-ID: On Solaris, the pam_unix module includes a pam_session which updates the lastlog file. Since OpenSSH calls pam_session before reading the lastlog file, SSH logins to systems with this configuration (as well as similar ones, I'd imagine) report the last login time and remote host as the values from the current session. My solution to this problem is to call pam_open_session in the child, after do_login has been called and the last login information has been retrieved and printed. This can result in the lastlog file being updated twice, but we'll need to live with that, since there's no way short of reading it directly to find out whether or not it has been updated, and even then, there's a mostly harmless race condition. A separate but slightly related issue that I'm nailing at the same time (as well as an explanation for the change in do_exec_no_pty): It's possible for pam_setcred to print messages that should be considered part of the session, and that would need to be done after the stdio and pty plumbing. Finally, I'm not too thrilled about the use of strlcpy to get the hostname out of lastlog. The ll_host field of lastlog is a fixed-width field and is not null-terminated. Since strlcpy copies n-1 bytes and then sets byte n-1 to 0, it would be more appropriate to use: strlcpy(li->hostname, last->ll_host, MIN_SIZEOF(li->hostname, last->ll_host + 1)); Think about what happens if sizeof(last->ll_host) = n (n < LINFO_HOSTSIZE) and a specific hostname is exactly n bytes long without any trailing 0-bytes. Also, watch out for other null-termination issues in the same region of code - I mention this because if LINFO_HOSTSIZE was set to coincide with sizeof(last->ll_host) of some particular system, it really should be bumped up by one to handle the trailing 0. Mark -- OpenSSH 2.9p2 Patch, 2001 September 6, Mark Mentovai Fix for the ordering of some of the PAM calls, including the problem with incorrect last login times on Solaris with PAM. See comments for details. diff -ur openssh-2.9p2.dist/session.c openssh-2.9p2/session.c Index: openssh-2.9p2/session.c --- openssh-2.9p2.dist/session.c Sat Jun 16 23:40:51 2001 +++ openssh-2.9p2/session.c Thu Sep 6 11:48:04 2001 @@ -456,10 +456,6 @@ session_proctitle(s); -#if defined(USE_PAM) - do_pam_setcred(1); -#endif /* USE_PAM */ - /* Fork the child. */ if ((pid = fork()) == 0) { /* Child. Reinitialize the log since the pid has changed. */ @@ -509,6 +505,13 @@ perror("dup2 stderr"); #endif /* USE_PIPES */ +#if defined(USE_PAM) + /* pam_setcred might print things that belong to the + session, put it after the stdio plumbing. + Mark Mentovai, 20010906 */ + do_pam_setcred(1); +#endif /* USE_PAM */ + /* Do processing for the child (exec command etc). */ do_child(s, command); /* NOTREACHED */ @@ -570,11 +573,6 @@ ptyfd = s->ptyfd; ttyfd = s->ttyfd; -#if defined(USE_PAM) - do_pam_session(s->pw->pw_name, s->tty); - do_pam_setcred(1); -#endif - /* Fork the child. */ if ((pid = fork()) == 0) { /* Child. Reinitialize the log because the pid has changed. */ @@ -609,6 +607,23 @@ else do_pre_login(s); # endif +#endif + +#if defined(USE_PAM) + /* The PAM session code must be after do_login because the + pam_open_session handler in the pam_unix module in + Solaris updates the lastlog file, which causes do_login + to report the current login as the last one. A lastlog + entry will be written again by lastlog_perform_login, + but we'll live with that for now. Can't just disable + lastlog writing in lastlog_perform_login if USE_PAM is + defined, because there are systems and configurations + with which pam_open_session does not touch lastlog. + Also, pam_setcred might print things that belong to the + session, so it should be called after the pty is set up. + Mark Mentovai, 20010906 */ + do_pam_session(s->pw->pw_name, s->tty); + do_pam_setcred(1); #endif /* Do common processing for the child, such as execing the command. */ From genty at austin.ibm.com Fri Sep 7 02:56:13 2001 From: genty at austin.ibm.com (Denise Genty) Date: Thu, 06 Sep 2001 11:56:13 -0500 Subject: AIX openssh use of SRC control Message-ID: <200109061656.f86GuEV39656@dgenty.austin.ibm.com> I'm new to using openSSH on AIX and want to know how others are launching and maintaing sshd. I see where sshd has a -i option for use with inetd, but I am thinking about adding the AIX SRC APIs so that I can use the commands: lssrc, startsrc and stopsrc to maintain the daemon. -- Denise M. Genty genty at austin.ibm.com (512)838-8170 - T/L 678-8170 AIX IP Security IBM Austin - UNIX Servers From douglas.manton at uk.ibm.com Fri Sep 7 03:01:59 2001 From: douglas.manton at uk.ibm.com (Doug E Manton) Date: Thu, 6 Sep 2001 18:01:59 +0100 Subject: AIX openssh use of SRC control Message-ID: Hi Denise, You can add SSH to the SRC using the command: mkssys -s sshd -u 0 -p /usr/sbin/sshd -a '-D' -G ssh -R -S -n 15 -f 9 Change /usr/sbin/sshd to wherever you have sshd installed. The -R automatically restarts SSH if it ever falls over. SSH requires the -D option to prevent it forking (a requirement of the SRC). You can then add this to /etc/rc.tcpip to initiate it on each boot: start /usr/sbin/sshd "$src_running" Best wishes, -------------------------------------------------------- Doug Manton, AT&T EMEA Commercial Security Solutions E: demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" From Nicolas.Williams at ubsw.com Fri Sep 7 03:20:15 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 6 Sep 2001 13:20:15 -0400 Subject: lastlog on Solaris with PAM (patch included) In-Reply-To: ; from mark-list@mentovai.com on Thu, Sep 06, 2001 at 12:16:08PM -0400 References: Message-ID: <20010906132014.U5739@sm2p1386swk.wdr.com> On Thu, Sep 06, 2001 at 12:16:08PM -0400, Mark Mentovai wrote: > A separate but slightly related issue that I'm nailing at the same time (as > well as an explanation for the change in do_exec_no_pty): It's possible for > pam_setcred to print messages that should be considered part of the session, > and that would need to be done after the stdio and pty plumbing. No PAMs should ever read/write from/to stdio directly. They should always use the conversation function. Also, the PAM_SILENT flag can be used to ask that modules be as quiet as possible. It might be worthwhile to use that flag in do_exec_no_pty(). > Mark 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 frank-m.mohr at db.com Fri Sep 7 05:15:52 2001 From: frank-m.mohr at db.com (Frank-M Mohr) Date: Thu, 6 Sep 2001 20:15:52 +0100 Subject: Antwort: Re: AIX openssh use of SRC control Message-ID: Hi I've finished and tested a patch to add src routines to openssh (based on the Redbook "Writing Reliable AIX Daemons") Since a few days I have the O.K. to post it on the list, but I still want to splitt my patch file into logical parts (SRC/Logging/Datatype fixes) Frank Datum: 06.09.2001 19:04 An: Denise Genty Kopie: openssh-unix-dev at mindrot.org Antwort an: dmanton at emea.att.com Betreff: Re: AIX openssh use of SRC control Nachrichtentext: Hi Denise, You can add SSH to the SRC using the command: mkssys -s sshd -u 0 -p /usr/sbin/sshd -a '-D' -G ssh -R -S -n 15 -f 9 Change /usr/sbin/sshd to wherever you have sshd installed. The -R automatically restarts SSH if it ever falls over. SSH requires the -D option to prevent it forking (a requirement of the SRC). You can then add this to /etc/rc.tcpip to initiate it on each boot: start /usr/sbin/sshd "$src_running" Best wishes, -------------------------------------------------------- Doug Manton, AT&T EMEA Commercial Security Solutions E: demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" -- 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 stevesk at pobox.com Fri Sep 7 05:44:11 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 6 Sep 2001 12:44:11 -0700 (PDT) Subject: openssh and multiple ports In-Reply-To: <20010906013526.K2447@flounder.net> Message-ID: On Thu, 6 Sep 2001, Adam McKenna wrote: :Sorry to add more fuel to this fire, but since we're having the discussion :anyway, it bears mentioning that SCP claims to support copying files :between *two* remote machines. (i.e., using a third machine as an :intermediate). This breaks if ssh is running on a different port on either :machine. There should be a way to set the port for both source and :destination. i wonder how many people use third-party copies? third-party copies work by changing: scp user1 at host1:dir/foo user2 at host2:dir/bar to: ssh -l user1 host1 scp dir/foo user2 at host2:dir/bar if we add some special port notation to the path, what happens when host2 scp does not recognize it? the way to do this is to handle -o properly (it's not handled at all now for third-party copies). scp -oport=2222 user1 at host1:dir/foo -oport=3333 user2 at host2:dir/bar then we get: ssh -l user1 -oport=2222 host1 scp -oport=3333 dir/foo user2 at host2:dir/bar it may not be that hard to fix this with optreset, but i'm not sure it's worth it. From adam-dated-1000237541.bcd841 at flounder.net Fri Sep 7 05:45:40 2001 From: adam-dated-1000237541.bcd841 at flounder.net (Adam McKenna) Date: Thu, 6 Sep 2001 12:45:40 -0700 Subject: openssh and multiple ports In-Reply-To: References: <20010906013526.K2447@flounder.net> Message-ID: <20010906124540.E14113@flounder.net> On Thu, Sep 06, 2001 at 12:44:11PM -0700, Kevin Steves wrote: > On Thu, 6 Sep 2001, Adam McKenna wrote: > :Sorry to add more fuel to this fire, but since we're having the discussion > :anyway, it bears mentioning that SCP claims to support copying files > :between *two* remote machines. (i.e., using a third machine as an > :intermediate). This breaks if ssh is running on a different port on either > :machine. There should be a way to set the port for both source and > :destination. > > i wonder how many people use third-party copies? The issue here is not how many people use the feature. The SCP documentation says it supports this feature, but it doesn't work in all cases. If the feature is not supported for hosts running sshd on different ports, then the documentation should be modified to indicate that. > third-party copies work by changing: > scp user1 at host1:dir/foo user2 at host2:dir/bar > to: > ssh -l user1 host1 scp dir/foo user2 at host2:dir/bar A number of workarounds exist for this problem. Again, this is not the point. See above. > if we add some special port notation to the path, what happens when host2 > scp does not recognize it? the way to do this is to handle -o properly > (it's not handled at all now for third-party copies). > > scp -oport=2222 user1 at host1:dir/foo -oport=3333 user2 at host2:dir/bar > then we get: > ssh -l user1 -oport=2222 host1 scp -oport=3333 dir/foo user2 at host2:dir/bar > > it may not be that hard to fix this with optreset, but i'm not sure it's > worth it. If I'm reading you correctly, what you're saying is that third party copies work by sending host1 an scp command which tells it to copy the file directly from host1 to host2. I thought this feature was supposed to enable secure file copy between two hosts that cannot reach each other at all, through a third host that is reachable by both. Is this not the case? --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From dwd at bell-labs.com Fri Sep 7 07:44:33 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Thu, 6 Sep 2001 16:44:33 -0500 Subject: bug in scp (OpenSSH) In-Reply-To: <00b101c1365c$00f2fc60$cc64a8c0@home.xyzzy.net>; from erik@xyzzy.net on Wed, Sep 05, 2001 at 06:42:11PM -0400 References: <20010905160452.A15208@lucent.com> <00b101c1365c$00f2fc60$cc64a8c0@home.xyzzy.net> Message-ID: <20010906164433.A11047@lucent.com> On Wed, Sep 05, 2001 at 06:42:11PM -0400, Erik Benner wrote: > I like the command line option to turn it off, or better yet a compile > option to toggle the default and a command line to toggle as well. Should > the toggle be for the bar or the throughput update? I don't think scp should print any progress information by default. - Dave Dykstra From adam-dated-1000248167.fb554c at flounder.net Fri Sep 7 08:42:46 2001 From: adam-dated-1000248167.fb554c at flounder.net (Adam McKenna) Date: Thu, 6 Sep 2001 15:42:46 -0700 Subject: PAM overrides PermitEmptyPasswords Message-ID: <20010906154246.D3928@flounder.net> I noticed while investigating Debian Bug #93200 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93200&repeatmerged=yes) that sshd refuses a login if /etc/pam.d/ssh doesn't specify "nullok" after the pam_unix.so module -- is there any way to resolve this problem? It seems that OpenSSH should override PAM in this case, someone posted a patch on 6/19 that appears to address this problem, (http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99293778402235&w=2) is there any chance this will be fixed in the next release? Thanks, --Adam -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010906/4b94ecd7/attachment.bin From mouring at etoh.eviladmin.org Fri Sep 7 08:53:01 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 6 Sep 2001 17:53:01 -0500 (CDT) Subject: PAM overrides PermitEmptyPasswords In-Reply-To: <20010906154246.D3928@flounder.net> Message-ID: auth-pam.c in auth_pam_password() already checks for this case in the current CVS tree. If it still occurs in the current tree than it should be addressed within auth_pam_password(). Otherwise you need to check and fix auth1.c and auth2.c. - Ben On Thu, 6 Sep 2001, Adam McKenna wrote: > I noticed while investigating Debian Bug #93200 > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93200&repeatmerged=yes) > that sshd refuses a login if /etc/pam.d/ssh doesn't specify "nullok" after > the pam_unix.so module -- is there any way to resolve this problem? It seems > that OpenSSH should override PAM in this case, someone posted a patch on 6/19 > that appears to address this problem, > (http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=99293778402235&w=2) > is there any chance this will be fixed in the next release? > > Thanks, > > --Adam > -- > Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA > http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A > From sturle.sunde at usit.uio.no Fri Sep 7 09:16:43 2001 From: sturle.sunde at usit.uio.no (Sturle Sunde) Date: 07 Sep 2001 01:16:43 +0200 Subject: sshd hangs on logout -- is this a bug? In-Reply-To: <20010906110026.T5739@sm2p1386swk.wdr.com> References: <20010905165751.A2447@flounder.net> <20010906110026.T5739@sm2p1386swk.wdr.com> Message-ID: [Quoting reformatted for readability] Nicolas Williams writes: > On Wed, Sep 05, 2001 at 04:57:51PM -0700, Adam McKenna wrote: >> In the changelog, there is an entry: >> >> 20001129 >> - (djm) Back out all the serverloop.c hacks. sshd will now hang again >> if there are background children with open fds. >> >> Does this mean that this is regarded as expected (and correct) >> behavior, that should not change in the future, or does it mean >> that this behavior is a known problem that someone will eventually >> fix? > > This is normal behaviour for RSH and is natural behaviour anyways. Not if you enter an interactive session (and rsh become rlogin). If I rsh to a machine, exec bash, sleep 100 & and logout, I get disconnected immediately. If I ssh to a machine running OpenSSH 2.9p2 and do the same, I don't get disconnected until the sleep is finished. SSH.com sshd disconnects immediately in all cases when the shell exits (like rlogind, not rshd). This difference in behaviour is very annoying, and I hoped it would be fixed in the next version. -- Sturle All eyes were on Ford Prefect. Some of them were on stalks. ~~~~~~ -- Douglas Adams, So long, and thanks for all the fish From packard at mail2.jpl.nasa.gov Fri Sep 7 09:59:36 2001 From: packard at mail2.jpl.nasa.gov (Scott Packard) Date: Thu, 6 Sep 2001 16:59:36 -0700 (PDT) Subject: bug in scp (OpenSSH) In-Reply-To: <20010906164433.A11047@lucent.com> Message-ID: I'm afraid I disagree. I like the scp progress info. To a naive user it let's them know that at least something is happening. The advanced user knows enough to turn it off, IMO. Regards, Scott On Thu, 6 Sep 2001, Dave Dykstra wrote: > Date: Thu, 6 Sep 2001 16:44:33 -0500 > From: Dave Dykstra > To: openssh-unix-dev at mindrot.org > Subject: Re: bug in scp (OpenSSH) > > On Wed, Sep 05, 2001 at 06:42:11PM -0400, Erik Benner wrote: > > I like the command line option to turn it off, or better yet a compile > > option to toggle the default and a command line to toggle as well. Should > > the toggle be for the bar or the throughput update? > > I don't think scp should print any progress information by default. > > - Dave Dykstra > From jason at shalott.net Fri Sep 7 10:50:10 2001 From: jason at shalott.net (Jason Stone) Date: Thu, 6 Sep 2001 17:50:10 -0700 (PDT) Subject: bug in scp (OpenSSH) In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm afraid I disagree. I like the scp progress info. > To a naive user it let's them know that at least > something is happening. The advanced user knows > enough to turn it off, IMO. If you as a sysadmin want your naive users to see the progress bar, you can alias scp to "scp -l" (or whatever the option would be) in the default shell prefs, just as many admins alias rm to "rm -i" But as has been said repeatedly, scp is supposed to be just the secure version of rcp, and I've never seen a version of rcp with a progress bar. -Jason ----------------------------------------------------------------------- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE7mBnHswXMWWtptckRAvGnAJ9OFS1IbkzpU2EF/1nE7Ly7FqYv7wCbB/Ns GkMgRD32+qM9wiWZt+qway0= =OsI3 -----END PGP SIGNATURE----- From erik at xyzzy.net Fri Sep 7 10:54:43 2001 From: erik at xyzzy.net (Erik Benner) Date: Thu, 6 Sep 2001 20:54:43 -0400 Subject: bug in scp (OpenSSH) In-Reply-To: Message-ID: <00cf01c13737$af6befa0$cc64a8c0@home.xyzzy.net> I have a version that does this... and adds my throughput back in to.... now for the tough part... What do I do next? I've not contributed code/fixes to a FreeBSD project before? Do I sent diffs? -----Original Message----- From: owner-openssh-unix-dev at mindrot.org [mailto:owner-openssh-unix-dev at mindrot.org]On Behalf Of Scott Packard Sent: Thursday, September 06, 2001 8:00 PM To: Dave Dykstra Cc: openssh-unix-dev at mindrot.org Subject: Re: bug in scp (OpenSSH) I'm afraid I disagree. I like the scp progress info. To a naive user it let's them know that at least something is happening. The advanced user knows enough to turn it off, IMO. Regards, Scott On Thu, 6 Sep 2001, Dave Dykstra wrote: > Date: Thu, 6 Sep 2001 16:44:33 -0500 > From: Dave Dykstra > To: openssh-unix-dev at mindrot.org > Subject: Re: bug in scp (OpenSSH) > > On Wed, Sep 05, 2001 at 06:42:11PM -0400, Erik Benner wrote: > > I like the command line option to turn it off, or better yet a compile > > option to toggle the default and a command line to toggle as well. Should > > the toggle be for the bar or the throughput update? > > I don't think scp should print any progress information by default. > > - Dave Dykstra > From mouring at etoh.eviladmin.org Fri Sep 7 10:51:00 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 6 Sep 2001 19:51:00 -0500 (CDT) Subject: bug in scp (OpenSSH) In-Reply-To: Message-ID: On Thu, 6 Sep 2001, Jason Stone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > I'm afraid I disagree. I like the scp progress info. > > To a naive user it let's them know that at least > > something is happening. The advanced user knows > > enough to turn it off, IMO. > > If you as a sysadmin want your naive users to see the progress bar, you > can alias scp to "scp -l" (or whatever the option would be) in the default > shell prefs, just as many admins alias rm to "rm -i" > "If the person does not want to see it they can always alias scp to 'scp -q'.." The street goes both ways. I'm sorry, but I think this argument has gone on too far and it is no where remotely useful. - Ben From jason at shalott.net Fri Sep 7 20:45:16 2001 From: jason at shalott.net (Jason Stone) Date: Fri, 7 Sep 2001 03:45:16 -0700 (PDT) Subject: bug in scp (OpenSSH) In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > If you as a sysadmin want your naive users to see the progress bar, you > > can alias scp to "scp -l" (or whatever the option would be) in the default > > shell prefs, just as many admins alias rm to "rm -i" > > > > "If the person does not want to see it they can always alias scp to 'scp > -q'.." Yes, but rcp doesn't take a "-q", so if I have my scripts call $RCP -q and $RCP is set to rcp, it doesn't go. This is the first response that I've seen from one of the maintainers/developers on this matter, and it still doesn't address the issue - are you going to consider taking out the progress bar or at least making it default to off? And if you aren't going to take it out, are you going to consider putting in any of the other good patches to scp that have been posted? -Jason ----------------------------------------------------------------------- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE7mKVBswXMWWtptckRAh92AJwMRxSBqZTU7B+QQCD5rdz8divaZQCfRSky VggTpGAOgbDLz7GIG647s+g= =0/kq -----END PGP SIGNATURE----- From mouring at etoh.eviladmin.org Fri Sep 7 23:07:07 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 7 Sep 2001 08:07:07 -0500 (CDT) Subject: bug in scp (OpenSSH) In-Reply-To: Message-ID: On Fri, 7 Sep 2001, Jason Stone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > If you as a sysadmin want your naive users to see the progress bar, you > > > can alias scp to "scp -l" (or whatever the option would be) in the default > > > shell prefs, just as many admins alias rm to "rm -i" > > > > > > > "If the person does not want to see it they can always alias scp to 'scp > > -q'.." > > Yes, but rcp doesn't take a "-q", so if I have my scripts call $RCP -q and > $RCP is set to rcp, it doesn't go. > > This is the first response that I've seen from one of the > maintainers/developers on this matter, and it still doesn't address the > issue - are you going to consider taking out the progress bar or at least > making it default to off? And if you aren't going to take it out, are you > going to consider putting in any of the other good patches to scp that > have been posted? > > The only intention I have towards scp is when I have free cycles to submit a patch to support basic sftp support so people will stop whining about "why won't scp work when going to a SSH Corp's v2.x+ server?" As for the other patches.. I would support the 'scp -o port user at site:/path -o port user at site2:/path' patch. However, not all scp's are created equal and this 'feature' will not work on the old SSH Corp 1.2.x scp due to lack of -o concept. Same goes true for older OpenSSH releases. I would support scp patch to fix 3rd party password authentication on the 2nd host. Even if I dispise the whole idea of how 3rd party scp is done. (This has not been brought up yet.. but I will bring it up since it is more valuable than most of the chatter on the topic.) Changing the default to scp to quiet.. I may consider support, but I still see no use for such a patch because one should be checking the $? not the stdout. Anything that changes the rcp protocol I won't touch. That is just the reality of the matter. As I've said before.. Take my views with a grain of salt because they don't always match with Markus or others in the group. I will say this.. Arguing over stuff without a patch to the code will not gain ground in your position. So far I've seen more arguing then code. If you want something fixed or changed.. WRITE THE CODE AND SUBMIT IT. At least there will be a TECHNICAL reason for why things are declined. And remember with things like scp you really need to sit down and do a decent amount of cross compatibity testing. We support a lot of version of SSH and anyone of them could break with some of the suggestions your fighting for. - Ben From Nicolas.Williams at ubsw.com Fri Sep 7 23:20:20 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 7 Sep 2001 09:20:20 -0400 Subject: sshd hangs on logout -- is this a bug? In-Reply-To: ; from sturle.sunde@usit.uio.no on Fri, Sep 07, 2001 at 01:16:43AM +0200 References: <20010905165751.A2447@flounder.net> <20010906110026.T5739@sm2p1386swk.wdr.com> Message-ID: <20010907092018.V5739@sm2p1386swk.wdr.com> On Fri, Sep 07, 2001 at 01:16:43AM +0200, Sturle Sunde wrote: > [Quoting reformatted for readability] > > Nicolas Williams writes: > > On Wed, Sep 05, 2001 at 04:57:51PM -0700, Adam McKenna wrote: > >> In the changelog, there is an entry: > >> > >> 20001129 > >> - (djm) Back out all the serverloop.c hacks. sshd will now hang again > >> if there are background children with open fds. > >> > >> Does this mean that this is regarded as expected (and correct) > >> behavior, that should not change in the future, or does it mean > >> that this behavior is a known problem that someone will eventually > >> fix? > > > > This is normal behaviour for RSH and is natural behaviour anyways. > > Not if you enter an interactive session (and rsh become rlogin). Ah, yes. [...] > -- > Sturle All eyes were on Ford Prefect. Some of them were on stalks. > ~~~~~~ -- Douglas Adams, So long, and thanks for all the fish 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 vinschen at redhat.com Fri Sep 7 23:43:09 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 7 Sep 2001 15:43:09 +0200 Subject: [PATCH]: Drop Cygwin workaround In-Reply-To: <20010830104348.F8703@cygbert.vinschen.de>; from vinschen@redhat.com on Thu, Aug 30, 2001 at 10:43:48AM +0200 References: <20010830104348.F8703@cygbert.vinschen.de> Message-ID: <20010907154309.E17245@cygbert.vinschen.de> Anybody here with write access to the CVS repository? Corinna On Thu, Aug 30, 2001 at 10:43:48AM +0200, Corinna Vinschen wrote: > Hi, > > the Cygwin specific workaround to sleep a second in daemon() isn't > needed anymore. We can eliminate it from the OpenSSH sources. > > Index: daemon.c > =================================================================== > RCS file: /cvs/openssh_cvs/openbsd-compat/daemon.c,v > retrieving revision 1.1 > diff -u -p -r1.1 daemon.c > --- daemon.c 2001/01/31 21:52:03 1.1 > +++ daemon.c 2001/08/30 08:41:39 > @@ -51,13 +51,6 @@ daemon(nochdir, noclose) > case 0: > break; > default: > -#ifdef HAVE_CYGWIN > - /* > - * This sleep avoids a race condition which kills the > - * child process if parent is started by a NT/W2K service. > - */ > - sleep(1); > -#endif > _exit(0); > } -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Fri Sep 7 23:45:51 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 7 Sep 2001 15:45:51 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010904212559.F15127@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Sep 04, 2001 at 09:25:59PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> Message-ID: <20010907154551.F17245@cygbert.vinschen.de> On Tue, Sep 04, 2001 at 09:25:59PM +0200, Corinna Vinschen wrote: > Hi, > > I have a problem with a Linux box which I updated from 2.5.2p2 > to 2.9p2 recently. It's running a tunnel started via inittab > using a script which starts > > ssh -2 -N -o 'ConnectionAttempts 3600' -L $host > > This has run reliable with 2.5.2 over the last months. Now, after > I have upgraded to 2.9p2, the tunnel is closed right after each > attempt of an application to use the tunnel which is a cron job > running each 5 minutes. So, now the tunnel is closed and restarted > each 5 minutes :-( > > The message in the syslog is "Connection closed by foreign host". > > If that's of interest, 2.5.2p2 was compiled with OpenSSL 0.9.5, > 2.9p2 is compiled using OpenSSL 0.9.6b. > > > Does anybody know what's going on or what I did wrong? Or do > I need to give more details? > > Corinna Sorry for being pushy. Does nobody know what the reason for the above difference could be? Why does 2.9p2 close the connection all the time and 2.5.2p2 doesn't? And - even more important - how can I workaround that with 2.9p2? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From wpilorz at bdk.pl Sat Sep 8 00:05:11 2001 From: wpilorz at bdk.pl (Wojtek Pilorz) Date: Fri, 7 Sep 2001 16:05:11 +0200 (CEST) Subject: pam_limits and OpenSSH In-Reply-To: <20010905173110.A12809@redhat.com> Message-ID: On Wed, 5 Sep 2001, Nalin Dahyabhai wrote: > Date: Wed, 5 Sep 2001 17:31:10 -0400 > From: Nalin Dahyabhai > To: Ognyan Kulev > Cc: openssh-unix-dev at mindrot.org > Subject: Re: pam_limits and OpenSSH > > On Wed, Sep 05, 2001 at 04:53:05PM +0300, Ognyan Kulev wrote: > > Perhaps the daemon first sets process limits and then switches to the > > user and/or fork(). But fork() cannot succeed because there is a > > process number limit to 40 that is applied to root. This is my > > hypothesis. I didn't look at sources. What you think about all this? > > Do you need more information? I use Debian GNU/Linux potato and OpenSSH > > 1.2.3-9.3. > > This is exactly the case. The process limit is set while the server > is still running as the superuser, so it can't fork() to start the > child (which would then do a setuid() to the user's ID). > > Opening the PAM session after performing the fork() and setuid() fixes > this for pam_limits, but breaks other modules which expect to be running > with superuser privileges when their pam_open_session() handlers are So what about opening PAM session after performing fork but before setuid() ? Would it be correct ? > called. This was the crux of the whole pam_open_session mess from a few > months ago -- my apologies for setting it in motion. > > Other process limits are going to have similar effects on sshd, and I > don't see a clean way to handle process limits within PAM in this case. > > Hope this cleared things up a bit, > > Nalin > Best regards, Wojtek From tim at multitalents.net Sat Sep 8 01:12:16 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 7 Sep 2001 08:12:16 -0700 (PDT) Subject: [PATCH]: Drop Cygwin workaround In-Reply-To: <20010830104348.F8703@cygbert.vinschen.de> Message-ID: On Thu, 30 Aug 2001, Corinna Vinschen wrote: > Hi, > > the Cygwin specific workaround to sleep a second in daemon() isn't > needed anymore. We can eliminate it from the OpenSSH sources. Is it not needed because of changes to the OpenSSH code or changes to Cygwin? > > Index: daemon.c > =================================================================== > RCS file: /cvs/openssh_cvs/openbsd-compat/daemon.c,v > retrieving revision 1.1 > diff -u -p -r1.1 daemon.c > --- daemon.c 2001/01/31 21:52:03 1.1 > +++ daemon.c 2001/08/30 08:41:39 > @@ -51,13 +51,6 @@ daemon(nochdir, noclose) > case 0: > break; > default: > -#ifdef HAVE_CYGWIN > - /* > - * This sleep avoids a race condition which kills the > - * child process if parent is started by a NT/W2K service. > - */ > - sleep(1); > -#endif > _exit(0); > } > > > Corinna > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vinschen at redhat.com Sat Sep 8 02:41:03 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 7 Sep 2001 18:41:03 +0200 Subject: [PATCH]: Drop Cygwin workaround In-Reply-To: ; from tim@multitalents.net on Fri, Sep 07, 2001 at 08:12:16AM -0700 References: <20010830104348.F8703@cygbert.vinschen.de> Message-ID: <20010907184103.G17245@cygbert.vinschen.de> On Fri, Sep 07, 2001 at 08:12:16AM -0700, Tim Rice wrote: > On Thu, 30 Aug 2001, Corinna Vinschen wrote: > > > Hi, > > > > the Cygwin specific workaround to sleep a second in daemon() isn't > > needed anymore. We can eliminate it from the OpenSSH sources. > > Is it not needed because of changes to the OpenSSH code or > changes to Cygwin? Changes to Cygwin. Corinna > > > > > Index: daemon.c > > =================================================================== > > RCS file: /cvs/openssh_cvs/openbsd-compat/daemon.c,v > > retrieving revision 1.1 > > diff -u -p -r1.1 daemon.c > > --- daemon.c 2001/01/31 21:52:03 1.1 > > +++ daemon.c 2001/08/30 08:41:39 > > @@ -51,13 +51,6 @@ daemon(nochdir, noclose) > > case 0: > > break; > > default: > > -#ifdef HAVE_CYGWIN > > - /* > > - * This sleep avoids a race condition which kills the > > - * child process if parent is started by a NT/W2K service. > > - */ > > - sleep(1); > > -#endif > > _exit(0); > > } > > > > > > Corinna > > > > > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From tim at multitalents.net Sat Sep 8 03:39:06 2001 From: tim at multitalents.net (Tim Rice) Date: Fri, 7 Sep 2001 10:39:06 -0700 (PDT) Subject: [PATCH]: Drop Cygwin workaround In-Reply-To: <20010907184103.G17245@cygbert.vinschen.de> Message-ID: On Fri, 7 Sep 2001, Corinna Vinschen wrote: > On Fri, Sep 07, 2001 at 08:12:16AM -0700, Tim Rice wrote: > > On Thu, 30 Aug 2001, Corinna Vinschen wrote: > > > > > Hi, > > > > > > the Cygwin specific workaround to sleep a second in daemon() isn't > > > needed anymore. We can eliminate it from the OpenSSH sources. > > > > Is it not needed because of changes to the OpenSSH code or > > changes to Cygwin? > > Changes to Cygwin. Then removing it would break on older versions of Cygwin. Unless you have a configure time test for Cygwin ver >= n.nn it doesn't seem worthwhile to remove the sleep(1). > > Corinna > > > > > > > > > Index: daemon.c > > > =================================================================== > > > RCS file: /cvs/openssh_cvs/openbsd-compat/daemon.c,v > > > retrieving revision 1.1 > > > diff -u -p -r1.1 daemon.c > > > --- daemon.c 2001/01/31 21:52:03 1.1 > > > +++ daemon.c 2001/08/30 08:41:39 > > > @@ -51,13 +51,6 @@ daemon(nochdir, noclose) > > > case 0: > > > break; > > > default: > > > -#ifdef HAVE_CYGWIN > > > - /* > > > - * This sleep avoids a race condition which kills the > > > - * child process if parent is started by a NT/W2K service. > > > - */ > > > - sleep(1); > > > -#endif > > > _exit(0); > > > } > > > > > > > > > Corinna > > > > > > > > > > -- > > Tim Rice Multitalents (707) 887-1469 > > tim at multitalents.net > > > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From stevesk at pobox.com Sat Sep 8 05:18:08 2001 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 7 Sep 2001 12:18:08 -0700 (PDT) Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010907154551.F17245@cygbert.vinschen.de> Message-ID: On Fri, 7 Sep 2001, Corinna Vinschen wrote: :Sorry for being pushy. Does nobody know what the reason for the :above difference could be? Why does 2.9p2 close the connection :all the time and 2.5.2p2 doesn't? And - even more important - :how can I workaround that with 2.9p2? i don't know what's wrong, something with local forwarding is different it seems. getting verbose output would be the next step. From stevesk at pobox.com Sat Sep 8 05:43:32 2001 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 7 Sep 2001 12:43:32 -0700 (PDT) Subject: bug in scp (OpenSSH) In-Reply-To: Message-ID: On Fri, 7 Sep 2001 mouring at etoh.eviladmin.org wrote: :I would support the 'scp -o port user at site:/path -o port :user at site2:/path' patch. However, not all scp's are created equal and :this 'feature' will not work on the old SSH Corp 1.2.x scp due to lack of :-o concept. Same goes true for older OpenSSH releases. valid point, i forgot that scp -o has not always been supported. since you can build the command youself to do third party transfers, i don't see much need to spend effort on this. :Changing the default to scp to quiet.. I may consider support, but I still :see no use for such a patch because one should be checking the $? not the :stdout. since most scp's i do are interactive, i don't have a problem with it being default, but i don't really care. if you're using batch scp, just specify -q. From jdamery at chiark.greenend.org.uk Sat Sep 8 06:23:34 2001 From: jdamery at chiark.greenend.org.uk (Jonathan D. Amery) Date: Fri, 7 Sep 2001 21:23:34 +0100 (BST) Subject: Suggestion Message-ID: Since it's not really possible to make it quit in this circumstance perhaps a message like the X11 forwardin one would be useful? "Waiting for forwarded connections to terminate... (press ~& to background)" So perhaps: "Waiting for backgrounded processes to terminate... (press ~& to background)" Jonathan. From dwd at bell-labs.com Sat Sep 8 07:09:23 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Fri, 7 Sep 2001 16:09:23 -0500 Subject: bug in scp (OpenSSH) In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Sep 07, 2001 at 08:07:07AM -0500 References: Message-ID: <20010907160922.A5878@lucent.com> On Fri, Sep 07, 2001 at 08:07:07AM -0500, mouring at etoh.eviladmin.org wrote: ... > Changing the default to scp to quiet.. I may consider support, but I still > see no use for such a patch because one should be checking the $? not the > stdout. I have scripts that do scp's behind the scenes, and having that extra output confuses users of the scripts. I had installed ssh 1.2.XX before that option was added, and when it was added as a default option I was not pleased. Fortunately, at least a configure option was added at the same time to disable it so I just changed my build scripts to do that. Now I'm transitioning my users to openssh, and I am reluctant to keep too many private patches so I have been thinking I would subject them to this but I'd really rather not. > As I've said before.. Take my views with a grain of salt because they > don't always match with Markus or others in the group. I would like to see what Markus has to say about it, because this is in his base code. I don't know how compile-time options are set for the base code though, since it doesn't use configure; as far as I know there aren't any. > I will say this.. Arguing over stuff without a patch to the code will not > gain ground in your position. So far I've seen more arguing then code. If > you want something fixed or changed.. WRITE THE CODE AND SUBMIT IT. At > least there will be a TECHNICAL reason for why things are declined. I'd be happy to submit a patch if I thought it might be accepted. - Dave Dykstra From nalin at redhat.com Sat Sep 8 07:21:10 2001 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 7 Sep 2001 17:21:10 -0400 Subject: pam_limits and OpenSSH In-Reply-To: ; from wpilorz@bdk.pl on Fri, Sep 07, 2001 at 04:05:11PM +0200 References: <20010905173110.A12809@redhat.com> Message-ID: <20010907172110.A2868@redhat.com> On Fri, Sep 07, 2001 at 04:05:11PM +0200, Wojtek Pilorz wrote: > > From: Nalin Dahyabhai > > Opening the PAM session after performing the fork() and setuid() fixes > > this for pam_limits, but breaks other modules which expect to be running > > with superuser privileges when their pam_open_session() handlers are > > So what about opening PAM session after performing fork but before > setuid() ? Would it be correct ? It's been a while since I looked at what's going on in that area of the tree, but IIRC the child exec()s the user's shell, and opening the session in the child makes it difficult for the parent to close the session when the user logs out. This depends on which modules are in use, though -- some modules handle this sort of situation just fine, while others will just fail. Nalin From wendyp at cray.com Sat Sep 8 07:45:07 2001 From: wendyp at cray.com (Wendy Palm) Date: Fri, 07 Sep 2001 16:45:07 -0500 Subject: bug in scp (OpenSSH) References: <20010907160922.A5878@lucent.com> Message-ID: <3B993FE3.AC61D424@cray.com> Dave Dykstra wrote: > > On Fri, Sep 07, 2001 at 08:07:07AM -0500, mouring at etoh.eviladmin.org wrote: > ... > > Changing the default to scp to quiet.. I may consider support, but I still > > see no use for such a patch because one should be checking the $? not the > > stdout. > > I have scripts that do scp's behind the scenes, and having that extra > output confuses users of the scripts. I had installed ssh 1.2.XX before > that option was added, and when it was added as a default option I was not > pleased. Fortunately, at least a configure option was added at the same > time to disable it so I just changed my build scripts to do that. Now I'm > transitioning my users to openssh, and I am reluctant to keep too many > private patches so I have been thinking I would subject them to this but > I'd really rather not. i agree and for the same reason. my of our customer sites have scripts with rcp/scp in them, and we're in the process of trying to get them to use secure transfers in the first place, so adding extraneous output to the default case is not my preference. i'd prefer the default to be quiet & an option to enable it. -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From blues at ds6.pg.gda.pl Sun Sep 9 09:56:16 2001 From: blues at ds6.pg.gda.pl (Blues) Date: Sun, 9 Sep 2001 01:56:16 +0200 (CEST) Subject: force SSH1 and SSH2 Message-ID: This is small patch for scp. It allows to force SSH1 or SSH2. P.S.: give me Cc: - I'm not subscribed... -- --------------------------------- pozdr. Pawe? Go?aszewski --------------------------------- R.I.P. - rest in pieces ... -------------- next part -------------- --- ./scp.c.org Sat Sep 8 23:37:22 2001 +++ ./scp.c Sun Sep 9 00:07:36 2001 @@ -244,9 +244,11 @@ addargs("-oFallBackToRsh no"); fflag = tflag = 0; - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:")) != -1) + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q1246S:o:")) != -1) switch (ch) { /* User-visible flags. */ + case '1': + case '2': case '4': case '6': case 'C': @@ -958,7 +960,7 @@ usage() { (void) fprintf(stderr, "usage: scp " - "[-pqrvBC46] [-S ssh] [-P port] [-c cipher] [-i identity] f1 f2\n" + "[-pqrvBC1246] [-S ssh] [-P port] [-c cipher] [-i identity] f1 f2\n" " or: scp [options] f1 ... fn directory\n"); exit(1); } --- ./scp.1.org Sun Sep 9 00:03:53 2001 +++ ./scp.1 Sun Sep 9 00:05:56 2001 @@ -19,7 +19,7 @@ .Nd secure copy (remote file copy program) .Sh SYNOPSIS .Nm scp -.Op Fl pqrvC46 +.Op Fl pqrvC1246 .Op Fl S Ar program .Op Fl P Ar port .Op Fl c Ar cipher @@ -110,6 +110,14 @@ .It Fl o Ar option The given option is directly passed to .Xr ssh 1 . +.It Fl 1 +Forces +.Nm +to use SSH1 only. +.It Fl 2 +Forces +.Nm +to use SSH2 only. .It Fl 4 Forces .Nm From J.S.Peatfield at damtp.cam.ac.uk Sun Sep 9 14:12:44 2001 From: J.S.Peatfield at damtp.cam.ac.uk (J.S.Peatfield at damtp.cam.ac.uk) Date: Sun, 09 Sep 2001 05:12:44 +0100 Subject: force SSH1 and SSH2 Message-ID: <200109090412.FAA15623.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> Does't scp -o 'protocol 1' ... or -o 'protocol 2' do what you need? From pekkas at netcore.fi Sun Sep 9 16:41:32 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 9 Sep 2001 09:41:32 +0300 (EEST) Subject: force SSH1 and SSH2 In-Reply-To: <200109090412.FAA15623.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> Message-ID: On Sun, 9 Sep 2001 J.S.Peatfield at damtp.cam.ac.uk wrote: > Does't scp -o 'protocol 1' ... or -o 'protocol 2' do what you need? Yes; the feature '-1' '-2' was removed from scp some time ago and I doubt it's coming back. -- 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 jdamery at chiark.greenend.org.uk Mon Sep 10 09:23:32 2001 From: jdamery at chiark.greenend.org.uk (Jonathan D. Amery) Date: Mon, 10 Sep 2001 00:23:32 +0100 (BST) Subject: scp bug with 0x0a in filename: Message-ID: This bug (Debian bug number 111692) occurs with filenames that have the character 0x0a in them (newline). This is how one repeats it: ming.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:15:50] $ : bash[592] ; cat > 'x x' This is a test. ming.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:17] $ : bash[593] ; scp 'x x' dorothee:ssh-test/ x x 0% | | 0 --:-- ETA x 100% |*****************************| 16 00:00 lost connection ming.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:39] $ : bash[594] ; dorothee.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:48] $ : bash[504] ; ls x dorothee.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:50] $ : bash[505] ; cat x x This is a testdorothee.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:52] $ : bash[506] ; If you notice the additional characters from the end of the filename ('x') have been appended to the front of the file, and the file has been named to the first part of the file name. -- Jonathan Amery. Now there's a light at the end of the tunnel, ##### Someone's lit a campfire in my cave. #######__o The first rays of dawn are breaking through the clouds, #######'/ And somehow I know I can be brave. - Steve Kitson From djm at mindrot.org Mon Sep 10 10:41:02 2001 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Sep 2001 10:41:02 +1000 (EST) Subject: bug in scp (OpenSSH) In-Reply-To: Message-ID: On Fri, 7 Sep 2001, Jason Stone wrote: > Yes, but rcp doesn't take a "-q", so if I have my scripts call $RCP -q and > $RCP is set to rcp, it doesn't go. > > This is the first response that I've seen from one of the > maintainers/developers on this matter, and it still doesn't address the > issue - are you going to consider taking out the progress bar or at least > making it default to off? And if you aren't going to take it out, are you > going to consider putting in any of the other good patches to scp that > have been posted? scp only displays the progress meter is stderr is a tty. How does this cause problems? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From maillist at framedealer.com Mon Sep 10 17:25:24 2001 From: maillist at framedealer.com (fine art service) Date: Mon, 10 Sep 2001 00:25:24 -0700 Subject: New Frames Message-ID: <000701c139c9$c1ba3420$0610c0d8@richhaines.qwest.net> Check Out FrameDealer.com Wholesale frames for the professional artist !!!!!!!! www.framedealer.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010910/124a883d/attachment.html From matthew at debian.org Mon Sep 10 21:33:18 2001 From: matthew at debian.org (Matthew Vernon) Date: 10 Sep 2001 12:33:18 +0100 Subject: scp doesn't work with large (>2GB) files Message-ID: <5bwv37th4x.fsf@chiark.greenend.org.uk> Hi, A bug I've had reported is that scp doesn't work with large files (Debian bug number 106809). The problem seems to be scp.c:504: if ((fd = open(name, O_RDONLY, 0)) < 0) Is there some reason why making that if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) would break things? It seems a simple fix to me... Thanks, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From vinschen at redhat.com Mon Sep 10 23:51:50 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 10 Sep 2001 15:51:50 +0200 Subject: scp doesn't work with large (>2GB) files In-Reply-To: <5bwv37th4x.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Mon, Sep 10, 2001 at 12:33:18PM +0100 References: <5bwv37th4x.fsf@chiark.greenend.org.uk> Message-ID: <20010910155150.Q937@cygbert.vinschen.de> On Mon, Sep 10, 2001 at 12:33:18PM +0100, Matthew Vernon wrote: > Hi, > > A bug I've had reported is that scp doesn't work with large files > (Debian bug number 106809). The problem seems to be scp.c:504: > > if ((fd = open(name, O_RDONLY, 0)) < 0) > > Is there some reason why making that > if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) #ifdef O_LARGEFILE if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) #endif would perhaps fit better. E.g. Cygwin has no O_LARGEFILE. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From bowman at math.ualberta.ca Tue Sep 11 04:14:44 2001 From: bowman at math.ualberta.ca (John Bowman) Date: 10 Sep 2001 18:14:44 -0000 Subject: sshd hangs on logout -- is this a bug? Message-ID: <20010910181444.17597.qmail@wizard.math.ualberta.ca> >In the changelog, there is an entry: > >20001129 > - (djm) Back out all the serverloop.c hacks. sshd will now hang again > if there are background children with open fds. > > Does this mean that this is regarded as expected (and correct) behavior, that > should not change in the future, or does it mean that this behavior is a > known problem that someone will eventually fix? Yes, this is a known bug with openssh-2.9p2 under Linux (and some other operating systems). This behaviour deviates from the programs rsh and ssh that openssh purportedly replaces. This problem has been fixed with a patch that was posted to this list several months ago. Unlike the original serverloop hacks mentioned above, under Linux the patch does not break ssh or scp or lead to data loss. Note: A minor update to the patch was made 29Aug01 so that it works correctly with the -T option. I attach the latest version below. For more information, see http://www.math.ualberta.ca/imaging/snfs/ -- John Bowman University of Alberta diff -ur openssh-2.9p2/channels.c openssh-2.9p2J2/channels.c --- openssh-2.9p2/channels.c Wed Jun 13 13:18:05 2001 +++ openssh-2.9p2J2/channels.c Wed Aug 29 15:04:44 2001 @@ -1137,6 +1137,15 @@ continue; if (ftab[c->type] == NULL) continue; + 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); if (chan_is_dead(c)) { /* diff -ur openssh-2.9p2/clientloop.c openssh-2.9p2J2/clientloop.c --- openssh-2.9p2/clientloop.c Fri Apr 20 06:50:51 2001 +++ openssh-2.9p2J2/clientloop.c Wed Aug 29 14:58:14 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; @@ -121,8 +122,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. */ void client_init_dispatch(void); int session_ident = -1; @@ -324,6 +325,10 @@ client_wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, int rekeying) { + struct timeval timer; + struct timeval *timerp; + int rc; + /* Add any selections by the channel mechanism. */ channel_prepare_select(readsetp, writesetp, maxfdp, rekeying); @@ -346,7 +351,14 @@ if (buffer_len(&stderr_buffer) > 0) FD_SET(fileno(stderr), *writesetp); } else { - FD_SET(connection_in, *readsetp); + /* channel_prepare_select could have closed the last channel */ + if ((session_status == SessionClose) + && !channel_still_open()) { + if (!packet_have_data_to_write()) + return; + } else { + FD_SET(connection_in, *readsetp); + } } /* Select server connection if have data to write to the server. */ @@ -362,7 +374,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]; /* @@ -379,7 +401,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; } void @@ -440,9 +463,13 @@ len = read(connection_in, buf, sizeof(buf)); if (len == 0) { /* Received EOF. The remote host has closed the connection. */ - snprintf(buf, sizeof buf, "Connection to %.300s closed by remote host.\r\n", - host); - buffer_append(&stderr_buffer, buf, strlen(buf)); +/* + * This message duplicates the one already in client_loop(). + * + * snprintf(buf, sizeof buf, "Connection to %.300s closed by remote host.\r\n", + * host); + * buffer_append(&stderr_buffer, buf, strlen(buf)); + */ quit_pending = 1; return; } @@ -751,7 +778,7 @@ if (id != session_ident) error("client_channel_closed: id %d != session_ident %d", id, session_ident); - session_closed = 1; + session_status = (options.sleep >= 0) ? SessionWait : SessionClose; if (in_raw_mode()) leave_raw_mode(); } @@ -776,6 +803,7 @@ start_time = get_current_time(); /* Initialize variables. */ + if(!have_pty) session_status=SessionWait; escape_pending = 0; last_was_cr = 1; exit_status = -1; @@ -840,7 +868,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-2.9p2/nchan.c openssh-2.9p2J2/nchan.c --- openssh-2.9p2/nchan.c Tue Apr 3 07:02:48 2001 +++ openssh-2.9p2J2/nchan.c Tue Jun 19 03:27:30 2001 @@ -56,7 +56,7 @@ /* helper */ static void chan_shutdown_write(Channel *c); -static void chan_shutdown_read(Channel *c); +void chan_shutdown_read(Channel *c); /* * SSH1 specific implementation of event functions @@ -479,7 +479,7 @@ c->wfd = -1; } } -static void +void chan_shutdown_read(Channel *c) { if (compat20 && c->type == SSH_CHANNEL_LARVAL) diff -ur openssh-2.9p2/nchan.h openssh-2.9p2J2/nchan.h --- openssh-2.9p2/nchan.h Sun Mar 4 23:16:12 2001 +++ openssh-2.9p2J2/nchan.h Tue Jun 19 03:27:30 2001 @@ -88,4 +88,5 @@ void chan_init_iostates(Channel * c); void chan_init(void); +void chan_shutdown_read(Channel *c); #endif diff -ur openssh-2.9p2/readconf.c openssh-2.9p2J2/readconf.c --- openssh-2.9p2/readconf.c Tue Apr 17 12:11:37 2001 +++ openssh-2.9p2J2/readconf.c Tue Jun 19 03:27:30 2001 @@ -111,7 +111,7 @@ oGlobalKnownHostsFile2, oUserKnownHostsFile2, oPubkeyAuthentication, oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, - oHostKeyAlgorithms + oHostKeyAlgorithms, oSleep } OpCodes; /* Textual representations of the tokens. */ @@ -177,6 +177,7 @@ { "dynamicforward", oDynamicForward }, { "preferredauthentications", oPreferredAuthentications }, { "hostkeyalgorithms", oHostKeyAlgorithms }, + { "sleep", oSleep }, { NULL, 0 } }; @@ -494,6 +495,10 @@ intptr = &options->connection_attempts; goto parse_int; + case oSleep: + intptr = &options->sleep; + goto parse_int; + case oCipher: intptr = &options->cipher; arg = strdelim(&s); @@ -761,6 +766,7 @@ options->num_remote_forwards = 0; options->log_level = (LogLevel) - 1; options->preferred_authentications = NULL; + options->sleep = -1; } /* diff -ur openssh-2.9p2/readconf.h openssh-2.9p2J2/readconf.h --- openssh-2.9p2/readconf.h Tue Apr 17 12:11:37 2001 +++ openssh-2.9p2J2/readconf.h Tue Jun 19 03:27:30 2001 @@ -97,6 +97,7 @@ /* Remote TCP/IP forward requests. */ int num_remote_forwards; Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION]; + int sleep; /* Exit delay in seconds */ } Options; diff -ur openssh-2.9p2/session.c openssh-2.9p2J2/session.c --- openssh-2.9p2/session.c Sat Jun 16 21:40:51 2001 +++ openssh-2.9p2J2/session.c Tue Jun 19 03:27:30 2001 @@ -1928,6 +1928,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-2.9p2/ssh.c openssh-2.9p2J2/ssh.c --- openssh-2.9p2/ssh.c Tue Apr 17 12:14:35 2001 +++ openssh-2.9p2J2/ssh.c Wed Aug 29 14:56:31 2001 @@ -182,6 +182,7 @@ fprintf(stderr, " -R listen-port:host:port Forward remote port to local address\n"); 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, " -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"); @@ -318,7 +319,7 @@ opt = av[optind][1]; if (!opt) usage(); - if (strchr("eilcmpLRDo", opt)) { /* options with arguments */ + if (strchr("eilcmpLRSDo", opt)) { /* options with arguments */ optarg = av[optind] + 2; if (strcmp(optarg, "") == 0) { if (optind >= ac - 1) @@ -488,7 +489,13 @@ } add_local_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) { From dbt at meat.net Tue Sep 11 04:38:29 2001 From: dbt at meat.net (David Terrell) Date: Mon, 10 Sep 2001 11:38:29 -0700 Subject: bug in scp (OpenSSH) In-Reply-To: ; from jason@shalott.net on Fri, Sep 07, 2001 at 03:45:16AM -0700 References: Message-ID: <20010910113829.A14510@pianosa.catch22.org> On Fri, Sep 07, 2001 at 03:45:16AM -0700, Jason Stone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > If you as a sysadmin want your naive users to see the progress bar, you > > > can alias scp to "scp -l" (or whatever the option would be) in the default > > > shell prefs, just as many admins alias rm to "rm -i" > > > > > > > "If the person does not want to see it they can always alias scp to 'scp > > -q'.." > > Yes, but rcp doesn't take a "-q", so if I have my scripts call $RCP -q and > $RCP is set to rcp, it doesn't go. Then set $RCP to scp -q You're making this more complicated than it needs to be. -- David Terrell | "the only part about medicinal marijuana that Prime Minister, Nebcorp | bothers me is that, when I started chemo, all of dbt at meat.net | my children and grandchildren told me they could http://wwn.nebcorp.com/ | get some for me if I needed it." -mrw's grandfather From thomas at xs4all.net Tue Sep 11 06:58:20 2001 From: thomas at xs4all.net (Thomas Wouters) Date: Mon, 10 Sep 2001 22:58:20 +0200 Subject: [PATCH] quick hack for 'resume' support in sftp Message-ID: <20010910225820.C22331@xs4all.nl> I saw several questions regarding 'resume transfer' support in sftp come up, in the archives, but no real satisfying answer. I had a particular itch myself, so I scratched it with a quick hack. Patch attached, since it's not really big. To explain, I need to use ssh (scp or sftp) to transfer files to and from a Windows box. No other method is available. And the Windows machine has no rsync or unixlike tools or cygwin or anything else I can use to fake resuming transfers, so I really have to have the resume support in sftp itself. I noticed the protocol supported it just fine, so I did a little dirty hacking and added a '-r' option to sftp that enables resuming. It's very rough: it triggers off (local) name alone, though it refuses to append to a file that's already larger than the new file. It cuts a bit off the end of the local file before resuming, but that's mostly out of paranoia. It should really compare a couple of blocks of the end of the local file with the remote file, but I didn't want to bother with that. It should really present a choice when it discovers a possibly partial local file with the same name, the way NcFTP does, but, again, I didn't want to bother with that. (And, frankly, the rest of sftp could do with a little more NcFTP or (Net)BSD FTP interface sprinkled in ;) But one thing at a time.) If there's any interest in getting this in the distributed sftp (in a more mature form, of course) I can get it in better shape, but I'm honestly clueless on the direction of ssh and sftp development. If this kind of thing is really not wanted, I guess I'll keep a patch somewhere on a website instead. I'd like to note, though, that in searching for an sftp version with resume support I found a number of Windows clients that claimed to support resuming in their sftp clients :-) Regards, Thomas. PS: Please include me in any responses, I'm not on the list right now. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- diff -cr openssh-2.9p2/sftp-client.c openssh-2.9p2.resume/sftp-client.c *** openssh-2.9p2/sftp-client.c Fri Apr 6 01:26:33 2001 --- openssh-2.9p2.resume/sftp-client.c Mon Sep 10 18:04:36 2001 *************** *** 48,53 **** --- 48,56 ---- /* XXX: what should this be? */ #define COPY_SIZE 8192 + /* resume or not (from sftp.c) */ + extern int enable_resume; + /* Message ID */ static u_int msg_id = 1; *************** *** 682,687 **** --- 685,691 ---- Buffer msg; Attrib junk, *a; int status; + struct stat localfile; a = do_stat(fd_in, fd_out, remote_path, 0); if (a == NULL) *************** *** 698,705 **** error("Cannot download a directory: %s", remote_path); return(-1); } ! ! local_fd = open(local_path, O_WRONLY | O_CREAT | O_TRUNC, mode); if (local_fd == -1) { error("Couldn't open local file \"%s\" for writing: %s", local_path, strerror(errno)); --- 702,720 ---- error("Cannot download a directory: %s", remote_path); return(-1); } ! ! if (enable_resume && (stat(local_path, &localfile) == 0) && ! S_ISREG(localfile.st_mode) && (localfile.st_size < a->size)) { ! local_fd = open(local_path, O_WRONLY, mode); ! offset = localfile.st_size - (localfile.st_size % 16384); ! if (local_fd != -1) { ! ftruncate(local_fd, offset); ! lseek(local_fd, 0, SEEK_END); ! } ! } else { ! local_fd = open(local_path, O_WRONLY | O_CREAT | O_TRUNC, mode); ! offset = 0; ! } if (local_fd == -1) { error("Couldn't open local file \"%s\" for writing: %s", local_path, strerror(errno)); *************** *** 727,733 **** } /* Read from remote and write to local */ - offset = 0; for(;;) { u_int len; char *data; --- 742,747 ---- diff -cr openssh-2.9p2/sftp.1 openssh-2.9p2.resume/sftp.1 *** openssh-2.9p2/sftp.1 Sun Apr 22 19:17:46 2001 --- openssh-2.9p2.resume/sftp.1 Mon Sep 10 18:07:56 2001 *************** *** 82,87 **** --- 82,89 ---- .Xr ssh 1 . .It Fl v Raise logging level. This option is also passed to ssh. + .It Fl r + Enable resuming of downloads. This might not work correctly. .El .Sh INTERACTIVE COMMANDS Once in interactive mode, diff -cr openssh-2.9p2/sftp.c openssh-2.9p2.resume/sftp.c *** openssh-2.9p2/sftp.c Mon Apr 16 10:26:42 2001 --- openssh-2.9p2.resume/sftp.c Mon Sep 10 17:52:39 2001 *************** *** 48,53 **** --- 48,54 ---- #include "scp-common.h" int use_ssh1 = 0; + int enable_resume = 0; char *ssh_program = _PATH_SSH_PROGRAM; char *sftp_server = NULL; FILE* infile; *************** *** 148,154 **** void usage(void) { ! fprintf(stderr, "usage: sftp [-1vC] [-b batchfile] [-osshopt=value] [user@]host[:file [file]]\n"); exit(1); } --- 149,155 ---- void usage(void) { ! fprintf(stderr, "usage: sftp [-1vCr] [-b batchfile] [-osshopt=value] [user@]host[:file [file]]\n"); exit(1); } *************** *** 167,173 **** infile = stdin; /* Read from STDIN unless changed by -b */ debug_level = compress_flag = 0; ! while ((ch = getopt(argc, argv, "1hvCo:s:S:b:")) != -1) { switch (ch) { case 'C': compress_flag = 1; --- 168,174 ---- infile = stdin; /* Read from STDIN unless changed by -b */ debug_level = compress_flag = 0; ! while ((ch = getopt(argc, argv, "1hvCro:s:S:b:")) != -1) { switch (ch) { case 'C': compress_flag = 1; *************** *** 197,202 **** --- 198,206 ---- fatal("%s (%s).", strerror(errno), optarg); } else fatal("Filename already specified."); + break; + case 'r': + enable_resume = 1; break; case 'h': default: From dwd at bell-labs.com Tue Sep 11 07:08:04 2001 From: dwd at bell-labs.com (Dave Dykstra) Date: Mon, 10 Sep 2001 16:08:04 -0500 Subject: bug in scp (OpenSSH) In-Reply-To: ; from djm@mindrot.org on Mon, Sep 10, 2001 at 10:41:02AM +1000 References: Message-ID: <20010910160804.A12231@lucent.com> On Mon, Sep 10, 2001 at 10:41:02AM +1000, Damien Miller wrote: > On Fri, 7 Sep 2001, Jason Stone wrote: > > > Yes, but rcp doesn't take a "-q", so if I have my scripts call $RCP -q and > > $RCP is set to rcp, it doesn't go. > > > > This is the first response that I've seen from one of the > > maintainers/developers on this matter, and it still doesn't address the > > issue - are you going to consider taking out the progress bar or at least > > making it default to off? And if you aren't going to take it out, are you > > going to consider putting in any of the other good patches to scp that > > have been posted? > > scp only displays the progress meter is stderr is a tty. How does this > cause problems? These are interactive scripts, where just some of the things they do use scp. The users of the scripts don't even realize an scp is happening, so they certainly don't expect that output. You could argue that the scripts should just use 'scp -q' or redirect stderr somewhere, but some of these scripts were written for the old ssh before the statistics were added (and when they did add it I chose the configure option to turn it off), and I don't own all the scripts; I maintain ssh, and the fewer incompatibilities with the old ssh, the easier it will be for me to upgrade everybody to OpenSSH. - Dave Dykstra From kitty at cs.wustl.edu Tue Sep 11 09:32:25 2001 From: kitty at cs.wustl.edu (Krishnakumar B) Date: Mon, 10 Sep 2001 18:32:25 -0500 Subject: Help with exporting keys Message-ID: <15261.19849.396479.542473@samba.doc.wustl.edu> Hi, In our department's setup we have a unfortunate situation where we have to use both OpenSSH and SSH (ssh.com's version). I have managed to export keys from OpenSSH to SSH's format. I also managed to export SSH's public key to OpenSSH's format. Now I would like to add the private key of SSH to the agent. Now when I try to add it simply by using ssh-add ~/.ssh2/id_dsa_1024_a I get a bad passphrase error. I thought that this was because OpenSSH couldn't grok the private key generated by SSH. When I tried exporting SSH's private key as follows: With SSH version 2.0.12 and OpenSSH_2.9p2 ----------------------------------------- samba> ssh-keygen -i -f ~/.ssh2/id_dsa_1024_a uudecode failed. With SSH version 2.4.0 and OpenSSH_2.9p2 ---------------------------------------- samba> ssh-keygen -i -f ~/.ssh2/id_dsa_1024_b unsupported cipher 3des-cbc decode blob failed. Anybody know why this export is failing ? Any workarounds for this ? I am generating the SSH keys on Solaris and Tru64. I am trying the export with OpenSSH on Linux/i686. -kitty. -- Krishnakumar B Distributed Object Computing Laboratory, Washington University in St.Louis From markus at openbsd.org Wed Sep 12 18:32:26 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 10:32:26 +0200 Subject: bug in scp (OpenSSH) In-Reply-To: <20010904184014.A24477@turtle.tat.physik.uni-tuebingen.de>; from koenig@tat.physik.uni-tuebingen.de on Tue, Sep 04, 2001 at 06:40:14PM +0200 References: <20010830131519.A13380@faui02.informatik.uni-erlangen.de> <20010831131846.A1399@folly> <20010904184014.A24477@turtle.tat.physik.uni-tuebingen.de> Message-ID: <20010912103226.B9578@folly> On Tue, Sep 04, 2001 at 06:40:14PM +0200, Harald Koenig wrote: > On Aug 31, Markus Friedl wrote: > > > On Fri, Aug 31, 2001 at 12:20:23PM +0200, Roman Drahtmueller wrote: > > > Are you serious that you want to keep a bug because "this is how the rcp > > > protocol works"? It is clearly flawed. > > > > should we really change the semantics of a 17 year old protocol, > > if you can use sftp, rsync or tar instead? > > if behaviour is broken and it's not explicitly designed to be broken > that way: yes. (and it _is_ broken). > > I tried "rcp" too and indeed, it does copy binary trash too. > fortuneately, at least with my ~8 kbytes source file, no > passwd entries show up in rcp buffers but only parts of > /etc/services. but who knows what might show up for longer source > files ?! > > > > however, you can try to modify sink() to truncate the ofd if > > response() returns an error. so the data will be sent but > > discarded. i'm not sure whether i like the idea. it might > > break other things. > > your 2nd patch below doesn't make any difference. > destination file still gets filled with null bytes. you did update scp on both sides? From markus at openbsd.org Wed Sep 12 20:27:57 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 12:27:57 +0200 Subject: scp1 issue In-Reply-To: ; from khaled@w-arts.com on Mon, Aug 27, 2001 at 03:50:01PM +0200 References: Message-ID: <20010912122757.A12133@folly> scp is just rcp over ssh, so it's not very different from ssh host cat file On Mon, Aug 27, 2001 at 03:50:01PM +0200, Khaled Daham wrote: > Hi. > > I hope this is not entirely inappropriate, I have tried > comp.security.ssh but have not received any response, anyhow > I am wondering how scp1 really works, as far as I can tell it should be > quite straight forward, just send > > version string > CMSG_SESSION_KEY > CMSG_USER > CMSG_AUTH_PASSWORD > CMSG_EXEC_CMD > > And wait for SMSG_STDOUT_DATA until SMSG_EXITSTATUS. > I have read the scp.c code and and it more or less just starts > ssh with the command "scp -f file-to-get", however when I do that in a > little client i made it just hangs after sshd does its > server_init_dispatch() > > debug1: session_new: init > debug1: session_new: session 0 > debug1: Exec command 'scp -f .profile' > debug1: PAM establishing creds > debug1: Entering interactive session. > debug1: fd 7 setting O_NONBLOCK > debug1: fd 7 IS O_NONBLOCK > debug1: fd 9 setting O_NONBLOCK > debug1: server_init_dispatch_13 > debug1: server_init_dispatch_15 > > --- This is with my client and here it stops, additional lines below is > with scp that comes with OpenSSH --- > > debug1: tvp!=NULL kid 0 mili 10 > debug1: Received SIGCHLD. > debug1: tvp!=NULL kid 1 mili 100 > debug1: End of interactive session; stdin 3, stdout (read 2710, sent 2710), > stderr 338 bytes. > debug1: Command exited with status 0. > debug1: Received exit confirmation. > Closing connection to 127.0.0.1 > > Now any other command works, like if i do cat/ls or anything i get data > back in STDOUT_DATA packets, so I am wondering if scp executed on the > remote side is waiting for something, but I can not figure out what, no > channels or anything is invoked as far as I can see in the OpenSSH code. > > Any suggestions ? > > /Khaled Daham, w.arts > Mail: khaled at w-arts.com > Cell: +46-70-6785492 > FreeBSD: The Power to Serve! http://www.FreeBSD.org/ > > > From markus at openbsd.org Wed Sep 12 20:29:15 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 12:29:15 +0200 Subject: permitopen flag in authorized_keys file In-Reply-To: ; from Florian.Weimer@RUS.Uni-Stuttgart.DE on Mon, Aug 27, 2001 at 08:35:18PM +0200 References: Message-ID: <20010912122915.B12133@folly> On Mon, Aug 27, 2001 at 08:35:18PM +0200, Florian Weimer wrote: > I've just discovered the permitopen flag. We need such a feature for > our poor man's VPN services, but this flag seems to be usable only if > you generate your authorized_keys file from a database or something > like that: keeping a long list of host/port combinations up to date > for several users and keys is no fun. > > As announced before, we have developed a far more powerful mechanism > for controlling port forwarding, see: > > http://cert.uni-stuttgart.de/projects/openssh.php > > (I'm currenty porting it to the most recent portable OpenSSH version.) > > Why haven't you used this already existing code? already existing code was used. From markus at openbsd.org Wed Sep 12 20:32:35 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 12:32:35 +0200 Subject: openssh and multiple ports In-Reply-To: <54763718.999609127@athyra>; from carson@taltos.org on Tue, Sep 04, 2001 at 01:12:07PM -0700 References: <3C1E3607B37295439F7C409EFBA08E680E2680@col-581-exs01.cist.saic. <3C1E3607B37295439F7C409EFBA08E680E2680@col-581-exs01.cist.saic.com> <54763718.999609127@athyra> Message-ID: <20010912123235.C12133@folly> On Tue, Sep 04, 2001 at 01:12:07PM -0700, Carson Gaspar wrote: > > > --On Tuesday, September 04, 2001 3:09 PM -0400 "Loomis, Rip" > wrote: > > > Having said that, I don't see that the -p port option is > > so onerous as to make it worth implementing the #port > > method. > > It wouldn't be so bad is ssh and scp used the _same_ option for an > alternate port, but they don't. inherited from rcp. From markus at openbsd.org Wed Sep 12 20:37:47 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 12:37:47 +0200 Subject: sshd hangs on logout -- is this a bug? In-Reply-To: ; from sturle.sunde@usit.uio.no on Fri, Sep 07, 2001 at 01:16:43AM +0200 References: <20010905165751.A2447@flounder.net> <20010906110026.T5739@sm2p1386swk.wdr.com> Message-ID: <20010912123747.D12133@folly> On Fri, Sep 07, 2001 at 01:16:43AM +0200, Sturle Sunde wrote: > [Quoting reformatted for readability] > > Nicolas Williams writes: > > On Wed, Sep 05, 2001 at 04:57:51PM -0700, Adam McKenna wrote: > >> In the changelog, there is an entry: > >> > >> 20001129 > >> - (djm) Back out all the serverloop.c hacks. sshd will now hang again > >> if there are background children with open fds. > >> > >> Does this mean that this is regarded as expected (and correct) > >> behavior, that should not change in the future, or does it mean > >> that this behavior is a known problem that someone will eventually > >> fix? > > > > This is normal behaviour for RSH and is natural behaviour anyways. > > Not if you enter an interactive session (and rsh become rlogin). > > If I rsh to a machine, exec bash, sleep 100 & and logout, I get > disconnected immediately. If I ssh to a machine running OpenSSH 2.9p2 > and do the same, I don't get disconnected until the sleep is finished. > SSH.com sshd disconnects immediately in all cases when the shell exits > (like rlogind, not rshd). This difference in behaviour is very > annoying, and I hoped it would be fixed in the next version. i think it's not a bug. sshd does not discard the data from the backgrounded process. if the backgrounded process want's ssh to exit than it should close the fd. however, i don't see these so called problems on *BSD systems, so perhaps some tty handling on linux/solaris is different (broken?) with regard to close/eof. who's looking into this? please not that recent ssh-1.2.x versions are working just like openssh, i.e. they do what people call 'hang' if the fd's are still used. (and this is IMHO the right way). -m From markus at openbsd.org Wed Sep 12 20:42:54 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 12:42:54 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010904212559.F15127@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Sep 04, 2001 at 09:25:59PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> Message-ID: <20010912124254.E12133@folly> the previous -N implementation was broken. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.c.diff?r1=1.105&r2=1.106 On Tue, Sep 04, 2001 at 09:25:59PM +0200, Corinna Vinschen wrote: > This has run reliable with 2.5.2 over the last months. Now, after > I have upgraded to 2.9p2, the tunnel is closed right after each > attempt of an application to use the tunnel which is a cron job > running each 5 minutes. So, now the tunnel is closed and restarted > each 5 minutes :-( i cannot reproduce this. the previous behaviour was to close the connection after the last connection to the localhost port has been closed. now (2.9) the connection should not be closed at all.... > > The message in the syslog is "Connection closed by foreign host". > > If that's of interest, 2.5.2p2 was compiled with OpenSSL 0.9.5, > 2.9p2 is compiled using OpenSSL 0.9.6b. > > > Does anybody know what's going on or what I did wrong? Or do > I need to give more details? > > Corinna > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com From markus at openbsd.org Wed Sep 12 20:52:02 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 12:52:02 +0200 Subject: scp bug with 0x0a in filename: In-Reply-To: ; from jdamery@chiark.greenend.org.uk on Mon, Sep 10, 2001 at 12:23:32AM +0100 References: Message-ID: <20010912125202.F12133@folly> i think this is a problem with the rcp protocol, it transfers the filename with a trailing \n. use sftp :) perhaps rcp/scp should refuse to transfer files with embedded \n? On Mon, Sep 10, 2001 at 12:23:32AM +0100, Jonathan D. Amery wrote: > > This bug (Debian bug number 111692) occurs with filenames that have the > character 0x0a in them (newline). > > This is how one repeats it: > > ming.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:15:50] $ > : bash[592] ; cat > 'x > x' > This is a test. > ming.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:17] $ > : bash[593] ; scp 'x > x' dorothee:ssh-test/ > x > x 0% | | 0 --:-- ETA > x 100% |*****************************| 16 00:00 > lost connection > ming.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:39] $ > : bash[594] ; > > dorothee.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:48] $ > : bash[504] ; ls > x > dorothee.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:50] $ > : bash[505] ; cat x > x > This is a testdorothee.empire.pick.ucam.org:~/ssh-test/ # [01/09/10.00:16:52] $ > : bash[506] ; > > > If you notice the additional characters from the end of the filename > ('x') have been appended to the front of the file, and the file has been > named to the first part of the file name. > > -- > Jonathan Amery. Now there's a light at the end of the tunnel, > ##### Someone's lit a campfire in my cave. > #######__o The first rays of dawn are breaking through the clouds, > #######'/ And somehow I know I can be brave. - Steve Kitson > From markus at openbsd.org Wed Sep 12 20:52:53 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 12:52:53 +0200 Subject: scp doesn't work with large (>2GB) files In-Reply-To: <5bwv37th4x.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Mon, Sep 10, 2001 at 12:33:18PM +0100 References: <5bwv37th4x.fsf@chiark.greenend.org.uk> Message-ID: <20010912125253.G12133@folly> why is O_LARGEFILE needed? is this some standard API? On Mon, Sep 10, 2001 at 12:33:18PM +0100, Matthew Vernon wrote: > Hi, > > A bug I've had reported is that scp doesn't work with large files > (Debian bug number 106809). The problem seems to be scp.c:504: > > if ((fd = open(name, O_RDONLY, 0)) < 0) > > Is there some reason why making that > if ((fd = open(name, O_RDONLY|O_LARGEFILE, 0)) < 0) > > would break things? It seems a simple fix to me... > > Thanks, > > 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 Wed Sep 12 20:57:32 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 12:57:32 +0200 Subject: sshd hangs on logout -- is this a bug? In-Reply-To: <20010910181444.17597.qmail@wizard.math.ualberta.ca>; from bowman@math.ualberta.ca on Mon, Sep 10, 2001 at 06:14:44PM -0000 References: <20010910181444.17597.qmail@wizard.math.ualberta.ca> Message-ID: <20010912125732.H12133@folly> On Mon, Sep 10, 2001 at 06:14:44PM -0000, John Bowman wrote: > --- openssh-2.9p2/session.c Sat Jun 16 21:40:51 2001 > +++ openssh-2.9p2J2/session.c Tue Jun 19 03:27:30 2001 > @@ -1928,6 +1928,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; ^^^ i still think this is very very wrong. see the comment: /* * emulate a write failure with 'chan_write_failed', nobody will be * interested in data we write. * Note that we must not call 'chan_read_failed', since there could * be some more data waiting in the pipe. */ you cannot shutdown the pipe, since you did not get an EOF if istate == CHAN_INPUT_OPEN, so you might loose data. if you don't loose data on linux than it's a timing/luck issue. From markus at openbsd.org Wed Sep 12 21:05:11 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 13:05:11 +0200 Subject: Help with exporting keys In-Reply-To: <15261.19849.396479.542473@samba.doc.wustl.edu>; from kitty@cs.wustl.edu on Mon, Sep 10, 2001 at 06:32:25PM -0500 References: <15261.19849.396479.542473@samba.doc.wustl.edu> Message-ID: <20010912130511.J12133@folly> openssh can only handle _unencrypted_ private keys from ssh.com On Mon, Sep 10, 2001 at 06:32:25PM -0500, Krishnakumar B wrote: > Hi, > > In our department's setup we have a unfortunate situation where we have to > use both OpenSSH and SSH (ssh.com's version). I have managed to export keys > from OpenSSH to SSH's format. I also managed to export SSH's public key to > OpenSSH's format. Now I would like to add the private key of SSH to the > agent. Now when I try to add it simply by using > > ssh-add ~/.ssh2/id_dsa_1024_a > > I get a bad passphrase error. I thought that this was because OpenSSH > couldn't grok the private key generated by SSH. When I tried exporting > SSH's private key as follows: > > With SSH version 2.0.12 and OpenSSH_2.9p2 > ----------------------------------------- > > samba> ssh-keygen -i -f ~/.ssh2/id_dsa_1024_a > uudecode failed. > > > With SSH version 2.4.0 and OpenSSH_2.9p2 > ---------------------------------------- > > samba> ssh-keygen -i -f ~/.ssh2/id_dsa_1024_b > unsupported cipher 3des-cbc > decode blob failed. > > Anybody know why this export is failing ? Any workarounds for this ? I am > generating the SSH keys on Solaris and Tru64. I am trying the export with > OpenSSH on Linux/i686. > > -kitty. > > -- > Krishnakumar B > Distributed Object Computing Laboratory, Washington University in St.Louis From khaled at w-arts.com Wed Sep 12 21:10:17 2001 From: khaled at w-arts.com (Khaled Daham) Date: Wed, 12 Sep 2001 13:10:17 +0200 (CEST) Subject: scp1 issue In-Reply-To: <20010912122757.A12133@folly> Message-ID: On Wed, 12 Sep 2001, Markus Friedl wrote: > scp is just rcp over ssh, so it's not very different from > > ssh host cat file Sending a CMSG_EXEC_CMD with 'cat some-file' works without a problem, but sending 'scp -f some-file' leads to the "hanging", or as it seems waiting for something. /Khaled Daham, w.arts Mail: khaled at w-arts.com Cell: +46-70-6785492 FreeBSD: The Power to Serve! http://www.FreeBSD.org/ This isn't rocket science -- but it _is_ computer science. The FreeBSD kernel is very well documented, unfortunately it's all in `C'. From markus at openbsd.org Wed Sep 12 21:10:58 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 13:10:58 +0200 Subject: bug in scp (OpenSSH) In-Reply-To: ; from jason@shalott.net on Tue, Sep 04, 2001 at 04:37:59PM -0700 References: <006b01c132e7$fceb5580$cc64a8c0@home.xyzzy.net> Message-ID: <20010912131058.K12133@folly> On Tue, Sep 04, 2001 at 04:37:59PM -0700, Jason Stone wrote: > > > >This has come up many times before, and the consensus of the developers > > >seems to be that they're not interested in fixing or adding features to > > >scp because they want to make scp just the secure version of rcp, and it's > > >not up to them to change rcp. > > > > One thing I have missing from other versions is the throughput meter > > in the status bar. > > Incidentally, at my last company, the progress bar was a source of > breakage for legacy scripts that didn't expect rcp to be producing any > output - so what's up with that? How does that fit into your model of > being rsh/rcp compatible and not introducing extraneous features? Do you > really think that breaking rcp compatibility with a status bar is a better > idea than "breaking" it with, for example, a flag to allow atomic > transfers? > > Don't you think that if the progress bar exists at all, it should at least > be enabled via commandline option or environment variable, and not be the > default? yes, i think so, but it's too late. i had an argument with the ssh developers when this was added to ssh-1.2.x some time ago, and i really don't want this happen again. the 'legacy' scripts don't see the bar if the are running without at tty (or with the -q option), but -- as i said -- it's a bad idea to change the default behaviour and it's a very bad idea to change it _again_. -m From mcv21 at cus.cam.ac.uk Wed Sep 12 21:14:47 2001 From: mcv21 at cus.cam.ac.uk (M.C. Vernon) Date: Wed, 12 Sep 2001 12:14:47 +0100 (BST) Subject: scp doesn't work with large (>2GB) files In-Reply-To: <20010912125253.G12133@folly> Message-ID: On Wed, 12 Sep 2001, Markus Friedl wrote: > why is O_LARGEFILE needed? is this some standard API? It's not a standard API, except on Solaris/SunOS and Linux (as far as a quick look will tell me). HP-UX 11i has this flag and notes "This is a non-standard flag which may be used by 32-bit applications to access files larger than 2 GB". OTOH, on those platforms, open() will fail on files bigger than 2GB. This seems to me a good reason to include this flag on platforms where it is defined. Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From deraadt at cvs.openbsd.org Wed Sep 12 21:22:03 2001 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Wed, 12 Sep 2001 05:22:03 -0600 Subject: scp doesn't work with large (>2GB) files In-Reply-To: Your message of "Wed, 12 Sep 2001 12:14:47 BST." Message-ID: <200109121122.f8CBM3q30819@cvs.openbsd.org> O_LARGEFILE is an API that should never have showed up. It is ridiculous twisted bullshit. Those vendors were foolish. > On Wed, 12 Sep 2001, Markus Friedl wrote: > > > why is O_LARGEFILE needed? is this some standard API? > > It's not a standard API, except on Solaris/SunOS and Linux (as far as a > quick look will tell me). HP-UX 11i has this flag and notes "This is a > non-standard flag which may be used by 32-bit applications to access files > larger than 2 GB". OTOH, on those platforms, open() will fail on files > bigger than 2GB. This seems to me a good reason to include this flag on > platforms where it is defined. > > Regards, > > Matthew > > -- > "At least you know where you are with Microsoft." > "True. I just wish I'd brought a paddle." > http://www.debian.org > From mcv21 at cus.cam.ac.uk Wed Sep 12 21:30:08 2001 From: mcv21 at cus.cam.ac.uk (M.C. Vernon) Date: Wed, 12 Sep 2001 12:30:08 +0100 (BST) Subject: scp doesn't work with large (>2GB) files In-Reply-To: <200109121122.f8CBM3q30819@cvs.openbsd.org> Message-ID: On Wed, 12 Sep 2001, Theo de Raadt wrote: > O_LARGEFILE is an API that should never have showed up. > > It is ridiculous twisted bullshit. Those vendors were foolish. OTOH, it has showed up. On AIX, HPUX, Solaris and Linux. BSD and Tru64 don't have it. Furthermore, using this flag on platforms that support it should have no bad effects (assuming proper error checking). Using O_LARGEFILE is probably the least worst solution to this problem on Linux at least. Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From deraadt at cvs.openbsd.org Wed Sep 12 21:36:21 2001 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Wed, 12 Sep 2001 05:36:21 -0600 Subject: scp doesn't work with large (>2GB) files In-Reply-To: Your message of "Wed, 12 Sep 2001 12:30:08 BST." Message-ID: <200109121136.f8CBaLq19023@cvs.openbsd.org> > Using O_LARGEFILE is probably the least worst solution to this problem on > Linux at least. I think you missed my point. Does sh use this flag? Does cat? Does emacs? Does awk? Does all that legacy software? Vendors who support this have made a monstrous effort. Their open system call is broken. When this flag is not set, software behaves different. Those vendors have completely failed to use their heads. You are apologizing for an incredibly bad decision. I am not saying that ssh code now doesn't need to use this absolute BULLSHIT. I am saying that you guys who can influence Linux development have stood on the wayside and permitted complete bullshit. From markus at openbsd.org Wed Sep 12 21:34:52 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 13:34:52 +0200 Subject: scp doesn't work with large (>2GB) files In-Reply-To: ; from mcv21@cus.cam.ac.uk on Wed, Sep 12, 2001 at 12:30:08PM +0100 References: <200109121122.f8CBM3q30819@cvs.openbsd.org> Message-ID: <20010912133452.A11601@faui02.informatik.uni-erlangen.de> On Wed, Sep 12, 2001 at 12:30:08PM +0100, M.C. Vernon wrote: > On Wed, 12 Sep 2001, Theo de Raadt wrote: > > > O_LARGEFILE is an API that should never have showed up. > > > > It is ridiculous twisted bullshit. Those vendors were foolish. > > OTOH, it has showed up. On AIX, HPUX, Solaris and Linux. BSD and Tru64 > don't have it. Furthermore, using this flag on platforms that support it > should have no bad effects (assuming proper error checking). > > Using O_LARGEFILE is probably the least worst solution to this problem on > Linux at least. i still don't see how a flag to open(2) can help if off_t is 32 bit? From vinschen at redhat.com Wed Sep 12 21:37:40 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 12 Sep 2001 13:37:40 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010912124254.E12133@folly>; from markus@openbsd.org on Wed, Sep 12, 2001 at 12:42:54PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> Message-ID: <20010912133740.B7308@cygbert.vinschen.de> On Wed, Sep 12, 2001 at 12:42:54PM +0200, Markus Friedl wrote: > the previous -N implementation was broken. > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.c.diff?r1=1.105&r2=1.106 > > On Tue, Sep 04, 2001 at 09:25:59PM +0200, Corinna Vinschen wrote: > > This has run reliable with 2.5.2 over the last months. Now, after > > I have upgraded to 2.9p2, the tunnel is closed right after each > > attempt of an application to use the tunnel which is a cron job > > running each 5 minutes. So, now the tunnel is closed and restarted > > each 5 minutes :-( > > i cannot reproduce this. > > the previous behaviour was to close the connection > after the last connection to the localhost port > has been closed. But that's exactly what happens now using 2.9p2 and even when using the latest from the portable CVS tree while the connection using 2.5.2p2 stays open all the time. I've just tried it again using the latest from cvs started from the command line using -v -v -v. The command is ssh -2 -g -N -o 'ConnectionAttempts 3600' \ -L 8110:pop.server.tld:110 \ tunnel.server.tld The debug output is: ============================================================================= [...usual stuff when connecting...] debug1: Connections to local port 8110 forwarded to remote address pop.server.tld:110 debug1: Local forwarding listening on 0.0.0.0 port 8110. debug1: fd 4 setting O_NONBLOCK debug2: fd 4 is O_NONBLOCK debug1: channel 0: new [port listener] debug1: Entering interactive session. ============================================================================= At that point it waits for activity. Now I'm starting fetchmail using port 8110 on localhost: ============================================================================= debug1: Connection to port 8110 forwarding to pop.server.tld port 110 requested. debug1: fd 5 setting O_NONBLOCK debug2: fd 5 is O_NONBLOCK debug1: channel 1: new [direct-tcpip] debug1: channel 1: open confirm rwindow 30000 rmax 16384 debug1: channel 1: read<=0 rfd 5 len 0 debug1: channel 1: read failed debug1: channel 1: input open -> drain debug1: channel 1: close_read debug1: channel 1: ibuf empty debug1: channel 1: input drain -> closed debug1: channel 1: send eof debug1: channel 1: rcvd close debug1: channel 1: output open -> drain debug2: channel 1: no data after CLOSE debug1: channel 1: obuf empty debug1: channel 1: output drain -> closed debug1: channel 1: close_write debug1: channel 1: send close debug1: channel 1: is dead debug1: channel_free: channel 1: direct-tcpip: listening port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3238, nchannels 2 debug3: channel_free: status: The following connections are open: #1 direct-tcpip: listening port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3238 (t4 r0 i8/0 o128/0 fd 5/5) debug3: channel_close_fds: channel 1: r 5 w 5 e -1 debug1: channel_free: channel 0: port listener, nchannels 1 debug3: channel_free: status: The following connections are open: debug3: channel_close_fds: channel 0: r 4 w 4 e -1 Connection to tunnel.server.tld closed by remote host. debug1: Transferred: stdin 0, stdout 0, stderr 53 bytes in 19.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2.8 debug1: Exit status -1 debug1: compress outgoing: raw data 1272, compressed 736, factor 0.58 debug1: compress incoming: raw data 2845, compressed 1813, factor 0.64 prompt$ ============================================================================= That's it. The connection has been closed. The same looks that way using 2.5.2p2: ============================================================================= [...usual stuff when connecting...] debug1: Connections to local port 8110 forwarded to remote address pop.server.tld:110 debug1: Local forwarding listening on 0.0.0.0 port 8110. debug1: fd 7 setting O_NONBLOCK debug1: fd 7 IS O_NONBLOCK debug1: channel 0: new [port listener] debug1: channel 1: new [client-session] debug1: send channel open 1 debug1: Entering interactive session. debug2: callback start debug1: client_init id 1 arg 0 debug2: callback done debug1: channel 1: open confirm rwindow 10000 rmax 32768 ============================================================================= At that point it waits for activity. Now I'm starting fetchmail using port 8110 on localhost: ============================================================================= debug1: Connection to port 8110 forwarding to pop.server.tld port 110 requested. debug1: fd 8 setting O_NONBLOCK debug1: fd 8 IS O_NONBLOCK debug1: channel 2: new [listen port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3246] debug1: channel 2: open confirm rwindow 30000 rmax 16384 debug1: channel 2: read<=0 rfd 8 len 0 debug1: channel 2: read failed debug1: channel 2: input open -> drain debug1: channel 2: close_read debug1: channel 2: input: no drain shortcut debug1: channel 2: ibuf empty debug1: channel 2: input drain -> closed debug1: channel 2: send eof debug1: channel 2: rcvd close debug1: channel 2: output open -> drain debug2: channel 2: no data after CLOSE debug1: channel 2: obuf empty debug1: channel 2: output drain -> closed debug1: channel 2: close_write debug1: channel 2: send close debug1: channel 2: is dead debug1: channel_free: channel 2: status: The following connections are open: #1 client-session (t4 r0 i1/0 o16/0 fd 4/5) #2 listen port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3246 (t4 r1 i8/0 o128/0 fd 8/8) ============================================================================= And at that point it still waits for the next connection, which is what I have expected. Hope that gives some hint, Corinna From vinschen at redhat.com Wed Sep 12 21:57:11 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 12 Sep 2001 13:57:11 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010912133740.B7308@cygbert.vinschen.de>; from vinschen@redhat.com on Wed, Sep 12, 2001 at 01:37:40PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> Message-ID: <20010912135711.P1285@cygbert.vinschen.de> On Wed, Sep 12, 2001 at 01:37:40PM +0200, Corinna Vinschen wrote: > I've just tried it again using the latest from cvs started > from the command line using -v -v -v. > > The command is > > ssh -2 -g -N -o 'ConnectionAttempts 3600' \ > -L 8110:pop.server.tld:110 \ > tunnel.server.tld BTW, just in case it could be important. The foreign server on the other side of the tunnel is running some F-Secure 2.0.12 on a SunOS 5.6 machine. The local client machine is a Linux i386, kernel 2.2.19. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From markus at openbsd.org Wed Sep 12 22:00:53 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 14:00:53 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010912133740.B7308@cygbert.vinschen.de>; from vinschen@redhat.com on Wed, Sep 12, 2001 at 01:37:40PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> Message-ID: <20010912140053.B11601@faui02.informatik.uni-erlangen.de> is the server running 2.9, too? On Wed, Sep 12, 2001 at 01:37:40PM +0200, Corinna Vinschen wrote: > On Wed, Sep 12, 2001 at 12:42:54PM +0200, Markus Friedl wrote: > > the previous -N implementation was broken. > > > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.c.diff?r1=1.105&r2=1.106 > > > > On Tue, Sep 04, 2001 at 09:25:59PM +0200, Corinna Vinschen wrote: > > > This has run reliable with 2.5.2 over the last months. Now, after > > > I have upgraded to 2.9p2, the tunnel is closed right after each > > > attempt of an application to use the tunnel which is a cron job > > > running each 5 minutes. So, now the tunnel is closed and restarted > > > each 5 minutes :-( > > > > i cannot reproduce this. > > > > the previous behaviour was to close the connection > > after the last connection to the localhost port > > has been closed. > > But that's exactly what happens now using 2.9p2 and even when > using the latest from the portable CVS tree while the connection > using 2.5.2p2 stays open all the time. > > I've just tried it again using the latest from cvs started > from the command line using -v -v -v. > > The command is > > ssh -2 -g -N -o 'ConnectionAttempts 3600' \ > -L 8110:pop.server.tld:110 \ > tunnel.server.tld > > The debug output is: > > ============================================================================= > [...usual stuff when connecting...] > debug1: Connections to local port 8110 forwarded to remote address pop.server.tld:110 > debug1: Local forwarding listening on 0.0.0.0 port 8110. > debug1: fd 4 setting O_NONBLOCK > debug2: fd 4 is O_NONBLOCK > debug1: channel 0: new [port listener] > debug1: Entering interactive session. > ============================================================================= > > At that point it waits for activity. Now I'm starting fetchmail using > port 8110 on localhost: > > ============================================================================= > debug1: Connection to port 8110 forwarding to pop.server.tld port 110 requested. > debug1: fd 5 setting O_NONBLOCK > debug2: fd 5 is O_NONBLOCK > debug1: channel 1: new [direct-tcpip] > debug1: channel 1: open confirm rwindow 30000 rmax 16384 > debug1: channel 1: read<=0 rfd 5 len 0 > debug1: channel 1: read failed > debug1: channel 1: input open -> drain > debug1: channel 1: close_read > debug1: channel 1: ibuf empty > debug1: channel 1: input drain -> closed > debug1: channel 1: send eof > debug1: channel 1: rcvd close > debug1: channel 1: output open -> drain > debug2: channel 1: no data after CLOSE > debug1: channel 1: obuf empty > debug1: channel 1: output drain -> closed > debug1: channel 1: close_write > debug1: channel 1: send close > debug1: channel 1: is dead > debug1: channel_free: channel 1: direct-tcpip: listening port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3238, nchannels 2 > debug3: channel_free: status: The following connections are open: > #1 direct-tcpip: listening port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3238 (t4 r0 i8/0 o128/0 fd 5/5) > > debug3: channel_close_fds: channel 1: r 5 w 5 e -1 > debug1: channel_free: channel 0: port listener, nchannels 1 > debug3: channel_free: status: The following connections are open: > > debug3: channel_close_fds: channel 0: r 4 w 4 e -1 > Connection to tunnel.server.tld closed by remote host. > debug1: Transferred: stdin 0, stdout 0, stderr 53 bytes in 19.0 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 2.8 > debug1: Exit status -1 > debug1: compress outgoing: raw data 1272, compressed 736, factor 0.58 > debug1: compress incoming: raw data 2845, compressed 1813, factor 0.64 > prompt$ > ============================================================================= > > That's it. The connection has been closed. > > > The same looks that way using 2.5.2p2: > > ============================================================================= > [...usual stuff when connecting...] > debug1: Connections to local port 8110 forwarded to remote address pop.server.tld:110 > debug1: Local forwarding listening on 0.0.0.0 port 8110. > debug1: fd 7 setting O_NONBLOCK > debug1: fd 7 IS O_NONBLOCK > debug1: channel 0: new [port listener] > debug1: channel 1: new [client-session] > debug1: send channel open 1 > debug1: Entering interactive session. > debug2: callback start > debug1: client_init id 1 arg 0 > debug2: callback done > debug1: channel 1: open confirm rwindow 10000 rmax 32768 > ============================================================================= > > At that point it waits for activity. Now I'm starting fetchmail using > port 8110 on localhost: > > ============================================================================= > debug1: Connection to port 8110 forwarding to pop.server.tld port 110 requested. > debug1: fd 8 setting O_NONBLOCK > debug1: fd 8 IS O_NONBLOCK > debug1: channel 2: new [listen port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3246] > debug1: channel 2: open confirm rwindow 30000 rmax 16384 > debug1: channel 2: read<=0 rfd 8 len 0 > debug1: channel 2: read failed > debug1: channel 2: input open -> drain > debug1: channel 2: close_read > debug1: channel 2: input: no drain shortcut > debug1: channel 2: ibuf empty > debug1: channel 2: input drain -> closed > debug1: channel 2: send eof > debug1: channel 2: rcvd close > debug1: channel 2: output open -> drain > debug2: channel 2: no data after CLOSE > debug1: channel 2: obuf empty > debug1: channel 2: output drain -> closed > debug1: channel 2: close_write > debug1: channel 2: send close > debug1: channel 2: is dead > debug1: channel_free: channel 2: status: The following connections are open: > #1 client-session (t4 r0 i1/0 o16/0 fd 4/5) > #2 listen port 8110 for pop.server.tld port 110, connect from 127.0.0.1 port 3246 (t4 r1 i8/0 o128/0 fd 8/8) > ============================================================================= > > And at that point it still waits for the next connection, which is what > I have expected. > > Hope that gives some hint, > Corinna From gert at greenie.muc.de Wed Sep 12 22:07:05 2001 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 12 Sep 2001 14:07:05 +0200 Subject: scp doesn't work with large (>2GB) files In-Reply-To: <20010912133452.A11601@faui02.informatik.uni-erlangen.de>; from Markus Friedl on Wed, Sep 12, 2001 at 01:34:52PM +0200 References: <200109121122.f8CBM3q30819@cvs.openbsd.org> <20010912133452.A11601@faui02.informatik.uni-erlangen.de> Message-ID: <20010912140705.C27805@greenie.muc.de> Hi, On Wed, Sep 12, 2001 at 01:34:52PM +0200, Markus Friedl wrote: > > Using O_LARGEFILE is probably the least worst solution to this problem on > > Linux at least. > > i still don't see how a flag to open(2) can help if off_t is 32 bit? As long as you don't use lseek() on that file descriptor - who cares? I think that's the main rationale behind O_LARGEFILE: "hello operating system: I know that I'm not going to do anything with file offsets, just read/write this file in a linear way, but it might cross 2Gbyte doing that - but that's OK, I know what I'm doing". 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 mstone at cs.loyola.edu Wed Sep 12 22:10:07 2001 From: mstone at cs.loyola.edu (Michael Stone) Date: Wed, 12 Sep 2001 08:10:07 -0400 Subject: scp doesn't work with large (>2GB) files In-Reply-To: ; from mcv21@cus.cam.ac.uk on Wed, Sep 12, 2001 at 12:14:47PM +0100 References: <20010912125253.G12133@folly> Message-ID: <20010912081007.V7029@justice.loyola.edu> On Wed, Sep 12, 2001 at 12:14:47PM +0100, M.C. Vernon wrote: > On Wed, 12 Sep 2001, Markus Friedl wrote: > > why is O_LARGEFILE needed? is this some standard API? > > It's not a standard API, except on Solaris/SunOS and Linux (as far as a > quick look will tell me). HP-UX 11i has this flag and notes "This is a > non-standard flag which may be used by 32-bit applications to access files > larger than 2 GB". OTOH, on those platforms, open() will fail on files > bigger than 2GB. This seems to me a good reason to include this flag on > platforms where it is defined. Actually, it's a terrible idea, because off_t will still be 32 bits. What would work is #define _FILE_OFFSET_BITS 64 which would make off_t 64 bits and add an implicit O_LARGEFILE. (That's what most of the utilities using O_LARGEFILE would be doing.) You can take a look at the configure routines from some of the GNU utilities (e.g., fileutils) to see how they do the large file support detection. -- Mike Stone From mcv21 at cus.cam.ac.uk Wed Sep 12 22:14:41 2001 From: mcv21 at cus.cam.ac.uk (M.C. Vernon) Date: Wed, 12 Sep 2001 13:14:41 +0100 (BST) Subject: scp doesn't work with large (>2GB) files In-Reply-To: <200109121136.f8CBaLq19023@cvs.openbsd.org> Message-ID: On Wed, 12 Sep 2001, Theo de Raadt wrote: > > Using O_LARGEFILE is probably the least worst solution to this problem on > > Linux at least. I took a random sample, and tried cat. strace output suggests that it does use this flag. > I think you missed my point. > I am not saying that ssh code now doesn't need to use this absolute > BULLSHIT. That's good. > I am saying that you guys who can influence Linux development have > stood on the wayside and permitted complete bullshit. The influence I have (or indeed have had) on Linux[1] development is roughly zero. Matthew [1]or the kernel and libc at least. -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From vinschen at redhat.com Wed Sep 12 22:33:59 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 12 Sep 2001 14:33:59 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010912140053.B11601@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Sep 12, 2001 at 02:00:53PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> Message-ID: <20010912143359.Q1285@cygbert.vinschen.de> On Wed, Sep 12, 2001 at 02:00:53PM +0200, Markus Friedl wrote: > is the server running 2.9, too? No, just in case you missed my previous mail, it's running F-Secure 2.0.12 on some Sparc running SunOS. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From jjaakkol at cs.Helsinki.FI Wed Sep 12 22:33:58 2001 From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola) Date: Wed, 12 Sep 2001 15:33:58 +0300 (EEST) Subject: scp doesn't work with large (>2GB) files In-Reply-To: <20010912081007.V7029@justice.loyola.edu> Message-ID: On Wed, 12 Sep 2001, Michael Stone wrote: > Actually, it's a terrible idea, because off_t will still be 32 bits. > What would work is > #define _FILE_OFFSET_BITS 64 > which would make off_t 64 bits and add an implicit O_LARGEFILE. (That's > what most of the utilities using O_LARGEFILE would be doing.) You can > take a look at the configure routines from some of the GNU utilities > (e.g., fileutils) to see how they do the large file support detection. You beat me to it. O_LARGEFILE should be considered part of Linux system internals and not be used directly by software intended to be portable. My educated guess is, that if you include '#define _FILE_OFFSET_BITS 64' into every .c file (preferably by config.h) in openssh distribution or just use '-D_FILE_OFFSET_BITS=64' while compiling it, it would work just fine with >2G files assuming you have glibc >= 2.1 and kernel >=2.4 (or 64 bit hardware, but then you won't need _FILE_OFFSET_BITS). - Jani From sturle.sunde at usit.uio.no Wed Sep 12 22:36:02 2001 From: sturle.sunde at usit.uio.no (Sturle Sunde) Date: 12 Sep 2001 14:36:02 +0200 Subject: sshd hangs on logout -- is this a bug? In-Reply-To: <20010912123747.D12133@folly> References: <20010905165751.A2447@flounder.net> <20010906110026.T5739@sm2p1386swk.wdr.com> <20010912123747.D12133@folly> Message-ID: Markus Friedl writes: > On Fri, Sep 07, 2001 at 01:16:43AM +0200, Sturle Sunde wrote: >> [Quoting reformatted for readability] >> Nicolas Williams writes: >>> On Wed, Sep 05, 2001 at 04:57:51PM -0700, Adam McKenna wrote: >>>> 20001129 >>>> - (djm) Back out all the serverloop.c hacks. sshd will now hang again >>>> if there are background children with open fds. >>> [...] >>> This is normal behaviour for RSH and is natural behaviour anyways. >> >> Not if you enter an interactive session (and rsh become rlogin). >> >> If I rsh to a machine, exec bash, sleep 100 & and logout, I get >> disconnected immediately. If I ssh to a machine running OpenSSH 2.9p2 >> and do the same, I don't get disconnected until the sleep is finished. >> SSH.com sshd disconnects immediately in all cases when the shell exits >> (like rlogind, not rshd). This difference in behaviour is very >> annoying, and I hoped it would be fixed in the next version. > > i think it's not a bug. I disagree. It breaks compability with rlogin and SSH.com ssh. > however, i don't see these so called problems on *BSD systems, so > perhaps some tty handling on linux/solaris is different (broken?) > with regard to close/eof. I get the same behaviour on AIX 4.3, IRIX 6.5, HP-UX 10.20 and 11i, OSF/DU/Tru64 4.0 and 5.0, Linux and Solaris (tested on 2.6, 7 and 8). Looks like normal behaviour to me. > please not that recent ssh-1.2.x versions are working just like > openssh, i.e. they do what people call 'hang' if the fd's are still > used. (and this is IMHO the right way). SSH-1.2.27 do not have this problem with any of the tested operating systems. Don't know about newer versions. -- Sturle All eyes were on Ford Prefect. Some of them were on stalks. ~~~~~~ -- Douglas Adams, So long, and thanks for all the fish From markus at openbsd.org Wed Sep 12 22:42:54 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 14:42:54 +0200 Subject: sshd hangs on logout -- is this a bug? In-Reply-To: ; from sturle.sunde@usit.uio.no on Wed, Sep 12, 2001 at 02:36:02PM +0200 References: <20010905165751.A2447@flounder.net> <20010906110026.T5739@sm2p1386swk.wdr.com> <20010912123747.D12133@folly> Message-ID: <20010912144254.D11601@faui02.informatik.uni-erlangen.de> On Wed, Sep 12, 2001 at 02:36:02PM +0200, Sturle Sunde wrote: > Markus Friedl writes: > > On Fri, Sep 07, 2001 at 01:16:43AM +0200, Sturle Sunde wrote: > >> [Quoting reformatted for readability] > >> Nicolas Williams writes: > >>> On Wed, Sep 05, 2001 at 04:57:51PM -0700, Adam McKenna wrote: > >>>> 20001129 > >>>> - (djm) Back out all the serverloop.c hacks. sshd will now hang again > >>>> if there are background children with open fds. > >>> [...] > >>> This is normal behaviour for RSH and is natural behaviour anyways. > >> > >> Not if you enter an interactive session (and rsh become rlogin). > >> > >> If I rsh to a machine, exec bash, sleep 100 & and logout, I get > >> disconnected immediately. If I ssh to a machine running OpenSSH 2.9p2 > >> and do the same, I don't get disconnected until the sleep is finished. > >> SSH.com sshd disconnects immediately in all cases when the shell exits > >> (like rlogind, not rshd). This difference in behaviour is very > >> annoying, and I hoped it would be fixed in the next version. > > > > i think it's not a bug. > > I disagree. It breaks compability with rlogin and SSH.com ssh. > > > however, i don't see these so called problems on *BSD systems, so > > perhaps some tty handling on linux/solaris is different (broken?) > > with regard to close/eof. > > I get the same behaviour on AIX 4.3, IRIX 6.5, HP-UX 10.20 and 11i, > OSF/DU/Tru64 4.0 and 5.0, Linux and Solaris (tested on 2.6, 7 and 8). > Looks like normal behaviour to me. so do you have a fix? > > please not that recent ssh-1.2.x versions are working just like > > openssh, i.e. they do what people call 'hang' if the fd's are still > > used. (and this is IMHO the right way). > > SSH-1.2.27 do not have this problem with any of the tested operating > systems. Don't know about newer versions. ssh-1.2.30 fixed this i think and no longer discards the data. From jjaakkol at cs.Helsinki.FI Wed Sep 12 23:47:06 2001 From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola) Date: Wed, 12 Sep 2001 16:47:06 +0300 (EEST) Subject: scp doesn't work with large (>2GB) files In-Reply-To: Message-ID: On Wed, 12 Sep 2001, Jani Jaakkola wrote: > My educated guess is, that if you include '#define _FILE_OFFSET_BITS 64' > into every .c file (preferably by config.h) in openssh distribution or > just use '-D_FILE_OFFSET_BITS=64' while compiling it, it would work just > fine with >2G files assuming you have glibc >= 2.1 and kernel >=2.4 (or > 64 bit hardware, but then you won't need _FILE_OFFSET_BITS). Now that I think of it, it should be simple as this: $ pwd /home/jjaakkol/src/openssh-2.9p2 $ CFLAGS=-D_FILE_OFFSET_BITS=64 ./configure $ make $ strace -e open ./scp scp.c localhost:/dev/null open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 open("/usr/lib/libz.so.1", O_RDONLY) = 3 open("/lib/libnsl.so.1", O_RDONLY) = 3 open("/lib/libutil.so.1", O_RDONLY) = 3 open("/usr/lib/libcrypto.so.1", O_RDONLY) = 3 open("/lib/libcrypt.so.1", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/lib/libdl.so.2", O_RDONLY) = 3 open("/etc/nsswitch.conf", O_RDONLY) = 3 open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/libnss_files.so.2", O_RDONLY) = 3 open("/etc/passwd", O_RDONLY) = 3 jjaakkol at localhost's password: open("scp.c", O_RDONLY|O_LARGEFILE) = 3 scp.c 100% |*****************************| 29441 00:00 $ So as you see, scp implicitly uses O_LARGEFILE when compiled with -D_FILE_OFFSET_BITS=64. Just remember that you need to have it enabled both in server and client for it to actually work assuming that openssh does not expect sizeof(off_t)==sizeof(long). I did not bother to actually test it, since most of my machines are still running 2.2 kernel. - Jani From Nicolas.Williams at ubsw.com Wed Sep 12 23:44:29 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 12 Sep 2001 09:44:29 -0400 Subject: scp doesn't work with large (>2GB) files In-Reply-To: <20010912133452.A11601@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Sep 12, 2001 at 01:34:52PM +0200 References: <200109121122.f8CBM3q30819@cvs.openbsd.org> <20010912133452.A11601@faui02.informatik.uni-erlangen.de> Message-ID: <20010912094427.W5739@sm2p1386swk.wdr.com> On Wed, Sep 12, 2001 at 01:34:52PM +0200, Markus Friedl wrote: > On Wed, Sep 12, 2001 at 12:30:08PM +0100, M.C. Vernon wrote: > > Using O_LARGEFILE is probably the least worst solution to this problem on > > Linux at least. > > i still don't see how a flag to open(2) can help if off_t is 32 bit? Perhaps the idea was to make sure that only programs compiled with off_t being 64 bits could open large files. Think, if an old program opened a large file and read sequencially past 2GB then tried to find the current offset then all hell would break loose -- thus the requirement that a new open flag or new open syscall be used might merely be meant prevent older programs from such situations. Solaris, in fact, has an open64() and the headers take care of doing something like: #define open open64 I bet that open64() internally sets O_LARGEFILE automatically so that OpenSSH should need no source changes other than defining some pre-processor constant to enable open64() et. al., on Solaris. I can't say about Linux... 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 wichert at wiggy.net Wed Sep 12 23:53:54 2001 From: wichert at wiggy.net (Wichert Akkerman) Date: Wed, 12 Sep 2001 15:53:54 +0200 Subject: scp doesn't work with large (>2GB) files In-Reply-To: <200109121136.f8CBaLq19023@cvs.openbsd.org> References: <200109121136.f8CBaLq19023@cvs.openbsd.org> Message-ID: <20010912155354.C719@wiggy.net> Previously Theo de Raadt wrote: > Does sh use this flag? > Does cat? > Does emacs? > Does awk? They all do if you have a recent version. > I am saying that you guys who can influence Linux development have > stood on the wayside and permitted complete bullshit. I'ld love to see how you intend to access 2>GB files on a 32 bit system without changing the ABI. 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 wichert at wiggy.net Wed Sep 12 23:55:40 2001 From: wichert at wiggy.net (Wichert Akkerman) Date: Wed, 12 Sep 2001 15:55:40 +0200 Subject: scp doesn't work with large (>2GB) files In-Reply-To: <20010912133452.A11601@faui02.informatik.uni-erlangen.de> References: <200109121122.f8CBM3q30819@cvs.openbsd.org> <20010912133452.A11601@faui02.informatik.uni-erlangen.de> Message-ID: <20010912155540.D719@wiggy.net> Previously Markus Friedl wrote: > i still don't see how a flag to open(2) can help if off_t is 32 bit? If I remember correctly you can compile with some option that turns off_t into a long long 64bit type. glibc will use a second set of 64bit syscall for file operations as well when present in the kernel so it all becomes transparent to the application. 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 matthew at debian.org Thu Sep 13 00:48:42 2001 From: matthew at debian.org (Matthew Vernon) Date: 12 Sep 2001 15:48:42 +0100 Subject: scp doesn't work with large (>2GB) files In-Reply-To: Michael Stone's message of Wed, 12 Sep 2001 12:32:02 GMT References: <20010912125253.G12133@folly> <20010912081007.V7029@justice.loyola.edu> Message-ID: <5bofog1n3p.fsf@chiark.greenend.org.uk> Michael Stone writes: > > On Wed, Sep 12, 2001 at 12:14:47PM +0100, M.C. Vernon wrote: > > On Wed, 12 Sep 2001, Markus Friedl wrote: > > > why is O_LARGEFILE needed? is this some standard API? > > > > It's not a standard API, except on Solaris/SunOS and Linux (as far as a > > quick look will tell me). HP-UX 11i has this flag and notes "This is a > > non-standard flag which may be used by 32-bit applications to access files > > larger than 2 GB". OTOH, on those platforms, open() will fail on files > > bigger than 2GB. This seems to me a good reason to include this flag on > > platforms where it is defined. > > Actually, it's a terrible idea, because off_t will still be 32 bits. > What would work is > #define _FILE_OFFSET_BITS 64 > which would make off_t 64 bits and add an implicit O_LARGEFILE. (That's > what most of the utilities using O_LARGEFILE would be doing.) You can > take a look at the configure routines from some of the GNU utilities > (e.g., fileutils) to see how they do the large file support detection. Yes, indeed. Can this go into the next release? adding a CFLAG of -D_FILE_OFFSET_BITS=64 for systems like Linux would be fine. In the mean time, I'll add it by hand to the debian/rules file. Thanks, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From mouring at etoh.eviladmin.org Thu Sep 13 01:45:26 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 12 Sep 2001 10:45:26 -0500 (CDT) Subject: scp doesn't work with large (>2GB) files In-Reply-To: <5bofog1n3p.fsf@chiark.greenend.org.uk> Message-ID: [..] > Yes, indeed. Can this go into the next release? adding a CFLAG of > -D_FILE_OFFSET_BITS=64 for systems like Linux would be fine. In the > mean time, I'll add it by hand to the debian/rules file. > Does this adversity affect older than 2.2 and below kernels? If not then I will enable it in the configure.in by default for Linux. - Ben From deraadt at cvs.openbsd.org Thu Sep 13 02:02:58 2001 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Wed, 12 Sep 2001 10:02:58 -0600 Subject: scp doesn't work with large (>2GB) files In-Reply-To: Your message of "Wed, 12 Sep 2001 09:44:29 EDT." <20010912094427.W5739@sm2p1386swk.wdr.com> Message-ID: <200109121602.f8CG2wq16574@cvs.openbsd.org> This is ridiculous. It means that any existing program that is not aware of this flag will have two divergent behaviours. That is the kind of bug that results in security holes. I have tons of experience with this, and this is INCREDIBLY dangerous. > On Wed, Sep 12, 2001 at 01:34:52PM +0200, Markus Friedl wrote: > > On Wed, Sep 12, 2001 at 12:30:08PM +0100, M.C. Vernon wrote: > > > Using O_LARGEFILE is probably the least worst solution to this problem on > > > Linux at least. > > > > i still don't see how a flag to open(2) can help if off_t is 32 bit? > > Perhaps the idea was to make sure that only programs compiled with off_t > being 64 bits could open large files. > > Think, if an old program opened a large file and read sequencially past > 2GB then tried to find the current offset then all hell would break > loose -- thus the requirement that a new open flag or new open syscall > be used might merely be meant prevent older programs from such > situations. > > Solaris, in fact, has an open64() and the headers take care of doing > something like: > > #define open open64 > > I bet that open64() internally sets O_LARGEFILE automatically so that > OpenSSH should need no source changes other than defining some > pre-processor constant to enable open64() et. al., on Solaris. > > I can't say about Linux... > > 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 jjaakkol at cs.Helsinki.FI Thu Sep 13 02:15:16 2001 From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola) Date: Wed, 12 Sep 2001 19:15:16 +0300 (EEST) Subject: scp doesn't work with large (>2GB) files In-Reply-To: Message-ID: On Wed, 12 Sep 2001 mouring at etoh.eviladmin.org wrote: > > [..] > > Yes, indeed. Can this go into the next release? adding a CFLAG of > > -D_FILE_OFFSET_BITS=64 for systems like Linux would be fine. In the > > mean time, I'll add it by hand to the debian/rules file. > > > > Does this adversity affect older than 2.2 and below kernels? If not then > I will enable it in the configure.in by default for Linux. No, older kernels just ignore O_LARGEFILE. And if the libc is old enough _FILE_OFFSET_BITS=64 does nothing. (glibc-2.0 is old enough). So unless openssh has some hidden assumptions about sizeof(off_t) it should be safe. Anyway, if there is such hidden assumptions, it would be better if they will be exposed. - Jani From mcv21 at cus.cam.ac.uk Thu Sep 13 02:22:00 2001 From: mcv21 at cus.cam.ac.uk (M.C. Vernon) Date: Wed, 12 Sep 2001 17:22:00 +0100 (BST) Subject: scp doesn't work with large (>2GB) files In-Reply-To: Message-ID: On Wed, 12 Sep 2001 mouring at etoh.eviladmin.org wrote: > > [..] > > Yes, indeed. Can this go into the next release? adding a CFLAG of > > -D_FILE_OFFSET_BITS=64 for systems like Linux would be fine. In the > > mean time, I'll add it by hand to the debian/rules file. > > > > Does this adversity affect older than 2.2 and below kernels? If not then > I will enable it in the configure.in by default for Linux. It shouldn't do - older kernels and libcs will ignore the flag (as will kernels without large file support built in). Thanks, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From wichert at wiggy.net Thu Sep 13 02:25:13 2001 From: wichert at wiggy.net (Wichert Akkerman) Date: Wed, 12 Sep 2001 18:25:13 +0200 Subject: scp doesn't work with large (>2GB) files In-Reply-To: References: <5bofog1n3p.fsf@chiark.greenend.org.uk> Message-ID: <20010912182513.B3787@wiggy.net> Previously mouring at etoh.eviladmin.org wrote: > Does this adversity affect older than 2.2 and below kernels? If not then > I will enable it in the configure.in by default for Linux. glibc will revert to old behaviour at runtime. 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 Darren.Moffat at eng.sun.com Thu Sep 13 02:43:11 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 12 Sep 2001 09:43:11 -0700 (PDT) Subject: scp doesn't work with large (>2GB) files Message-ID: <200109121643.f8CGhBVj176959@jurassic.eng.sun.com> >On Wed, Sep 12, 2001 at 12:30:08PM +0100, M.C. Vernon wrote: >> On Wed, 12 Sep 2001, Theo de Raadt wrote: >> >> > O_LARGEFILE is an API that should never have showed up. >> > >> > It is ridiculous twisted bullshit. Those vendors were foolish. >> >> OTOH, it has showed up. On AIX, HPUX, Solaris and Linux. BSD and Tru64 >> don't have it. Furthermore, using this flag on platforms that support it >> should have no bad effects (assuming proper error checking). >> >> Using O_LARGEFILE is probably the least worst solution to this problem on >> Linux at least. > >i still don't see how a flag to open(2) can help if off_t is 32 bit? Please don't bring Solaris into the justification for passing O_LARGEFILE to open this is NOT the recommened way to do it. On Solaris if you are building a 64bit application off_t is 64bit and open(2) and friends automatically deal with largefiles correctly. If you are a 32bit application you have a choice but passing O_LARGEFILE to open is NOT one of them. For more details see lfcompile(5) http://docs.sun.com:80/ab2/@LegacyPageView?toc=SUNWab_40_4%3A%2Fsafedir%2Fspac e3%2Fcoll3%2FSUNWaman%2Ftoc%2FREFMAN5%3A0059_lfcompile.5;bt=man+Pages(5)%3A+He aders,+Tables+and+Macros;ps=ps%2FSUNWab_40_4%2FREFMAN5%2F0059_lfcompile.5&Ab2L ang=C&Ab2Enc=iso-8859-1 -- Darren J Moffat From jjaakkol at cs.Helsinki.FI Thu Sep 13 02:56:48 2001 From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola) Date: Wed, 12 Sep 2001 19:56:48 +0300 (EEST) Subject: scp doesn't work with large (>2GB) files In-Reply-To: <200109121602.f8CG2wq16574@cvs.openbsd.org> Message-ID: On Wed, 12 Sep 2001, Theo de Raadt wrote: > This is ridiculous. > > It means that any existing program that is not aware of this flag > will have two divergent behaviours. > > That is the kind of bug that results in security holes. I have tons > of experience with this, and this is INCREDIBLY dangerous. Yes, in Linux existing programs that do not use -D_FILE_OFFSET_BITS=64 cannot open or write files larger than 2G (they fail with EFBIG). Personally I don't think that this poses a great security risk, since failing to open a file can happen for a myriad of other reasons too. However, if an existing 32-bit off_t program could open a file larger than 2G, it would be suspect to at least signedness errors when off_t overflows. And that is one of the reasons for which O_LARGEFILE should not be used directly. So, O_LARGEFILE should not be used by openssh. - Jani From Darren.Moffat at eng.sun.com Thu Sep 13 03:04:48 2001 From: Darren.Moffat at eng.sun.com (Darren Moffat) Date: Wed, 12 Sep 2001 10:04:48 -0700 (PDT) Subject: scp doesn't work with large (>2GB) files Message-ID: <200109121704.f8CH4kVj181435@jurassic.eng.sun.com> >This is ridiculous. > >It means that any existing program that is not aware of this flag >will have two divergent behaviours. It is not a flag in the recommened way to deal with it. It is a differnet ABI that is enabled at compile time to change the off set size and the API calls that use it. Part of the reason it was done this way is to help transition from the old 32bit off_t to a 64bit off_t and to provide access to largefiles from 32bit applications. A program either is 64bit safe or it isn't it isn't possible to have two divergent behaviours. It is possible to generate 2 different binaries from the same source one that works with largefiles and one that doesn't depending on your compiler flags when building a 32bit binary. When building a 64bit binary there is only one option and that is a 64bit off_t. It isn't just a matter of recompiling your code either, you must also check all of the code to ensure that you correcly use off_t everywhere rather than sloppy code that uses int or long for file offsets (there is some code in scp that has/had incorrect types for file offsets). >That is the kind of bug that results in security holes. I have tons >of experience with this, and this is INCREDIBLY dangerous. Solaris has had this functionality in a released version of the OS since 2.6 (1997) and we have had no indication that is it possible to cause any security issues because of it. Some people have been recommending the wrong way to deal with this issue but there is a standard interface and it does work as designed when properly called and to my knowledge there are no security issues with it. Passing O_LARGEFILE to open(2) without any other changes is the wrong way to do it and may cause problems with code that doesn't check all return values for functions that manipulate files and file offsets. I believe the Solaris man pages largefile(5), lfcompile(5) on docs.sun.com are a good starting point for -- Darren J Moffat From deraadt at cvs.openbsd.org Thu Sep 13 03:12:29 2001 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Wed, 12 Sep 2001 11:12:29 -0600 Subject: scp doesn't work with large (>2GB) files In-Reply-To: Your message of "Wed, 12 Sep 2001 10:04:48 PDT." <200109121704.f8CH4kVj181435@jurassic.eng.sun.com> Message-ID: <200109121712.f8CHCUq31100@cvs.openbsd.org> > Part of the reason it was done this way is to help transition from the > old 32bit off_t to a 64bit off_t and to provide access to largefiles > from 32bit applications. Still, it is ridiculous. It is a strong reversal from the unification efforts of POSIX. Sun should have looked at kernel-supported emulation environments for better handling of this. Doing so has worked VERY WELL for us. > Passing O_LARGEFILE to open(2) without any other changes is the wrong > way to do it and may cause problems with code that doesn't check all > return values for functions that manipulate files and file offsets. OK. So people are saying that patch is bogus. Not surprising, I suppose: Markus gets mailed lots of bogus patches. From mouring at etoh.eviladmin.org Thu Sep 13 03:17:54 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 12 Sep 2001 12:17:54 -0500 (CDT) Subject: scp doesn't work with large (>2GB) files In-Reply-To: <200109121712.f8CHCUq31100@cvs.openbsd.org> Message-ID: I'm unsure if anything needs to be done on Solaris (since I've yet to have a chance to test due to US and personal issues..), but I will be doing the -D_FILE_OFFSET_BITS=64 solution for Linux if no one in the portable group has a problem. I refuse to touch O_LARGEFILE directly. Since it cannot work for sftp since it actively uses lseek(). - Ben On Wed, 12 Sep 2001, Theo de Raadt wrote: > > Part of the reason it was done this way is to help transition from the > > old 32bit off_t to a 64bit off_t and to provide access to largefiles > > from 32bit applications. > > Still, it is ridiculous. It is a strong reversal from the unification > efforts of POSIX. > > Sun should have looked at kernel-supported emulation environments for > better handling of this. > > Doing so has worked VERY WELL for us. > > > Passing O_LARGEFILE to open(2) without any other changes is the wrong > > way to do it and may cause problems with code that doesn't check all > > return values for functions that manipulate files and file offsets. > > OK. So people are saying that patch is bogus. Not surprising, I > suppose: Markus gets mailed lots of bogus patches. > From stevesk at pobox.com Thu Sep 13 04:26:02 2001 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 12 Sep 2001 11:26:02 -0700 (PDT) Subject: lastlog with hp-ux 10.20 In-Reply-To: <200109062245.f86MjX7580402@matrix.Colorado.EDU> Message-ID: i haven't heard of problems with configure/lastlog on 10.20. i'll copy the development list as there are folks there who use 10.20. On Thu, 6 Sep 2001, Jesse Caldwell wrote: :one last problem with openssh -- building openssh on HPUX 10.20 fails :on loginrec.c (i don't have the errors handy but i would be more than :happy to recreate them). i get the same error with 2.9p2 and 9/6/2001 :cvs source, and i tried two versions of gcc and the cc compiler, so :this is pretty repeatable. :) using --without-lastlog gets around it. :just wondering if you guys already had a fix or if i should go about :clobbering the source myself. From Frank.Smith at unilever.com Sun Sep 2 19:16:11 2001 From: Frank.Smith at unilever.com (Frank Smith) Date: Sun, 2 Sep 2001 05:16:11 -0400 Subject: ssh failure at password query Message-ID: dear sir, i encountered something very odd with openssh. when i try to connect to my sshd daemon, i get repeated password errors. this happens on all connections to my server. outbound connections to other ssh sites work with no problem. the remote site can connect to itself, but not to my site. i captured the output of the sshd -d -d -d -e -D command to provide you with some trace data. i also included the ssh_config file and the sshd_config file so you can see i did nothing radical in the config files. this problem also occurred with just a straight sshd command using the unmodified config files, but that command generated no trace data for you. i run slackware linux with the 2.2.16 kernel. i saw this problem with both openssh-2.9p1 and openssh-2.9p2 i used openssl-0.9.6a and openssl-0.9.6b. my uptime was about five hours. in all cases, i got the same basic error. any suggestions as to what needs attention and how it should be fixed? thank you for your time and assistance. frank smith frank.smith at unilever.com trace from sshd -d -d -d -e -D ------------------------------------------------------------------------ debug1: Seeding random number generator debug3: cipher ok: blowfish-cbc [blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: cast128-cbc [blowfish-cbc,cast128-cbc,arcfour] debug3: cipher ok: arcfour [blowfish-cbc,cast128-cbc,arcfour] debug3: ciphers ok: [blowfish-cbc,cast128-cbc,arcfour] debug1: sshd version OpenSSH_2.9p2 Could not load host key: /local/etc/ssh_host_key debug3: No RSA1 key file /local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: No RSA1 key file /local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA socket: Invalid argument debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Server will not fork when running in debugging mode. Connection from 162.87.6.13 port 1163 debug1: Client protocol version 2.0; client software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9p2 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: list_hostkey_types: ssh-rsa,ssh-dss 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: blowfish-cbc,cast128-cbc,arcfour debug2: kex_parse_kexinit: blowfish-cbc,cast128-cbc,arcfour 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: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: blowfish-cbc,cast128-cbc,arcfour debug2: kex_parse_kexinit: blowfish-cbc,cast128-cbc,arcfour 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: mac_init: found hmac-md5 debug1: kex: client->server blowfish-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client blowfish-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 123/256 debug1: bits set: 1067/2049 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1018/2049 debug2: ssh_rsa_sign: done debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent 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: KEX done debug1: userauth-request for user fdsmith service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for fdsmith debug2: input_userauth_request: try method none Failed none for fdsmith from 162.87.6.13 port 1163 ssh2 debug1: userauth-request for user fdsmith service ssh-connection method password debug1: attempt 1 failures 1 debug2: input_userauth_request: try method password Failed password for fdsmith from 162.87.6.13 port 1163 ssh2 debug1: userauth-request for user fdsmith service ssh-connection method password debug1: attempt 2 failures 2 debug2: input_userauth_request: try method password Failed password for fdsmith from 162.87.6.13 port 1163 ssh2 debug1: userauth-request for user fdsmith service ssh-connection method password debug1: attempt 3 failures 3 debug2: input_userauth_request: try method password Failed password for fdsmith from 162.87.6.13 port 1163 ssh2 debug1: userauth-request for user fdsmith service ssh-connection method keyboard-interactive debug1: attempt 4 failures 4 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive language devs Failed keyboard-interactive for fdsmith from 162.87.6.13 port 1163 ssh2 debug1: userauth-request for user fdsmith service ssh-connection method keyboard-interactive debug1: attempt 5 failures 5 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive language devs Failed keyboard-interactive for fdsmith from 162.87.6.13 port 1163 ssh2 debug1: userauth-request for user fdsmith service ssh-connection method keyboard-interactive debug1: attempt 6 failures 6 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive language devs Failed keyboard-interactive for fdsmith from 162.87.6.13 port 1163 ssh2 Connection closed by 162.87.6.13 debug1: Calling cleanup 0x8062bec(0x0) ------------------------------------------------------------------------ ssh_config file ------------------------------------------------------------------------ # # $Id$ # $OpenBSD: ssh_config,v 1.10 2001/04/03 21:19:38 todd Exp $ # # History: # $Log$ # This is ssh client systemwide configuration file. See ssh(1) for more # information. This file provides defaults for users, and the values can # be changed in per-user configuration files or on the command line. # Configuration data is parsed as follows: # 1. command line options # 2. user-specific file # 3. system-wide file # Any configuration value is only changed the first time it is set. # Thus, host-specific definitions should be at the beginning of the # configuration file, and defaults at the end. # Site-wide defaults for various options # Host * # ForwardAgent no # ForwardX11 no # RhostsAuthentication no # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking yes # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_dsa # IdentityFile ~/.ssh/id_rsa # Port 22 Protocol 2 Cipher blowfish Ciphers blowfish-cbc,cast128-cbc,arcfour # EscapeChar ~ UserKnownHostsFile /dev/null ------------------------------------------------------------------------ sshd_config file ------------------------------------------------------------------------ # # $Id$ # $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $ # # History: # $Log$ # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/local/bin # This is the sshd server system-wide configuration file. See sshd(8) # for more information. Port 22 Protocol 2 #ListenAddress 0.0.0.0 #ListenAddress :: HostKey /local/etc/ssh_host_key HostKey /local/etc/ssh_host_rsa_key HostKey /local/etc/ssh_host_dsa_key ServerKeyBits 2048 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes Ciphers blowfish-cbc,cast128-cbc,arcfour # # Don't read ~/.rhosts and ~/.shosts files IgnoreRhosts yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication IgnoreUserKnownHosts yes StrictModes yes X11Forwarding no X11DisplayOffset 10 PrintMotd yes #PrintLastLog no KeepAlive yes # Logging SyslogFacility AUTH LogLevel INFO #obsoletes QuietMode and FascistLogging RhostsAuthentication no # # For this to work you will also need host keys in /local/etc/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 HostbasedAuthentication no # RSAAuthentication 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 #CheckMail yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp /local/libexec/sftp-server ------------------------------------------------------------------------ From markus at openbsd.org Thu Sep 13 04:50:16 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 12 Sep 2001 20:50:16 +0200 Subject: scp1 issue In-Reply-To: ; from khaled@w-arts.com on Wed, Sep 12, 2001 at 01:10:17PM +0200 References: <20010912122757.A12133@folly> Message-ID: <20010912205016.A23361@folly> On Wed, Sep 12, 2001 at 01:10:17PM +0200, Khaled Daham wrote: > On Wed, 12 Sep 2001, Markus Friedl wrote: > > > scp is just rcp over ssh, so it's not very different from > > > > ssh host cat file > > Sending a CMSG_EXEC_CMD with 'cat some-file' works without a problem, but > sending 'scp -f some-file' leads to the "hanging", or as it seems waiting > for something. who is waiting? > > /Khaled Daham, w.arts > Mail: khaled at w-arts.com > Cell: +46-70-6785492 > FreeBSD: The Power to Serve! http://www.FreeBSD.org/ > > This isn't rocket science -- but it _is_ computer science. > The FreeBSD kernel is very well documented, unfortunately it's all in `C'. > From mouring at etoh.eviladmin.org Thu Sep 13 04:48:56 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 12 Sep 2001 13:48:56 -0500 (CDT) Subject: AES update.. In-Reply-To: <20010912183221.739972DF12@shitei.mindrot.org> Message-ID: I've done a decent size update of the OpenSSH portable from the upstream tree. There is an AES upgrade that needs to take place, but I need people to test and tell me what endedness changes need to be applied (if any). Attached is the patch. It is geared towards the latter snapshots..Unsure how it will patch (if at all) against 2.9pX series. Thanks. - Ben "This is dark day in humanity." Index: cipher.c =================================================================== RCS file: /var/cvs/openssh/cipher.c,v retrieving revision 1.37 diff -u -r1.37 cipher.c --- cipher.c 2001/07/04 03:32:32 1.37 +++ cipher.c 2001/09/12 18:51:58 @@ -35,7 +35,7 @@ */ #include "includes.h" -RCSID("$OpenBSD: cipher.c,v 1.46 2001/06/25 08:25:36 markus Exp $"); +RCSID("$OpenBSD: cipher.c,v 1.47 2001/08/23 11:31:59 markus Exp $"); #include "xmalloc.h" #include "log.h" @@ -283,66 +283,65 @@ static void rijndael_setkey(CipherContext *cc, const u_char *key, u_int keylen) { - rijndael_set_key(&cc->u.rijndael.enc, (u4byte *)key, 8*keylen, 1); - rijndael_set_key(&cc->u.rijndael.dec, (u4byte *)key, 8*keylen, 0); + rijndael_set_key(&cc->u.rijndael.enc, (char *)key, 8*keylen, 1); + rijndael_set_key(&cc->u.rijndael.dec, (char *)key, 8*keylen, 0); } static void rijndael_setiv(CipherContext *cc, const u_char *iv, u_int ivlen) { - if (iv == NULL) - fatal("no IV for %s.", cc->cipher->name); - memcpy((u_char *)cc->u.rijndael.iv, iv, RIJNDAEL_BLOCKSIZE); + if (iv == NULL || ivlen != RIJNDAEL_BLOCKSIZE) + fatal("bad/no IV for %s.", cc->cipher->name); + memcpy(cc->u.rijndael.iv, iv, RIJNDAEL_BLOCKSIZE); } static void rijndael_cbc_encrypt(CipherContext *cc, u_char *dest, const u_char *src, u_int len) { rijndael_ctx *ctx = &cc->u.rijndael.enc; - u4byte *iv = cc->u.rijndael.iv; - u4byte in[4]; - u4byte *cprev, *cnow, *plain; - int i, blocks = len / RIJNDAEL_BLOCKSIZE; + u_char *iv = cc->u.rijndael.iv; + u_char in[RIJNDAEL_BLOCKSIZE]; + u_char *cprev, *cnow, *plain; + int i, j, blocks = len / RIJNDAEL_BLOCKSIZE; + if (len == 0) return; if (len % RIJNDAEL_BLOCKSIZE) fatal("rijndael_cbc_encrypt: bad len %d", len); - cnow = (u4byte*) dest; - plain = (u4byte*) src; + cnow = dest; + plain = (u_char *) src; cprev = iv; - for(i = 0; i < blocks; i++, plain+=4, cnow+=4) { - in[0] = plain[0] ^ cprev[0]; - in[1] = plain[1] ^ cprev[1]; - in[2] = plain[2] ^ cprev[2]; - in[3] = plain[3] ^ cprev[3]; + for (i = 0; i < blocks; i++, plain+=RIJNDAEL_BLOCKSIZE, + cnow+=RIJNDAEL_BLOCKSIZE) { + for (j = 0; j < RIJNDAEL_BLOCKSIZE; j++) + in[j] = plain[j] ^ cprev[j]; rijndael_encrypt(ctx, in, cnow); cprev = cnow; } memcpy(iv, cprev, RIJNDAEL_BLOCKSIZE); } - static void rijndael_cbc_decrypt(CipherContext *cc, u_char *dest, const u_char *src, u_int len) { rijndael_ctx *ctx = &cc->u.rijndael.dec; - u4byte *iv = cc->u.rijndael.iv; - u4byte ivsaved[4]; - u4byte *cnow = (u4byte*) (src+len-RIJNDAEL_BLOCKSIZE); - u4byte *plain = (u4byte*) (dest+len-RIJNDAEL_BLOCKSIZE); - u4byte *ivp; - int i, blocks = len / RIJNDAEL_BLOCKSIZE; + u_char *iv = cc->u.rijndael.iv; + u_char ivsaved[RIJNDAEL_BLOCKSIZE]; + u_char *cnow = (u_char *) (src+len-RIJNDAEL_BLOCKSIZE); + u_char *plain = dest+len-RIJNDAEL_BLOCKSIZE; + u_char *ivp; + int i, j, blocks = len / RIJNDAEL_BLOCKSIZE; + if (len == 0) return; if (len % RIJNDAEL_BLOCKSIZE) fatal("rijndael_cbc_decrypt: bad len %d", len); memcpy(ivsaved, cnow, RIJNDAEL_BLOCKSIZE); - for(i = blocks; i > 0; i--, cnow-=4, plain-=4) { + for (i = blocks; i > 0; i--, cnow-=RIJNDAEL_BLOCKSIZE, + plain-=RIJNDAEL_BLOCKSIZE) { rijndael_decrypt(ctx, cnow, plain); - ivp = (i == 1) ? iv : cnow-4; - plain[0] ^= ivp[0]; - plain[1] ^= ivp[1]; - plain[2] ^= ivp[2]; - plain[3] ^= ivp[3]; + ivp = (i == 1) ? iv : cnow-RIJNDAEL_BLOCKSIZE; + for (j = 0; j < RIJNDAEL_BLOCKSIZE; j++) + plain[j] ^= ivp[j]; } memcpy(iv, ivsaved, RIJNDAEL_BLOCKSIZE); } Index: cipher.h =================================================================== RCS file: /var/cvs/openssh/cipher.h,v retrieving revision 1.22 diff -u -r1.22 cipher.h --- cipher.h 2001/07/04 04:46:57 1.22 +++ cipher.h 2001/09/12 18:51:59 @@ -32,7 +32,7 @@ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -/* RCSID("$OpenBSD: cipher.h,v 1.28 2001/06/26 17:27:23 markus Exp $"); */ +/* RCSID("$OpenBSD: cipher.h,v 1.29 2001/08/23 11:31:59 markus Exp $"); */ #ifndef CIPHER_H #define CIPHER_H @@ -85,7 +85,7 @@ u_char iv[8]; } cast; struct { - u4byte iv[4]; + u_char iv[16]; rijndael_ctx enc; rijndael_ctx dec; } rijndael; Index: rijndael.c =================================================================== RCS file: /var/cvs/openssh/rijndael.c,v retrieving revision 1.10 diff -u -r1.10 rijndael.c --- rijndael.c 2001/08/06 21:24:12 1.10 +++ rijndael.c 2001/09/12 18:52:28 @@ -1,425 +1,1241 @@ -/* $OpenBSD: rijndael.c,v 1.8 2001/07/30 16:23:30 stevesk Exp $ */ +/** + * rijndael-alg-fst.c + * + * @version 3.0 (December 2000) + * + * Optimised ANSI C code for the Rijndael cipher (now AES) + * + * @author Vincent Rijmen + * @author Antoon Bosselaers + * @author Paulo Barreto + * + * This code is hereby placed in the public domain. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''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 AUTHORS OR CONTRIBUTORS 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 +#include -/* This is an independent implementation of the encryption algorithm: */ -/* */ -/* RIJNDAEL by Joan Daemen and Vincent Rijmen */ -/* */ -/* which is a candidate algorithm in the Advanced Encryption Standard */ -/* programme of the US National Institute of Standards and Technology. */ - -/* - ----------------------------------------------------------------------- - Copyright (c) 2001 Dr Brian Gladman , Worcester, UK - - TERMS - - 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 'as is' with no guarantees of correctness or - fitness for purpose. - ----------------------------------------------------------------------- -*/ - -/* Timing data for Rijndael (rijndael.c) - -Algorithm: rijndael (rijndael.c) - -128 bit key: -Key Setup: 305/1389 cycles (encrypt/decrypt) -Encrypt: 374 cycles = 68.4 mbits/sec -Decrypt: 352 cycles = 72.7 mbits/sec -Mean: 363 cycles = 70.5 mbits/sec - -192 bit key: -Key Setup: 277/1595 cycles (encrypt/decrypt) -Encrypt: 439 cycles = 58.3 mbits/sec -Decrypt: 425 cycles = 60.2 mbits/sec -Mean: 432 cycles = 59.3 mbits/sec - -256 bit key: -Key Setup: 374/1960 cycles (encrypt/decrypt) -Encrypt: 502 cycles = 51.0 mbits/sec -Decrypt: 498 cycles = 51.4 mbits/sec -Mean: 500 cycles = 51.2 mbits/sec - -*/ - -#include "config.h" #include "rijndael.h" - -void gen_tabs __P((void)); - -/* 3. Basic macros for speeding up generic operations */ - -/* Circular rotate of 32 bit values */ - -#define rotr(x,n) (((x) >> ((int)(n))) | ((x) << (32 - (int)(n)))) -#define rotl(x,n) (((x) << ((int)(n))) | ((x) >> (32 - (int)(n)))) - -/* Invert byte order in a 32 bit variable */ - -#define bswap(x) ((rotl(x, 8) & 0x00ff00ff) | (rotr(x, 8) & 0xff00ff00)) - -/* Extract byte from a 32 bit quantity (little endian notation) */ - -#define byte(x,n) ((u1byte)((x) >> (8 * n))) - -#ifdef WORDS_BIGENDIAN -#define BYTE_SWAP -#endif - -#ifdef BYTE_SWAP -#define io_swap(x) bswap(x) -#else -#define io_swap(x) (x) -#endif - -#define LARGE_TABLES - -u1byte pow_tab[256]; -u1byte log_tab[256]; -u1byte sbx_tab[256]; -u1byte isb_tab[256]; -u4byte rco_tab[ 10]; -u4byte ft_tab[4][256]; -u4byte it_tab[4][256]; - -#ifdef LARGE_TABLES - u4byte fl_tab[4][256]; - u4byte il_tab[4][256]; -#endif - -u4byte tab_gen = 0; - -#define ff_mult(a,b) (a && b ? pow_tab[(log_tab[a] + log_tab[b]) % 255] : 0) - -#define f_rn(bo, bi, n, k) \ - bo[n] = ft_tab[0][byte(bi[n],0)] ^ \ - ft_tab[1][byte(bi[(n + 1) & 3],1)] ^ \ - ft_tab[2][byte(bi[(n + 2) & 3],2)] ^ \ - ft_tab[3][byte(bi[(n + 3) & 3],3)] ^ *(k + n) - -#define i_rn(bo, bi, n, k) \ - bo[n] = it_tab[0][byte(bi[n],0)] ^ \ - it_tab[1][byte(bi[(n + 3) & 3],1)] ^ \ - it_tab[2][byte(bi[(n + 2) & 3],2)] ^ \ - it_tab[3][byte(bi[(n + 1) & 3],3)] ^ *(k + n) - -#ifdef LARGE_TABLES - -#define ls_box(x) \ - ( fl_tab[0][byte(x, 0)] ^ \ - fl_tab[1][byte(x, 1)] ^ \ - fl_tab[2][byte(x, 2)] ^ \ - fl_tab[3][byte(x, 3)] ) - -#define f_rl(bo, bi, n, k) \ - bo[n] = fl_tab[0][byte(bi[n],0)] ^ \ - fl_tab[1][byte(bi[(n + 1) & 3],1)] ^ \ - fl_tab[2][byte(bi[(n + 2) & 3],2)] ^ \ - fl_tab[3][byte(bi[(n + 3) & 3],3)] ^ *(k + n) - -#define i_rl(bo, bi, n, k) \ - bo[n] = il_tab[0][byte(bi[n],0)] ^ \ - il_tab[1][byte(bi[(n + 3) & 3],1)] ^ \ - il_tab[2][byte(bi[(n + 2) & 3],2)] ^ \ - il_tab[3][byte(bi[(n + 1) & 3],3)] ^ *(k + n) - -#else - -#define ls_box(x) \ - ((u4byte)sbx_tab[byte(x, 0)] << 0) ^ \ - ((u4byte)sbx_tab[byte(x, 1)] << 8) ^ \ - ((u4byte)sbx_tab[byte(x, 2)] << 16) ^ \ - ((u4byte)sbx_tab[byte(x, 3)] << 24) - -#define f_rl(bo, bi, n, k) \ - bo[n] = (u4byte)sbx_tab[byte(bi[n],0)] ^ \ - rotl(((u4byte)sbx_tab[byte(bi[(n + 1) & 3],1)]), 8) ^ \ - rotl(((u4byte)sbx_tab[byte(bi[(n + 2) & 3],2)]), 16) ^ \ - rotl(((u4byte)sbx_tab[byte(bi[(n + 3) & 3],3)]), 24) ^ *(k + n) - -#define i_rl(bo, bi, n, k) \ - bo[n] = (u4byte)isb_tab[byte(bi[n],0)] ^ \ - rotl(((u4byte)isb_tab[byte(bi[(n + 3) & 3],1)]), 8) ^ \ - rotl(((u4byte)isb_tab[byte(bi[(n + 2) & 3],2)]), 16) ^ \ - rotl(((u4byte)isb_tab[byte(bi[(n + 1) & 3],3)]), 24) ^ *(k + n) - -#endif - -void -gen_tabs(void) -{ - u4byte i, t; - u1byte p, q; - - /* log and power tables for GF(2**8) finite field with */ - /* 0x11b as modular polynomial - the simplest prmitive */ - /* root is 0x11, used here to generate the tables */ - for(i = 0,p = 1; i < 256; ++i) { - pow_tab[i] = (u1byte)p; log_tab[p] = (u1byte)i; +#define FULL_UNROLL - p = p ^ (p << 1) ^ (p & 0x80 ? 0x01b : 0); - } - - log_tab[1] = 0; p = 1; - - for(i = 0; i < 10; ++i) { - rco_tab[i] = p; +/* +Te0[x] = S [x].[02, 01, 01, 03]; +Te1[x] = S [x].[03, 02, 01, 01]; +Te2[x] = S [x].[01, 03, 02, 01]; +Te3[x] = S [x].[01, 01, 03, 02]; +Te4[x] = S [x].[01, 01, 01, 01]; + +Td0[x] = Si[x].[0e, 09, 0d, 0b]; +Td1[x] = Si[x].[0b, 0e, 09, 0d]; +Td2[x] = Si[x].[0d, 0b, 0e, 09]; +Td3[x] = Si[x].[09, 0d, 0b, 0e]; +Td4[x] = Si[x].[01, 01, 01, 01]; +*/ - p = (p << 1) ^ (p & 0x80 ? 0x1b : 0); +static const u32 Te0[256] = { + 0xc66363a5U, 0xf87c7c84U, 0xee777799U, 0xf67b7b8dU, + 0xfff2f20dU, 0xd66b6bbdU, 0xde6f6fb1U, 0x91c5c554U, + 0x60303050U, 0x02010103U, 0xce6767a9U, 0x562b2b7dU, + 0xe7fefe19U, 0xb5d7d762U, 0x4dababe6U, 0xec76769aU, + 0x8fcaca45U, 0x1f82829dU, 0x89c9c940U, 0xfa7d7d87U, + 0xeffafa15U, 0xb25959ebU, 0x8e4747c9U, 0xfbf0f00bU, + 0x41adadecU, 0xb3d4d467U, 0x5fa2a2fdU, 0x45afafeaU, + 0x239c9cbfU, 0x53a4a4f7U, 0xe4727296U, 0x9bc0c05bU, + 0x75b7b7c2U, 0xe1fdfd1cU, 0x3d9393aeU, 0x4c26266aU, + 0x6c36365aU, 0x7e3f3f41U, 0xf5f7f702U, 0x83cccc4fU, + 0x6834345cU, 0x51a5a5f4U, 0xd1e5e534U, 0xf9f1f108U, + 0xe2717193U, 0xabd8d873U, 0x62313153U, 0x2a15153fU, + 0x0804040cU, 0x95c7c752U, 0x46232365U, 0x9dc3c35eU, + 0x30181828U, 0x379696a1U, 0x0a05050fU, 0x2f9a9ab5U, + 0x0e070709U, 0x24121236U, 0x1b80809bU, 0xdfe2e23dU, + 0xcdebeb26U, 0x4e272769U, 0x7fb2b2cdU, 0xea75759fU, + 0x1209091bU, 0x1d83839eU, 0x582c2c74U, 0x341a1a2eU, + 0x361b1b2dU, 0xdc6e6eb2U, 0xb45a5aeeU, 0x5ba0a0fbU, + 0xa45252f6U, 0x763b3b4dU, 0xb7d6d661U, 0x7db3b3ceU, + 0x5229297bU, 0xdde3e33eU, 0x5e2f2f71U, 0x13848497U, + 0xa65353f5U, 0xb9d1d168U, 0x00000000U, 0xc1eded2cU, + 0x40202060U, 0xe3fcfc1fU, 0x79b1b1c8U, 0xb65b5bedU, + 0xd46a6abeU, 0x8dcbcb46U, 0x67bebed9U, 0x7239394bU, + 0x944a4adeU, 0x984c4cd4U, 0xb05858e8U, 0x85cfcf4aU, + 0xbbd0d06bU, 0xc5efef2aU, 0x4faaaae5U, 0xedfbfb16U, + 0x864343c5U, 0x9a4d4dd7U, 0x66333355U, 0x11858594U, + 0x8a4545cfU, 0xe9f9f910U, 0x04020206U, 0xfe7f7f81U, + 0xa05050f0U, 0x783c3c44U, 0x259f9fbaU, 0x4ba8a8e3U, + 0xa25151f3U, 0x5da3a3feU, 0x804040c0U, 0x058f8f8aU, + 0x3f9292adU, 0x219d9dbcU, 0x70383848U, 0xf1f5f504U, + 0x63bcbcdfU, 0x77b6b6c1U, 0xafdada75U, 0x42212163U, + 0x20101030U, 0xe5ffff1aU, 0xfdf3f30eU, 0xbfd2d26dU, + 0x81cdcd4cU, 0x180c0c14U, 0x26131335U, 0xc3ecec2fU, + 0xbe5f5fe1U, 0x359797a2U, 0x884444ccU, 0x2e171739U, + 0x93c4c457U, 0x55a7a7f2U, 0xfc7e7e82U, 0x7a3d3d47U, + 0xc86464acU, 0xba5d5de7U, 0x3219192bU, 0xe6737395U, + 0xc06060a0U, 0x19818198U, 0x9e4f4fd1U, 0xa3dcdc7fU, + 0x44222266U, 0x542a2a7eU, 0x3b9090abU, 0x0b888883U, + 0x8c4646caU, 0xc7eeee29U, 0x6bb8b8d3U, 0x2814143cU, + 0xa7dede79U, 0xbc5e5ee2U, 0x160b0b1dU, 0xaddbdb76U, + 0xdbe0e03bU, 0x64323256U, 0x743a3a4eU, 0x140a0a1eU, + 0x924949dbU, 0x0c06060aU, 0x4824246cU, 0xb85c5ce4U, + 0x9fc2c25dU, 0xbdd3d36eU, 0x43acacefU, 0xc46262a6U, + 0x399191a8U, 0x319595a4U, 0xd3e4e437U, 0xf279798bU, + 0xd5e7e732U, 0x8bc8c843U, 0x6e373759U, 0xda6d6db7U, + 0x018d8d8cU, 0xb1d5d564U, 0x9c4e4ed2U, 0x49a9a9e0U, + 0xd86c6cb4U, 0xac5656faU, 0xf3f4f407U, 0xcfeaea25U, + 0xca6565afU, 0xf47a7a8eU, 0x47aeaee9U, 0x10080818U, + 0x6fbabad5U, 0xf0787888U, 0x4a25256fU, 0x5c2e2e72U, + 0x381c1c24U, 0x57a6a6f1U, 0x73b4b4c7U, 0x97c6c651U, + 0xcbe8e823U, 0xa1dddd7cU, 0xe874749cU, 0x3e1f1f21U, + 0x964b4bddU, 0x61bdbddcU, 0x0d8b8b86U, 0x0f8a8a85U, + 0xe0707090U, 0x7c3e3e42U, 0x71b5b5c4U, 0xcc6666aaU, + 0x904848d8U, 0x06030305U, 0xf7f6f601U, 0x1c0e0e12U, + 0xc26161a3U, 0x6a35355fU, 0xae5757f9U, 0x69b9b9d0U, + 0x17868691U, 0x99c1c158U, 0x3a1d1d27U, 0x279e9eb9U, + 0xd9e1e138U, 0xebf8f813U, 0x2b9898b3U, 0x22111133U, + 0xd26969bbU, 0xa9d9d970U, 0x078e8e89U, 0x339494a7U, + 0x2d9b9bb6U, 0x3c1e1e22U, 0x15878792U, 0xc9e9e920U, + 0x87cece49U, 0xaa5555ffU, 0x50282878U, 0xa5dfdf7aU, + 0x038c8c8fU, 0x59a1a1f8U, 0x09898980U, 0x1a0d0d17U, + 0x65bfbfdaU, 0xd7e6e631U, 0x844242c6U, 0xd06868b8U, + 0x824141c3U, 0x299999b0U, 0x5a2d2d77U, 0x1e0f0f11U, + 0x7bb0b0cbU, 0xa85454fcU, 0x6dbbbbd6U, 0x2c16163aU, +}; +static const u32 Te1[256] = { + 0xa5c66363U, 0x84f87c7cU, 0x99ee7777U, 0x8df67b7bU, + 0x0dfff2f2U, 0xbdd66b6bU, 0xb1de6f6fU, 0x5491c5c5U, + 0x50603030U, 0x03020101U, 0xa9ce6767U, 0x7d562b2bU, + 0x19e7fefeU, 0x62b5d7d7U, 0xe64dababU, 0x9aec7676U, + 0x458fcacaU, 0x9d1f8282U, 0x4089c9c9U, 0x87fa7d7dU, + 0x15effafaU, 0xebb25959U, 0xc98e4747U, 0x0bfbf0f0U, + 0xec41adadU, 0x67b3d4d4U, 0xfd5fa2a2U, 0xea45afafU, + 0xbf239c9cU, 0xf753a4a4U, 0x96e47272U, 0x5b9bc0c0U, + 0xc275b7b7U, 0x1ce1fdfdU, 0xae3d9393U, 0x6a4c2626U, + 0x5a6c3636U, 0x417e3f3fU, 0x02f5f7f7U, 0x4f83ccccU, + 0x5c683434U, 0xf451a5a5U, 0x34d1e5e5U, 0x08f9f1f1U, + 0x93e27171U, 0x73abd8d8U, 0x53623131U, 0x3f2a1515U, + 0x0c080404U, 0x5295c7c7U, 0x65462323U, 0x5e9dc3c3U, + 0x28301818U, 0xa1379696U, 0x0f0a0505U, 0xb52f9a9aU, + 0x090e0707U, 0x36241212U, 0x9b1b8080U, 0x3ddfe2e2U, + 0x26cdebebU, 0x694e2727U, 0xcd7fb2b2U, 0x9fea7575U, + 0x1b120909U, 0x9e1d8383U, 0x74582c2cU, 0x2e341a1aU, + 0x2d361b1bU, 0xb2dc6e6eU, 0xeeb45a5aU, 0xfb5ba0a0U, + 0xf6a45252U, 0x4d763b3bU, 0x61b7d6d6U, 0xce7db3b3U, + 0x7b522929U, 0x3edde3e3U, 0x715e2f2fU, 0x97138484U, + 0xf5a65353U, 0x68b9d1d1U, 0x00000000U, 0x2cc1ededU, + 0x60402020U, 0x1fe3fcfcU, 0xc879b1b1U, 0xedb65b5bU, + 0xbed46a6aU, 0x468dcbcbU, 0xd967bebeU, 0x4b723939U, + 0xde944a4aU, 0xd4984c4cU, 0xe8b05858U, 0x4a85cfcfU, + 0x6bbbd0d0U, 0x2ac5efefU, 0xe54faaaaU, 0x16edfbfbU, + 0xc5864343U, 0xd79a4d4dU, 0x55663333U, 0x94118585U, + 0xcf8a4545U, 0x10e9f9f9U, 0x06040202U, 0x81fe7f7fU, + 0xf0a05050U, 0x44783c3cU, 0xba259f9fU, 0xe34ba8a8U, + 0xf3a25151U, 0xfe5da3a3U, 0xc0804040U, 0x8a058f8fU, + 0xad3f9292U, 0xbc219d9dU, 0x48703838U, 0x04f1f5f5U, + 0xdf63bcbcU, 0xc177b6b6U, 0x75afdadaU, 0x63422121U, + 0x30201010U, 0x1ae5ffffU, 0x0efdf3f3U, 0x6dbfd2d2U, + 0x4c81cdcdU, 0x14180c0cU, 0x35261313U, 0x2fc3ececU, + 0xe1be5f5fU, 0xa2359797U, 0xcc884444U, 0x392e1717U, + 0x5793c4c4U, 0xf255a7a7U, 0x82fc7e7eU, 0x477a3d3dU, + 0xacc86464U, 0xe7ba5d5dU, 0x2b321919U, 0x95e67373U, + 0xa0c06060U, 0x98198181U, 0xd19e4f4fU, 0x7fa3dcdcU, + 0x66442222U, 0x7e542a2aU, 0xab3b9090U, 0x830b8888U, + 0xca8c4646U, 0x29c7eeeeU, 0xd36bb8b8U, 0x3c281414U, + 0x79a7dedeU, 0xe2bc5e5eU, 0x1d160b0bU, 0x76addbdbU, + 0x3bdbe0e0U, 0x56643232U, 0x4e743a3aU, 0x1e140a0aU, + 0xdb924949U, 0x0a0c0606U, 0x6c482424U, 0xe4b85c5cU, + 0x5d9fc2c2U, 0x6ebdd3d3U, 0xef43acacU, 0xa6c46262U, + 0xa8399191U, 0xa4319595U, 0x37d3e4e4U, 0x8bf27979U, + 0x32d5e7e7U, 0x438bc8c8U, 0x596e3737U, 0xb7da6d6dU, + 0x8c018d8dU, 0x64b1d5d5U, 0xd29c4e4eU, 0xe049a9a9U, + 0xb4d86c6cU, 0xfaac5656U, 0x07f3f4f4U, 0x25cfeaeaU, + 0xafca6565U, 0x8ef47a7aU, 0xe947aeaeU, 0x18100808U, + 0xd56fbabaU, 0x88f07878U, 0x6f4a2525U, 0x725c2e2eU, + 0x24381c1cU, 0xf157a6a6U, 0xc773b4b4U, 0x5197c6c6U, + 0x23cbe8e8U, 0x7ca1ddddU, 0x9ce87474U, 0x213e1f1fU, + 0xdd964b4bU, 0xdc61bdbdU, 0x860d8b8bU, 0x850f8a8aU, + 0x90e07070U, 0x427c3e3eU, 0xc471b5b5U, 0xaacc6666U, + 0xd8904848U, 0x05060303U, 0x01f7f6f6U, 0x121c0e0eU, + 0xa3c26161U, 0x5f6a3535U, 0xf9ae5757U, 0xd069b9b9U, + 0x91178686U, 0x5899c1c1U, 0x273a1d1dU, 0xb9279e9eU, + 0x38d9e1e1U, 0x13ebf8f8U, 0xb32b9898U, 0x33221111U, + 0xbbd26969U, 0x70a9d9d9U, 0x89078e8eU, 0xa7339494U, + 0xb62d9b9bU, 0x223c1e1eU, 0x92158787U, 0x20c9e9e9U, + 0x4987ceceU, 0xffaa5555U, 0x78502828U, 0x7aa5dfdfU, + 0x8f038c8cU, 0xf859a1a1U, 0x80098989U, 0x171a0d0dU, + 0xda65bfbfU, 0x31d7e6e6U, 0xc6844242U, 0xb8d06868U, + 0xc3824141U, 0xb0299999U, 0x775a2d2dU, 0x111e0f0fU, + 0xcb7bb0b0U, 0xfca85454U, 0xd66dbbbbU, 0x3a2c1616U, +}; +static const u32 Te2[256] = { + 0x63a5c663U, 0x7c84f87cU, 0x7799ee77U, 0x7b8df67bU, + 0xf20dfff2U, 0x6bbdd66bU, 0x6fb1de6fU, 0xc55491c5U, + 0x30506030U, 0x01030201U, 0x67a9ce67U, 0x2b7d562bU, + 0xfe19e7feU, 0xd762b5d7U, 0xabe64dabU, 0x769aec76U, + 0xca458fcaU, 0x829d1f82U, 0xc94089c9U, 0x7d87fa7dU, + 0xfa15effaU, 0x59ebb259U, 0x47c98e47U, 0xf00bfbf0U, + 0xadec41adU, 0xd467b3d4U, 0xa2fd5fa2U, 0xafea45afU, + 0x9cbf239cU, 0xa4f753a4U, 0x7296e472U, 0xc05b9bc0U, + 0xb7c275b7U, 0xfd1ce1fdU, 0x93ae3d93U, 0x266a4c26U, + 0x365a6c36U, 0x3f417e3fU, 0xf702f5f7U, 0xcc4f83ccU, + 0x345c6834U, 0xa5f451a5U, 0xe534d1e5U, 0xf108f9f1U, + 0x7193e271U, 0xd873abd8U, 0x31536231U, 0x153f2a15U, + 0x040c0804U, 0xc75295c7U, 0x23654623U, 0xc35e9dc3U, + 0x18283018U, 0x96a13796U, 0x050f0a05U, 0x9ab52f9aU, + 0x07090e07U, 0x12362412U, 0x809b1b80U, 0xe23ddfe2U, + 0xeb26cdebU, 0x27694e27U, 0xb2cd7fb2U, 0x759fea75U, + 0x091b1209U, 0x839e1d83U, 0x2c74582cU, 0x1a2e341aU, + 0x1b2d361bU, 0x6eb2dc6eU, 0x5aeeb45aU, 0xa0fb5ba0U, + 0x52f6a452U, 0x3b4d763bU, 0xd661b7d6U, 0xb3ce7db3U, + 0x297b5229U, 0xe33edde3U, 0x2f715e2fU, 0x84971384U, + 0x53f5a653U, 0xd168b9d1U, 0x00000000U, 0xed2cc1edU, + 0x20604020U, 0xfc1fe3fcU, 0xb1c879b1U, 0x5bedb65bU, + 0x6abed46aU, 0xcb468dcbU, 0xbed967beU, 0x394b7239U, + 0x4ade944aU, 0x4cd4984cU, 0x58e8b058U, 0xcf4a85cfU, + 0xd06bbbd0U, 0xef2ac5efU, 0xaae54faaU, 0xfb16edfbU, + 0x43c58643U, 0x4dd79a4dU, 0x33556633U, 0x85941185U, + 0x45cf8a45U, 0xf910e9f9U, 0x02060402U, 0x7f81fe7fU, + 0x50f0a050U, 0x3c44783cU, 0x9fba259fU, 0xa8e34ba8U, + 0x51f3a251U, 0xa3fe5da3U, 0x40c08040U, 0x8f8a058fU, + 0x92ad3f92U, 0x9dbc219dU, 0x38487038U, 0xf504f1f5U, + 0xbcdf63bcU, 0xb6c177b6U, 0xda75afdaU, 0x21634221U, + 0x10302010U, 0xff1ae5ffU, 0xf30efdf3U, 0xd26dbfd2U, + 0xcd4c81cdU, 0x0c14180cU, 0x13352613U, 0xec2fc3ecU, + 0x5fe1be5fU, 0x97a23597U, 0x44cc8844U, 0x17392e17U, + 0xc45793c4U, 0xa7f255a7U, 0x7e82fc7eU, 0x3d477a3dU, + 0x64acc864U, 0x5de7ba5dU, 0x192b3219U, 0x7395e673U, + 0x60a0c060U, 0x81981981U, 0x4fd19e4fU, 0xdc7fa3dcU, + 0x22664422U, 0x2a7e542aU, 0x90ab3b90U, 0x88830b88U, + 0x46ca8c46U, 0xee29c7eeU, 0xb8d36bb8U, 0x143c2814U, + 0xde79a7deU, 0x5ee2bc5eU, 0x0b1d160bU, 0xdb76addbU, + 0xe03bdbe0U, 0x32566432U, 0x3a4e743aU, 0x0a1e140aU, + 0x49db9249U, 0x060a0c06U, 0x246c4824U, 0x5ce4b85cU, + 0xc25d9fc2U, 0xd36ebdd3U, 0xacef43acU, 0x62a6c462U, + 0x91a83991U, 0x95a43195U, 0xe437d3e4U, 0x798bf279U, + 0xe732d5e7U, 0xc8438bc8U, 0x37596e37U, 0x6db7da6dU, + 0x8d8c018dU, 0xd564b1d5U, 0x4ed29c4eU, 0xa9e049a9U, + 0x6cb4d86cU, 0x56faac56U, 0xf407f3f4U, 0xea25cfeaU, + 0x65afca65U, 0x7a8ef47aU, 0xaee947aeU, 0x08181008U, + 0xbad56fbaU, 0x7888f078U, 0x256f4a25U, 0x2e725c2eU, + 0x1c24381cU, 0xa6f157a6U, 0xb4c773b4U, 0xc65197c6U, + 0xe823cbe8U, 0xdd7ca1ddU, 0x749ce874U, 0x1f213e1fU, + 0x4bdd964bU, 0xbddc61bdU, 0x8b860d8bU, 0x8a850f8aU, + 0x7090e070U, 0x3e427c3eU, 0xb5c471b5U, 0x66aacc66U, + 0x48d89048U, 0x03050603U, 0xf601f7f6U, 0x0e121c0eU, + 0x61a3c261U, 0x355f6a35U, 0x57f9ae57U, 0xb9d069b9U, + 0x86911786U, 0xc15899c1U, 0x1d273a1dU, 0x9eb9279eU, + 0xe138d9e1U, 0xf813ebf8U, 0x98b32b98U, 0x11332211U, + 0x69bbd269U, 0xd970a9d9U, 0x8e89078eU, 0x94a73394U, + 0x9bb62d9bU, 0x1e223c1eU, 0x87921587U, 0xe920c9e9U, + 0xce4987ceU, 0x55ffaa55U, 0x28785028U, 0xdf7aa5dfU, + 0x8c8f038cU, 0xa1f859a1U, 0x89800989U, 0x0d171a0dU, + 0xbfda65bfU, 0xe631d7e6U, 0x42c68442U, 0x68b8d068U, + 0x41c38241U, 0x99b02999U, 0x2d775a2dU, 0x0f111e0fU, + 0xb0cb7bb0U, 0x54fca854U, 0xbbd66dbbU, 0x163a2c16U, +}; +static const u32 Te3[256] = { + + 0x6363a5c6U, 0x7c7c84f8U, 0x777799eeU, 0x7b7b8df6U, + 0xf2f20dffU, 0x6b6bbdd6U, 0x6f6fb1deU, 0xc5c55491U, + 0x30305060U, 0x01010302U, 0x6767a9ceU, 0x2b2b7d56U, + 0xfefe19e7U, 0xd7d762b5U, 0xababe64dU, 0x76769aecU, + 0xcaca458fU, 0x82829d1fU, 0xc9c94089U, 0x7d7d87faU, + 0xfafa15efU, 0x5959ebb2U, 0x4747c98eU, 0xf0f00bfbU, + 0xadadec41U, 0xd4d467b3U, 0xa2a2fd5fU, 0xafafea45U, + 0x9c9cbf23U, 0xa4a4f753U, 0x727296e4U, 0xc0c05b9bU, + 0xb7b7c275U, 0xfdfd1ce1U, 0x9393ae3dU, 0x26266a4cU, + 0x36365a6cU, 0x3f3f417eU, 0xf7f702f5U, 0xcccc4f83U, + 0x34345c68U, 0xa5a5f451U, 0xe5e534d1U, 0xf1f108f9U, + 0x717193e2U, 0xd8d873abU, 0x31315362U, 0x15153f2aU, + 0x04040c08U, 0xc7c75295U, 0x23236546U, 0xc3c35e9dU, + 0x18182830U, 0x9696a137U, 0x05050f0aU, 0x9a9ab52fU, + 0x0707090eU, 0x12123624U, 0x80809b1bU, 0xe2e23ddfU, + 0xebeb26cdU, 0x2727694eU, 0xb2b2cd7fU, 0x75759feaU, + 0x09091b12U, 0x83839e1dU, 0x2c2c7458U, 0x1a1a2e34U, + 0x1b1b2d36U, 0x6e6eb2dcU, 0x5a5aeeb4U, 0xa0a0fb5bU, + 0x5252f6a4U, 0x3b3b4d76U, 0xd6d661b7U, 0xb3b3ce7dU, + 0x29297b52U, 0xe3e33eddU, 0x2f2f715eU, 0x84849713U, + 0x5353f5a6U, 0xd1d168b9U, 0x00000000U, 0xeded2cc1U, + 0x20206040U, 0xfcfc1fe3U, 0xb1b1c879U, 0x5b5bedb6U, + 0x6a6abed4U, 0xcbcb468dU, 0xbebed967U, 0x39394b72U, + 0x4a4ade94U, 0x4c4cd498U, 0x5858e8b0U, 0xcfcf4a85U, + 0xd0d06bbbU, 0xefef2ac5U, 0xaaaae54fU, 0xfbfb16edU, + 0x4343c586U, 0x4d4dd79aU, 0x33335566U, 0x85859411U, + 0x4545cf8aU, 0xf9f910e9U, 0x02020604U, 0x7f7f81feU, + 0x5050f0a0U, 0x3c3c4478U, 0x9f9fba25U, 0xa8a8e34bU, + 0x5151f3a2U, 0xa3a3fe5dU, 0x4040c080U, 0x8f8f8a05U, + 0x9292ad3fU, 0x9d9dbc21U, 0x38384870U, 0xf5f504f1U, + 0xbcbcdf63U, 0xb6b6c177U, 0xdada75afU, 0x21216342U, + 0x10103020U, 0xffff1ae5U, 0xf3f30efdU, 0xd2d26dbfU, + 0xcdcd4c81U, 0x0c0c1418U, 0x13133526U, 0xecec2fc3U, + 0x5f5fe1beU, 0x9797a235U, 0x4444cc88U, 0x1717392eU, + 0xc4c45793U, 0xa7a7f255U, 0x7e7e82fcU, 0x3d3d477aU, + 0x6464acc8U, 0x5d5de7baU, 0x19192b32U, 0x737395e6U, + 0x6060a0c0U, 0x81819819U, 0x4f4fd19eU, 0xdcdc7fa3U, + 0x22226644U, 0x2a2a7e54U, 0x9090ab3bU, 0x8888830bU, + 0x4646ca8cU, 0xeeee29c7U, 0xb8b8d36bU, 0x14143c28U, + 0xdede79a7U, 0x5e5ee2bcU, 0x0b0b1d16U, 0xdbdb76adU, + 0xe0e03bdbU, 0x32325664U, 0x3a3a4e74U, 0x0a0a1e14U, + 0x4949db92U, 0x06060a0cU, 0x24246c48U, 0x5c5ce4b8U, + 0xc2c25d9fU, 0xd3d36ebdU, 0xacacef43U, 0x6262a6c4U, + 0x9191a839U, 0x9595a431U, 0xe4e437d3U, 0x79798bf2U, + 0xe7e732d5U, 0xc8c8438bU, 0x3737596eU, 0x6d6db7daU, + 0x8d8d8c01U, 0xd5d564b1U, 0x4e4ed29cU, 0xa9a9e049U, + 0x6c6cb4d8U, 0x5656faacU, 0xf4f407f3U, 0xeaea25cfU, + 0x6565afcaU, 0x7a7a8ef4U, 0xaeaee947U, 0x08081810U, + 0xbabad56fU, 0x787888f0U, 0x25256f4aU, 0x2e2e725cU, + 0x1c1c2438U, 0xa6a6f157U, 0xb4b4c773U, 0xc6c65197U, + 0xe8e823cbU, 0xdddd7ca1U, 0x74749ce8U, 0x1f1f213eU, + 0x4b4bdd96U, 0xbdbddc61U, 0x8b8b860dU, 0x8a8a850fU, + 0x707090e0U, 0x3e3e427cU, 0xb5b5c471U, 0x6666aaccU, + 0x4848d890U, 0x03030506U, 0xf6f601f7U, 0x0e0e121cU, + 0x6161a3c2U, 0x35355f6aU, 0x5757f9aeU, 0xb9b9d069U, + 0x86869117U, 0xc1c15899U, 0x1d1d273aU, 0x9e9eb927U, + 0xe1e138d9U, 0xf8f813ebU, 0x9898b32bU, 0x11113322U, + 0x6969bbd2U, 0xd9d970a9U, 0x8e8e8907U, 0x9494a733U, + 0x9b9bb62dU, 0x1e1e223cU, 0x87879215U, 0xe9e920c9U, + 0xcece4987U, 0x5555ffaaU, 0x28287850U, 0xdfdf7aa5U, + 0x8c8c8f03U, 0xa1a1f859U, 0x89898009U, 0x0d0d171aU, + 0xbfbfda65U, 0xe6e631d7U, 0x4242c684U, 0x6868b8d0U, + 0x4141c382U, 0x9999b029U, 0x2d2d775aU, 0x0f0f111eU, + 0xb0b0cb7bU, 0x5454fca8U, 0xbbbbd66dU, 0x16163a2cU, +}; +static const u32 Te4[256] = { + 0x63636363U, 0x7c7c7c7cU, 0x77777777U, 0x7b7b7b7bU, + 0xf2f2f2f2U, 0x6b6b6b6bU, 0x6f6f6f6fU, 0xc5c5c5c5U, + 0x30303030U, 0x01010101U, 0x67676767U, 0x2b2b2b2bU, + 0xfefefefeU, 0xd7d7d7d7U, 0xababababU, 0x76767676U, + 0xcacacacaU, 0x82828282U, 0xc9c9c9c9U, 0x7d7d7d7dU, + 0xfafafafaU, 0x59595959U, 0x47474747U, 0xf0f0f0f0U, + 0xadadadadU, 0xd4d4d4d4U, 0xa2a2a2a2U, 0xafafafafU, + 0x9c9c9c9cU, 0xa4a4a4a4U, 0x72727272U, 0xc0c0c0c0U, + 0xb7b7b7b7U, 0xfdfdfdfdU, 0x93939393U, 0x26262626U, + 0x36363636U, 0x3f3f3f3fU, 0xf7f7f7f7U, 0xccccccccU, + 0x34343434U, 0xa5a5a5a5U, 0xe5e5e5e5U, 0xf1f1f1f1U, + 0x71717171U, 0xd8d8d8d8U, 0x31313131U, 0x15151515U, + 0x04040404U, 0xc7c7c7c7U, 0x23232323U, 0xc3c3c3c3U, + 0x18181818U, 0x96969696U, 0x05050505U, 0x9a9a9a9aU, + 0x07070707U, 0x12121212U, 0x80808080U, 0xe2e2e2e2U, + 0xebebebebU, 0x27272727U, 0xb2b2b2b2U, 0x75757575U, + 0x09090909U, 0x83838383U, 0x2c2c2c2cU, 0x1a1a1a1aU, + 0x1b1b1b1bU, 0x6e6e6e6eU, 0x5a5a5a5aU, 0xa0a0a0a0U, + 0x52525252U, 0x3b3b3b3bU, 0xd6d6d6d6U, 0xb3b3b3b3U, + 0x29292929U, 0xe3e3e3e3U, 0x2f2f2f2fU, 0x84848484U, + 0x53535353U, 0xd1d1d1d1U, 0x00000000U, 0xededededU, + 0x20202020U, 0xfcfcfcfcU, 0xb1b1b1b1U, 0x5b5b5b5bU, + 0x6a6a6a6aU, 0xcbcbcbcbU, 0xbebebebeU, 0x39393939U, + 0x4a4a4a4aU, 0x4c4c4c4cU, 0x58585858U, 0xcfcfcfcfU, + 0xd0d0d0d0U, 0xefefefefU, 0xaaaaaaaaU, 0xfbfbfbfbU, + 0x43434343U, 0x4d4d4d4dU, 0x33333333U, 0x85858585U, + 0x45454545U, 0xf9f9f9f9U, 0x02020202U, 0x7f7f7f7fU, + 0x50505050U, 0x3c3c3c3cU, 0x9f9f9f9fU, 0xa8a8a8a8U, + 0x51515151U, 0xa3a3a3a3U, 0x40404040U, 0x8f8f8f8fU, + 0x92929292U, 0x9d9d9d9dU, 0x38383838U, 0xf5f5f5f5U, + 0xbcbcbcbcU, 0xb6b6b6b6U, 0xdadadadaU, 0x21212121U, + 0x10101010U, 0xffffffffU, 0xf3f3f3f3U, 0xd2d2d2d2U, + 0xcdcdcdcdU, 0x0c0c0c0cU, 0x13131313U, 0xececececU, + 0x5f5f5f5fU, 0x97979797U, 0x44444444U, 0x17171717U, + 0xc4c4c4c4U, 0xa7a7a7a7U, 0x7e7e7e7eU, 0x3d3d3d3dU, + 0x64646464U, 0x5d5d5d5dU, 0x19191919U, 0x73737373U, + 0x60606060U, 0x81818181U, 0x4f4f4f4fU, 0xdcdcdcdcU, + 0x22222222U, 0x2a2a2a2aU, 0x90909090U, 0x88888888U, + 0x46464646U, 0xeeeeeeeeU, 0xb8b8b8b8U, 0x14141414U, + 0xdedededeU, 0x5e5e5e5eU, 0x0b0b0b0bU, 0xdbdbdbdbU, + 0xe0e0e0e0U, 0x32323232U, 0x3a3a3a3aU, 0x0a0a0a0aU, + 0x49494949U, 0x06060606U, 0x24242424U, 0x5c5c5c5cU, + 0xc2c2c2c2U, 0xd3d3d3d3U, 0xacacacacU, 0x62626262U, + 0x91919191U, 0x95959595U, 0xe4e4e4e4U, 0x79797979U, + 0xe7e7e7e7U, 0xc8c8c8c8U, 0x37373737U, 0x6d6d6d6dU, + 0x8d8d8d8dU, 0xd5d5d5d5U, 0x4e4e4e4eU, 0xa9a9a9a9U, + 0x6c6c6c6cU, 0x56565656U, 0xf4f4f4f4U, 0xeaeaeaeaU, + 0x65656565U, 0x7a7a7a7aU, 0xaeaeaeaeU, 0x08080808U, + 0xbabababaU, 0x78787878U, 0x25252525U, 0x2e2e2e2eU, + 0x1c1c1c1cU, 0xa6a6a6a6U, 0xb4b4b4b4U, 0xc6c6c6c6U, + 0xe8e8e8e8U, 0xddddddddU, 0x74747474U, 0x1f1f1f1fU, + 0x4b4b4b4bU, 0xbdbdbdbdU, 0x8b8b8b8bU, 0x8a8a8a8aU, + 0x70707070U, 0x3e3e3e3eU, 0xb5b5b5b5U, 0x66666666U, + 0x48484848U, 0x03030303U, 0xf6f6f6f6U, 0x0e0e0e0eU, + 0x61616161U, 0x35353535U, 0x57575757U, 0xb9b9b9b9U, + 0x86868686U, 0xc1c1c1c1U, 0x1d1d1d1dU, 0x9e9e9e9eU, + 0xe1e1e1e1U, 0xf8f8f8f8U, 0x98989898U, 0x11111111U, + 0x69696969U, 0xd9d9d9d9U, 0x8e8e8e8eU, 0x94949494U, + 0x9b9b9b9bU, 0x1e1e1e1eU, 0x87878787U, 0xe9e9e9e9U, + 0xcecececeU, 0x55555555U, 0x28282828U, 0xdfdfdfdfU, + 0x8c8c8c8cU, 0xa1a1a1a1U, 0x89898989U, 0x0d0d0d0dU, + 0xbfbfbfbfU, 0xe6e6e6e6U, 0x42424242U, 0x68686868U, + 0x41414141U, 0x99999999U, 0x2d2d2d2dU, 0x0f0f0f0fU, + 0xb0b0b0b0U, 0x54545454U, 0xbbbbbbbbU, 0x16161616U, +}; +static const u32 Td0[256] = { + 0x51f4a750U, 0x7e416553U, 0x1a17a4c3U, 0x3a275e96U, + 0x3bab6bcbU, 0x1f9d45f1U, 0xacfa58abU, 0x4be30393U, + 0x2030fa55U, 0xad766df6U, 0x88cc7691U, 0xf5024c25U, + 0x4fe5d7fcU, 0xc52acbd7U, 0x26354480U, 0xb562a38fU, + 0xdeb15a49U, 0x25ba1b67U, 0x45ea0e98U, 0x5dfec0e1U, + 0xc32f7502U, 0x814cf012U, 0x8d4697a3U, 0x6bd3f9c6U, + 0x038f5fe7U, 0x15929c95U, 0xbf6d7aebU, 0x955259daU, + 0xd4be832dU, 0x587421d3U, 0x49e06929U, 0x8ec9c844U, + 0x75c2896aU, 0xf48e7978U, 0x99583e6bU, 0x27b971ddU, + 0xbee14fb6U, 0xf088ad17U, 0xc920ac66U, 0x7dce3ab4U, + 0x63df4a18U, 0xe51a3182U, 0x97513360U, 0x62537f45U, + 0xb16477e0U, 0xbb6bae84U, 0xfe81a01cU, 0xf9082b94U, + 0x70486858U, 0x8f45fd19U, 0x94de6c87U, 0x527bf8b7U, + 0xab73d323U, 0x724b02e2U, 0xe31f8f57U, 0x6655ab2aU, + 0xb2eb2807U, 0x2fb5c203U, 0x86c57b9aU, 0xd33708a5U, + 0x302887f2U, 0x23bfa5b2U, 0x02036abaU, 0xed16825cU, + 0x8acf1c2bU, 0xa779b492U, 0xf307f2f0U, 0x4e69e2a1U, + 0x65daf4cdU, 0x0605bed5U, 0xd134621fU, 0xc4a6fe8aU, + 0x342e539dU, 0xa2f355a0U, 0x058ae132U, 0xa4f6eb75U, + 0x0b83ec39U, 0x4060efaaU, 0x5e719f06U, 0xbd6e1051U, + 0x3e218af9U, 0x96dd063dU, 0xdd3e05aeU, 0x4de6bd46U, + 0x91548db5U, 0x71c45d05U, 0x0406d46fU, 0x605015ffU, + 0x1998fb24U, 0xd6bde997U, 0x894043ccU, 0x67d99e77U, + 0xb0e842bdU, 0x07898b88U, 0xe7195b38U, 0x79c8eedbU, + 0xa17c0a47U, 0x7c420fe9U, 0xf8841ec9U, 0x00000000U, + 0x09808683U, 0x322bed48U, 0x1e1170acU, 0x6c5a724eU, + 0xfd0efffbU, 0x0f853856U, 0x3daed51eU, 0x362d3927U, + 0x0a0fd964U, 0x685ca621U, 0x9b5b54d1U, 0x24362e3aU, + 0x0c0a67b1U, 0x9357e70fU, 0xb4ee96d2U, 0x1b9b919eU, + 0x80c0c54fU, 0x61dc20a2U, 0x5a774b69U, 0x1c121a16U, + 0xe293ba0aU, 0xc0a02ae5U, 0x3c22e043U, 0x121b171dU, + 0x0e090d0bU, 0xf28bc7adU, 0x2db6a8b9U, 0x141ea9c8U, + 0x57f11985U, 0xaf75074cU, 0xee99ddbbU, 0xa37f60fdU, + 0xf701269fU, 0x5c72f5bcU, 0x44663bc5U, 0x5bfb7e34U, + 0x8b432976U, 0xcb23c6dcU, 0xb6edfc68U, 0xb8e4f163U, + 0xd731dccaU, 0x42638510U, 0x13972240U, 0x84c61120U, + 0x854a247dU, 0xd2bb3df8U, 0xaef93211U, 0xc729a16dU, + 0x1d9e2f4bU, 0xdcb230f3U, 0x0d8652ecU, 0x77c1e3d0U, + 0x2bb3166cU, 0xa970b999U, 0x119448faU, 0x47e96422U, + 0xa8fc8cc4U, 0xa0f03f1aU, 0x567d2cd8U, 0x223390efU, + 0x87494ec7U, 0xd938d1c1U, 0x8ccaa2feU, 0x98d40b36U, + 0xa6f581cfU, 0xa57ade28U, 0xdab78e26U, 0x3fadbfa4U, + 0x2c3a9de4U, 0x5078920dU, 0x6a5fcc9bU, 0x547e4662U, + 0xf68d13c2U, 0x90d8b8e8U, 0x2e39f75eU, 0x82c3aff5U, + 0x9f5d80beU, 0x69d0937cU, 0x6fd52da9U, 0xcf2512b3U, + 0xc8ac993bU, 0x10187da7U, 0xe89c636eU, 0xdb3bbb7bU, + 0xcd267809U, 0x6e5918f4U, 0xec9ab701U, 0x834f9aa8U, + 0xe6956e65U, 0xaaffe67eU, 0x21bccf08U, 0xef15e8e6U, + 0xbae79bd9U, 0x4a6f36ceU, 0xea9f09d4U, 0x29b07cd6U, + 0x31a4b2afU, 0x2a3f2331U, 0xc6a59430U, 0x35a266c0U, + 0x744ebc37U, 0xfc82caa6U, 0xe090d0b0U, 0x33a7d815U, + 0xf104984aU, 0x41ecdaf7U, 0x7fcd500eU, 0x1791f62fU, + 0x764dd68dU, 0x43efb04dU, 0xccaa4d54U, 0xe49604dfU, + 0x9ed1b5e3U, 0x4c6a881bU, 0xc12c1fb8U, 0x4665517fU, + 0x9d5eea04U, 0x018c355dU, 0xfa877473U, 0xfb0b412eU, + 0xb3671d5aU, 0x92dbd252U, 0xe9105633U, 0x6dd64713U, + 0x9ad7618cU, 0x37a10c7aU, 0x59f8148eU, 0xeb133c89U, + 0xcea927eeU, 0xb761c935U, 0xe11ce5edU, 0x7a47b13cU, + 0x9cd2df59U, 0x55f2733fU, 0x1814ce79U, 0x73c737bfU, + 0x53f7cdeaU, 0x5ffdaa5bU, 0xdf3d6f14U, 0x7844db86U, + 0xcaaff381U, 0xb968c43eU, 0x3824342cU, 0xc2a3405fU, + 0x161dc372U, 0xbce2250cU, 0x283c498bU, 0xff0d9541U, + 0x39a80171U, 0x080cb3deU, 0xd8b4e49cU, 0x6456c190U, + 0x7bcb8461U, 0xd532b670U, 0x486c5c74U, 0xd0b85742U, +}; +static const u32 Td1[256] = { + 0x5051f4a7U, 0x537e4165U, 0xc31a17a4U, 0x963a275eU, + 0xcb3bab6bU, 0xf11f9d45U, 0xabacfa58U, 0x934be303U, + 0x552030faU, 0xf6ad766dU, 0x9188cc76U, 0x25f5024cU, + 0xfc4fe5d7U, 0xd7c52acbU, 0x80263544U, 0x8fb562a3U, + 0x49deb15aU, 0x6725ba1bU, 0x9845ea0eU, 0xe15dfec0U, + 0x02c32f75U, 0x12814cf0U, 0xa38d4697U, 0xc66bd3f9U, + 0xe7038f5fU, 0x9515929cU, 0xebbf6d7aU, 0xda955259U, + 0x2dd4be83U, 0xd3587421U, 0x2949e069U, 0x448ec9c8U, + 0x6a75c289U, 0x78f48e79U, 0x6b99583eU, 0xdd27b971U, + 0xb6bee14fU, 0x17f088adU, 0x66c920acU, 0xb47dce3aU, + 0x1863df4aU, 0x82e51a31U, 0x60975133U, 0x4562537fU, + 0xe0b16477U, 0x84bb6baeU, 0x1cfe81a0U, 0x94f9082bU, + 0x58704868U, 0x198f45fdU, 0x8794de6cU, 0xb7527bf8U, + 0x23ab73d3U, 0xe2724b02U, 0x57e31f8fU, 0x2a6655abU, + 0x07b2eb28U, 0x032fb5c2U, 0x9a86c57bU, 0xa5d33708U, + 0xf2302887U, 0xb223bfa5U, 0xba02036aU, 0x5ced1682U, + 0x2b8acf1cU, 0x92a779b4U, 0xf0f307f2U, 0xa14e69e2U, + 0xcd65daf4U, 0xd50605beU, 0x1fd13462U, 0x8ac4a6feU, + 0x9d342e53U, 0xa0a2f355U, 0x32058ae1U, 0x75a4f6ebU, + 0x390b83ecU, 0xaa4060efU, 0x065e719fU, 0x51bd6e10U, + 0xf93e218aU, 0x3d96dd06U, 0xaedd3e05U, 0x464de6bdU, + 0xb591548dU, 0x0571c45dU, 0x6f0406d4U, 0xff605015U, + 0x241998fbU, 0x97d6bde9U, 0xcc894043U, 0x7767d99eU, + 0xbdb0e842U, 0x8807898bU, 0x38e7195bU, 0xdb79c8eeU, + 0x47a17c0aU, 0xe97c420fU, 0xc9f8841eU, 0x00000000U, + 0x83098086U, 0x48322bedU, 0xac1e1170U, 0x4e6c5a72U, + 0xfbfd0effU, 0x560f8538U, 0x1e3daed5U, 0x27362d39U, + 0x640a0fd9U, 0x21685ca6U, 0xd19b5b54U, 0x3a24362eU, + 0xb10c0a67U, 0x0f9357e7U, 0xd2b4ee96U, 0x9e1b9b91U, + 0x4f80c0c5U, 0xa261dc20U, 0x695a774bU, 0x161c121aU, + 0x0ae293baU, 0xe5c0a02aU, 0x433c22e0U, 0x1d121b17U, + 0x0b0e090dU, 0xadf28bc7U, 0xb92db6a8U, 0xc8141ea9U, + 0x8557f119U, 0x4caf7507U, 0xbbee99ddU, 0xfda37f60U, + 0x9ff70126U, 0xbc5c72f5U, 0xc544663bU, 0x345bfb7eU, + 0x768b4329U, 0xdccb23c6U, 0x68b6edfcU, 0x63b8e4f1U, + 0xcad731dcU, 0x10426385U, 0x40139722U, 0x2084c611U, + 0x7d854a24U, 0xf8d2bb3dU, 0x11aef932U, 0x6dc729a1U, + 0x4b1d9e2fU, 0xf3dcb230U, 0xec0d8652U, 0xd077c1e3U, + 0x6c2bb316U, 0x99a970b9U, 0xfa119448U, 0x2247e964U, + 0xc4a8fc8cU, 0x1aa0f03fU, 0xd8567d2cU, 0xef223390U, + 0xc787494eU, 0xc1d938d1U, 0xfe8ccaa2U, 0x3698d40bU, + 0xcfa6f581U, 0x28a57adeU, 0x26dab78eU, 0xa43fadbfU, + 0xe42c3a9dU, 0x0d507892U, 0x9b6a5fccU, 0x62547e46U, + 0xc2f68d13U, 0xe890d8b8U, 0x5e2e39f7U, 0xf582c3afU, + 0xbe9f5d80U, 0x7c69d093U, 0xa96fd52dU, 0xb3cf2512U, + 0x3bc8ac99U, 0xa710187dU, 0x6ee89c63U, 0x7bdb3bbbU, + 0x09cd2678U, 0xf46e5918U, 0x01ec9ab7U, 0xa8834f9aU, + 0x65e6956eU, 0x7eaaffe6U, 0x0821bccfU, 0xe6ef15e8U, + 0xd9bae79bU, 0xce4a6f36U, 0xd4ea9f09U, 0xd629b07cU, + 0xaf31a4b2U, 0x312a3f23U, 0x30c6a594U, 0xc035a266U, + 0x37744ebcU, 0xa6fc82caU, 0xb0e090d0U, 0x1533a7d8U, + 0x4af10498U, 0xf741ecdaU, 0x0e7fcd50U, 0x2f1791f6U, + 0x8d764dd6U, 0x4d43efb0U, 0x54ccaa4dU, 0xdfe49604U, + 0xe39ed1b5U, 0x1b4c6a88U, 0xb8c12c1fU, 0x7f466551U, + 0x049d5eeaU, 0x5d018c35U, 0x73fa8774U, 0x2efb0b41U, + 0x5ab3671dU, 0x5292dbd2U, 0x33e91056U, 0x136dd647U, + 0x8c9ad761U, 0x7a37a10cU, 0x8e59f814U, 0x89eb133cU, + 0xeecea927U, 0x35b761c9U, 0xede11ce5U, 0x3c7a47b1U, + 0x599cd2dfU, 0x3f55f273U, 0x791814ceU, 0xbf73c737U, + 0xea53f7cdU, 0x5b5ffdaaU, 0x14df3d6fU, 0x867844dbU, + 0x81caaff3U, 0x3eb968c4U, 0x2c382434U, 0x5fc2a340U, + 0x72161dc3U, 0x0cbce225U, 0x8b283c49U, 0x41ff0d95U, + 0x7139a801U, 0xde080cb3U, 0x9cd8b4e4U, 0x906456c1U, + 0x617bcb84U, 0x70d532b6U, 0x74486c5cU, 0x42d0b857U, +}; +static const u32 Td2[256] = { + 0xa75051f4U, 0x65537e41U, 0xa4c31a17U, 0x5e963a27U, + 0x6bcb3babU, 0x45f11f9dU, 0x58abacfaU, 0x03934be3U, + 0xfa552030U, 0x6df6ad76U, 0x769188ccU, 0x4c25f502U, + 0xd7fc4fe5U, 0xcbd7c52aU, 0x44802635U, 0xa38fb562U, + 0x5a49deb1U, 0x1b6725baU, 0x0e9845eaU, 0xc0e15dfeU, + 0x7502c32fU, 0xf012814cU, 0x97a38d46U, 0xf9c66bd3U, + 0x5fe7038fU, 0x9c951592U, 0x7aebbf6dU, 0x59da9552U, + 0x832dd4beU, 0x21d35874U, 0x692949e0U, 0xc8448ec9U, + 0x896a75c2U, 0x7978f48eU, 0x3e6b9958U, 0x71dd27b9U, + 0x4fb6bee1U, 0xad17f088U, 0xac66c920U, 0x3ab47dceU, + 0x4a1863dfU, 0x3182e51aU, 0x33609751U, 0x7f456253U, + 0x77e0b164U, 0xae84bb6bU, 0xa01cfe81U, 0x2b94f908U, + 0x68587048U, 0xfd198f45U, 0x6c8794deU, 0xf8b7527bU, + 0xd323ab73U, 0x02e2724bU, 0x8f57e31fU, 0xab2a6655U, + 0x2807b2ebU, 0xc2032fb5U, 0x7b9a86c5U, 0x08a5d337U, + 0x87f23028U, 0xa5b223bfU, 0x6aba0203U, 0x825ced16U, + 0x1c2b8acfU, 0xb492a779U, 0xf2f0f307U, 0xe2a14e69U, + 0xf4cd65daU, 0xbed50605U, 0x621fd134U, 0xfe8ac4a6U, + 0x539d342eU, 0x55a0a2f3U, 0xe132058aU, 0xeb75a4f6U, + 0xec390b83U, 0xefaa4060U, 0x9f065e71U, 0x1051bd6eU, + + 0x8af93e21U, 0x063d96ddU, 0x05aedd3eU, 0xbd464de6U, + 0x8db59154U, 0x5d0571c4U, 0xd46f0406U, 0x15ff6050U, + 0xfb241998U, 0xe997d6bdU, 0x43cc8940U, 0x9e7767d9U, + 0x42bdb0e8U, 0x8b880789U, 0x5b38e719U, 0xeedb79c8U, + 0x0a47a17cU, 0x0fe97c42U, 0x1ec9f884U, 0x00000000U, + 0x86830980U, 0xed48322bU, 0x70ac1e11U, 0x724e6c5aU, + 0xfffbfd0eU, 0x38560f85U, 0xd51e3daeU, 0x3927362dU, + 0xd9640a0fU, 0xa621685cU, 0x54d19b5bU, 0x2e3a2436U, + 0x67b10c0aU, 0xe70f9357U, 0x96d2b4eeU, 0x919e1b9bU, + 0xc54f80c0U, 0x20a261dcU, 0x4b695a77U, 0x1a161c12U, + 0xba0ae293U, 0x2ae5c0a0U, 0xe0433c22U, 0x171d121bU, + 0x0d0b0e09U, 0xc7adf28bU, 0xa8b92db6U, 0xa9c8141eU, + 0x198557f1U, 0x074caf75U, 0xddbbee99U, 0x60fda37fU, + 0x269ff701U, 0xf5bc5c72U, 0x3bc54466U, 0x7e345bfbU, + 0x29768b43U, 0xc6dccb23U, 0xfc68b6edU, 0xf163b8e4U, + 0xdccad731U, 0x85104263U, 0x22401397U, 0x112084c6U, + 0x247d854aU, 0x3df8d2bbU, 0x3211aef9U, 0xa16dc729U, + 0x2f4b1d9eU, 0x30f3dcb2U, 0x52ec0d86U, 0xe3d077c1U, + 0x166c2bb3U, 0xb999a970U, 0x48fa1194U, 0x642247e9U, + 0x8cc4a8fcU, 0x3f1aa0f0U, 0x2cd8567dU, 0x90ef2233U, + 0x4ec78749U, 0xd1c1d938U, 0xa2fe8ccaU, 0x0b3698d4U, + 0x81cfa6f5U, 0xde28a57aU, 0x8e26dab7U, 0xbfa43fadU, + 0x9de42c3aU, 0x920d5078U, 0xcc9b6a5fU, 0x4662547eU, + 0x13c2f68dU, 0xb8e890d8U, 0xf75e2e39U, 0xaff582c3U, + 0x80be9f5dU, 0x937c69d0U, 0x2da96fd5U, 0x12b3cf25U, + 0x993bc8acU, 0x7da71018U, 0x636ee89cU, 0xbb7bdb3bU, + 0x7809cd26U, 0x18f46e59U, 0xb701ec9aU, 0x9aa8834fU, + 0x6e65e695U, 0xe67eaaffU, 0xcf0821bcU, 0xe8e6ef15U, + 0x9bd9bae7U, 0x36ce4a6fU, 0x09d4ea9fU, 0x7cd629b0U, + 0xb2af31a4U, 0x23312a3fU, 0x9430c6a5U, 0x66c035a2U, + 0xbc37744eU, 0xcaa6fc82U, 0xd0b0e090U, 0xd81533a7U, + 0x984af104U, 0xdaf741ecU, 0x500e7fcdU, 0xf62f1791U, + 0xd68d764dU, 0xb04d43efU, 0x4d54ccaaU, 0x04dfe496U, + 0xb5e39ed1U, 0x881b4c6aU, 0x1fb8c12cU, 0x517f4665U, + 0xea049d5eU, 0x355d018cU, 0x7473fa87U, 0x412efb0bU, + 0x1d5ab367U, 0xd25292dbU, 0x5633e910U, 0x47136dd6U, + 0x618c9ad7U, 0x0c7a37a1U, 0x148e59f8U, 0x3c89eb13U, + 0x27eecea9U, 0xc935b761U, 0xe5ede11cU, 0xb13c7a47U, + 0xdf599cd2U, 0x733f55f2U, 0xce791814U, 0x37bf73c7U, + 0xcdea53f7U, 0xaa5b5ffdU, 0x6f14df3dU, 0xdb867844U, + 0xf381caafU, 0xc43eb968U, 0x342c3824U, 0x405fc2a3U, + 0xc372161dU, 0x250cbce2U, 0x498b283cU, 0x9541ff0dU, + 0x017139a8U, 0xb3de080cU, 0xe49cd8b4U, 0xc1906456U, + 0x84617bcbU, 0xb670d532U, 0x5c74486cU, 0x5742d0b8U, +}; +static const u32 Td3[256] = { + 0xf4a75051U, 0x4165537eU, 0x17a4c31aU, 0x275e963aU, + 0xab6bcb3bU, 0x9d45f11fU, 0xfa58abacU, 0xe303934bU, + 0x30fa5520U, 0x766df6adU, 0xcc769188U, 0x024c25f5U, + 0xe5d7fc4fU, 0x2acbd7c5U, 0x35448026U, 0x62a38fb5U, + 0xb15a49deU, 0xba1b6725U, 0xea0e9845U, 0xfec0e15dU, + 0x2f7502c3U, 0x4cf01281U, 0x4697a38dU, 0xd3f9c66bU, + 0x8f5fe703U, 0x929c9515U, 0x6d7aebbfU, 0x5259da95U, + 0xbe832dd4U, 0x7421d358U, 0xe0692949U, 0xc9c8448eU, + 0xc2896a75U, 0x8e7978f4U, 0x583e6b99U, 0xb971dd27U, + 0xe14fb6beU, 0x88ad17f0U, 0x20ac66c9U, 0xce3ab47dU, + 0xdf4a1863U, 0x1a3182e5U, 0x51336097U, 0x537f4562U, + 0x6477e0b1U, 0x6bae84bbU, 0x81a01cfeU, 0x082b94f9U, + 0x48685870U, 0x45fd198fU, 0xde6c8794U, 0x7bf8b752U, + 0x73d323abU, 0x4b02e272U, 0x1f8f57e3U, 0x55ab2a66U, + 0xeb2807b2U, 0xb5c2032fU, 0xc57b9a86U, 0x3708a5d3U, + 0x2887f230U, 0xbfa5b223U, 0x036aba02U, 0x16825cedU, + 0xcf1c2b8aU, 0x79b492a7U, 0x07f2f0f3U, 0x69e2a14eU, + 0xdaf4cd65U, 0x05bed506U, 0x34621fd1U, 0xa6fe8ac4U, + 0x2e539d34U, 0xf355a0a2U, 0x8ae13205U, 0xf6eb75a4U, + 0x83ec390bU, 0x60efaa40U, 0x719f065eU, 0x6e1051bdU, + 0x218af93eU, 0xdd063d96U, 0x3e05aeddU, 0xe6bd464dU, + 0x548db591U, 0xc45d0571U, 0x06d46f04U, 0x5015ff60U, + 0x98fb2419U, 0xbde997d6U, 0x4043cc89U, 0xd99e7767U, + 0xe842bdb0U, 0x898b8807U, 0x195b38e7U, 0xc8eedb79U, + 0x7c0a47a1U, 0x420fe97cU, 0x841ec9f8U, 0x00000000U, + 0x80868309U, 0x2bed4832U, 0x1170ac1eU, 0x5a724e6cU, + 0x0efffbfdU, 0x8538560fU, 0xaed51e3dU, 0x2d392736U, + 0x0fd9640aU, 0x5ca62168U, 0x5b54d19bU, 0x362e3a24U, + 0x0a67b10cU, 0x57e70f93U, 0xee96d2b4U, 0x9b919e1bU, + 0xc0c54f80U, 0xdc20a261U, 0x774b695aU, 0x121a161cU, + 0x93ba0ae2U, 0xa02ae5c0U, 0x22e0433cU, 0x1b171d12U, + 0x090d0b0eU, 0x8bc7adf2U, 0xb6a8b92dU, 0x1ea9c814U, + 0xf1198557U, 0x75074cafU, 0x99ddbbeeU, 0x7f60fda3U, + 0x01269ff7U, 0x72f5bc5cU, 0x663bc544U, 0xfb7e345bU, + 0x4329768bU, 0x23c6dccbU, 0xedfc68b6U, 0xe4f163b8U, + 0x31dccad7U, 0x63851042U, 0x97224013U, 0xc6112084U, + 0x4a247d85U, 0xbb3df8d2U, 0xf93211aeU, 0x29a16dc7U, + 0x9e2f4b1dU, 0xb230f3dcU, 0x8652ec0dU, 0xc1e3d077U, + 0xb3166c2bU, 0x70b999a9U, 0x9448fa11U, 0xe9642247U, + 0xfc8cc4a8U, 0xf03f1aa0U, 0x7d2cd856U, 0x3390ef22U, + 0x494ec787U, 0x38d1c1d9U, 0xcaa2fe8cU, 0xd40b3698U, + 0xf581cfa6U, 0x7ade28a5U, 0xb78e26daU, 0xadbfa43fU, + 0x3a9de42cU, 0x78920d50U, 0x5fcc9b6aU, 0x7e466254U, + 0x8d13c2f6U, 0xd8b8e890U, 0x39f75e2eU, 0xc3aff582U, + 0x5d80be9fU, 0xd0937c69U, 0xd52da96fU, 0x2512b3cfU, + 0xac993bc8U, 0x187da710U, 0x9c636ee8U, 0x3bbb7bdbU, + 0x267809cdU, 0x5918f46eU, 0x9ab701ecU, 0x4f9aa883U, + 0x956e65e6U, 0xffe67eaaU, 0xbccf0821U, 0x15e8e6efU, + 0xe79bd9baU, 0x6f36ce4aU, 0x9f09d4eaU, 0xb07cd629U, + 0xa4b2af31U, 0x3f23312aU, 0xa59430c6U, 0xa266c035U, + 0x4ebc3774U, 0x82caa6fcU, 0x90d0b0e0U, 0xa7d81533U, + 0x04984af1U, 0xecdaf741U, 0xcd500e7fU, 0x91f62f17U, + 0x4dd68d76U, 0xefb04d43U, 0xaa4d54ccU, 0x9604dfe4U, + 0xd1b5e39eU, 0x6a881b4cU, 0x2c1fb8c1U, 0x65517f46U, + 0x5eea049dU, 0x8c355d01U, 0x877473faU, 0x0b412efbU, + 0x671d5ab3U, 0xdbd25292U, 0x105633e9U, 0xd647136dU, + 0xd7618c9aU, 0xa10c7a37U, 0xf8148e59U, 0x133c89ebU, + 0xa927eeceU, 0x61c935b7U, 0x1ce5ede1U, 0x47b13c7aU, + 0xd2df599cU, 0xf2733f55U, 0x14ce7918U, 0xc737bf73U, + 0xf7cdea53U, 0xfdaa5b5fU, 0x3d6f14dfU, 0x44db8678U, + 0xaff381caU, 0x68c43eb9U, 0x24342c38U, 0xa3405fc2U, + 0x1dc37216U, 0xe2250cbcU, 0x3c498b28U, 0x0d9541ffU, + 0xa8017139U, 0x0cb3de08U, 0xb4e49cd8U, 0x56c19064U, + 0xcb84617bU, 0x32b670d5U, 0x6c5c7448U, 0xb85742d0U, +}; +static const u32 Td4[256] = { + 0x52525252U, 0x09090909U, 0x6a6a6a6aU, 0xd5d5d5d5U, + 0x30303030U, 0x36363636U, 0xa5a5a5a5U, 0x38383838U, + 0xbfbfbfbfU, 0x40404040U, 0xa3a3a3a3U, 0x9e9e9e9eU, + 0x81818181U, 0xf3f3f3f3U, 0xd7d7d7d7U, 0xfbfbfbfbU, + 0x7c7c7c7cU, 0xe3e3e3e3U, 0x39393939U, 0x82828282U, + 0x9b9b9b9bU, 0x2f2f2f2fU, 0xffffffffU, 0x87878787U, + 0x34343434U, 0x8e8e8e8eU, 0x43434343U, 0x44444444U, + 0xc4c4c4c4U, 0xdedededeU, 0xe9e9e9e9U, 0xcbcbcbcbU, + 0x54545454U, 0x7b7b7b7bU, 0x94949494U, 0x32323232U, + 0xa6a6a6a6U, 0xc2c2c2c2U, 0x23232323U, 0x3d3d3d3dU, + 0xeeeeeeeeU, 0x4c4c4c4cU, 0x95959595U, 0x0b0b0b0bU, + 0x42424242U, 0xfafafafaU, 0xc3c3c3c3U, 0x4e4e4e4eU, + 0x08080808U, 0x2e2e2e2eU, 0xa1a1a1a1U, 0x66666666U, + 0x28282828U, 0xd9d9d9d9U, 0x24242424U, 0xb2b2b2b2U, + 0x76767676U, 0x5b5b5b5bU, 0xa2a2a2a2U, 0x49494949U, + 0x6d6d6d6dU, 0x8b8b8b8bU, 0xd1d1d1d1U, 0x25252525U, + 0x72727272U, 0xf8f8f8f8U, 0xf6f6f6f6U, 0x64646464U, + 0x86868686U, 0x68686868U, 0x98989898U, 0x16161616U, + 0xd4d4d4d4U, 0xa4a4a4a4U, 0x5c5c5c5cU, 0xccccccccU, + 0x5d5d5d5dU, 0x65656565U, 0xb6b6b6b6U, 0x92929292U, + 0x6c6c6c6cU, 0x70707070U, 0x48484848U, 0x50505050U, + 0xfdfdfdfdU, 0xededededU, 0xb9b9b9b9U, 0xdadadadaU, + 0x5e5e5e5eU, 0x15151515U, 0x46464646U, 0x57575757U, + 0xa7a7a7a7U, 0x8d8d8d8dU, 0x9d9d9d9dU, 0x84848484U, + 0x90909090U, 0xd8d8d8d8U, 0xababababU, 0x00000000U, + 0x8c8c8c8cU, 0xbcbcbcbcU, 0xd3d3d3d3U, 0x0a0a0a0aU, + 0xf7f7f7f7U, 0xe4e4e4e4U, 0x58585858U, 0x05050505U, + 0xb8b8b8b8U, 0xb3b3b3b3U, 0x45454545U, 0x06060606U, + 0xd0d0d0d0U, 0x2c2c2c2cU, 0x1e1e1e1eU, 0x8f8f8f8fU, + 0xcacacacaU, 0x3f3f3f3fU, 0x0f0f0f0fU, 0x02020202U, + 0xc1c1c1c1U, 0xafafafafU, 0xbdbdbdbdU, 0x03030303U, + 0x01010101U, 0x13131313U, 0x8a8a8a8aU, 0x6b6b6b6bU, + 0x3a3a3a3aU, 0x91919191U, 0x11111111U, 0x41414141U, + 0x4f4f4f4fU, 0x67676767U, 0xdcdcdcdcU, 0xeaeaeaeaU, + 0x97979797U, 0xf2f2f2f2U, 0xcfcfcfcfU, 0xcecececeU, + 0xf0f0f0f0U, 0xb4b4b4b4U, 0xe6e6e6e6U, 0x73737373U, + 0x96969696U, 0xacacacacU, 0x74747474U, 0x22222222U, + 0xe7e7e7e7U, 0xadadadadU, 0x35353535U, 0x85858585U, + 0xe2e2e2e2U, 0xf9f9f9f9U, 0x37373737U, 0xe8e8e8e8U, + 0x1c1c1c1cU, 0x75757575U, 0xdfdfdfdfU, 0x6e6e6e6eU, + 0x47474747U, 0xf1f1f1f1U, 0x1a1a1a1aU, 0x71717171U, + 0x1d1d1d1dU, 0x29292929U, 0xc5c5c5c5U, 0x89898989U, + 0x6f6f6f6fU, 0xb7b7b7b7U, 0x62626262U, 0x0e0e0e0eU, + 0xaaaaaaaaU, 0x18181818U, 0xbebebebeU, 0x1b1b1b1bU, + 0xfcfcfcfcU, 0x56565656U, 0x3e3e3e3eU, 0x4b4b4b4bU, + 0xc6c6c6c6U, 0xd2d2d2d2U, 0x79797979U, 0x20202020U, + 0x9a9a9a9aU, 0xdbdbdbdbU, 0xc0c0c0c0U, 0xfefefefeU, + 0x78787878U, 0xcdcdcdcdU, 0x5a5a5a5aU, 0xf4f4f4f4U, + 0x1f1f1f1fU, 0xddddddddU, 0xa8a8a8a8U, 0x33333333U, + 0x88888888U, 0x07070707U, 0xc7c7c7c7U, 0x31313131U, + 0xb1b1b1b1U, 0x12121212U, 0x10101010U, 0x59595959U, + 0x27272727U, 0x80808080U, 0xececececU, 0x5f5f5f5fU, + 0x60606060U, 0x51515151U, 0x7f7f7f7fU, 0xa9a9a9a9U, + 0x19191919U, 0xb5b5b5b5U, 0x4a4a4a4aU, 0x0d0d0d0dU, + 0x2d2d2d2dU, 0xe5e5e5e5U, 0x7a7a7a7aU, 0x9f9f9f9fU, + 0x93939393U, 0xc9c9c9c9U, 0x9c9c9c9cU, 0xefefefefU, + 0xa0a0a0a0U, 0xe0e0e0e0U, 0x3b3b3b3bU, 0x4d4d4d4dU, + 0xaeaeaeaeU, 0x2a2a2a2aU, 0xf5f5f5f5U, 0xb0b0b0b0U, + 0xc8c8c8c8U, 0xebebebebU, 0xbbbbbbbbU, 0x3c3c3c3cU, + 0x83838383U, 0x53535353U, 0x99999999U, 0x61616161U, + 0x17171717U, 0x2b2b2b2bU, 0x04040404U, 0x7e7e7e7eU, + 0xbabababaU, 0x77777777U, 0xd6d6d6d6U, 0x26262626U, + 0xe1e1e1e1U, 0x69696969U, 0x14141414U, 0x63636363U, + 0x55555555U, 0x21212121U, 0x0c0c0c0cU, 0x7d7d7d7dU, +}; +static const u32 rcon[] = { + 0x01000000, 0x02000000, 0x04000000, 0x08000000, + 0x10000000, 0x20000000, 0x40000000, 0x80000000, + 0x1B000000, 0x36000000, /* for 128-bit blocks, Rijndael never uses more than 10 rcon values */ +}; + +#define GETU32(pt) (((u32)(pt)[0] << 24) ^ ((u32)(pt)[1] << 16) ^ ((u32)(pt)[2] << 8) ^ ((u32)(pt)[3])) +#define PUTU32(ct, st) { (ct)[0] = (u8)((st) >> 24); (ct)[1] = (u8)((st) >> 16); (ct)[2] = (u8)((st) >> 8); (ct)[3] = (u8)(st); } + +/** + * Expand the cipher key into the encryption key schedule. + * + * @return the number of rounds for the given cipher key size. + */ +static int rijndaelKeySetupEnc(u32 rk[/*4*(Nr + 1)*/], const u8 cipherKey[], int keyBits) { + int i = 0; + u32 temp; + + rk[0] = GETU32(cipherKey ); + rk[1] = GETU32(cipherKey + 4); + rk[2] = GETU32(cipherKey + 8); + rk[3] = GETU32(cipherKey + 12); + if (keyBits == 128) { + for (;;) { + temp = rk[3]; + rk[4] = rk[0] ^ + (Te4[(temp >> 16) & 0xff] & 0xff000000) ^ + (Te4[(temp >> 8) & 0xff] & 0x00ff0000) ^ + (Te4[(temp ) & 0xff] & 0x0000ff00) ^ + (Te4[(temp >> 24) ] & 0x000000ff) ^ + rcon[i]; + rk[5] = rk[1] ^ rk[4]; + rk[6] = rk[2] ^ rk[5]; + rk[7] = rk[3] ^ rk[6]; + if (++i == 10) { + return 10; + } + rk += 4; + } } - - /* note that the affine byte transformation matrix in */ - /* rijndael specification is in big endian format with */ - /* bit 0 as the most significant bit. In the remainder */ - /* of the specification the bits are numbered from the */ - /* least significant end of a byte. */ - - for(i = 0; i < 256; ++i) { - p = (i ? pow_tab[255 - log_tab[i]] : 0); q = p; - q = (q >> 7) | (q << 1); p ^= q; - q = (q >> 7) | (q << 1); p ^= q; - q = (q >> 7) | (q << 1); p ^= q; - q = (q >> 7) | (q << 1); p ^= q ^ 0x63; - sbx_tab[i] = (u1byte)p; isb_tab[p] = (u1byte)i; + rk[4] = GETU32(cipherKey + 16); + rk[5] = GETU32(cipherKey + 20); + if (keyBits == 192) { + for (;;) { + temp = rk[ 5]; + rk[ 6] = rk[ 0] ^ + (Te4[(temp >> 16) & 0xff] & 0xff000000) ^ + (Te4[(temp >> 8) & 0xff] & 0x00ff0000) ^ + (Te4[(temp ) & 0xff] & 0x0000ff00) ^ + (Te4[(temp >> 24) ] & 0x000000ff) ^ + rcon[i]; + rk[ 7] = rk[ 1] ^ rk[ 6]; + rk[ 8] = rk[ 2] ^ rk[ 7]; + rk[ 9] = rk[ 3] ^ rk[ 8]; + if (++i == 8) { + return 12; + } + rk[10] = rk[ 4] ^ rk[ 9]; + rk[11] = rk[ 5] ^ rk[10]; + rk += 6; + } } - - for(i = 0; i < 256; ++i) { - p = sbx_tab[i]; - -#ifdef LARGE_TABLES + rk[6] = GETU32(cipherKey + 24); + rk[7] = GETU32(cipherKey + 28); + if (keyBits == 256) { + for (;;) { + temp = rk[ 7]; + rk[ 8] = rk[ 0] ^ + (Te4[(temp >> 16) & 0xff] & 0xff000000) ^ + (Te4[(temp >> 8) & 0xff] & 0x00ff0000) ^ + (Te4[(temp ) & 0xff] & 0x0000ff00) ^ + (Te4[(temp >> 24) ] & 0x000000ff) ^ + rcon[i]; + rk[ 9] = rk[ 1] ^ rk[ 8]; + rk[10] = rk[ 2] ^ rk[ 9]; + rk[11] = rk[ 3] ^ rk[10]; + if (++i == 7) { + return 14; + } + temp = rk[11]; + rk[12] = rk[ 4] ^ + (Te4[(temp >> 24) ] & 0xff000000) ^ + (Te4[(temp >> 16) & 0xff] & 0x00ff0000) ^ + (Te4[(temp >> 8) & 0xff] & 0x0000ff00) ^ + (Te4[(temp ) & 0xff] & 0x000000ff); + rk[13] = rk[ 5] ^ rk[12]; + rk[14] = rk[ 6] ^ rk[13]; + rk[15] = rk[ 7] ^ rk[14]; - t = p; fl_tab[0][i] = t; - fl_tab[1][i] = rotl(t, 8); - fl_tab[2][i] = rotl(t, 16); - fl_tab[3][i] = rotl(t, 24); -#endif - t = ((u4byte)ff_mult(2, p)) | - ((u4byte)p << 8) | - ((u4byte)p << 16) | - ((u4byte)ff_mult(3, p) << 24); - - ft_tab[0][i] = t; - ft_tab[1][i] = rotl(t, 8); - ft_tab[2][i] = rotl(t, 16); - ft_tab[3][i] = rotl(t, 24); - - p = isb_tab[i]; - -#ifdef LARGE_TABLES - - t = p; il_tab[0][i] = t; - il_tab[1][i] = rotl(t, 8); - il_tab[2][i] = rotl(t, 16); - il_tab[3][i] = rotl(t, 24); -#endif - t = ((u4byte)ff_mult(14, p)) | - ((u4byte)ff_mult( 9, p) << 8) | - ((u4byte)ff_mult(13, p) << 16) | - ((u4byte)ff_mult(11, p) << 24); - - it_tab[0][i] = t; - it_tab[1][i] = rotl(t, 8); - it_tab[2][i] = rotl(t, 16); - it_tab[3][i] = rotl(t, 24); + rk += 8; + } } - - tab_gen = 1; + return 0; } - -#define star_x(x) (((x) & 0x7f7f7f7f) << 1) ^ ((((x) & 0x80808080) >> 7) * 0x1b) -#define imix_col(y,x) \ - u = star_x(x); \ - v = star_x(u); \ - w = star_x(v); \ - t = w ^ (x); \ - (y) = u ^ v ^ w; \ - (y) ^= rotr(u ^ t, 8) ^ \ - rotr(v ^ t, 16) ^ \ - rotr(t,24) - -/* initialise the key schedule from the user supplied key */ - -#define loop4(i) \ -{ t = ls_box(rotr(t, 8)) ^ rco_tab[i]; \ - t ^= e_key[4 * i]; e_key[4 * i + 4] = t; \ - t ^= e_key[4 * i + 1]; e_key[4 * i + 5] = t; \ - t ^= e_key[4 * i + 2]; e_key[4 * i + 6] = t; \ - t ^= e_key[4 * i + 3]; e_key[4 * i + 7] = t; \ +/** + * Expand the cipher key into the decryption key schedule. + * + * @return the number of rounds for the given cipher key size. + */ +static int +rijndaelKeySetupDec(u32 rk[/*4*(Nr + 1)*/], const u8 cipherKey[], int keyBits, + int have_encrypt) { + int Nr, i, j; + u32 temp; + + if (have_encrypt) { + Nr = have_encrypt; + } else { + /* expand the cipher key: */ + Nr = rijndaelKeySetupEnc(rk, cipherKey, keyBits); + } + /* invert the order of the round keys: */ + for (i = 0, j = 4*Nr; i < j; i += 4, j -= 4) { + temp = rk[i ]; rk[i ] = rk[j ]; rk[j ] = temp; + temp = rk[i + 1]; rk[i + 1] = rk[j + 1]; rk[j + 1] = temp; + temp = rk[i + 2]; rk[i + 2] = rk[j + 2]; rk[j + 2] = temp; + temp = rk[i + 3]; rk[i + 3] = rk[j + 3]; rk[j + 3] = temp; + } + /* apply the inverse MixColumn transform to all round keys but the first and the last: */ + for (i = 1; i < Nr; i++) { + rk += 4; + rk[0] = + Td0[Te4[(rk[0] >> 24) ] & 0xff] ^ + Td1[Te4[(rk[0] >> 16) & 0xff] & 0xff] ^ + Td2[Te4[(rk[0] >> 8) & 0xff] & 0xff] ^ + Td3[Te4[(rk[0] ) & 0xff] & 0xff]; + rk[1] = + Td0[Te4[(rk[1] >> 24) ] & 0xff] ^ + Td1[Te4[(rk[1] >> 16) & 0xff] & 0xff] ^ + Td2[Te4[(rk[1] >> 8) & 0xff] & 0xff] ^ + Td3[Te4[(rk[1] ) & 0xff] & 0xff]; + rk[2] = + Td0[Te4[(rk[2] >> 24) ] & 0xff] ^ + Td1[Te4[(rk[2] >> 16) & 0xff] & 0xff] ^ + Td2[Te4[(rk[2] >> 8) & 0xff] & 0xff] ^ + Td3[Te4[(rk[2] ) & 0xff] & 0xff]; + rk[3] = + Td0[Te4[(rk[3] >> 24) ] & 0xff] ^ + Td1[Te4[(rk[3] >> 16) & 0xff] & 0xff] ^ + Td2[Te4[(rk[3] >> 8) & 0xff] & 0xff] ^ + Td3[Te4[(rk[3] ) & 0xff] & 0xff]; + } + return Nr; } -#define loop6(i) \ -{ t = ls_box(rotr(t, 8)) ^ rco_tab[i]; \ - t ^= e_key[6 * i]; e_key[6 * i + 6] = t; \ - t ^= e_key[6 * i + 1]; e_key[6 * i + 7] = t; \ - t ^= e_key[6 * i + 2]; e_key[6 * i + 8] = t; \ - t ^= e_key[6 * i + 3]; e_key[6 * i + 9] = t; \ - t ^= e_key[6 * i + 4]; e_key[6 * i + 10] = t; \ - t ^= e_key[6 * i + 5]; e_key[6 * i + 11] = t; \ +static void rijndaelEncrypt(const u32 rk[/*4*(Nr + 1)*/], int Nr, const u8 pt[16], u8 ct[16]) { + u32 s0, s1, s2, s3, t0, t1, t2, t3; +#ifndef FULL_UNROLL + int r; +#endif /* ?FULL_UNROLL */ + + /* + * map byte array block to cipher state + * and add initial round key: + */ + s0 = GETU32(pt ) ^ rk[0]; + s1 = GETU32(pt + 4) ^ rk[1]; + s2 = GETU32(pt + 8) ^ rk[2]; + s3 = GETU32(pt + 12) ^ rk[3]; +#ifdef FULL_UNROLL + /* round 1: */ + t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >> 8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[ 4]; + t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >> 8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[ 5]; + t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >> 8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[ 6]; + t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >> 8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[ 7]; + /* round 2: */ + s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >> 8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[ 8]; + s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >> 8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[ 9]; + s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >> 8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[10]; + s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >> 8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[11]; + /* round 3: */ + t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >> 8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[12]; + t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >> 8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[13]; + t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >> 8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[14]; + t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >> 8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[15]; + /* round 4: */ + s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >> 8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[16]; + s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >> 8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[17]; + s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >> 8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[18]; + s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >> 8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[19]; + /* round 5: */ + t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >> 8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[20]; + t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >> 8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[21]; + t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >> 8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[22]; + t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >> 8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[23]; + /* round 6: */ + s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >> 8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[24]; + s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >> 8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[25]; + s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >> 8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[26]; + s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >> 8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[27]; + /* round 7: */ + t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >> 8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[28]; + t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >> 8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[29]; + t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >> 8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[30]; + t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >> 8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[31]; + /* round 8: */ + s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >> 8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[32]; + s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >> 8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[33]; + s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >> 8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[34]; + s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >> 8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[35]; + /* round 9: */ + t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >> 8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[36]; + t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >> 8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[37]; + t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >> 8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[38]; + t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >> 8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[39]; + if (Nr > 10) { + /* round 10: */ + s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >> 8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[40]; + s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >> 8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[41]; + s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >> 8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[42]; + s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >> 8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[43]; + /* round 11: */ + t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >> 8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[44]; + t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >> 8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[45]; + t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >> 8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[46]; + t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >> 8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[47]; + if (Nr > 12) { + /* round 12: */ + s0 = Te0[t0 >> 24] ^ Te1[(t1 >> 16) & 0xff] ^ Te2[(t2 >> 8) & 0xff] ^ Te3[t3 & 0xff] ^ rk[48]; + s1 = Te0[t1 >> 24] ^ Te1[(t2 >> 16) & 0xff] ^ Te2[(t3 >> 8) & 0xff] ^ Te3[t0 & 0xff] ^ rk[49]; + s2 = Te0[t2 >> 24] ^ Te1[(t3 >> 16) & 0xff] ^ Te2[(t0 >> 8) & 0xff] ^ Te3[t1 & 0xff] ^ rk[50]; + s3 = Te0[t3 >> 24] ^ Te1[(t0 >> 16) & 0xff] ^ Te2[(t1 >> 8) & 0xff] ^ Te3[t2 & 0xff] ^ rk[51]; + /* round 13: */ + t0 = Te0[s0 >> 24] ^ Te1[(s1 >> 16) & 0xff] ^ Te2[(s2 >> 8) & 0xff] ^ Te3[s3 & 0xff] ^ rk[52]; + t1 = Te0[s1 >> 24] ^ Te1[(s2 >> 16) & 0xff] ^ Te2[(s3 >> 8) & 0xff] ^ Te3[s0 & 0xff] ^ rk[53]; + t2 = Te0[s2 >> 24] ^ Te1[(s3 >> 16) & 0xff] ^ Te2[(s0 >> 8) & 0xff] ^ Te3[s1 & 0xff] ^ rk[54]; + t3 = Te0[s3 >> 24] ^ Te1[(s0 >> 16) & 0xff] ^ Te2[(s1 >> 8) & 0xff] ^ Te3[s2 & 0xff] ^ rk[55]; + } + } + rk += Nr << 2; +#else /* !FULL_UNROLL */ + /* + * Nr - 1 full rounds: + */ + r = Nr >> 1; + for (;;) { + t0 = + Te0[(s0 >> 24) ] ^ + Te1[(s1 >> 16) & 0xff] ^ + Te2[(s2 >> 8) & 0xff] ^ + Te3[(s3 ) & 0xff] ^ + rk[4]; + t1 = + Te0[(s1 >> 24) ] ^ + Te1[(s2 >> 16) & 0xff] ^ + Te2[(s3 >> 8) & 0xff] ^ + Te3[(s0 ) & 0xff] ^ + rk[5]; + t2 = + Te0[(s2 >> 24) ] ^ + Te1[(s3 >> 16) & 0xff] ^ + Te2[(s0 >> 8) & 0xff] ^ + Te3[(s1 ) & 0xff] ^ + rk[6]; + t3 = + Te0[(s3 >> 24) ] ^ + Te1[(s0 >> 16) & 0xff] ^ + Te2[(s1 >> 8) & 0xff] ^ + Te3[(s2 ) & 0xff] ^ + rk[7]; + + rk += 8; + if (--r == 0) { + break; + } + + s0 = + Te0[(t0 >> 24) ] ^ + Te1[(t1 >> 16) & 0xff] ^ + Te2[(t2 >> 8) & 0xff] ^ + Te3[(t3 ) & 0xff] ^ + rk[0]; + s1 = + Te0[(t1 >> 24) ] ^ + Te1[(t2 >> 16) & 0xff] ^ + Te2[(t3 >> 8) & 0xff] ^ + Te3[(t0 ) & 0xff] ^ + rk[1]; + s2 = + Te0[(t2 >> 24) ] ^ + Te1[(t3 >> 16) & 0xff] ^ + Te2[(t0 >> 8) & 0xff] ^ + Te3[(t1 ) & 0xff] ^ + rk[2]; + s3 = + Te0[(t3 >> 24) ] ^ + Te1[(t0 >> 16) & 0xff] ^ + Te2[(t1 >> 8) & 0xff] ^ + Te3[(t2 ) & 0xff] ^ + rk[3]; + } +#endif /* ?FULL_UNROLL */ + /* + * apply last round and + * map cipher state to byte array block: + */ + s0 = + (Te4[(t0 >> 24) ] & 0xff000000) ^ + (Te4[(t1 >> 16) & 0xff] & 0x00ff0000) ^ + (Te4[(t2 >> 8) & 0xff] & 0x0000ff00) ^ + (Te4[(t3 ) & 0xff] & 0x000000ff) ^ + rk[0]; + PUTU32(ct , s0); + s1 = + (Te4[(t1 >> 24) ] & 0xff000000) ^ + (Te4[(t2 >> 16) & 0xff] & 0x00ff0000) ^ + (Te4[(t3 >> 8) & 0xff] & 0x0000ff00) ^ + (Te4[(t0 ) & 0xff] & 0x000000ff) ^ + rk[1]; + PUTU32(ct + 4, s1); + s2 = + (Te4[(t2 >> 24) ] & 0xff000000) ^ + (Te4[(t3 >> 16) & 0xff] & 0x00ff0000) ^ + (Te4[(t0 >> 8) & 0xff] & 0x0000ff00) ^ + (Te4[(t1 ) & 0xff] & 0x000000ff) ^ + rk[2]; + PUTU32(ct + 8, s2); + s3 = + (Te4[(t3 >> 24) ] & 0xff000000) ^ + (Te4[(t0 >> 16) & 0xff] & 0x00ff0000) ^ + (Te4[(t1 >> 8) & 0xff] & 0x0000ff00) ^ + (Te4[(t2 ) & 0xff] & 0x000000ff) ^ + rk[3]; + PUTU32(ct + 12, s3); } -#define loop8(i) \ -{ t = ls_box(rotr(t, 8)) ^ rco_tab[i]; \ - t ^= e_key[8 * i]; e_key[8 * i + 8] = t; \ - t ^= e_key[8 * i + 1]; e_key[8 * i + 9] = t; \ - t ^= e_key[8 * i + 2]; e_key[8 * i + 10] = t; \ - t ^= e_key[8 * i + 3]; e_key[8 * i + 11] = t; \ - t = e_key[8 * i + 4] ^ ls_box(t); \ - e_key[8 * i + 12] = t; \ - t ^= e_key[8 * i + 5]; e_key[8 * i + 13] = t; \ - t ^= e_key[8 * i + 6]; e_key[8 * i + 14] = t; \ - t ^= e_key[8 * i + 7]; e_key[8 * i + 15] = t; \ +static void rijndaelDecrypt(const u32 rk[/*4*(Nr + 1)*/], int Nr, const u8 ct[16], u8 pt[16]) { + u32 s0, s1, s2, s3, t0, t1, t2, t3; +#ifndef FULL_UNROLL + int r; +#endif /* ?FULL_UNROLL */ + + /* + * map byte array block to cipher state + * and add initial round key: + */ + s0 = GETU32(ct ) ^ rk[0]; + s1 = GETU32(ct + 4) ^ rk[1]; + s2 = GETU32(ct + 8) ^ rk[2]; + s3 = GETU32(ct + 12) ^ rk[3]; +#ifdef FULL_UNROLL + /* round 1: */ + t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >> 8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[ 4]; + t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >> 8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[ 5]; + t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >> 8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[ 6]; + t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >> 8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[ 7]; + /* round 2: */ + s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >> 8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[ 8]; + s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >> 8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[ 9]; + s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >> 8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[10]; + s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >> 8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[11]; + /* round 3: */ + t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >> 8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[12]; + t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >> 8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[13]; + t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >> 8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[14]; + t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >> 8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[15]; + /* round 4: */ + s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >> 8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[16]; + s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >> 8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[17]; + s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >> 8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[18]; + s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >> 8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[19]; + /* round 5: */ + t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >> 8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[20]; + t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >> 8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[21]; + t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >> 8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[22]; + t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >> 8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[23]; + /* round 6: */ + s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >> 8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[24]; + s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >> 8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[25]; + s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >> 8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[26]; + s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >> 8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[27]; + /* round 7: */ + t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >> 8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[28]; + t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >> 8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[29]; + t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >> 8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[30]; + t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >> 8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[31]; + /* round 8: */ + s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >> 8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[32]; + s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >> 8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[33]; + s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >> 8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[34]; + s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >> 8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[35]; + /* round 9: */ + t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >> 8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[36]; + t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >> 8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[37]; + t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >> 8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[38]; + t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >> 8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[39]; + if (Nr > 10) { + /* round 10: */ + s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >> 8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[40]; + s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >> 8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[41]; + s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >> 8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[42]; + s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >> 8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[43]; + /* round 11: */ + t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >> 8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[44]; + t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >> 8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[45]; + t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >> 8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[46]; + t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >> 8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[47]; + if (Nr > 12) { + /* round 12: */ + s0 = Td0[t0 >> 24] ^ Td1[(t3 >> 16) & 0xff] ^ Td2[(t2 >> 8) & 0xff] ^ Td3[t1 & 0xff] ^ rk[48]; + s1 = Td0[t1 >> 24] ^ Td1[(t0 >> 16) & 0xff] ^ Td2[(t3 >> 8) & 0xff] ^ Td3[t2 & 0xff] ^ rk[49]; + s2 = Td0[t2 >> 24] ^ Td1[(t1 >> 16) & 0xff] ^ Td2[(t0 >> 8) & 0xff] ^ Td3[t3 & 0xff] ^ rk[50]; + s3 = Td0[t3 >> 24] ^ Td1[(t2 >> 16) & 0xff] ^ Td2[(t1 >> 8) & 0xff] ^ Td3[t0 & 0xff] ^ rk[51]; + /* round 13: */ + t0 = Td0[s0 >> 24] ^ Td1[(s3 >> 16) & 0xff] ^ Td2[(s2 >> 8) & 0xff] ^ Td3[s1 & 0xff] ^ rk[52]; + t1 = Td0[s1 >> 24] ^ Td1[(s0 >> 16) & 0xff] ^ Td2[(s3 >> 8) & 0xff] ^ Td3[s2 & 0xff] ^ rk[53]; + t2 = Td0[s2 >> 24] ^ Td1[(s1 >> 16) & 0xff] ^ Td2[(s0 >> 8) & 0xff] ^ Td3[s3 & 0xff] ^ rk[54]; + t3 = Td0[s3 >> 24] ^ Td1[(s2 >> 16) & 0xff] ^ Td2[(s1 >> 8) & 0xff] ^ Td3[s0 & 0xff] ^ rk[55]; + } + } + rk += Nr << 2; +#else /* !FULL_UNROLL */ + /* + * Nr - 1 full rounds: + */ + r = Nr >> 1; + for (;;) { + t0 = + Td0[(s0 >> 24) ] ^ + Td1[(s3 >> 16) & 0xff] ^ + Td2[(s2 >> 8) & 0xff] ^ + Td3[(s1 ) & 0xff] ^ + rk[4]; + t1 = + Td0[(s1 >> 24) ] ^ + Td1[(s0 >> 16) & 0xff] ^ + Td2[(s3 >> 8) & 0xff] ^ + Td3[(s2 ) & 0xff] ^ + rk[5]; + t2 = + Td0[(s2 >> 24) ] ^ + Td1[(s1 >> 16) & 0xff] ^ + Td2[(s0 >> 8) & 0xff] ^ + Td3[(s3 ) & 0xff] ^ + rk[6]; + t3 = + Td0[(s3 >> 24) ] ^ + Td1[(s2 >> 16) & 0xff] ^ + Td2[(s1 >> 8) & 0xff] ^ + Td3[(s0 ) & 0xff] ^ + rk[7]; + + rk += 8; + if (--r == 0) { + break; + } + + s0 = + Td0[(t0 >> 24) ] ^ + Td1[(t3 >> 16) & 0xff] ^ + Td2[(t2 >> 8) & 0xff] ^ + Td3[(t1 ) & 0xff] ^ + rk[0]; + s1 = + Td0[(t1 >> 24) ] ^ + Td1[(t0 >> 16) & 0xff] ^ + Td2[(t3 >> 8) & 0xff] ^ + Td3[(t2 ) & 0xff] ^ + rk[1]; + s2 = + Td0[(t2 >> 24) ] ^ + Td1[(t1 >> 16) & 0xff] ^ + Td2[(t0 >> 8) & 0xff] ^ + Td3[(t3 ) & 0xff] ^ + rk[2]; + s3 = + Td0[(t3 >> 24) ] ^ + Td1[(t2 >> 16) & 0xff] ^ + Td2[(t1 >> 8) & 0xff] ^ + Td3[(t0 ) & 0xff] ^ + rk[3]; + } +#endif /* ?FULL_UNROLL */ + /* + * apply last round and + * map cipher state to byte array block: + */ + s0 = + (Td4[(t0 >> 24) ] & 0xff000000) ^ + (Td4[(t3 >> 16) & 0xff] & 0x00ff0000) ^ + (Td4[(t2 >> 8) & 0xff] & 0x0000ff00) ^ + (Td4[(t1 ) & 0xff] & 0x000000ff) ^ + rk[0]; + PUTU32(pt , s0); + s1 = + (Td4[(t1 >> 24) ] & 0xff000000) ^ + (Td4[(t0 >> 16) & 0xff] & 0x00ff0000) ^ + (Td4[(t3 >> 8) & 0xff] & 0x0000ff00) ^ + (Td4[(t2 ) & 0xff] & 0x000000ff) ^ + rk[1]; + PUTU32(pt + 4, s1); + s2 = + (Td4[(t2 >> 24) ] & 0xff000000) ^ + (Td4[(t1 >> 16) & 0xff] & 0x00ff0000) ^ + (Td4[(t0 >> 8) & 0xff] & 0x0000ff00) ^ + (Td4[(t3 ) & 0xff] & 0x000000ff) ^ + rk[2]; + PUTU32(pt + 8, s2); + s3 = + (Td4[(t3 >> 24) ] & 0xff000000) ^ + (Td4[(t2 >> 16) & 0xff] & 0x00ff0000) ^ + (Td4[(t1 >> 8) & 0xff] & 0x0000ff00) ^ + (Td4[(t0 ) & 0xff] & 0x000000ff) ^ + rk[3]; + PUTU32(pt + 12, s3); } -rijndael_ctx * -rijndael_set_key(rijndael_ctx *ctx, const u4byte *in_key, const u4byte key_len, - int encrypt) +void +rijndael_set_key(rijndael_ctx *ctx, u_char *key, int bits, int encrypt) { - u4byte i, t, u, v, w; - u4byte *e_key = ctx->e_key; - u4byte *d_key = ctx->d_key; - - ctx->decrypt = !encrypt; - - if(!tab_gen) - gen_tabs(); - - ctx->k_len = (key_len + 31) / 32; - - e_key[0] = io_swap(in_key[0]); e_key[1] = io_swap(in_key[1]); - e_key[2] = io_swap(in_key[2]); e_key[3] = io_swap(in_key[3]); - - switch(ctx->k_len) { - case 4: t = e_key[3]; - for(i = 0; i < 10; ++i) - loop4(i); - break; - - case 6: e_key[4] = io_swap(in_key[4]); t = e_key[5] = io_swap(in_key[5]); - for(i = 0; i < 8; ++i) - loop6(i); - break; - - case 8: e_key[4] = io_swap(in_key[4]); e_key[5] = io_swap(in_key[5]); - e_key[6] = io_swap(in_key[6]); t = e_key[7] = io_swap(in_key[7]); - for(i = 0; i < 7; ++i) - loop8(i); - break; - } - - if (!encrypt) { - d_key[0] = e_key[0]; d_key[1] = e_key[1]; - d_key[2] = e_key[2]; d_key[3] = e_key[3]; - - for(i = 4; i < 4 * ctx->k_len + 24; ++i) { - imix_col(d_key[i], e_key[i]); - } + ctx->Nr = rijndaelKeySetupEnc(ctx->ek, key, bits); + if (encrypt) { + ctx->decrypt = 0; + memset(ctx->dk, 0, sizeof(ctx->dk)); + } else { + ctx->decrypt = 1; + memcpy(ctx->dk, ctx->ek, sizeof(ctx->ek)); + rijndaelKeySetupDec(ctx->dk, key, bits, ctx->Nr); } - - return ctx; } -/* encrypt a block of text */ - -#define f_nround(bo, bi, k) \ - f_rn(bo, bi, 0, k); \ - f_rn(bo, bi, 1, k); \ - f_rn(bo, bi, 2, k); \ - f_rn(bo, bi, 3, k); \ - k += 4 - -#define f_lround(bo, bi, k) \ - f_rl(bo, bi, 0, k); \ - f_rl(bo, bi, 1, k); \ - f_rl(bo, bi, 2, k); \ - f_rl(bo, bi, 3, k) - void -rijndael_encrypt(rijndael_ctx *ctx, const u4byte *in_blk, u4byte *out_blk) +rijndael_decrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) { - u4byte k_len = ctx->k_len; - u4byte *e_key = ctx->e_key; - u4byte b0[4], b1[4], *kp; - - b0[0] = io_swap(in_blk[0]) ^ e_key[0]; - b0[1] = io_swap(in_blk[1]) ^ e_key[1]; - b0[2] = io_swap(in_blk[2]) ^ e_key[2]; - b0[3] = io_swap(in_blk[3]) ^ e_key[3]; - - kp = e_key + 4; - - if(k_len > 6) { - f_nround(b1, b0, kp); f_nround(b0, b1, kp); - } - - if(k_len > 4) { - f_nround(b1, b0, kp); f_nround(b0, b1, kp); - } - - f_nround(b1, b0, kp); f_nround(b0, b1, kp); - f_nround(b1, b0, kp); f_nround(b0, b1, kp); - f_nround(b1, b0, kp); f_nround(b0, b1, kp); - f_nround(b1, b0, kp); f_nround(b0, b1, kp); - f_nround(b1, b0, kp); f_lround(b0, b1, kp); - - out_blk[0] = io_swap(b0[0]); out_blk[1] = io_swap(b0[1]); - out_blk[2] = io_swap(b0[2]); out_blk[3] = io_swap(b0[3]); + rijndaelDecrypt(ctx->dk, ctx->Nr, src, dst); } -/* decrypt a block of text */ - -#define i_nround(bo, bi, k) \ - i_rn(bo, bi, 0, k); \ - i_rn(bo, bi, 1, k); \ - i_rn(bo, bi, 2, k); \ - i_rn(bo, bi, 3, k); \ - k -= 4 - -#define i_lround(bo, bi, k) \ - i_rl(bo, bi, 0, k); \ - i_rl(bo, bi, 1, k); \ - i_rl(bo, bi, 2, k); \ - i_rl(bo, bi, 3, k) - void -rijndael_decrypt(rijndael_ctx *ctx, const u4byte *in_blk, u4byte *out_blk) +rijndael_encrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) { - u4byte b0[4], b1[4], *kp; - u4byte k_len = ctx->k_len; - u4byte *e_key = ctx->e_key; - u4byte *d_key = ctx->d_key; - - b0[0] = io_swap(in_blk[0]) ^ e_key[4 * k_len + 24]; - b0[1] = io_swap(in_blk[1]) ^ e_key[4 * k_len + 25]; - b0[2] = io_swap(in_blk[2]) ^ e_key[4 * k_len + 26]; - b0[3] = io_swap(in_blk[3]) ^ e_key[4 * k_len + 27]; - - kp = d_key + 4 * (k_len + 5); - - if(k_len > 6) { - i_nround(b1, b0, kp); i_nround(b0, b1, kp); - } - - if(k_len > 4) { - i_nround(b1, b0, kp); i_nround(b0, b1, kp); - } - - i_nround(b1, b0, kp); i_nround(b0, b1, kp); - i_nround(b1, b0, kp); i_nround(b0, b1, kp); - i_nround(b1, b0, kp); i_nround(b0, b1, kp); - i_nround(b1, b0, kp); i_nround(b0, b1, kp); - i_nround(b1, b0, kp); i_lround(b0, b1, kp); - - out_blk[0] = io_swap(b0[0]); out_blk[1] = io_swap(b0[1]); - out_blk[2] = io_swap(b0[2]); out_blk[3] = io_swap(b0[3]); + rijndaelEncrypt(ctx->ek, ctx->Nr, src, dst); } Index: rijndael.h =================================================================== RCS file: /var/cvs/openssh/rijndael.h,v retrieving revision 1.8 diff -u -r1.8 rijndael.h --- rijndael.h 2001/08/06 21:24:12 1.8 +++ rijndael.h 2001/09/12 18:52:29 @@ -1,63 +1,49 @@ -/* $OpenBSD: rijndael.h,v 1.9 2001/07/30 16:23:30 stevesk Exp $ */ - -/* This is an independent implementation of the encryption algorithm: */ -/* */ -/* RIJNDAEL by Joan Daemen and Vincent Rijmen */ -/* */ -/* which is a candidate algorithm in the Advanced Encryption Standard */ -/* programme of the US National Institute of Standards and Technology. */ - -/* - ----------------------------------------------------------------------- - Copyright (c) 2001 Dr Brian Gladman , Worcester, UK - - TERMS - - 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 'as is' with no guarantees of correctness or - fitness for purpose. - ----------------------------------------------------------------------- -*/ - -#ifndef _RIJNDAEL_H_ -#define _RIJNDAEL_H_ - -#include "config.h" - -/* 1. Standard types for AES cryptography source code */ - -typedef u_int8_t u1byte; /* an 8 bit unsigned character type */ -typedef u_int16_t u2byte; /* a 16 bit unsigned integer type */ -typedef u_int32_t u4byte; /* a 32 bit unsigned integer type */ - -typedef int8_t s1byte; /* an 8 bit signed character type */ -typedef int16_t s2byte; /* a 16 bit signed integer type */ -typedef int32_t s4byte; /* a 32 bit signed integer type */ - -typedef struct _rijndael_ctx { - u4byte k_len; - int decrypt; - u4byte e_key[64]; - u4byte d_key[64]; +/** + * rijndael-alg-fst.h + * + * @version 3.0 (December 2000) + * + * Optimised ANSI C code for the Rijndael cipher (now AES) + * + * @author Vincent Rijmen + * @author Antoon Bosselaers + * @author Paulo Barreto + * + * This code is hereby placed in the public domain. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''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 AUTHORS OR CONTRIBUTORS 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. + */ +#ifndef __RIJNDAEL_H +#define __RIJNDAEL_H + +#define MAXKC (256/32) +#define MAXKB (256/8) +#define MAXNR 14 + +typedef unsigned char u8; +typedef unsigned short u16; +typedef unsigned int u32; + +/* The structure for key information */ +typedef struct { + int decrypt; + int Nr; /* key-length-dependent number of rounds */ + u32 ek[4*(MAXNR + 1)]; /* encrypt key schedule */ + u32 dk[4*(MAXNR + 1)]; /* decrypt key schedule */ } rijndael_ctx; - - -/* 2. Standard interface for AES cryptographic routines */ - -/* These are all based on 32 bit unsigned values and will therefore */ -/* require endian conversions for big-endian architectures */ -rijndael_ctx * -rijndael_set_key __P((rijndael_ctx *, const u4byte *, const u4byte, int)); -void rijndael_encrypt __P((rijndael_ctx *, const u4byte *, u4byte *)); -void rijndael_decrypt __P((rijndael_ctx *, const u4byte *, u4byte *)); +void rijndael_set_key(rijndael_ctx *, u_char *, int, int); +void rijndael_decrypt(rijndael_ctx *, u_char *, u_char *); +void rijndael_encrypt(rijndael_ctx *, u_char *, u_char *); -#endif /* _RIJNDAEL_H_ */ +#endif /* __RIJNDAEL_H */ From khaled at w-arts.com Thu Sep 13 05:16:23 2001 From: khaled at w-arts.com (Khaled Daham) Date: Wed, 12 Sep 2001 21:16:23 +0200 (CEST) Subject: scp1 issue In-Reply-To: <20010912205016.A23361@folly> Message-ID: On Wed, 12 Sep 2001, Markus Friedl wrote: > On Wed, Sep 12, 2001 at 01:10:17PM +0200, Khaled Daham wrote: > > On Wed, 12 Sep 2001, Markus Friedl wrote: > > > > > scp is just rcp over ssh, so it's not very different from > > > > > > ssh host cat file > > > > Sending a CMSG_EXEC_CMD with 'cat some-file' works without a problem, but > > sending 'scp -f some-file' leads to the "hanging", or as it seems waiting > > for something. > > who is waiting? It seems like 'scp -f' is waiting for something, after I sent CMSG_EXEC_CMD ( with scp -f ) I do not get a single packet back from the server, with any other command i get SMSG_STDOUT_DATA ( well those that send anything to stdout like ls, cat etc ). /Khaled Daham, w.arts Mail: khaled at w-arts.com Cell: +46-70-6785492 FreeBSD: The Power to Serve! http://www.FreeBSD.org/ This isn't rocket science -- but it _is_ computer science. The FreeBSD kernel is very well documented, unfortunately it's all in `C'. From mouring at etoh.eviladmin.org Thu Sep 13 05:19:37 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 12 Sep 2001 14:19:37 -0500 (CDT) Subject: AES update Message-ID: I've done a decent size update of the OpenSSH portable from the upstream tree. There is an AES upgrade that needs to take place, but I need people to test and tell me what endedness changes need to be applied (if any). Attached is the patch. It is geared towards the latter snapshots..Unsure how it will patch (if at all) against 2.9pX series. http://www.eviladmin.org/~mouring/openssh/aes.patch Thanks. - Ben "This is dark day in humanity." From jmknoble at pobox.com Thu Sep 13 06:36:18 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 12 Sep 2001 16:36:18 -0400 Subject: scp bug with 0x0a in filename: In-Reply-To: <20010912125202.F12133@folly>; from markus@openbsd.org on Wed, Sep 12, 2001 at 12:52:02PM +0200 References: <20010912125202.F12133@folly> Message-ID: <20010912163618.O1349@zax.half.pint-stowp.cx> Circa 2001-Sep-12 12:52:02 +0200 dixit Markus Friedl: : i think this is a problem with the rcp protocol, it transfers : the filename with a trailing \n. use sftp :) Or use rsync. -- 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/20010912/184eda29/attachment.bin From mouring at etoh.eviladmin.org Thu Sep 13 06:40:07 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 12 Sep 2001 15:40:07 -0500 (CDT) Subject: AES update In-Reply-To: Message-ID: Bah, I did not mean for this go out twice.. disregard the first one. - Ben On Wed, 12 Sep 2001 mouring at etoh.eviladmin.org wrote: > > I've done a decent size update of the OpenSSH portable from the upstream > tree. There is an AES upgrade that needs to take place, but I need people > to test and tell me what endedness changes need to be applied (if any). > > Attached is the patch. It is geared towards the latter snapshots..Unsure > how it will patch (if at all) against 2.9pX series. > > http://www.eviladmin.org/~mouring/openssh/aes.patch > > Thanks. > > - Ben > "This is dark day in humanity." > > From johnh at aproposretail.com Thu Sep 13 07:08:38 2001 From: johnh at aproposretail.com (John Hardin) Date: Wed, 12 Sep 2001 14:08:38 -0700 Subject: Q: 2.5.2p2, RSA auth and expired passwords Message-ID: <3B9FCED6.650CA424@aproposretail.com> Quick question: ssh client and server 2.5.2p2, RSA authentication. Should the user be prompted to change their password if it's expired? -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 From Nicolas.Williams at ubsw.com Thu Sep 13 07:29:32 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 12 Sep 2001 17:29:32 -0400 Subject: Q: 2.5.2p2, RSA auth and expired passwords In-Reply-To: <3B9FCED6.650CA424@aproposretail.com>; from johnh@aproposretail.com on Wed, Sep 12, 2001 at 02:08:38PM -0700 References: <3B9FCED6.650CA424@aproposretail.com> Message-ID: <20010912172931.X5739@sm2p1386swk.wdr.com> If you were using Kerberos V password validation, how could you check if the user's password is expired without having access to the user's password? If the user requires pre-authentication, then you can't. Nico On Wed, Sep 12, 2001 at 02:08:38PM -0700, John Hardin wrote: > Quick question: > > ssh client and server 2.5.2p2, RSA authentication. Should the user be > prompted to change their password if it's expired? > > -- > John Hardin > Internal Systems Administrator voice: (425) 672-1304 > Apropos Retail Management Systems, Inc. fax: (425) 672-0192 -- 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 johnh at aproposretail.com Thu Sep 13 07:38:49 2001 From: johnh at aproposretail.com (John Hardin) Date: Wed, 12 Sep 2001 14:38:49 -0700 Subject: Q: 2.5.2p2, RSA auth and expired passwords References: <3B9FCED6.650CA424@aproposretail.com> <20010912172931.X5739@sm2p1386swk.wdr.com> Message-ID: <3B9FD5E9.B28B1FF9@aproposretail.com> Nicolas Williams wrote: > > If you were using Kerberos V password validation, how could you check > if the user's password is expired without having access to the user's > password? If the user requires pre-authentication, then you can't. > > On Wed, Sep 12, 2001 at 02:08:38PM -0700, John Hardin wrote: > > Quick question: > > > > ssh client and server 2.5.2p2, RSA authentication. Should the user be > > prompted to change their password if it's expired? That's just it, we're using only plain-vanilla RSA1 authentication. Should it even be checking to see whether the password has expired? I wouldn't expect it to. I was very surprised when an ssh user with RSA auth came to me with a "your password has expired" notice on the screen. -- John Hardin Internal Systems Administrator voice: (425) 672-1304 Apropos Retail Management Systems, Inc. fax: (425) 672-0192 From openssh-unix-dev at thewrittenword.com Thu Sep 13 14:01:45 2001 From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com) Date: Wed, 12 Sep 2001 23:01:45 -0500 Subject: scp doesn't work with large (>2GB) files In-Reply-To: <5bofog1n3p.fsf@chiark.greenend.org.uk>; from matthew@debian.org on Wed, Sep 12, 2001 at 03:48:42PM +0100 References: <20010912125253.G12133@folly> <20010912081007.V7029@justice.loyola.edu> <5bofog1n3p.fsf@chiark.greenend.org.uk> Message-ID: <20010912230144.A58396@oolong.il.thewrittenword.com> On Wed, Sep 12, 2001 at 03:48:42PM +0100, Matthew Vernon wrote: > Michael Stone writes: > > > > > On Wed, Sep 12, 2001 at 12:14:47PM +0100, M.C. Vernon wrote: > > > On Wed, 12 Sep 2001, Markus Friedl wrote: > > > > why is O_LARGEFILE needed? is this some standard API? > > > > > > It's not a standard API, except on Solaris/SunOS and Linux (as far as a > > > quick look will tell me). HP-UX 11i has this flag and notes "This is a > > > non-standard flag which may be used by 32-bit applications to access files > > > larger than 2 GB". OTOH, on those platforms, open() will fail on files > > > bigger than 2GB. This seems to me a good reason to include this flag on > > > platforms where it is defined. > > > > Actually, it's a terrible idea, because off_t will still be 32 bits. > > What would work is > > #define _FILE_OFFSET_BITS 64 > > which would make off_t 64 bits and add an implicit O_LARGEFILE. (That's > > what most of the utilities using O_LARGEFILE would be doing.) You can > > take a look at the configure routines from some of the GNU utilities > > (e.g., fileutils) to see how they do the large file support detection. > > Yes, indeed. Can this go into the next release? adding a CFLAG of > -D_FILE_OFFSET_BITS=64 for systems like Linux would be fine. In the > mean time, I'll add it by hand to the debian/rules file. No! No! No! Look at AC_SYS_LARGEFILE from autoconf 2.50! That is the solution. Do *NOT* have _FILE_OFFSET_BITS hard-coded anywhere in OpenSSH. It's *very very* wrong. All you have to do is drop AC_SYS_LARGEFILE into configure.in and bam!, largefile support. Just make sure "#include " is the first thing the .c files see to get the redefinitions. And, if you explicitly do not want LFS (large file summit) support, then --disable-largefile will do the trick. We already do this with the version of OpenSSH we distribute and it works. I thought we had distributed a patch against 2.9p2 but maybe we didn't. Anyway, I can work up one against CVS. -- albert chin (china at thewrittenword.com) From markus at openbsd.org Thu Sep 13 17:50:35 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 13 Sep 2001 09:50:35 +0200 Subject: scp1 issue In-Reply-To: ; from khaled@w-arts.com on Wed, Sep 12, 2001 at 09:16:23PM +0200 References: <20010912205016.A23361@folly> Message-ID: <20010913095034.A29765@faui02.informatik.uni-erlangen.de> On Wed, Sep 12, 2001 at 09:16:23PM +0200, Khaled Daham wrote: > On Wed, 12 Sep 2001, Markus Friedl wrote: > > > On Wed, Sep 12, 2001 at 01:10:17PM +0200, Khaled Daham wrote: > > > On Wed, 12 Sep 2001, Markus Friedl wrote: > > > > > > > scp is just rcp over ssh, so it's not very different from > > > > > > > > ssh host cat file > > > > > > Sending a CMSG_EXEC_CMD with 'cat some-file' works without a problem, but > > > sending 'scp -f some-file' leads to the "hanging", or as it seems waiting > > > for something. > > > > who is waiting? > > It seems like 'scp -f' is waiting for something, after I sent > CMSG_EXEC_CMD ( with scp -f ) I do not get a single packet back > from the server, with any other command i get SMSG_STDOUT_DATA ( well > those that send anything to stdout like ls, cat etc ). well, scp -f is waiting for scp -t. From markus at openbsd.org Thu Sep 13 19:30:55 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 13 Sep 2001 11:30:55 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010912143359.Q1285@cygbert.vinschen.de>; from vinschen@redhat.com on Wed, Sep 12, 2001 at 02:33:59PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> Message-ID: <20010913113055.A16130@folly> On Wed, Sep 12, 2001 at 02:33:59PM +0200, Corinna Vinschen wrote: > On Wed, Sep 12, 2001 at 02:00:53PM +0200, Markus Friedl wrote: > > is the server running 2.9, too? > > No, just in case you missed my previous mail, it's running > F-Secure 2.0.12 on some Sparc running SunOS. hm, i'm not sure what the 'correct' behaviour according to the protocol specs is. i'll try some other servers. From markus at openbsd.org Thu Sep 13 19:35:42 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 13 Sep 2001 11:35:42 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010912143359.Q1285@cygbert.vinschen.de>; from vinschen@redhat.com on Wed, Sep 12, 2001 at 02:33:59PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> Message-ID: <20010913113542.B16130@folly> On Wed, Sep 12, 2001 at 02:33:59PM +0200, Corinna Vinschen wrote: > On Wed, Sep 12, 2001 at 02:00:53PM +0200, Markus Friedl wrote: > > is the server running 2.9, too? > > No, just in case you missed my previous mail, it's running > F-Secure 2.0.12 on some Sparc running SunOS. ok, i think that ssh.com < 2.1.0 behaves different from newer releases. newer ssh.com servers keep the connection, older servers tear the connection down. -m From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Sep 13 20:22:22 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 13 Sep 2001 12:22:22 +0200 Subject: lastlog with hp-ux 10.20 In-Reply-To: ; from stevesk@pobox.com on Wed, Sep 12, 2001 at 11:26:02AM -0700 References: <200109062245.f86MjX7580402@matrix.Colorado.EDU> Message-ID: <20010913122222.A5691@ws01.aet.tu-cottbus.de> On Wed, Sep 12, 2001 at 11:26:02AM -0700, Kevin Steves wrote: > i haven't heard of problems with configure/lastlog on 10.20. i'll copy > the development list as there are folks there who use 10.20. > > On Thu, 6 Sep 2001, Jesse Caldwell wrote: > :one last problem with openssh -- building openssh on HPUX 10.20 fails > :on loginrec.c (i don't have the errors handy but i would be more than > :happy to recreate them). i get the same error with 2.9p2 and 9/6/2001 > :cvs source, and i tried two versions of gcc and the cc compiler, so > :this is pretty repeatable. :) using --without-lastlog gets around it. > :just wondering if you guys already had a fix or if i should go about > :clobbering the source myself. I cannot reproduce your problem with both 2.9p2 and today's (13.9.2001) cvs source. (10.20 with up-to-date patches.) 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 tsamcik at icpnet.pl Thu Sep 13 20:47:44 2001 From: tsamcik at icpnet.pl (Tomek Samcik) Date: Thu, 13 Sep 2001 12:47:44 +0200 Subject: documentation of ssh Message-ID: <18713776779.20010913124744@icpnet.pl> does anyone know where can I find documentation or specification of some open source implementation of ssh - decription of modules, functions, their tasks etc. -- Best regards, Tomek mailto:tsamcik at icpnet.pl From vinschen at redhat.com Thu Sep 13 22:07:02 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 13 Sep 2001 14:07:02 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010913113542.B16130@folly>; from markus@openbsd.org on Thu, Sep 13, 2001 at 11:35:42AM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> Message-ID: <20010913140702.U1285@cygbert.vinschen.de> On Thu, Sep 13, 2001 at 11:35:42AM +0200, Markus Friedl wrote: > On Wed, Sep 12, 2001 at 02:33:59PM +0200, Corinna Vinschen wrote: > > On Wed, Sep 12, 2001 at 02:00:53PM +0200, Markus Friedl wrote: > > > is the server running 2.9, too? > > > > No, just in case you missed my previous mail, it's running > > F-Secure 2.0.12 on some Sparc running SunOS. > > ok, i think that ssh.com < 2.1.0 behaves different from > newer releases. > > newer ssh.com servers keep the connection, older servers > tear the connection down. But, uhm, why does that result in different behaviour of 2.9p2 in contrast to 2.5.2p2 as client using the same server? And how can I workaround that using 2.9p2? I'm not that keen to stick with 2.5.2p2 on that machine... Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From Nicolas.Williams at ubsw.com Thu Sep 13 23:09:34 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 13 Sep 2001 09:09:34 -0400 Subject: Q: 2.5.2p2, RSA auth and expired passwords In-Reply-To: <3B9FD5E9.B28B1FF9@aproposretail.com>; from johnh@aproposretail.com on Wed, Sep 12, 2001 at 02:38:49PM -0700 References: <3B9FCED6.650CA424@aproposretail.com> <20010912172931.X5739@sm2p1386swk.wdr.com> <3B9FD5E9.B28B1FF9@aproposretail.com> Message-ID: <20010913090933.Y5739@sm2p1386swk.wdr.com> On Wed, Sep 12, 2001 at 02:38:49PM -0700, John Hardin wrote: > Nicolas Williams wrote: > > > > If you were using Kerberos V password validation, how could you check > > if the user's password is expired without having access to the user's > > password? If the user requires pre-authentication, then you can't. > > > > On Wed, Sep 12, 2001 at 02:08:38PM -0700, John Hardin wrote: > > > Quick question: > > > > > > ssh client and server 2.5.2p2, RSA authentication. Should the user be > > > prompted to change their password if it's expired? > > That's just it, we're using only plain-vanilla RSA1 authentication. > Should it even be checking to see whether the password has expired? "Plain-vanilla RSA1 authentication" means no password is involved. The user may have a password, and you might like to check wether or not it's expired, but, as I pointed out, there are some password validation technologies where this check cannot be done without actually having the password -- and having that password available means you're not doing "plain-vanilla RSA1 authentication"! > I wouldn't expect it to. I was very surprised when an ssh user with RSA > auth came to me with a "your password has expired" notice on the screen. Well, with some technologies it could be done. E.g., /etc/shadow, NIS/NIS+, etc... I have not checked, but I imagine that if you compile SSH with PAM support then if the modules in your PAM stack support checking for password expiry without a password, then so must SSH. > -- > John Hardin 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 jdamery at pick.ucam.org Fri Sep 14 04:41:06 2001 From: jdamery at pick.ucam.org (Jonathan Amery) Date: Thu, 13 Sep 2001 19:41:06 +0100 (BST) Subject: ssh argv[0] support Message-ID: <15264.64962.70051.11362@ming.empire.pick.ucam.org> Right - I know you've had a discussion about the argv[0] stuff already, but I've written this simple script to simulate the (now missing) support for Debian, and was asked to send it to you... --- ssh-argv0 --- #! /bin/sh -e if [ "${0##*/}" == "ssh-argv0" ] then echo 'ssh-argv0: This script should not be run like this, see ssh-argv0(1) for details' 1>&2; exit 1; fi ssh "${0##*/}" "$@" ------ end ------ -- ssh-argv0.1 -- .Dd September 7, 2001 .Dt SSH-ARGV0 1 .Os Debian Project .Sh NAME .Nm ssh-argv0 .Nd replaces the old ssh command-name as hostname handling .Sh SYNOPSIS .Ar hostname | user at hostname .Op Fl l Ar login_name .Op Ar command .Pp .Ar hostname | user at hostname .Op Fl afgknqstvxACNPTX1246 .Op Fl c Ar cipher_spec .Op Fl e Ar escape_char .Op Fl i Ar identity_file .Op Fl l Ar login_name .Op Fl m Ar mac_spec .Op Fl o Ar option .Op Fl p Ar port .Oo Fl L Xo .Sm off .Ar port : .Ar host : .Ar hostport .Sm on .Xc .Oc .Oo Fl R Xo .Sm off .Ar port : .Ar host : .Ar hostport .Sm on .Xc .Oc .Op Ar command .Sh DESCRIPTION .Nm replaces the old ssh command-name as hostname handling. If you link to this script with a hostname then executing the link is equivalent to having executed ssh with that hostname as an argument. All other arguments are passed to ssh and will be processed normally .Sh OPTIONS See .Xr ssh 1 .Sh FILES See .Xr ssh 1 .Sh AUTHORS OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt and Dug Song removed many bugs, re-added newer features and created OpenSSH. Markus Friedl contributed the support for SSH protocol versions 1.5 and 2.0. Jonathan Amery wrote this ssh-argv0 script and the associated documentation. .Sh SEE ALSO .Xr ssh 1 ------ end ------ ----- patch ----- --- ssh.1.orig Fri Sep 7 20:03:05 2001 +++ ssh.1 Fri Sep 7 20:17:29 2001 @@ -1404,6 +1404,7 @@ .Xr scp 1 , .Xr sftp 1 , .Xr ssh-add 1 , +.Xr ssh-argv0 1 , .Xr ssh-agent 1 , .Xr ssh-keygen 1 , .Xr telnet 1 , From jdamery at pick.ucam.org Fri Sep 14 04:54:55 2001 From: jdamery at pick.ucam.org (Jonathan Amery) Date: Thu, 13 Sep 2001 19:54:55 +0100 (BST) Subject: Debian bug #111744 - SSH 2.9p2-5 port-forwarded connection may fail to close cleanly Message-ID: <15265.255.122586.783619@ming.empire.pick.ucam.org> I've got this report (edited for clarity): # As it happens, it is unique to tunneling. I only have one protocol to # test with tunnelling at present due to firewalling on the host I'm # connecting to (rdp to a terminal server). # # When I try and telnet [host] 3389, it works fine, and I can disconnect # as normal. If I try the rdp client, I get this error: # # rdesktop: A Remote Desktop Protocol client. # Version 1.0.0-pl19-6-6. Copyright (C) 1999-2000 Matt Chapman. # See http://www.rdesktop.org/ for more information. # # Connection successful. # tcp_recv read: Success # ERROR: expected DT, got 240 # disconnecting # # ...and *that's* when ssh won't exit cleanly. I've done a netstat -an # | grep 3389, and there's no output there; I don't think the connect is # still open, but perhaps something messy happens with the rdesktop # connect, and it causes ssh to become confused? The command he's running is: $ slogin -2 -X -C -lrichardp -L 3389:172.20.1.92:3389 ssh.optimation.co.nz Now, usually one would expect a message like the following if the ssh couldn't end because it was still forewarding connections: % Waiting for forwarded connections to terminate... % The following connections are open: % #0 direct-tcpip: listening port 54321 for xantha port 9, connect % from 127.0.0.1 port 2337 (t4 r1 i1/0 o16/0) However in this case that didn't happen. We are fairly sure that there is a bug in rdesktop - but even so ssh should either exit or give that message in our opinion. Any suggestions? (The Debian BTS entry for this bug includes some strace output which I could mail to this list if it was thought helpful). Thanks, Jonathan. From mouring at etoh.eviladmin.org Fri Sep 14 05:16:10 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 13 Sep 2001 14:16:10 -0500 (CDT) Subject: ssh argv[0] support In-Reply-To: <15264.64962.70051.11362@ming.empire.pick.ucam.org> Message-ID: I would rather see people submit C code to correct the issue than shell script hacks. Nothing personal, but lets solve this problem correctly and not half-ass. - Ben On Thu, 13 Sep 2001, Jonathan Amery wrote: > > Right - I know you've had a discussion about the argv[0] stuff > already, but I've written this simple script to simulate the (now > missing) support for Debian, and was asked to send it to you... > > --- ssh-argv0 --- > #! /bin/sh -e > if [ "${0##*/}" == "ssh-argv0" ] > then > echo 'ssh-argv0: This script should not be run like this, see > ssh-argv0(1) for details' 1>&2; > exit 1; > fi > ssh "${0##*/}" "$@" > ------ end ------ > -- ssh-argv0.1 -- > .Dd September 7, 2001 > .Dt SSH-ARGV0 1 > .Os Debian Project > .Sh NAME > .Nm ssh-argv0 > .Nd replaces the old ssh command-name as hostname handling > .Sh SYNOPSIS > .Ar hostname | user at hostname > .Op Fl l Ar login_name > .Op Ar command > .Pp > .Ar hostname | user at hostname > .Op Fl afgknqstvxACNPTX1246 > .Op Fl c Ar cipher_spec > .Op Fl e Ar escape_char > .Op Fl i Ar identity_file > .Op Fl l Ar login_name > .Op Fl m Ar mac_spec > .Op Fl o Ar option > .Op Fl p Ar port > .Oo Fl L Xo > .Sm off > .Ar port : > .Ar host : > .Ar hostport > .Sm on > .Xc > .Oc > .Oo Fl R Xo > .Sm off > .Ar port : > .Ar host : > .Ar hostport > .Sm on > .Xc > .Oc > .Op Ar command > .Sh DESCRIPTION > .Nm > replaces the old ssh command-name as hostname handling. > If you link to this script with a hostname then executing the link is > equivalent to having executed ssh with that hostname as an argument. > All other arguments are passed to ssh and will be processed normally > .Sh OPTIONS > See > .Xr ssh 1 > .Sh FILES > See > .Xr ssh 1 > .Sh AUTHORS > OpenSSH is a derivative of the original and free > ssh 1.2.12 release by Tatu Ylonen. > Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, > Theo de Raadt and Dug Song > removed many bugs, re-added newer features and > created OpenSSH. > Markus Friedl contributed the support for SSH > protocol versions 1.5 and 2.0. > Jonathan Amery wrote this ssh-argv0 script and the associated > documentation. > .Sh SEE ALSO > .Xr ssh 1 > ------ end ------ > ----- patch ----- > --- ssh.1.orig Fri Sep 7 20:03:05 2001 > +++ ssh.1 Fri Sep 7 20:17:29 2001 > @@ -1404,6 +1404,7 @@ > .Xr scp 1 , > .Xr sftp 1 , > .Xr ssh-add 1 , > +.Xr ssh-argv0 1 , > .Xr ssh-agent 1 , > .Xr ssh-keygen 1 , > .Xr telnet 1 , > > From jdamery at chiark.greenend.org.uk Fri Sep 14 10:03:03 2001 From: jdamery at chiark.greenend.org.uk (Jonathan Amery) Date: Fri, 14 Sep 2001 01:03:03 +0100 Subject: ssh argv[0] support In-Reply-To: References: <15264.64962.70051.11362@ming.empire.pick.ucam.org> Message-ID: In article you write: > >I would rather see people submit C code to correct the issue than >shell script hacks. Nothing personal, but lets solve this problem >correctly and not half-ass. > In what way is this (POSIX shell) script a 'hack'? It's already been decided that it's impossible to do it right in the main ssh code (what if you rename ssh was IIRC the main argument), and C is not the right language to do the job (particularly given it's dodgy string handling). Also OpenSSH already distribute one shell script (in contrib) - ssh-copy-id (which *is* dodgy and hacky, but I'm working on it). And I might note that one comment in the original discussion was that a shell script was precisely the right way to do it. If you don't want 'hacky' shell-scripts then feel free to revert to the old way of doing it, or write an equivilantly portable and bug-free C-programme. Jonathan. From mouring at etoh.eviladmin.org Fri Sep 14 11:07:31 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 13 Sep 2001 20:07:31 -0500 (CDT) Subject: ssh argv[0] support In-Reply-To: Message-ID: On Fri, 14 Sep 2001, Jonathan Amery wrote: > In article you write: > > > >I would rather see people submit C code to correct the issue than > >shell script hacks. Nothing personal, but lets solve this problem > >correctly and not half-ass. > > > In what way is this (POSIX shell) script a 'hack'? It's already been > decided that it's impossible to do it right in the main ssh code (what if > you rename ssh was IIRC the main argument), and C is not the right > language to do the job (particularly given it's dodgy string > handling). > No it was decided that more care should be taken while doing it and not adding in a massive function from another program which could have security issues because of it's #ifdef complexity (the one suggested was from sendmail). > Also OpenSSH already distribute one shell script (in contrib) - > ssh-copy-id (which *is* dodgy and hacky, but I'm working on it). > I don't see how this related to setproctitle() emulation. ssh-copy-id is a script that that copies your *.pub file to another location and sets it up in authorized_keys. I don't see the connection. > And I might note that one comment in the original discussion was that > a shell script was precisely the right way to do it. If you don't > want 'hacky' shell-scripts then feel free to revert to the old way of > doing it, or write an equivilantly portable and bug-free C-programme. > What converstation? Last I remember on the list Steve stated that we should take one OS at a time to assure it was correct. HP/UX is done. It works native on those OSes with setproctitle(). Just leaves OSes like Linux, NeXT, etc to look at. - Ben From rjk+news at sfere.greenend.org.uk Fri Sep 14 22:30:37 2001 From: rjk+news at sfere.greenend.org.uk (Richard Kettlewell) Date: 14 Sep 2001 13:30:37 +0100 Subject: ssh argv[0] support In-Reply-To: Jonathan Amery's message of "Thu, 13 Sep 2001 19:32:02 GMT" References: <15264.64962.70051.11362@ming.empire.pick.ucam.org> Message-ID: <84vgim2bv6.fsf@rjk.greenend.org.uk> Jonathan Amery writes: > #! /bin/sh -e > if [ "${0##*/}" == "ssh-argv0" ] > then > echo 'ssh-argv0: This script should not be run like this, see > ssh-argv0(1) for details' 1>&2; > exit 1; > fi > ssh "${0##*/}" "$@" What's wrong using with shell aliases to achieve the same effect? In fact I think shell aliases are actually better. For example, using bash alias syntax: alias pick="ssh jdamery at pick.ucam.org" would work even when ucam.org wasn't in the DNS search list or when your local username wasn't jdamery, situations in which just linking ~/bin/pick to your proposed ssh-argv0 would fail. (You could link ~/bin/jdamery at pick.ucam.org to it instead, but that would result in more typing.) -- http://www.greenend.org.uk/rjk/ From jdamery at chiark.greenend.org.uk Sat Sep 15 01:52:19 2001 From: jdamery at chiark.greenend.org.uk (Jonathan Amery) Date: Fri, 14 Sep 2001 16:52:19 +0100 Subject: ssh argv[0] support In-Reply-To: <84vgim2bv6.fsf@rjk.greenend.org.uk> References: <15264.64962.70051.11362@ming.empire.pick.ucam.org> Message-ID: In article <84vgim2bv6.fsf at rjk.greenend.org.uk> you write: >Jonathan Amery writes: > >> #! /bin/sh -e >> if [ "${0##*/}" == "ssh-argv0" ] >> then >> echo 'ssh-argv0: This script should not be run like this, see >> ssh-argv0(1) for details' 1>&2; >> exit 1; >> fi >> ssh "${0##*/}" "$@" >What's wrong using with shell aliases to achieve the same effect? (a) This replaces a feature that was removed from openssh in 2.3.something (or there abouts). (b) The only way I've seen the feature used on a large scale is to have a symlink farm in /usr/local/ which then allows all users of the machines to use this feature, regardless of which shell they use (and in local scripts and the like). >In fact I think shell aliases are actually better. For example, using >bash alias syntax: > > alias pick="ssh jdamery at pick.ucam.org" > >would work even when ucam.org wasn't in the DNS search list or when >your local username wasn't jdamery, situations in which just linking >~/bin/pick to your proposed ssh-argv0 would fail. That's what your .ssh/config is for, for example (from my .ssh/config at work): Host chiark HostName login.chiark.greenend.org.uk Compression yes CompressionLevel 9 User jdamery FallBackToRsh no And a symlink from ~/bin/chiark -> /usr/bin/ssh However, I do suspect that most users of the feature are sysadmins of machines within the same administrative control and hence this will not be needed. Jonathan. From Nicolas.Williams at ubsw.com Sat Sep 15 01:59:36 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 14 Sep 2001 11:59:36 -0400 Subject: ssh argv[0] support In-Reply-To: ; from jdamery@chiark.greenend.org.uk on Fri, Sep 14, 2001 at 04:52:19PM +0100 References: <15264.64962.70051.11362@ming.empire.pick.ucam.org> <84vgim2bv6.fsf@rjk.greenend.org.uk> Message-ID: <20010914115935.Z5739@sm2p1386swk.wdr.com> Why would you want this feature anyways??? It doesn't scale, for one, and is just ugly, not to mention the fact that it pollutes the command namespace and that namespace collisions could break your scripts? Nico On Fri, Sep 14, 2001 at 04:52:19PM +0100, Jonathan Amery wrote: > In article <84vgim2bv6.fsf at rjk.greenend.org.uk> you write: > >Jonathan Amery writes: > > > >> #! /bin/sh -e > >> if [ "${0##*/}" == "ssh-argv0" ] > >> then > >> echo 'ssh-argv0: This script should not be run like this, see > >> ssh-argv0(1) for details' 1>&2; > >> exit 1; > >> fi > >> ssh "${0##*/}" "$@" > >What's wrong using with shell aliases to achieve the same effect? > > (a) This replaces a feature that was removed from openssh in > 2.3.something (or there abouts). > > (b) The only way I've seen the feature used on a large scale is to > have a symlink farm in /usr/local/ which then allows all > users of the machines to use this feature, regardless of which shell > they use (and in local scripts and the like). > > >In fact I think shell aliases are actually better. For example, using > >bash alias syntax: > > > > alias pick="ssh jdamery at pick.ucam.org" > > > >would work even when ucam.org wasn't in the DNS search list or when > >your local username wasn't jdamery, situations in which just linking > >~/bin/pick to your proposed ssh-argv0 would fail. > > That's what your .ssh/config is for, for example (from my .ssh/config > at work): > > Host chiark > HostName login.chiark.greenend.org.uk > Compression yes > CompressionLevel 9 > User jdamery > FallBackToRsh no > > And a symlink from ~/bin/chiark -> /usr/bin/ssh > > However, I do suspect that most users of the feature are sysadmins of > machines within the same administrative control and hence this will > not be needed. > > Jonathan. -- 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 mark.mayben at weblinkwireless.com Fri Sep 14 07:29:54 2001 From: mark.mayben at weblinkwireless.com (Mark Mayben) Date: Thu, 13 Sep 2001 16:29:54 -0500 Subject: sftp Message-ID: <3BA12552.9F1DD160@weblinkwireless.com> Afternoon, I am in the process of putting openssh onto our NT servers as a remote command console and all is going well with sshd. I tried to add the sftp-server into the config file and it will not connect. The error I get is: Recieved message too long 1298752370 The I added to the sshd config file is: Subsystem sftp c:\ssh\sftp-server.exe Where c:\ssh is where the program located. Any ideas? Thanks -- Mark Mayben, MCSE Sr. Network Administrator WebLink Wireless, Inc. Phone: 214-765-4461 E-Mail: mark.mayben at weblinkwireless.com From mmokrejs at natur.cuni.cz Fri Sep 14 07:08:38 2001 From: mmokrejs at natur.cuni.cz (=?iso-8859-2?Q?Martin_MOKREJ=A9?=) Date: Thu, 13 Sep 2001 23:08:38 +0200 (MET DST) Subject: Can't compile openssh-SNAP-20010913 Message-ID: Hi, I'm trying to compiled openssh with kerberosIV support and AFS on Irix 6.5.10 with cc, but no luck: cc -O3 -n32 -TARG:platform=IP22 -I/usr/local/include -I/software/@sys/usr/local/include -L/usr/local/lib -L/software/@sys/usr/local/lib -I. -I. -I/usr/local/include -I/usr/athena/include -DETCDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c auth-passwd.c cc-1143 cc: ERROR File = /usr/include/crypt.h, Line = 38 Declaration is incompatible with "void des_encrypt(unsigned long *, struct des_ks_struct *, int)" (declared at line 181 of "/usr/athena/include/des.h"). extern void des_encrypt(char *, int); ^ 1 error detected in the compilation of "auth-passwd.c". Any idea what to do? Thanks. ;-) -- Martin Mokrejs - PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs MIPS / Institute for Bioinformatics GSF - National Research Center for Environment and Health Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany From markus at openbsd.org Sat Sep 15 03:55:21 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 14 Sep 2001 19:55:21 +0200 Subject: Debian bug #111744 - SSH 2.9p2-5 port-forwarded connection may fail to close cleanly In-Reply-To: <15265.255.122586.783619@ming.empire.pick.ucam.org>; from jdamery@pick.ucam.org on Thu, Sep 13, 2001 at 07:54:55PM +0100 References: <15265.255.122586.783619@ming.empire.pick.ucam.org> Message-ID: <20010914195521.B21216@folly> did you check netstat? On Thu, Sep 13, 2001 at 07:54:55PM +0100, Jonathan Amery wrote: > > I've got this report (edited for clarity): > > # As it happens, it is unique to tunneling. I only have one protocol to > # test with tunnelling at present due to firewalling on the host I'm > # connecting to (rdp to a terminal server). > # > # When I try and telnet [host] 3389, it works fine, and I can disconnect > # as normal. If I try the rdp client, I get this error: > # > # rdesktop: A Remote Desktop Protocol client. > # Version 1.0.0-pl19-6-6. Copyright (C) 1999-2000 Matt Chapman. > # See http://www.rdesktop.org/ for more information. > # > # Connection successful. > # tcp_recv read: Success > # ERROR: expected DT, got 240 > # disconnecting > # > # ...and *that's* when ssh won't exit cleanly. I've done a netstat -an > # | grep 3389, and there's no output there; I don't think the connect is > # still open, but perhaps something messy happens with the rdesktop > # connect, and it causes ssh to become confused? > > The command he's running is: > > $ slogin -2 -X -C -lrichardp -L 3389:172.20.1.92:3389 ssh.optimation.co.nz > > Now, usually one would expect a message like the following if the ssh > couldn't end because it was still forewarding connections: > > % Waiting for forwarded connections to terminate... > % The following connections are open: > % #0 direct-tcpip: listening port 54321 for xantha port 9, connect > % from 127.0.0.1 port 2337 (t4 r1 i1/0 o16/0) > > However in this case that didn't happen. > > We are fairly sure that there is a bug in rdesktop - but even so ssh > should either exit or give that message in our opinion. > > Any suggestions? > > (The Debian BTS entry for this bug includes some strace output which > I could mail to this list if it was thought helpful). > > Thanks, > > Jonathan. From markus at openbsd.org Sat Sep 15 03:54:05 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 14 Sep 2001 19:54:05 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010913140702.U1285@cygbert.vinschen.de>; from vinschen@redhat.com on Thu, Sep 13, 2001 at 02:07:02PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> Message-ID: <20010914195405.A21216@folly> On Thu, Sep 13, 2001 at 02:07:02PM +0200, Corinna Vinschen wrote: > On Thu, Sep 13, 2001 at 11:35:42AM +0200, Markus Friedl wrote: > > On Wed, Sep 12, 2001 at 02:33:59PM +0200, Corinna Vinschen wrote: > > > On Wed, Sep 12, 2001 at 02:00:53PM +0200, Markus Friedl wrote: > > > > is the server running 2.9, too? > > > > > > No, just in case you missed my previous mail, it's running > > > F-Secure 2.0.12 on some Sparc running SunOS. > > > > ok, i think that ssh.com < 2.1.0 behaves different from > > newer releases. > > > > newer ssh.com servers keep the connection, older servers > > tear the connection down. > > But, uhm, why does that result in different behaviour of 2.9p2 because 2.5 had a 'broken' implementation like the older ssh servers. it was 'fixed' in 2.9, now you see this behaviour against older, broken servers. the problem is that the drafts for the protocol have changed since 1997. > in contrast to 2.5.2p2 as client using the same server? And > how can I workaround that using 2.9p2? I'm not that keen to > stick with 2.5.2p2 on that machine... > > Corinna > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com From chuck at fiu.edu Sat Sep 15 07:35:37 2001 From: chuck at fiu.edu (Chuck Lyon) Date: Fri, 14 Sep 2001 17:35:37 -0400 Subject: Scads of defunct processes ins AIX 4.3.3 Message-ID: <001801c13d65$36209220$d9fd5e83@cjl02> I hope someone can help. I've installed 2.9p2 on a number of AIX boxes and it works great. The problem is that a HUGE >700 number of defunct processes get generated by sshd. Did I do something wrong ? Any suggestions ? Please email chuck at fiu.edu as I don't subscribe to the list. TIA, Chuck -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2834 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010914/ecb0f5d6/attachment.bin From ssklar at stanford.edu Sat Sep 15 08:25:08 2001 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Fri, 14 Sep 2001 15:25:08 -0700 Subject: Scads of defunct processes ins AIX 4.3.3 In-Reply-To: <001801c13d65$36209220$d9fd5e83@cjl02> References: <001801c13d65$36209220$d9fd5e83@cjl02> Message-ID: How are you starting the initial sshd daemon? If through /etc/inittab, make sure that the action is not set to "respawn", but is "once". Better would be to just call a script that starts the daemon after checking some things. Perhaps I'm off-base here; in any case, I'd be happy to help you if you provide more information. --Sandy >I hope someone can help. I've installed 2.9p2 on a number of AIX boxes and >it works great. >The problem is that a HUGE >700 number of defunct processes get generated >by sshd. Did I do >something wrong ? Any suggestions ? > >Please email chuck at fiu.edu as I don't subscribe to the list. > > >TIA, >Chuck > > >Content-Type: application/x-pkcs7-signature; > name="smime.p7s" >Content-Disposition: attachment; > filename="smime.p7s" > >Attachment converted: home:smime.p7s (????/----) (0006FBEC) -- ------------------------------------------------ sandor w. sklar | Non impediti unix systems administrator | ratione stanford university itss-css | cogitationis ------------------------------------------------- From mouring at etoh.eviladmin.org Sat Sep 15 09:24:13 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 14 Sep 2001 18:24:13 -0500 (CDT) Subject: Call for testers. Message-ID: http://bass.directhit.com/openssh_snap/ Starting tonight I plan on tracking changes very closely with the OpenBSD tree. I need people to test the latest snapshot (9/14 at of right now) and report success or failure on compiling. I am starting this now because we are looking at a code freeze soon and I really want to ensure it compiles and runs on all existing platforms. So we (the portable group) is not rushing to get a release out of the door. Anyone with AES issues in 2.9pX (Cray, NeXT FAT binary, etc) please test to see if the current snapshot supports your platform correctly. - Ben From vinschen at redhat.com Sat Sep 15 09:57:02 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 15 Sep 2001 01:57:02 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010914195405.A21216@folly>; from markus@openbsd.org on Fri, Sep 14, 2001 at 07:54:05PM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> Message-ID: <20010915015702.A2694@cygbert.vinschen.de> On Fri, Sep 14, 2001 at 07:54:05PM +0200, Markus Friedl wrote: > On Thu, Sep 13, 2001 at 02:07:02PM +0200, Corinna Vinschen wrote: > > On Thu, Sep 13, 2001 at 11:35:42AM +0200, Markus Friedl wrote: > > > On Wed, Sep 12, 2001 at 02:33:59PM +0200, Corinna Vinschen wrote: > > > > On Wed, Sep 12, 2001 at 02:00:53PM +0200, Markus Friedl wrote: > > > > > is the server running 2.9, too? > > > > > > > > No, just in case you missed my previous mail, it's running > > > > F-Secure 2.0.12 on some Sparc running SunOS. > > > > > > ok, i think that ssh.com < 2.1.0 behaves different from > > > newer releases. > > > > > > newer ssh.com servers keep the connection, older servers > > > tear the connection down. > > > > But, uhm, why does that result in different behaviour of 2.9p2 > > because 2.5 had a 'broken' implementation like the older ssh > servers. it was 'fixed' in 2.9, now you see this behaviour > against older, broken servers. the problem is that > the drafts for the protocol have changed since 1997. Shouldn't 2.9 behave `broken' when it knows that it communicates with an old `broken' server? > > in contrast to 2.5.2p2 as client using the same server? And > > how can I workaround that using 2.9p2? I'm not that keen to > > stick with 2.5.2p2 on that machine... Otherwise there's neither a workaround nor a sort of a compatibility mode in 2.9. Which means I'm stuck with 2.5.2 unless the server side decides to upgrade :-( Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From wendyp at cray.com Sat Sep 15 11:25:00 2001 From: wendyp at cray.com (Wendy Palm) Date: Fri, 14 Sep 2001 20:25:00 -0500 Subject: Call for testers. References: Message-ID: <3BA2ADEC.99071A0A@cray.com> redhat 6.2, compiled fine. irix 6.5 - compiled fine. solaris 5.8 - compiled fine except for missing prototype *** session.c.orig Fri Sep 14 19:01:42 2001 --- session.c Fri Sep 14 19:02:08 2001 *************** *** 130,135 **** --- 130,136 ---- void do_exec(Session *, const char *); void do_login(Session *, const char *); void do_child(Session *, const char *); + void do_pre_login(Session *); void do_motd(void); int check_quietlogin(Session *, const char *); cray unicos - compiled fine once i added the rest of the unicos changes that haven't been integrated yet. (you caught me just as i was leaving for the night, so i hurried up and ran them). have a good weekend, wendy mouring at etoh.eviladmin.org wrote: > > http://bass.directhit.com/openssh_snap/ > > Starting tonight I plan on tracking changes very closely with the OpenBSD > tree. I need people to test the latest snapshot (9/14 at of right now) > and report success or failure on compiling. > > I am starting this now because we are looking at a code freeze soon and I > really want to ensure it compiles and runs on all existing platforms. So > we (the portable group) is not rushing to get a release out of the door. > > Anyone with AES issues in 2.9pX (Cray, NeXT FAT binary, etc) please test > to see if the current snapshot supports your platform correctly. > > - Ben -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From mouring at etoh.eviladmin.org Sat Sep 15 15:02:55 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 15 Sep 2001 00:02:55 -0500 (CDT) Subject: Call for testers. In-Reply-To: <3BA2ADEC.99071A0A@cray.com> Message-ID: Main concern when you have time is to test the AES implementation at this point to know if there still needs to have stuff mucked around with post-3.0 (sadly it does not look like Cray will get into 3.0 at this moment). Thanks - Ben On Fri, 14 Sep 2001, Wendy Palm wrote: > redhat 6.2, compiled fine. > irix 6.5 - compiled fine. > solaris 5.8 - compiled fine except for missing prototype > > *** session.c.orig Fri Sep 14 19:01:42 2001 > --- session.c Fri Sep 14 19:02:08 2001 > *************** > *** 130,135 **** > --- 130,136 ---- > void do_exec(Session *, const char *); > void do_login(Session *, const char *); > void do_child(Session *, const char *); > + void do_pre_login(Session *); > void do_motd(void); > int check_quietlogin(Session *, const char *); > > cray unicos - compiled fine once i added the rest of the unicos changes that > haven't been integrated yet. > > (you caught me just as i was leaving for the night, so i hurried up and > ran them). > > have a good weekend, > wendy > > > mouring at etoh.eviladmin.org wrote: > > > > http://bass.directhit.com/openssh_snap/ > > > > Starting tonight I plan on tracking changes very closely with the OpenBSD > > tree. I need people to test the latest snapshot (9/14 at of right now) > > and report success or failure on compiling. > > > > I am starting this now because we are looking at a code freeze soon and I > > really want to ensure it compiles and runs on all existing platforms. So > > we (the portable group) is not rushing to get a release out of the door. > > > > Anyone with AES issues in 2.9pX (Cray, NeXT FAT binary, etc) please test > > to see if the current snapshot supports your platform correctly. > > > > - Ben > > -- > wendy palm > Cray OS Sustaining Engineering, Cray Inc. > wendyp at cray.com, 651-605-9154 > From Lutz.Jaenicke at aet.TU-Cottbus.DE Sat Sep 15 17:12:34 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Sat, 15 Sep 2001 09:12:34 +0200 Subject: Call for testers. In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Sep 14, 2001 at 06:24:13PM -0500 References: Message-ID: <20010915091234.A5852@serv01.aet.tu-cottbus.de> On Fri, Sep 14, 2001 at 06:24:13PM -0500, mouring at etoh.eviladmin.org wrote: > > http://bass.directhit.com/openssh_snap/ > > Starting tonight I plan on tracking changes very closely with the OpenBSD > tree. I need people to test the latest snapshot (9/14 at of right now) > and report success or failure on compiling. > > I am starting this now because we are looking at a code freeze soon and I > really want to ensure it compiles and runs on all existing platforms. So > we (the portable group) is not rushing to get a release out of the door. Mumble, mumble. I feel like a parrot: the fix for the ssh-agent forwarding problem on some platforms (e.g. HP-UX) is still not in the code. Background: When using agent forwarding (-A) and actually accessing the agent, the forwarded connection is not closed. This has two consequences: 1. with the forwarded connection still open, the ssh connection will not close down properly (similar to the often discussed sleep;exit hang). 2. The ssh-agent itself will only serve a limited number of connections at a time (10?), so that the ssh-agent will run into a resource limit and will stop accepting connections. Reason is, that on some platforms (namely HP-UX), the shutdown() in only one direction is not propagated (ssh uses shutdown() on the UNIX socket to the agent, but the agent never learns about this shutdown()). I have seen similar effects on pipe-connections on HP-UX, which therefore requires the USE_PIPE flag. I would therefore expect the other platforms requiring the USE_PIPE flag to also be affected. According to configure.in these are: cygwin, NeXT, SunOS4, SNI-SysV, SysV4.2, SysV5, SCO3.2v?, unicos. I have again attached the patch worked out between Markus Friedl and myself. Please test, whether agent forwarding works for you _and_, if you experience the problem described above, whether the patch appended helps. To test: * start the agent and load a key. * connect to a server with ssh -A. * from there open another ssh connection which requires public key authentication with the key in the agent. * exit both connections. If the second exit hangs, you have the problem described. Hint1: the patch only affects the client, as it is the UNIX socket between client and ssh-agent that makes the problem. Hint2: don't forget to "make clean; make" after applying the patch, as the data structures are changed. Sorry for bothering you with this longish email, but the security advantages of agent forwarding are obvious: - a malicious ssh-client binary cannot log your password, as you do not type it in. (This does not protect the malicious binary from changing the communication once established, but this is much harder to exploit than simply logging the password and using it later.) - the password timing attack does not apply, as no passwords have to be typed in to open the second connection. 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 -------------- next part -------------- diff -r -u newsoft/openssh_cvs/channels.c n2/openssh/channels.c --- newsoft/openssh_cvs/channels.c Thu Jul 19 18:03:32 2001 +++ n2/openssh/channels.c Wed Jul 25 18:09:44 2001 @@ -260,6 +260,7 @@ c->cb_fn = NULL; c->cb_arg = NULL; c->cb_event = 0; + c->force_drain = 0; c->detach_user = NULL; c->input_filter = NULL; debug("channel %d: new [%s]", found, remote_name); @@ -1031,6 +1032,7 @@ xfree(remote_ipaddr); return; } + nc->force_drain = 0; if (compat20) { packet_start(SSH2_MSG_CHANNEL_OPEN); packet_put_cstring("x11"); @@ -1185,6 +1187,7 @@ xfree(name); close(newsock); } + nc->force_drain = 0; if (compat20) { packet_start(SSH2_MSG_CHANNEL_OPEN); packet_put_cstring("auth-agent at openssh.com"); @@ -1781,6 +1784,13 @@ if (c == NULL) packet_disconnect("Received ieof for nonexistent channel %d.", id); chan_rcvd_ieof(c); + + /* XXX force input close */ + if (c->force_drain) { + debug2("channel %d: XXX FORCE input drain", c->self); + c->istate = CHAN_INPUT_WAIT_DRAIN; + } + } void @@ -2669,6 +2679,7 @@ close(sock); } else { c->remote_id = remote_id; + c->force_drain = 1; } } if (c == NULL) { @@ -2931,6 +2942,7 @@ close(sock); } else { c->remote_id = remote_id; + c->force_drain = 1; } } if (c == NULL) { diff -r -u newsoft/openssh_cvs/channels.h n2/openssh/channels.h --- newsoft/openssh_cvs/channels.h Thu Jul 19 18:03:33 2001 +++ n2/openssh/channels.h Thu Jul 19 18:31:56 2001 @@ -77,6 +77,7 @@ int efd; /* extended fd */ int sock; /* sock fd */ int isatty; /* rfd is a tty */ + int force_drain; /* force close on iEOF */ Buffer input; /* data read from socket, to be sent over * encrypted connection */ Buffer output; /* data received over encrypted connection for diff -r -u newsoft/openssh_cvs/clientloop.c n2/openssh/clientloop.c --- newsoft/openssh_cvs/clientloop.c Thu Jul 19 18:03:33 2001 +++ n2/openssh/clientloop.c Thu Jul 19 19:24:27 2001 @@ -1111,6 +1111,7 @@ error("client_request_x11: channel_new failed"); close(sock); } + c->force_drain = 1; return c; } @@ -1136,6 +1137,7 @@ error("client_request_agent: channel_new failed"); close(sock); } + c->force_drain = 1; return c; } From ayamura at ayamura.org Sat Sep 15 18:20:36 2001 From: ayamura at ayamura.org (Ayamura KIKUCHI) Date: 15 Sep 2001 17:20:36 +0900 Subject: Call for testers. In-Reply-To: <3BA2ADEC.99071A0A@cray.com> References: <3BA2ADEC.99071A0A@cray.com> Message-ID: <20010915082036.68769.qmail@edge.ayamura.org> > > Starting tonight I plan on tracking changes very closely with the OpenBSD > > tree. I need people to test the latest snapshot (9/14 at of right now) > > and report success or failure on compiling. > irix 6.5 - compiled fine. Really? 1 error detected in the compilation of "rijndael.c in openssh-SNAP-20010915. % uname -aR IRIX64 sea.ayamura.org 6.5 6.5.13f 07091544 IP28 % cc -version MIPSpro Compilers: Version 7.3.1.2m, Patch 4268 % cc -O2 -OPT:Olimit=0 -I. -I/usr/local/ssl/include -I/usr/local/include ... -DHAVE_CONFIG_H -c rijndael.c cc-1020 cc: ERROR File = rijndael.h, Line = 45 The identifier "u_char" is undefined. void rijndael_set_key(rijndael_ctx *, u_char *, int, int); ^ cc-1020 cc: ERROR File = rijndael.h, Line = 46 The identifier "u_char" is undefined. void rijndael_decrypt(rijndael_ctx *, u_char *, u_char *); ^ cc-1020 cc: ERROR File = rijndael.h, Line = 46 The identifier "u_char" is undefined. void rijndael_decrypt(rijndael_ctx *, u_char *, u_char *); ^ cc-1020 cc: ERROR File = rijndael.h, Line = 47 The identifier "u_char" is undefined. void rijndael_encrypt(rijndael_ctx *, u_char *, u_char *); ^ cc-1020 cc: ERROR File = rijndael.h, Line = 47 The identifier "u_char" is undefined. void rijndael_encrypt(rijndael_ctx *, u_char *, u_char *); ^ cc-1020 cc: ERROR File = rijndael.c, Line = 1218 The identifier "u_char" is undefined. rijndael_set_key(rijndael_ctx *ctx, u_char *key, int bits, int encrypt) ^ cc-1020 cc: ERROR File = rijndael.c, Line = 1232 The identifier "u_char" is undefined. rijndael_decrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) ^ cc-1020 cc: ERROR File = rijndael.c, Line = 1232 The identifier "u_char" is undefined. rijndael_decrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) ^ cc-1020 cc: ERROR File = rijndael.c, Line = 1238 The identifier "u_char" is undefined. rijndael_encrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) ^ cc-1020 cc: ERROR File = rijndael.c, Line = 1238 The identifier "u_char" is undefined. rijndael_encrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) -- Ayamura KIKUCHI, M.D., Ph.D. From vinschen at redhat.com Sat Sep 15 19:06:26 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 15 Sep 2001 11:06:26 +0200 Subject: Call for testers. In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Sep 14, 2001 at 06:24:13PM -0500 References: Message-ID: <20010915110626.C533@cygbert.vinschen.de> On Fri, Sep 14, 2001 at 06:24:13PM -0500, mouring at etoh.eviladmin.org wrote: > > http://bass.directhit.com/openssh_snap/ > > Starting tonight I plan on tracking changes very closely with the OpenBSD > tree. I need people to test the latest snapshot (9/14 at of right now) > and report success or failure on compiling. > > I am starting this now because we are looking at a code freeze soon and I > really want to ensure it compiles and runs on all existing platforms. So > we (the portable group) is not rushing to get a release out of the door. > > Anyone with AES issues in 2.9pX (Cray, NeXT FAT binary, etc) please test > to see if the current snapshot supports your platform correctly. At least one additional include is needed in rijndael.c to compile on Cygwin: Index: rijndael.c =================================================================== RCS file: /cvs/openssh_cvs/rijndael.c,v retrieving revision 1.11 diff -u -p -r1.11 rijndael.c --- rijndael.c 2001/09/14 02:47:34 1.11 +++ rijndael.c 2001/09/15 08:53:47 @@ -23,6 +23,7 @@ * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ +#include #include #include Otherwise u_char isn't defined. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From markus at openbsd.org Sat Sep 15 19:06:51 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 15 Sep 2001 11:06:51 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010915015702.A2694@cygbert.vinschen.de>; from vinschen@redhat.com on Sat, Sep 15, 2001 at 01:57:02AM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> <20010915015702.A2694@cygbert.vinschen.de> Message-ID: <20010915110650.C28361@folly> On Sat, Sep 15, 2001 at 01:57:02AM +0200, Corinna Vinschen wrote: > On Fri, Sep 14, 2001 at 07:54:05PM +0200, Markus Friedl wrote: > > On Thu, Sep 13, 2001 at 02:07:02PM +0200, Corinna Vinschen wrote: > > > On Thu, Sep 13, 2001 at 11:35:42AM +0200, Markus Friedl wrote: > > > > On Wed, Sep 12, 2001 at 02:33:59PM +0200, Corinna Vinschen wrote: > > > > > On Wed, Sep 12, 2001 at 02:00:53PM +0200, Markus Friedl wrote: > > > > > > is the server running 2.9, too? > > > > > > > > > > No, just in case you missed my previous mail, it's running > > > > > F-Secure 2.0.12 on some Sparc running SunOS. > > > > > > > > ok, i think that ssh.com < 2.1.0 behaves different from > > > > newer releases. > > > > > > > > newer ssh.com servers keep the connection, older servers > > > > tear the connection down. > > > > > > But, uhm, why does that result in different behaviour of 2.9p2 > > > > because 2.5 had a 'broken' implementation like the older ssh > > servers. it was 'fixed' in 2.9, now you see this behaviour > > against older, broken servers. the problem is that > > the drafts for the protocol have changed since 1997. > > Shouldn't 2.9 behave `broken' when it knows that it communicates > with an old `broken' server? > > > > in contrast to 2.5.2p2 as client using the same server? And > > > how can I workaround that using 2.9p2? I'm not that keen to > > > stick with 2.5.2p2 on that machine... > > Otherwise there's neither a workaround nor a sort of a compatibility > mode in 2.9. Which means I'm stuck with 2.5.2 unless the server > side decides to upgrade :-( look at compat.c, we have many emulations of 'broken' code. i'll look into this, but i think it's too ugly. From markus at openbsd.org Sat Sep 15 19:08:38 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 15 Sep 2001 11:08:38 +0200 Subject: Call for testers. In-Reply-To: <20010915082036.68769.qmail@edge.ayamura.org>; from ayamura@ayamura.org on Sat, Sep 15, 2001 at 05:20:36PM +0900 References: <3BA2ADEC.99071A0A@cray.com> <20010915082036.68769.qmail@edge.ayamura.org> Message-ID: <20010915110838.D28361@folly> rijndael.c does not include includes.h On Sat, Sep 15, 2001 at 05:20:36PM +0900, Ayamura KIKUCHI wrote: > > > Starting tonight I plan on tracking changes very closely with the OpenBSD > > > tree. I need people to test the latest snapshot (9/14 at of right now) > > > and report success or failure on compiling. > > > irix 6.5 - compiled fine. > > Really? 1 error detected in the compilation of "rijndael.c > in openssh-SNAP-20010915. > > % uname -aR > IRIX64 sea.ayamura.org 6.5 6.5.13f 07091544 IP28 > % cc -version > MIPSpro Compilers: Version 7.3.1.2m, Patch 4268 > > % cc -O2 -OPT:Olimit=0 -I. -I/usr/local/ssl/include > -I/usr/local/include ... -DHAVE_CONFIG_H -c rijndael.c > > cc-1020 cc: ERROR File = rijndael.h, Line = 45 > The identifier "u_char" is undefined. > > void rijndael_set_key(rijndael_ctx *, u_char *, int, int); > ^ > cc-1020 cc: ERROR File = rijndael.h, Line = 46 > The identifier "u_char" is undefined. > > void rijndael_decrypt(rijndael_ctx *, u_char *, u_char *); > ^ > cc-1020 cc: ERROR File = rijndael.h, Line = 46 > The identifier "u_char" is undefined. > > void rijndael_decrypt(rijndael_ctx *, u_char *, u_char *); > ^ > cc-1020 cc: ERROR File = rijndael.h, Line = 47 > The identifier "u_char" is undefined. > > void rijndael_encrypt(rijndael_ctx *, u_char *, u_char *); > ^ > cc-1020 cc: ERROR File = rijndael.h, Line = 47 > The identifier "u_char" is undefined. > > void rijndael_encrypt(rijndael_ctx *, u_char *, u_char *); > ^ > cc-1020 cc: ERROR File = rijndael.c, Line = 1218 > The identifier "u_char" is undefined. > > rijndael_set_key(rijndael_ctx *ctx, u_char *key, int bits, int encrypt) > ^ > cc-1020 cc: ERROR File = rijndael.c, Line = 1232 > The identifier "u_char" is undefined. > > rijndael_decrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) > ^ > cc-1020 cc: ERROR File = rijndael.c, Line = 1232 > The identifier "u_char" is undefined. > > rijndael_decrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) > ^ > cc-1020 cc: ERROR File = rijndael.c, Line = 1238 > The identifier "u_char" is undefined. > > rijndael_encrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) > ^ > cc-1020 cc: ERROR File = rijndael.c, Line = 1238 > The identifier "u_char" is undefined. > > rijndael_encrypt(rijndael_ctx *ctx, u_char *src, u_char *dst) > > -- > Ayamura KIKUCHI, M.D., Ph.D. From pekkas at netcore.fi Sat Sep 15 20:12:57 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 15 Sep 2001 13:12:57 +0300 (EEST) Subject: Call for testers. In-Reply-To: Message-ID: On Fri, 14 Sep 2001 mouring at etoh.eviladmin.org wrote: > http://bass.directhit.com/openssh_snap/ > Starting tonight I plan on tracking changes very closely with the OpenBSD > tree. I need people to test the latest snapshot (9/14 at of right now) > and report success or failure on compiling. > > I am starting this now because we are looking at a code freeze soon and I > really want to ensure it compiles and runs on all existing platforms. So > we (the portable group) is not rushing to get a release out of the door. Compiled & run fine on RHL62 and RHL72beta. A couple of issues (mostly just fine-tuning :-).. 1) it would be nice if the init scripts took advantage of the new sshd -t feature. Patch attached. The failure will look like: # ./sshd restart /etc/ssh/sshd_config: line 11: Bad configuration option: Unf /etc/ssh/sshd_config: terminating, 1 bad configuration options [FAILED] and the syslog output will be: Sep 15 12:46:48 haukka sshd: Configuration file or keys failed (note that keys almost never should fail as they are autogenerated if missing or support disabled..) 2) Merging the latest Red Hat openssh spec file and the current one a bit. XXX: ssh-keyscan is in both openssh and openssh-clients; I removed it from openssh, your mileage may vary. If there is a will, I could try to merge these further. 3) Taking package descriptions from latest Red Hat spec; IMO these are a bit better, -askpass, -gnome-askpass etc. are too "noisy" at least; as they require OpenSSH, one should not need to explain openssh in those. (separate patch from above for clarity; this might also be a bit more controversial..) 4) A patch from Red Hat that makes sshd.c do setgroups so that under some circumstances supplemental groups are removed (the cookie attack). May or may not be useful. I fixed a warning in this one, in the ambiguous if - if - else structure. 5) It might be time to remove --with-ipv4-default, at least for redhat7, but this is a policy decision.. -- 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 -------------- next part -------------- Index: sshd.init =================================================================== RCS file: /cvs/openssh_cvs/contrib/redhat/sshd.init,v retrieving revision 1.8 diff -u -r1.8 sshd.init --- sshd.init 2001/04/27 00:46:18 1.8 +++ sshd.init 2001/09/15 09:55:09 @@ -96,6 +96,16 @@ fi fi } +do_restart_sanity_check() { + $SSHD -t + RETVAL=$? + if [ ! "$RETVAL" = 0 ]; then + my_failure "Configuration file or keys" + echo + exit $RETVAL + fi +} + case "$1" in start) @@ -127,12 +137,14 @@ echo ;; restart) + do_restart_sanity_check $0 stop $0 start RETVAL=$? ;; condrestart) if [ -f /var/lock/subsys/sshd ] ; then + do_restart_sanity_check $0 stop $0 start RETVAL=$? -------------- next part -------------- Index: openssh.spec =================================================================== RCS file: /cvs/openssh_cvs/contrib/redhat/openssh.spec,v retrieving revision 1.73 diff -u -r1.73 openssh.spec --- openssh.spec 2001/07/25 00:11:15 1.73 +++ openssh.spec 2001/09/15 09:32:33 @@ -36,18 +36,21 @@ Version: %{oversion} Release: 1 Packager: Damien Miller -URL: http://www.openssh.com/ +URL: http://www.openssh.com/portable.html Source0: ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-%{oversion}.tar.gz %if ! %{no_x11_askpass} -Source1: http://www.jmknoble.cx/software/x11-ssh-askpass/x11-ssh-askpass-%{aversion}.tar.gz +Source1: http://www.pobox.com/~jmknoble/software/x11-ssh-askpass/x11-ssh-askpass-%{aversion}.tar.gz %endif -Copyright: BSD +License: BSD Group: Applications/Internet BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot Obsoletes: ssh BuildPreReq: perl, openssl-devel, tcp_wrappers BuildPreReq: /bin/login, /usr/include/security/pam_appl.h BuildPreReq: rpm >= 3.0.5 +%if ! %{no_x11_askpass} +BuildPreReq: XFree86-devel +%endif %if ! %{no_gnome_askpass} BuildPreReq: gnome-libs-devel %endif @@ -242,13 +245,10 @@ %files %defattr(-,root,root) -%doc ChangeLog OVERVIEW README* INSTALL -%doc CREDITS LICENCE +%doc CREDITS ChangeLog INSTALL LICENCE OVERVIEW README* RFC* TODO WARNING* %attr(0755,root,root) %{_bindir}/ssh-keygen %attr(0755,root,root) %{_bindir}/scp -%attr(0755,root,root) %{_bindir}/ssh-keyscan %attr(0644,root,root) %{_mandir}/man1/ssh-keygen.1* -%attr(0644,root,root) %{_mandir}/man1/ssh-keyscan.1* %attr(0644,root,root) %{_mandir}/man1/scp.1* %attr(0755,root,root) %dir %{_sysconfdir} %attr(0600,root,root) %config(noreplace) %{_sysconfdir}/moduli -------------- next part -------------- --- openssh.spec.1 Sat Sep 15 12:27:22 2001 +++ openssh.spec Sat Sep 15 12:34:02 2001 @@ -31,7 +31,7 @@ %define exact_openssl_version %(rpm -q openssl | cut -d - -f 2) -Summary: OpenSSH free Secure Shell (SSH) implementation +Summary: The OpenSSH implementation of SSH. Name: openssh Version: %{oversion} Release: 1 @@ -62,13 +62,13 @@ Requires: rpm >= 3.0.5 %package clients -Summary: OpenSSH Secure Shell protocol clients +Summary: OpenSSH clients. Requires: openssh = %{version}-%{release} Group: Applications/Internet Obsoletes: ssh-clients %package server -Summary: OpenSSH Secure Shell protocol server (sshd) +Summary: The OpenSSH server daemon. Group: System Environment/Daemons Obsoletes: ssh-server PreReq: openssh = %{version}-%{release}, chkconfig >= 0.9 @@ -77,87 +77,55 @@ %endif %package askpass -Summary: OpenSSH X11 passphrase dialog +Summary: A passphrase dialog for OpenSSH and X. Group: Applications/Internet Requires: openssh = %{version}-%{release} Obsoletes: ssh-extras %package askpass-gnome -Summary: OpenSSH GNOME passphrase dialog +Summary: A passphrase dialog for OpenSSH, X, and GNOME. Group: Applications/Internet Requires: openssh = %{version}-%{release} Obsoletes: ssh-extras %description -Ssh (Secure Shell) a program for logging into a remote machine and for -executing commands in a remote machine. It is intended to replace -rlogin and rsh, and provide secure encrypted communications between -two untrusted hosts over an insecure network. X11 connections and +SSH (Secure SHell) is a program for logging into and executing +commands on a remote machine. SSH is intended to replace rlogin and +rsh, and to provide secure encrypted communications between two +untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. -OpenSSH is OpenBSD's rework of the last free version of SSH, bringing it -up to date in terms of security and features, as well as removing all -patented algorithms to separate libraries (OpenSSL). +OpenSSH is OpenBSD's version of the last free version of SSH, bringing +it up to date in terms of security and features, as well as removing +all patented algorithms to separate libraries. This package includes the core files necessary for both the OpenSSH -client and server. To make this package useful, you should also +client and server. To make this package useful, you should also install openssh-clients, openssh-server, or both. %description clients -Ssh (Secure Shell) a program for logging into a remote machine and for -executing commands in a remote machine. It is intended to replace -rlogin and rsh, and provide secure encrypted communications between -two untrusted hosts over an insecure network. X11 connections and -arbitrary TCP/IP ports can also be forwarded over the secure channel. - -OpenSSH is OpenBSD's rework of the last free version of SSH, bringing it -up to date in terms of security and features, as well as removing all -patented algorithms to separate libraries (OpenSSL). - -This package includes the clients necessary to make encrypted connections -to SSH servers. +OpenSSH is a free version of SSH (Secure SHell), a program for logging +into and executing commands on a remote machine. This package includes +the clients necessary to make encrypted connections to SSH servers. +You'll also need to install the openssh package on OpenSSH clients. %description server -Ssh (Secure Shell) a program for logging into a remote machine and for -executing commands in a remote machine. It is intended to replace -rlogin and rsh, and provide secure encrypted communications between -two untrusted hosts over an insecure network. X11 connections and -arbitrary TCP/IP ports can also be forwarded over the secure channel. - -OpenSSH is OpenBSD's rework of the last free version of SSH, bringing it -up to date in terms of security and features, as well as removing all -patented algorithms to separate libraries (OpenSSL). - -This package contains the secure shell daemon. The sshd is the server -part of the secure shell protocol and allows ssh clients to connect to -your host. +OpenSSH is a free version of SSH (Secure SHell), a program for logging +into and executing commands on a remote machine. This package contains +the secure shell daemon (sshd). The sshd daemon allows SSH clients to +securely connect to your SSH server. You also need to have the openssh +package installed. %description askpass -Ssh (Secure Shell) a program for logging into a remote machine and for -executing commands in a remote machine. It is intended to replace -rlogin and rsh, and provide secure encrypted communications between -two untrusted hosts over an insecure network. X11 connections and -arbitrary TCP/IP ports can also be forwarded over the secure channel. - -OpenSSH is OpenBSD's rework of the last free version of SSH, bringing it -up to date in terms of security and features, as well as removing all -patented algorithms to separate libraries (OpenSSL). - -This package contains Jim Knoble's X11 passphrase -dialog. +OpenSSH is a free version of SSH (Secure SHell), a program for logging +into and executing commands on a remote machine. This package contains +an X11 passphrase dialog for OpenSSH. %description askpass-gnome -Ssh (Secure Shell) a program for logging into a remote machine and for -executing commands in a remote machine. It is intended to replace -rlogin and rsh, and provide secure encrypted communications between -two untrusted hosts over an insecure network. X11 connections and -arbitrary TCP/IP ports can also be forwarded over the secure channel. - -OpenSSH is OpenBSD's rework of the last free version of SSH, bringing it -up to date in terms of security and features, as well as removing all -patented algorithms to separate libraries (OpenSSL). - -This package contains the GNOME passphrase dialog. +OpenSSH is a free version of SSH (Secure SHell), a program for logging +into and executing commands on a remote machine. This package contains +an X11 passphrase dialog for OpenSSH and the GNOME GUI desktop +environment. %prep -------------- next part -------------- Fix one piece of zen-parse at gmx.net's advisory on cookie files. Index: sshd.c =================================================================== RCS file: /cvs/openssh_cvs/sshd.c,v retrieving revision 1.161 diff -u -r1.161 sshd.c --- sshd.c 2001/09/12 16:58:05 1.161 +++ sshd.c 2001/09/15 10:09:57 @@ -776,6 +776,17 @@ #ifdef HAVE_SCO_PROTECTED_PW (void) set_auth_parameters(ac, av); #endif + /* Clear out any supplemental groups we may have inherited. This + * prevents inadvertent creation of files with bad modes (in the + * portable version at least, it's certainly possible for a pluggable + * authentication module to create a file, and we can't control the + * code in eery module which might be used). */ + if (setgroups(0, NULL) < 0) { + if (debug_flag) + error("setgroups() failed: %.200s", strerror(errno)); + else + fatal("setgroups() failed: %.200s", strerror(errno)); + } /* Initialize the log (it is reinitialized below in case we forked). */ if (debug_flag && !inetd_flag) From pekkas at netcore.fi Sat Sep 15 20:17:09 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 15 Sep 2001 13:17:09 +0300 (EEST) Subject: Call for testers. In-Reply-To: Message-ID: On Sat, 15 Sep 2001, Pekka Savola wrote: > 1) it would be nice if the init scripts took advantage of the new sshd -t > feature. Patch attached. The failure will look like: Whoops, a small buglet here: +do_restart_sanity_check() { + $SSHD -t s/$SSHD/sshd/ (openssh official .init file doesn't define $SSHD and I developed this on Red Hat's version). -- 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 pekkas at netcore.fi Sat Sep 15 20:21:14 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 15 Sep 2001 13:21:14 +0300 (EEST) Subject: 2.9p2: sshd -6, port fwd of ipv4 fails In-Reply-To: Message-ID: I tested this on the newest snapshot without '--with-ipv4-default', and started sshd with just 'sshd', and port forwarding of IPv4 worked. So it seems "the problem" appears to have been that '-6' doesn't like forwarding through mapped addresses (different situation in OpenBSD and the rest of the world, as OpenBSD disallows using mapped addresses in these circumstances altogether). On Mon, 23 Jul 2001, Pekka Savola wrote: > Running openssh-2.9p2 on Linux. > > If server is run with 'sshd -6' (to enable ipv6 easily on server end), ie > all IPv4 are represented as mapped addresses, port forwarding will not > work; just running plain ol' IPv4 fixes this of course. > > The server error, when forwarding from the client '143:localhost:143' and > connecting to localhost 143 is: > > debug1: server_input_channel_open: ctype direct-tcpip rchan 1 win 20480 max 2048 > debug1: server_request_direct_tcpip: originator 127.0.0.1 port 1340, target 127.0.0.1 port 143 > connect_to 127.0.0.1: unknown host (Address family for hostname not supported) > debug1: server_input_channel_open: failure direct-tcpip > > The problem is that the connecting clients might not know a thing about > IPv6, so it wouldn't even be possible to forward something like > '143/::127.0.0.1/143', I suspect. > > So it might appear sshd -6 is not entirely "safe" if you want to forward > ports w/ ipv4? > > I wonder if this would work properly on systems that do double bind, ie. > separate ipv4 and ipv6 socket. At least 2.5.2pX on FreeBSD appeared to > have some problems, but didn't go to much into detail there. > > -- 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 djm at mindrot.org Sat Sep 15 21:30:50 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Sep 2001 21:30:50 +1000 (EST) Subject: Call for testers. In-Reply-To: Message-ID: On Sat, 15 Sep 2001, Pekka Savola wrote: > 1) it would be nice if the init scripts took advantage of the new sshd -t > feature. Patch attached. The failure will look like: APplied. > 2) Merging the latest Red Hat openssh spec file and the current one a bit. > XXX: ssh-keyscan is in both openssh and openssh-clients; I removed it from > openssh, your mileage may vary. If there is a will, I could try to merge > these further. Applied. > 3) Taking package descriptions from latest Red Hat spec; IMO these are a > bit better, -askpass, -gnome-askpass etc. are too "noisy" at least; as > they require OpenSSH, one should not need to explain openssh in those. > (separate patch from above for clarity; this might also be a bit more > controversial..) Applied with changes. > 4) A patch from Red Hat that makes sshd.c do setgroups so that under some > circumstances supplemental groups are removed (the cookie attack). May or > may not be useful. > > I fixed a warning in this one, in the ambiguous if - if - else structure. Applied after changes - it is always fatal to fail. > 5) It might be time to remove --with-ipv4-default, at least for redhat7, > but this is a policy decision.. Maybe for Redhat 7.2. Has the long name resolution delay when using a Linux box with IPv6 available (in the kernel) but not configured been resolved? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sat Sep 15 21:39:22 2001 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Sep 2001 21:39:22 +1000 (EST) Subject: Call for testers. In-Reply-To: <20010915082036.68769.qmail@edge.ayamura.org> Message-ID: On 15 Sep 2001, Ayamura KIKUCHI wrote: > > > Starting tonight I plan on tracking changes very closely with the OpenBSD > > > tree. I need people to test the latest snapshot (9/14 at of right now) > > > and report success or failure on compiling. > > > irix 6.5 - compiled fine. > > Really? 1 error detected in the compilation of "rijndael.c > in openssh-SNAP-20010915. Please try tomorrow's snapshot - it should have this problem fixed. Regards, Damien Miller -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From pekkas at netcore.fi Sat Sep 15 21:57:36 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 15 Sep 2001 14:57:36 +0300 (EEST) Subject: Call for testers. In-Reply-To: Message-ID: On Sat, 15 Sep 2001, Damien Miller wrote: > Applied after changes - it is always fatal to fail. > > > 5) It might be time to remove --with-ipv4-default, at least for redhat7, > > but this is a policy decision.. > > Maybe for Redhat 7.2. Has the long name resolution delay when using a > Linux box with IPv6 available (in the kernel) but not configured been > resolved? Latest openssh packages for Red Hat don't have this option anymore; moreover, it seems Mandrake etc. removed it around 2.5.2. It should be safe. (some users might wonder about the pf-10 messages in the syslog though). One of my workstations (RHL72 beta, RHL71 was ok too) has IPv6 enabled (module loaded) but only link-local addresses are configured (no IPv6 router); there are no problems with connecting to IPv4 with this. Only thing that changes is an extra DNS query for AAAA records which causes a delay order of dozens or a hundred milliseconds. No big deal IMO. I don't recall seeing the behaviour you mentioned on RHL62 (glibc 2.1) either, but I can't be 100% sure. I guess it was something from glibc 2.0 or libc5 times. If version is bumped to 3.0, this might be a logical time to embrace IPv6 too.. ;-) -- 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 wayned at users.sourceforge.net Sun Sep 16 05:48:00 2001 From: wayned at users.sourceforge.net (Wayne Davison) Date: Sat, 15 Sep 2001 12:48:00 -0700 (PDT) Subject: Call for testers. In-Reply-To: Message-ID: On Fri, 14 Sep 2001 mouring at etoh.eviladmin.org wrote: > I am starting this now because we are looking at a code freeze soon and I > really want to ensure it compiles and runs on all existing platforms. I've compiled the cvs version on Linux Mandrake 8.0 and Solaris x86 2.6 with some minor problems on Solaris. Back in revision 1.133 of session.c, the conditional prototype for do_pre_login() was removed. This either needs to go back into the file, or the do_pre_login() function needs to be moved up in session.c above do_exec_pty(). Here's a patch for the former option: Index: session.c --- session.c 2001/09/15 02:25:54 1.146 +++ session.c 2001/09/15 19:18:00 @@ -129,6 +129,9 @@ void do_exec_no_pty(Session *, const char *); void do_exec(Session *, const char *); void do_login(Session *, const char *); +#ifdef LOGIN_NEEDS_UTMPX +static void do_pre_login(Session *s); +#endif void do_child(Session *, const char *); void do_motd(void); int check_quietlogin(Session *, const char *); And, in revision 1.6 of sshlogin.h, the prototype for record_utmp_only() was removed. This either needs to be restored, or an extern prototype for the function added to session.c inside the do_pre_login() function. Here's a patch for the former choice: Index: sshlogin.h --- sshlogin.h 2001/07/04 04:46:58 1.6 +++ sshlogin.h 2001/09/15 19:31:44 @@ -17,6 +17,11 @@ void record_login(pid_t, const char *, const char *, uid_t, const char *, struct sockaddr *); +#ifdef LOGIN_NEEDS_UTMPX +void +record_utmp_only(pid_t, const char *, const char *, + const char *, struct sockaddr *); +#endif void record_logout(pid_t, const char *); u_long get_last_login_time(uid_t, const char *, char *, u_int); Also, the bugs I reported back on June 6 in the LOGIN_NEEDS_UTMPX handling are still there. The following patch combines the two patches I sent back then (and resent together recently). This only affects UseLogin=yes on LOGIN_NEEDS_UTMPX systems (currently only Solaris, but I think that the configure section for Unicos also needs to set this define -- Wendy?). This patch doesn't affect the normal (non- LOGIN_NEEDS_UTMPX) processing at all, so it's quite safe. Index: loginrec.c --- loginrec.c 2001/08/06 23:29:17 1.34 +++ loginrec.c 2001/08/21 17:53:43 @@ -448,6 +448,8 @@ login_utmp_only(struct logininfo *li) { li->type = LTYPE_LOGIN; + /* set the timestamp */ + login_set_current_time(li); # ifdef USE_UTMP utmp_write_entry(li); # endif @@ -456,9 +458,10 @@ # endif # ifdef USE_UTMPX utmpx_write_entry(li); -# endif -# ifdef USE_WTMPX +# else +# ifdef USE_WTMPX wtmpx_write_entry(li); +# endif # endif return 0; } ..wayne.. From shorty at getuid.de Sun Sep 16 06:23:17 2001 From: shorty at getuid.de (Christian Kurz) Date: Sat, 15 Sep 2001 22:23:17 +0200 Subject: Call for testers. In-Reply-To: References: Message-ID: <20010915222317.G666@salem.getuid.de> On 01-09-14 mouring at etoh.eviladmin.org wrote: > http://bass.directhit.com/openssh_snap/ > Starting tonight I plan on tracking changes very closely with the OpenBSD > tree. I need people to test the latest snapshot (9/14 at of right now) Is this source identical with the current cvs code? I'll ask because with the current code from cvs, I'll get a lot of these warnings: |/usr/include/sys/types.h:34: warning: `u_char' previously declared here |gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local -DETCDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c auth-rh-rsa.c |In file included from config.h:779, | from includes.h:22, | from auth-rh-rsa.c:15: |defines.h:242: warning: redefinition of `u_char' |/usr/include/sys/types.h:34: warning: `u_char' previously declared here Christian -- A good reputation is more valuable than money. -- Publilius Syrus From mouring at etoh.eviladmin.org Sun Sep 16 08:48:16 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sat, 15 Sep 2001 17:48:16 -0500 (CDT) Subject: Call for testers. In-Reply-To: <20010915222317.G666@salem.getuid.de> Message-ID: You sure you rebuild your configure? I don't see any of those errors on a fresh CVS tree. - Ben On Sat, 15 Sep 2001, Christian Kurz wrote: > On 01-09-14 mouring at etoh.eviladmin.org wrote: > > http://bass.directhit.com/openssh_snap/ > > > Starting tonight I plan on tracking changes very closely with the OpenBSD > > tree. I need people to test the latest snapshot (9/14 at of right now) > > Is this source identical with the current cvs code? I'll ask because > with the current code from cvs, I'll get a lot of these warnings: > > |/usr/include/sys/types.h:34: warning: `u_char' previously declared here > |gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local -DETCDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c auth-rh-rsa.c > |In file included from config.h:779, > | from includes.h:22, > | from auth-rh-rsa.c:15: > |defines.h:242: warning: redefinition of `u_char' > |/usr/include/sys/types.h:34: warning: `u_char' previously declared here > > Christian > -- > A good reputation is more valuable than money. > -- Publilius Syrus > From djm at mindrot.org Sun Sep 16 17:32:00 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Sep 2001 17:32:00 +1000 (EST) Subject: Call for testers. In-Reply-To: <20010915222317.G666@salem.getuid.de> Message-ID: On Sat, 15 Sep 2001, Christian Kurz wrote: > On 01-09-14 mouring at etoh.eviladmin.org wrote: > > http://bass.directhit.com/openssh_snap/ > > > Starting tonight I plan on tracking changes very closely with the OpenBSD > > tree. I need people to test the latest snapshot (9/14 at of right now) > > Is this source identical with the current cvs code? I'll ask because > with the current code from cvs, I'll get a lot of these warnings: > > |/usr/include/sys/types.h:34: warning: `u_char' previously declared here > |gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local -DETCDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/bin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/bin/sftp-server\" -D_PATH_SSH_PIDDIR=\"/var/run\" -DHAVE_CONFIG_H -c auth-rh-rsa.c > |In file included from config.h:779, > | from includes.h:22, > | from auth-rh-rsa.c:15: > |defines.h:242: warning: redefinition of `u_char' > |/usr/include/sys/types.h:34: warning: `u_char' previously declared here Have you regenerated and rerun configure after cvs updating? The definition of u_char in defines.h should be contingent on an autoconf test. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From djm at mindrot.org Sun Sep 16 17:39:58 2001 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Sep 2001 17:39:58 +1000 (EST) Subject: Call for testers. In-Reply-To: Message-ID: On Sat, 15 Sep 2001, Wayne Davison wrote: > Back in revision 1.133 of session.c, the conditional prototype for > do_pre_login() was removed. This either needs to go back into the file, > or the do_pre_login() function needs to be moved up in session.c above > do_exec_pty(). Here's a patch for the former option: It is static in the lastest CVS. > And, in revision 1.6 of sshlogin.h, the prototype for record_utmp_only() > was removed. This either needs to be restored, or an extern prototype > for the function added to session.c inside the do_pre_login() function. > Here's a patch for the former choice: Do we even need this function? It appears identical to record_login() except it takes one less argumentm which isn't used anyway. > Also, the bugs I reported back on June 6 in the LOGIN_NEEDS_UTMPX > handling are still there. The following patch combines the two patches > I sent back then (and resent together recently). This only affects > UseLogin=yes on LOGIN_NEEDS_UTMPX systems (currently only Solaris, but I > think that the configure section for Unicos also needs to set this > define -- Wendy?). This patch doesn't affect the normal (non- > LOGIN_NEEDS_UTMPX) processing at all, so it's quite safe. > > Index: loginrec.c > --- loginrec.c 2001/08/06 23:29:17 1.34 > +++ loginrec.c 2001/08/21 17:53:43 > @@ -448,6 +448,8 @@ > login_utmp_only(struct logininfo *li) > { > li->type = LTYPE_LOGIN; > + /* set the timestamp */ > + login_set_current_time(li); > # ifdef USE_UTMP > utmp_write_entry(li); > # endif > @@ -456,9 +458,10 @@ > # endif > # ifdef USE_UTMPX > utmpx_write_entry(li); > -# endif > -# ifdef USE_WTMPX > +# else > +# ifdef USE_WTMPX > wtmpx_write_entry(li); > +# endif This doesn't look right - this appears to make the wtmpx_write_entry() call only if we are not using utmpx. Could you explain this a little more? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From shorty at getuid.de Sun Sep 16 19:41:17 2001 From: shorty at getuid.de (Christian Kurz) Date: Sun, 16 Sep 2001 11:41:17 +0200 Subject: Call for testers. In-Reply-To: References: <20010915222317.G666@salem.getuid.de> Message-ID: <20010916114117.J666@salem.getuid.de> On 01-09-15 mouring at etoh.eviladmin.org wrote: > You sure you rebuild your configure? I don't see any of those errors on a > fresh CVS tree. Thanks, that was my problem. Looks like it was too late yesterday and I was too tired, so I forgot to rerun configure. :(( Christian -- A good reputation is more valuable than money. -- Publilius Syrus From semi_rass at svitonline.com Sun Sep 16 21:57:36 2001 From: semi_rass at svitonline.com (semi_rass at svitonline.com) Date: Sun, 16 Sep 2001 13:57:36 +0200 Subject: Êîíô. Message-ID: -------------- next part -------------- A non-text attachment was scrubbed... Name: ved_offshor.doc Type: application/octet-stream Size: 45056 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010916/14a57ba5/attachment.obj From kalin at thinrope.net Mon Sep 17 03:50:24 2001 From: kalin at thinrope.net (Kalin Kozhuharov) Date: Mon, 17 Sep 2001 02:50:24 +0900 Subject: openssh-2.9p2: --with-pid-dir does not work? Message-ID: <3BA4E660.9090209@thinrope.net> Hello! I was trying to configure/install the latest openssh-2.9p2 with some not very traditional layout and the configure script didn't make it properly. I was trying to: ./configure \ --prefix=/opt/openssh \ --sysconfdir=/etc/opt/openssh \ --with-pid-dir=/var/opt/openssh/run \ --with-ssl-dir=/opt/openssl But instead the MakefileS read: ... piddir=/etc/opt/openssh ... I could reproduce the bug several times on one Debian box, I think the system is not important here. This issue was addressed before in 2.9p1 and some code was corrected as I see, but still is not working. I looked through some source code, but I couldn't spot the bug :( How I manually fixed it: 1. Run ./configure as above 2. Edit ./Makefile & ./openbsd-compat/Makefile to say piddir=Your/Pid/dir 3. Edit ./config.h to say #define _PATH_SSH_PIDDIR "/Your/Pid/dir" 4. Continue with normal make make install *** in .contrib/solaris/build-pkg script there is a reference to ../../Makefile *** **** I got just one insignificant warning **** ***** I didn't get /var/opt/openssh/run directory created! ***** Now at my 5th (or was it 7th) rebuild I did everything almost correct. And having spent so much time, may be I should have fixed the default path in Makefile.in and live with it? But this is not the programmers way, right? Now just have to set it up, ha! If you reply to this, please send cc to my e-mail as well! Kalin Kozhuharov -- ||///_ o ******************************* ||//,_/> WWW: http://ThinRope.Net/ |||\ <" |||\\ ' ******************************* From wayned at users.sourceforge.net Mon Sep 17 07:39:10 2001 From: wayned at users.sourceforge.net (Wayne Davison) Date: Sun, 16 Sep 2001 14:39:10 -0700 (PDT) Subject: Call for testers. In-Reply-To: Message-ID: On Sun, 16 Sep 2001, Damien Miller wrote: > It is static in the lastest CVS. Which is why my prototype was also static. The way you have the code now, the addition of the "static" keyword just adds an extra warning because it is first declared to be external (by implication) and then declared to be static. If you don't want to include the prototype, you need to move the function up in the file. > Do we even need this function? It appears identical to record_login() > except it takes one less argumentm which isn't used anyway. Yes, it's needed because it calls login_utmp_only() rather than login_login(). You could merge the two functions together, but that might make it harder to sync up with the BSD version. > this appears to make the wtmpx_write_entry() call only if we are not > using utmpx. Could you explain this a little more? This eliminates a duplicate entry in the "last" log. It's one of the weirdnesses of the Solaris login process when UseLogin is true that you can't call WTMPX before running "login". ..wayne.. From chuck at fiu.edu Mon Sep 17 08:36:57 2001 From: chuck at fiu.edu (chuck) Date: Sun, 16 Sep 2001 18:36:57 -0400 Subject: Scads of defunct processes ins AIX 4.3.3 References: <001801c13d65$36209220$d9fd5e83@cjl02> Message-ID: <3BA52989.8010702@fiu.edu> Thanx Sandor! Well, I did have it set to respawn, but I thought I had changed that. I'm going to try starting it manually and see what happens although I was sure I already did that on one box after removing it from inittab. Thanx for the insight. Chuck Sandor W. Sklar wrote: > How are you starting the initial sshd daemon? If through /etc/inittab, > make sure that the action is not set to "respawn", but is "once". > Better would be to just call a script that starts the daemon after > checking some things. > > Perhaps I'm off-base here; in any case, I'd be happy to help you if > you provide more information. > > --Sandy > >> I hope someone can help. I've installed 2.9p2 on a number of AIX >> boxes and >> it works great. >> The problem is that a HUGE >700 number of defunct processes get >> generated >> by sshd. Did I do >> something wrong ? Any suggestions ? >> >> Please email chuck at fiu.edu as I don't subscribe to the list. >> >> >> TIA, >> Chuck >> >> >> Content-Type: application/x-pkcs7-signature; >> name="smime.p7s" >> Content-Disposition: attachment; >> filename="smime.p7s" >> >> Attachment converted: home:smime.p7s (????/----) (0006FBEC) > > From qralston+ml.openssh-unix-dev at andrew.cmu.edu Mon Sep 17 11:38:30 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Sun, 16 Sep 2001 21:38:30 -0400 (EDT) Subject: making openssh work with chroot()'ed accounts? Message-ID: I've been trying to get openssh to play nicely with chroot()'ed accounts (on Red Hat Linux 7.1), but so far, I haven't had much success. I can stick this line in /etc/pam.d/sshd: session required /lib/security/pam_chroot.so debug onerr=fail For slogin, this works great. But scp and sftp don't apply the chroot, because they don't invoke do_pam_session(). Even worse, I can't disable sftp access for chroot()'ed accounts without disabling it for everyone. (Using the "command" option in the authorized_keys2 file will break scp, but sftp will still work.) I looked at Ricardo Cerqueira's contrib/chroot.diff patch. However, it only seems to apply to pam sessions. Even if that weren't the case, the "/./" hack won't permit me to locate the user's ~/.ssh directory (the one that matters; not the one the user sees after the chroot() call has taken place) in a place where they don't have access to it. Is there some easy way to get openssh to work with chroot()'ed accounts? Something I've missed, perhaps? Assuming I haven't overlooked something, I was considering adding a "ChrootConfig" option to the sshd_config file. E.g.: ChrootConfig /etc/security/chroot.conf This would function in the same way as pam_chroot (each line in the file is of the form "username directory", where "username" is a regular expression, and "directory" is the directory to which to chroot() if the regular expression matches. The chroot() call would occur just before the setuid/setgid calls. Thoughts? -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From peterw at usa.net Mon Sep 17 11:51:22 2001 From: peterw at usa.net (Peter W) Date: Sun, 16 Sep 2001 21:51:22 -0400 Subject: keypair auth and limiting access to sftp In-Reply-To: ; from qralston+ml.openssh-unix-dev@andrew.cmu.edu on Sun, Sep 16, 2001 at 09:38:30PM -0400 References: Message-ID: <20010916215122.J11955@usa.net> On Sun, Sep 16, 2001 at 09:38:30PM -0400, James Ralston wrote: > Even worse, I can't disable sftp access for chroot()'ed accounts > without disabling it for everyone. (Using the "command" option in the > authorized_keys2 file will break scp, but sftp will still work.) I was about to post on that topic. I would like to see OpenSSH changed so you can have the sftp subsystem installed/available, but *disable* access to the sftp susbsytem on a keypair-by-keypair basis in the authorized_keys2 file, much as one restricts commands with command= As it stands,[0] it is unsafe to depend on authorized_keys2 to restrict a client keypair authentication to some well-defined task. -Peter [0] based on my observations of 2.5.2p2, reading of 2.9x documentation, and a response on usenet From mouring at etoh.eviladmin.org Mon Sep 17 12:37:55 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Sun, 16 Sep 2001 21:37:55 -0500 (CDT) Subject: keypair auth and limiting access to sftp In-Reply-To: <20010916215122.J11955@usa.net> Message-ID: Peter, you may want to check the current snapshot. On 9/14 I included a patch from the OpenBSD tree on subsystem and key pairs. [..] - markus at cvs.openbsd.org 2001/09/14 [session.c] command=xxx overwrites subsystems, too [..] Hope this helps what you are doing. On Sun, 16 Sep 2001, Peter W wrote: > On Sun, Sep 16, 2001 at 09:38:30PM -0400, James Ralston wrote: > > > Even worse, I can't disable sftp access for chroot()'ed accounts > > without disabling it for everyone. (Using the "command" option in the > > authorized_keys2 file will break scp, but sftp will still work.) > > I was about to post on that topic. I would like to see OpenSSH changed > so you can have the sftp subsystem installed/available, but *disable* > access to the sftp susbsytem on a keypair-by-keypair basis in the > authorized_keys2 file, much as one restricts commands with command= > > As it stands,[0] it is unsafe to depend on authorized_keys2 to restrict > a client keypair authentication to some well-defined task. > > -Peter > > [0] based on my observations of 2.5.2p2, reading of 2.9x documentation, > and a response on usenet > From jmknoble at pobox.com Mon Sep 17 13:31:16 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Sun, 16 Sep 2001 23:31:16 -0400 Subject: ANNOUNCE: x11-ssh-askpass v1.2.4 Message-ID: <20010916233116.C2398@quipu.half.pint-stowp.cx> x11-ssh-askpass version 1.2.4 (code name: Boudin) is now available from the following locations: http://www.poboxc.com/~jmknoble/software/x11-ssh-askpass/ http://www.ntrnet.net/~jmknoble/software/x11-ssh-askpass/ x11-ssh-askpass is a passphrase dialog for use with OpenSSH under the X Window System. Significant changes since version 1.2.2 include: - Minor changes in Imakefile to accommodate building under XFree86-4.1.x. - Changed email and web locations to working addresses. (Version 1.2.3 was never publically released). [Damien, please try this with your Roswell system and tell me whether it works.] -- 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: 249 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010916/d3d83800/attachment.bin From a_ghsek at yahoo.co.in Mon Sep 17 14:13:16 2001 From: a_ghsek at yahoo.co.in (=?iso-8859-1?q?hari=20sekar?=) Date: Mon, 17 Sep 2001 05:13:16 +0100 (BST) Subject: ssh client hangs on exit! Message-ID: <20010917041316.27228.qmail@web8006.mail.in.yahoo.com> To whomsoever it may concern, I have compiled openssh-2.9p2 in LynxOS and it works fine. But there is one problem. The ssh client program hangs on exit. I run the sshd server in LynxOS and connect from a ssh client in Linux system. This is the debug output that I get: < sshd running in LynxOS on i386 machine> # ./sshd -d debug1: Seeding random number generator debug1: sshd version OpenSSH_2.9p2 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 192.168.0.126 port 1022 debug1: Client protocol version 1.5; client software version OpenSSH_2.1.1 debug1: match: OpenSSH_2.1.1 pat ^OpenSSH[-_]2\.[012] debug1: Local version string SSH-1.99-OpenSSH_2.9p2 debug1: Sent 768 bit server key and 1024 bit host key. debug1: Encryption type: 3des debug1: Received session key; encryption turned on. debug1: Installing crc compensation attack detector. debug1: Attempting authentication for harit. Accepted password for harit from 192.168.0.126 port 1022 debug1: session_new: init debug1: session_new: session 0 debug1: Allocating pty. debug1: Ignoring unsupported tty mode opcode 7 (0x7) debug1: Ignoring unsupported tty mode opcode 12 (0xc) debug1: Ignoring unsupported tty mode opcode 13 (0xd) debug1: Ignoring unsupported tty mode opcode 14 (0xe) debug1: Ignoring unsupported tty mode opcode 18 (0x12) debug1: Ignoring unsupported tty mode opcode 41 (0x29) debug1: Ignoring unsupported tty mode opcode 60 (0x3c) debug1: Ignoring unsupported tty mode opcode 61 (0x3d) debug1: Ignoring unsupported tty mode opcode 62 (0x3e) debug1: Entering interactive session. debug1: fd 7 setting O_NONBLOCK debug1: fd 8 IS O_NONBLOCK debug1: server_init_dispatch_13 debug1: server_init_dispatch_15 debug1: Received SIGCHLD. lynx1> exit logout and then hangs. I don't get such problems if I connect to a ssh server running on a Linux machine. It has been mentioned in openssh website's FAQ section that this problem exists on Linux and HP machines. If so, what is the reason for this? Is there a way out? Can anyone help me fix the problem? Thanks in advance, Hari. ____________________________________________________________ Do You Yahoo!? Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com From douglas.manton at uk.ibm.com Mon Sep 17 18:05:52 2001 From: douglas.manton at uk.ibm.com (Doug E Manton) Date: Mon, 17 Sep 2001 09:05:52 +0100 Subject: Scads of defunct processes ins AIX 4.3.3 Message-ID: Chuck, There is a better way to manage sshd under AIX. The AIX SRC (system resource controller) can control the SSH daemon, and even respawn it should it fall over -- without generating tonnes of unneccessary children. As root, execute: mkssys -s sshd -u 0 -p /usr/sbin/sshd -a '-D' -G ssh -R -S -n 15 -f 9 Change /usr/sbin/sshd to wherever you have sshd installed. The -R automatically restarts SSH if it ever falls over. SSH requires the -D option to prevent it forking (a requirement of the SRC). You can now start sshd using the command: startsrc -s sshd and stop it using (if you just kill it, SRC will start a new one!): stopsrc -s sshd You can set it to auto start on boot by adding this line to the end of /etc/rc.tcpip start /usr/sbin/sshd "$src_running" Hope this is useful! -------------------------------------------------------- Doug Manton, AT&T EMEA Commercial Security Solutions E: demanton at att.com -------------------------------------------------------- "If privacy is outlawed, only outlaws will have privacy" From peterw at usa.net Tue Sep 18 02:28:13 2001 From: peterw at usa.net (Peter W) Date: Mon, 17 Sep 2001 12:28:13 -0400 Subject: keypair auth and limiting access to sftp In-Reply-To: ; from mouring@etoh.eviladmin.org on Sun, Sep 16, 2001 at 09:37:55PM -0500 References: <20010916215122.J11955@usa.net> Message-ID: <20010917122813.C837@usa.net> On Sun, Sep 16, 2001 at 09:37:55PM -0500, mouring at etoh.eviladmin.org wrote: > > Peter, you may want to check the current snapshot. On 9/14 I included > a patch from the OpenBSD tree on subsystem and key pairs. > [session.c] > command=xxx overwrites subsystems, too The patch is so small that I don't understand it! I figured it might be more "correct" to add a subsystem= restriction, so you could, for instance, allow a user to use sftp but not issue commands; or would that simply be a matter of listing the subsystem command (e.g. "/usr/libexec/openssh/sftp-server") in the command= restriction? > Hope this helps what you are doing. I hope so, too. Any idea when this might be rolled out in an official release? I think the current behavior does pose security threats, as many admins have been using command= and the no-* restrictions in hopes of securely allowing things like rsync to work with keypair auth, and the ability of clients presenting keypairs that are otherwise tightly restricted to use sftp is frightening. It could lead to almost immediate remote shell. Step 1) connect with sftp and overwrite authorized_key2 Step 2) connect with ssh and you have a full shell Ugh. That attack just hit me. -Peter > On Sun, 16 Sep 2001, Peter W wrote: > > I was about to post on that topic. I would like to see OpenSSH changed > > so you can have the sftp subsystem installed/available, but *disable* > > access to the sftp susbsytem on a keypair-by-keypair basis in the > > authorized_keys2 file, much as one restricts commands with command= > > > > As it stands,[0] it is unsafe to depend on authorized_keys2 to restrict > > a client keypair authentication to some well-defined task. From wendyp at cray.com Tue Sep 18 03:51:54 2001 From: wendyp at cray.com (Wendy Palm) Date: Mon, 17 Sep 2001 12:51:54 -0500 Subject: Call for testers. References: <20010915110626.C533@cygbert.vinschen.de> Message-ID: <3BA6383A.977386F0@cray.com> apparently i grabbed the snapshot too soon, because upon checking out what everyone else is having problems with, i see that rijndael.c in snapshot 0914 is from july (looks completely different.) i'm rerunning my tests now. ignore my previous email regarding successes with my OSs. wendy Corinna Vinschen wrote: > > On Fri, Sep 14, 2001 at 06:24:13PM -0500, mouring at etoh.eviladmin.org wrote: > > > > http://bass.directhit.com/openssh_snap/ > > > > Starting tonight I plan on tracking changes very closely with the OpenBSD > > tree. I need people to test the latest snapshot (9/14 at of right now) > > and report success or failure on compiling. > > > > I am starting this now because we are looking at a code freeze soon and I > > really want to ensure it compiles and runs on all existing platforms. So > > we (the portable group) is not rushing to get a release out of the door. > > > > Anyone with AES issues in 2.9pX (Cray, NeXT FAT binary, etc) please test > > to see if the current snapshot supports your platform correctly. > > At least one additional include is needed in rijndael.c to compile > on Cygwin: > > Index: rijndael.c > =================================================================== > RCS file: /cvs/openssh_cvs/rijndael.c,v > retrieving revision 1.11 > diff -u -p -r1.11 rijndael.c > --- rijndael.c 2001/09/14 02:47:34 1.11 > +++ rijndael.c 2001/09/15 08:53:47 > @@ -23,6 +23,7 @@ > * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, > * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > */ > +#include > #include > #include > > Otherwise u_char isn't defined. > > Corinna > > -- > Corinna Vinschen > Cygwin Developer > Red Hat, Inc. > mailto:vinschen at redhat.com -- wendy palm Cray OS Sustaining Engineering, Cray Inc. wendyp at cray.com, 651-605-9154 From eggert at twinsun.com Tue Sep 18 03:56:09 2001 From: eggert at twinsun.com (Paul Eggert) Date: Mon, 17 Sep 2001 10:56:09 -0700 (PDT) Subject: autoconf cleanup for AC_FUNC_GETPGRP and GETPGRP_VOID In-Reply-To: (akim@epita.fr) References: <001201c13ea2$63f1ce60$54f8e0d5@pandora.be> Message-ID: <200109171756.f8HHu9I24071@shade.twinsun.com> > From: Akim Demaille > Date: 17 Sep 2001 11:22:19 +0200 > > | 2001-09-16 Tim Van Holder > | * lib/autoconf/functions.m4: (AC_FUNC_GETPGRP) Don't rely on > | setpgrp() being present. I looked into that problem a bit more. Several programs use AC_FUNC_GETPGRP and GETPGRP_VOID, including Bash, Gawk, and OpenSSH, but they use it only to decide whether they must pass an arg (either 0 or getpid()) to getpgrp, which is the only sane thing to do in my opinion. And I noticed that Vile avoids AC_FUNC_GETPGRP entirely, just checking whether getpgrp(0) is allowed; I think this is a better test, as it matches how programs actually use GETPGRP_VOID. So here is a patch to simplify this ancient cruft so that it works the way that Vile does things. This patch shouldn't require any change to any of the programs I looked into, but I'll CC: this to bug-bash, bug-gawk, and openssh-unix-dev to give them a heads-up. 2001-09-17 Paul Eggert * doc/autoconf.texi (Particular Functions): AC_FUNC_GETPGRP now merely checks whether it is an error to pass an argument to getpgrp. * lib/autoconf/functions.m4 (_AC_FUNC_GETPGRP_TEST): Remove. (AC_FUNC_GETPGRP): Don't bother with a runtime test. Just check whether it is a (compile-time) error to pass an argument to getpgrp. This simpler test supports the revised documentation, and is all that AC_FUNC_GETPGRP's users really need. diff -ru autoconf/doc/autoconf.texi autoconf-fix1/doc/autoconf.texi --- autoconf/doc/autoconf.texi Mon Sep 17 17:05:37 2001 +++ autoconf-fix1/doc/autoconf.texi Mon Sep 17 17:46:43 2001 @@ -3577,11 +3577,24 @@ @defmac AC_FUNC_GETPGRP @acindex FUNC_GETPGRP @cvindex GETPGRP_VOID + at c @fuindex getpgid @c @fuindex getpgrp + at prindex @code{getpgid} @prindex @code{getpgrp} -If @code{getpgrp} takes no argument (the @sc{posix.1} version), define - at code{GETPGRP_VOID}. Otherwise, it is the @sc{bsd} version, which takes -a process ID as an argument. This macro does not check whether +Define @code{GETPGRP_VOID} if it is an error to pass 0 to + at code{getpgrp}; this is the @sc{posix.1} behavior. On older BSD +systems, you must pass 0 to @code{getpgrp}, as it takes an argument and +behaves like @sc{posix.1}'s @code{getpgid}. + + at example +#if GETPGRP_VOID + pid = getpgrp (); +#else + pid = getpgrp (0); +#endif + at end example + +This macro does not check whether @code{getpgrp} exists at all; if you need to work in that situation, first call @code{AC_CHECK_FUNC} for @code{getpgrp}. @end defmac diff -ru autoconf/lib/autoconf/functions.m4 autoconf-fix1/lib/autoconf/functions.m4 --- autoconf/lib/autoconf/functions.m4 Wed Aug 22 17:52:14 2001 +++ autoconf-fix1/lib/autoconf/functions.m4 Mon Sep 17 17:28:59 2001 @@ -594,91 +594,20 @@ [Define if you have the `getmntent' function.])])]) -# _AC_FUNC_GETPGRP_TEST -# --------------------- -# A program that exits with success iff `getpgrp' seems to ignore its -# argument. -m4_define([_AC_FUNC_GETPGRP_TEST], -[AC_LANG_SOURCE([AC_INCLUDES_DEFAULT] -[[ -/* - * If this system has a BSD-style getpgrp(), - * which takes a pid argument, exit unsuccessfully. - * - * Snarfed from Chet Ramey's bash pgrp.c test program - */ - -int pid; -int pg1, pg2, pg3, pg4; -int ng, np, s, child; - -int -main () -{ - pid = getpid (); - pg1 = getpgrp (0); - pg2 = getpgrp (); - pg3 = getpgrp (pid); - pg4 = getpgrp (1); - - /* If all of these values are the same, it's pretty sure that we're - on a system that ignores getpgrp's first argument. */ - if (pg2 == pg4 && pg1 == pg3 && pg2 == pg3) - exit (0); - - child = fork (); - if (child < 0) - exit(1); - else if (child == 0) - { - np = getpid (); - /* If this is Sys V, this will not work; pgrp will be set to np - because setpgrp just changes a pgrp to be the same as the - pid. */ - setpgrp (np, pg1); - ng = getpgrp (0); /* Same result for Sys V and BSD */ - if (ng == pg1) - exit (1); - else - exit (0); - } - else - { - wait (&s); - exit (s>>8); - } -}]]) -])# _AC_FUNC_GETPGRP_TEST - - # AC_FUNC_GETPGRP # --------------- -# Figure out whether getpgrp takes an argument or not. Try first using -# prototypes (AC_COMPILE), and if the compiler is of no help, try a runtime -# test. +# Figure out whether getpgrp requires zero arguments. AC_DEFUN([AC_FUNC_GETPGRP], -[AC_CACHE_CHECK(whether getpgrp takes no argument, ac_cv_func_getpgrp_void, +[AC_CACHE_CHECK(whether getpgrp requires zero arguments, + ac_cv_func_getpgrp_void, [# Use it with a single arg. AC_COMPILE_IFELSE([AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT], [getpgrp (0);])], - [ac_func_getpgrp_1=yes], - [ac_func_getpgrp_1=no]) -# Use it with no arg. -AC_COMPILE_IFELSE([AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT], [getpgrp ();])], - [ac_func_getpgrp_0=yes], - [ac_func_getpgrp_0=no]) -# If both static checks agree, we are done. -case $ac_func_getpgrp_0:$ac_func_getpgrp_1 in - yes:no) ac_cv_func_getpgrp_void=yes;; - no:yes) ac_cv_func_getpgrp_void=false;; - *) AC_RUN_IFELSE([_AC_FUNC_GETPGRP_TEST], - [ac_cv_func_getpgrp_void=yes], - [ac_cv_func_getpgrp_void=no], - [AC_MSG_ERROR([cannot check getpgrp if cross compiling])]);; -esac # $ac_func_getpgrp_0:$ac_func_getpgrp_1 + [ac_cv_func_getpgrp_void=no], + [ac_cv_func_getpgrp_void=yes]) ]) if test $ac_cv_func_getpgrp_void = yes; then AC_DEFINE(GETPGRP_VOID, 1, - [Define if the `getpgrp' function takes no argument.]) + [Define if the `getpgrp' function requires zero arguments.]) fi ])# AC_FUNC_GETPGRP From aline.runde at philips.com Tue Sep 18 05:25:51 2001 From: aline.runde at philips.com (aline.runde at philips.com) Date: Mon, 17 Sep 2001 12:25:51 -0700 Subject: OpenSSH error messages. Message-ID: % ssh -V OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f I'm wondering if there is any patch for this OpenSSH version for Solaris 2.6 and 7. I cannot ssh to the system, please see errors from var/adm/messages: % tail /var/adm/messages Sep 16 18:11:15 es3 sshd[21487]: fatal: Read from socket failed: Resource temporarily unavailable Sep 16 18:11:25 es3 sshd[21488]: fatal: Read from socket failed: Resource temporarily unavailable Sep 16 18:33:37 es3 sshd[21505]: fatal: Read from socket failed: Resource temporarily unavailable Sep 17 13:55:36 es3 sshd[22734]: fatal: Read from socket failed: Resource temporarily unavailable Did you see these errors before. Please show me how to fix it. Thanks, Aline... From markus at openbsd.org Tue Sep 18 06:25:18 2001 From: markus at openbsd.org (Markus Friedl) Date: Mon, 17 Sep 2001 22:25:18 +0200 Subject: keypair auth and limiting access to sftp In-Reply-To: <20010917122813.C837@usa.net>; from peterw@usa.net on Mon, Sep 17, 2001 at 12:28:13PM -0400 References: <20010916215122.J11955@usa.net> <20010917122813.C837@usa.net> Message-ID: <20010917222518.B17218@folly> On Mon, Sep 17, 2001 at 12:28:13PM -0400, Peter W wrote: > or would that simply be a matter > of listing the subsystem command (e.g. "/usr/libexec/openssh/sftp-server") > in the command= restriction? yes. From qralston+ml.openssh-unix-dev at andrew.cmu.edu Tue Sep 18 07:06:42 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Mon, 17 Sep 2001 17:06:42 -0400 (EDT) Subject: keypair auth and limiting access to sftp In-Reply-To: Message-ID: On Sun, 16 Sep 2001 mouring at etoh.eviladmin.org wrote: > Peter, you may want to check the current snapshot. On 9/14 I > included a patch from the OpenBSD tree on subsystem and key pairs. > > [..] > - markus at cvs.openbsd.org 2001/09/14 > [session.c] > command=xxx overwrites subsystems, too > [..] > > Hope this helps what you are doing. Making sftp inaccessable to chroot'ed accounts is certainly one way to prevent chroot'ed accounts from using sftp to break out of their chroot jails, yes. But it's not a very useful one. I *want* the chroot'ed accounts to be able to use sftp, because if they can't, then I'm going to have to open up ftp in order to allow them to upload files. (And if I have to do *that*, I might as well just not even bother with openssh, and instead tell the userse to just use telnet/ftp instead.) I refuse to accept that the only way I can maintain the integrity of my system's security is to drop ssh/sftp in favor of telnet/ftp. After pondering the pam sources a bit more, here's a question: why does sshd only bother to call do_pam_session() when allocating a pty? If sshd instead were to always call do_pam_session() after the user was authenticated, regardless of what the command to execute was, and regardless of whether the user requested a pty or not, then that would cause ssh, scp, sftp, and any future subsystems to implement pam_chroot.so. Would you accept a patch to make sshd always call do_pam_session()? -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From peterw at usa.net Tue Sep 18 07:17:11 2001 From: peterw at usa.net (Peter W) Date: Mon, 17 Sep 2001 17:17:11 -0400 Subject: keypair auth and limiting access to sftp [no relation to chroot()] In-Reply-To: ; from qralston+ml.openssh-unix-dev@andrew.cmu.edu on Mon, Sep 17, 2001 at 05:06:42PM -0400 References: Message-ID: <20010917171711.O837@usa.net> On Mon, Sep 17, 2001 at 05:06:42PM -0400, James Ralston wrote: > On Sun, 16 Sep 2001 mouring at etoh.eviladmin.org wrote: > > > Peter, you may want to check the current snapshot. On 9/14 I > > included a patch from the OpenBSD tree on subsystem and key pairs. > > > > [..] > > - markus at cvs.openbsd.org 2001/09/14 > > [session.c] > > command=xxx overwrites subsystems, too > > [..] > > > > Hope this helps what you are doing. > > Making sftp inaccessable to chroot'ed accounts is certainly one way to > prevent chroot'ed accounts from using sftp to break out of their > chroot jails, yes. I'm not talking about chroot jails at all. I'm talking about sftp making it easy to bypass all restrictions in ~/.ssh/authorized_keys* (gaining full access as the user despite explicit restrictions). That's why I changed the Subject line -- my beef has nothing to do with chroot(). You just happened on the same sftp problem that I did. This is a *huge* security problem. -Peter From qralston+ml.openssh-unix-dev at andrew.cmu.edu Tue Sep 18 07:40:33 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Mon, 17 Sep 2001 17:40:33 -0400 (EDT) Subject: making openssh work with chroot()'ed accounts? In-Reply-To: <20010917171711.O837@usa.net> Message-ID: On Mon, 17 Sep 2001, Peter W wrote: > I'm not talking about chroot jails at all. I'm talking about sftp > making it easy to bypass all restrictions in ~/.ssh/authorized_keys* > (gaining full access as the user despite explicit restrictions). > That's why I changed the Subject line -- my beef has nothing to do > with chroot(). You just happened on the same sftp problem that I > did. This is a *huge* security problem. It's not really the same problem. You want to keep restricted users (in the sense of what's listed in ~/.ssh/authorized_keys*) from accessing the sftp subsystem, because (as you correctly surmised) allowing restricted users to access sftp will permit them to bypass the restrictions, and is thus a huge security hole. I want to *permit* restricted users (in the sense of users who are in a chroot() jail) to access sftp, but in order to do that, I need sftp to obey the same restrictions (meaning, call chroot() before taking any action that would allow the user to get to any files located outside of the chroot'ed home). This patch: > - markus at cvs.openbsd.org 2001/09/14 > [session.c] > command=xxx overwrites subsystems, too ...should solve your problem. But it won't solve mine. On a related matter, I discovered that sshd would not honor the ~/.ssh/authorized_keys* files unless they (and the ~ and ~/.ssh directories) were owned by the user in question. I think that restriction should be relaxed; IMHO, sshd should honor the ~/.ssh/authorized_keys* files if they (or the intervening directories) are owned by the user in question or by root... -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From mouring at etoh.eviladmin.org Tue Sep 18 07:36:17 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 17 Sep 2001 16:36:17 -0500 (CDT) Subject: making openssh work with chroot()'ed accounts? In-Reply-To: Message-ID: The way I setup sftp for web is odd but works on most if not all accounts (except I don't do chroot). 1. Assign the user's shell to the sftp server. 2. change /home/$USER ownership to root. 3. create a directory for /home/$USER/.ssh/ and lock it down to 000 4. make WWW (in my case) and chown it to $USER It resolves a lot of issues, but it is not the 'best' way to go. There are chroot() sftp-server patches floating around. But chroot() sshd is going to make a mess of things when doing scp or sftp. - Ben On Mon, 17 Sep 2001, James Ralston wrote: > On Mon, 17 Sep 2001, Peter W wrote: > > > I'm not talking about chroot jails at all. I'm talking about sftp > > making it easy to bypass all restrictions in ~/.ssh/authorized_keys* > > (gaining full access as the user despite explicit restrictions). > > That's why I changed the Subject line -- my beef has nothing to do > > with chroot(). You just happened on the same sftp problem that I > > did. This is a *huge* security problem. > > It's not really the same problem. > > You want to keep restricted users (in the sense of what's listed in > ~/.ssh/authorized_keys*) from accessing the sftp subsystem, because > (as you correctly surmised) allowing restricted users to access sftp > will permit them to bypass the restrictions, and is thus a huge > security hole. > > I want to *permit* restricted users (in the sense of users who are in > a chroot() jail) to access sftp, but in order to do that, I need sftp > to obey the same restrictions (meaning, call chroot() before taking > any action that would allow the user to get to any files located > outside of the chroot'ed home). > > This patch: > > > - markus at cvs.openbsd.org 2001/09/14 > > [session.c] > > command=xxx overwrites subsystems, too > > ...should solve your problem. But it won't solve mine. > > On a related matter, I discovered that sshd would not honor the > ~/.ssh/authorized_keys* files unless they (and the ~ and ~/.ssh > directories) were owned by the user in question. I think that > restriction should be relaxed; IMHO, sshd should honor the > ~/.ssh/authorized_keys* files if they (or the intervening directories) > are owned by the user in question or by root... > > -- > James Ralston, Information Technology > Software Engineering Institute > Carnegie Mellon University, Pittsburgh, PA, USA > > From qralston+ml.openssh-unix-dev at andrew.cmu.edu Tue Sep 18 08:35:25 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Mon, 17 Sep 2001 18:35:25 -0400 (EDT) Subject: making openssh work with chroot()'ed accounts? In-Reply-To: Message-ID: On Mon, 17 Sep 2001 mouring at etoh.eviladmin.org wrote: > 1. Assign the user's shell to the sftp server. > 2. change /home/$USER ownership to root. > 3. create a directory for /home/$USER/.ssh/ and lock it down to 000 > 4. make WWW (in my case) and chown it to $USER Unfortunately, my users need interactive access as well as sftp access, so this won't work for me. > It resolves a lot of issues, but it is not the 'best' way to go. > There are chroot() sftp-server patches floating around. But > chroot() sshd is igoing to make a mess of things when doing scp or > sftp. I'm not sure what mess you're referring to. If sshd always calls do_pam_session(), which will ensure that pam_chroot will always run, then for scp/sftp to work properly, I'll need to set up a complete directory structure (executables, shared libraries, etc.) in my chroot'ed directory structure. But I already have to do all of those things, anyway, so that the user's shell, other programs, etc. will run in the chroot'ed structure. Stuffing copies of sftp-server, scp, et. al. into the chroot'ed structure is a minor thing, really. Is this the mess you were referring to, or was it something else? Do you know of any reason why making sshd always call do_pam_session() wouldn't work? The pam_chroot module seems to do a good job, so it would seem to me that *not* stuffing that functionality into sshd would be the best course of action... -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From mouring at etoh.eviladmin.org Tue Sep 18 08:26:52 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Mon, 17 Sep 2001 17:26:52 -0500 (CDT) Subject: making openssh work with chroot()'ed accounts? In-Reply-To: Message-ID: On Mon, 17 Sep 2001, James Ralston wrote: [..] > > Is this the mess you were referring to, or was it something else? > Yes. Maintaining such machinery is nasty, IMHO.. =) But I tend to deploy chroot() sparingly. > Do you know of any reason why making sshd always call do_pam_session() > wouldn't work? The pam_chroot module seems to do a good job, so it > would seem to me that *not* stuffing that functionality into sshd > would be the best course of action... > Sorry, I will not claim to understand PAM in some respects. I know that PAM does not always act the same on every platform (Seems HP/UX vs Solaris to be the major waring parties. =). - Ben From qralston+ml.openssh-unix-dev at andrew.cmu.edu Tue Sep 18 10:00:49 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Mon, 17 Sep 2001 20:00:49 -0400 (EDT) Subject: making openssh work with chroot()'ed accounts? In-Reply-To: Message-ID: On Mon, 17 Sep 2001 mouring at etoh.eviladmin.org wrote: > Yes. Maintaining such machinery [replicated programs/libraries for > chroot'ed directory structures] is nasty, IMHO.. =) But I tend to > deploy chroot() sparingly. To some degree, I agree, but IMO it's a small price to pay for being able to run something in a chroot() environment. > Sorry, I will not claim to understand PAM in some respects. I know > that PAM does not always act the same on every platform (Seems HP/UX > vs Solaris to be the major waring parties. =). Well, let me ask this: do you approve of this method? I don't think it will too difficult to patch sshd to always use do_pam_session, and do it appropriately (famous last words, I know). It might work, it might not; I'll have to test it to see. But if the patch *does* work, I'd rather see it (eventually) get accepted back into the distribution. Having "unofficial" patches floating around for a software package is a pain for all involved... -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From jmknoble at pobox.com Tue Sep 18 11:21:19 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 17 Sep 2001 21:21:19 -0400 Subject: ANNOUNCE: x11-ssh-askpass v1.2.4.1 In-Reply-To: <20010916233116.C2398@quipu.half.pint-stowp.cx>; from jmknoble@pobox.com on Sun, Sep 16, 2001 at 11:31:16PM -0400 Message-ID: <20010917212119.A1927@quipu.half.pint-stowp.cx> x11-ssh-askpass version 1.2.4.1 (code name: Etouffee) is now available from the following locations: http://www.poboxc.com/~jmknoble/software/x11-ssh-askpass/ http://www.ntrnet.net/~jmknoble/software/x11-ssh-askpass/ Significant changes since version 1.2.4 include: - Version 1.2.4 included a default Imakefile with an incorrect default value for the C compiler. Fixed. x11-ssh-askpass is a passphrase dialog for use with OpenSSH under the X Window System. -- 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: 249 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010917/3011a913/attachment.bin From J.S.Peatfield at damtp.cam.ac.uk Tue Sep 18 11:50:14 2001 From: J.S.Peatfield at damtp.cam.ac.uk (J.S.Peatfield at damtp.cam.ac.uk) Date: Tue, 18 Sep 2001 02:50:14 +0100 Subject: lastlog with hp-ux 10.20 Message-ID: <200109180150.f8I1oEa21135.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> I've not tried anything more recent that 2.9p1 on hp-ux 10.20 but on that the only problem I had was with the HP cc needed a minor change to the code in openbsd-compat/strmode.c (it barfed on a non-ansi definition): *** openbsd-compat/strmode.c.orig Wed Mar 14 23:23:41 2001 --- openbsd-compat/strmode.c Wed Mar 14 23:24:36 2001 *************** *** 42,51 **** #include #include ! void ! strmode(mode, p) ! register mode_t mode; ! register char *p; { /* print type */ switch (mode & S_IFMT) { --- 42,48 ---- #include #include ! void strmode( register mode_t mode, register char *p) { /* print type */ switch (mode & S_IFMT) { of course loginrec.c may have changed since then... From stevesk at pobox.com Tue Sep 18 12:21:28 2001 From: stevesk at pobox.com (Kevin Steves) Date: Mon, 17 Sep 2001 19:21:28 -0700 (PDT) Subject: lastlog with hp-ux 10.20 In-Reply-To: <200109180150.f8I1oEa21135.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> Message-ID: On Tue, 18 Sep 2001 J.S.Peatfield at damtp.cam.ac.uk wrote: :I've not tried anything more recent that 2.9p1 on hp-ux 10.20 but on that the :only problem I had was with the HP cc needed a minor change to the code in :openbsd-compat/strmode.c (it barfed on a non-ansi definition): that is caused by a defect in the HP compiler; a fixed version has been available for 2.5 years or so. one is at: ftp://ftp.itrc.hp.com/superseded_patches/hp-ux_patches/s700_800/10.X/PHSS_17507.txt i don't know if there is a newer patch, or if it's now only available on newer application CDs from HP. the prototype and definition have been synced in the CVS version however. From J.S.Peatfield at damtp.cam.ac.uk Tue Sep 18 12:33:38 2001 From: J.S.Peatfield at damtp.cam.ac.uk (J.S.Peatfield at damtp.cam.ac.uk) Date: Tue, 18 Sep 2001 03:33:38 +0100 Subject: lastlog with hp-ux 10.20 Message-ID: <200109180233.f8I2XbY21226.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> Our (very old) HPs arn't on maintenence any more so we can only apply security patches.... [At least that is what HP told us]. Oddly the compilers we have was installed from the last CDs they shipped us in November 1999, which is more recent than 2.5 years ago so I wonder why that patch wasn't already applied... :-) -- Jon From djm at mindrot.org Tue Sep 18 13:42:27 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 18 Sep 2001 13:42:27 +1000 (EST) Subject: making openssh work with chroot()'ed accounts? In-Reply-To: Message-ID: On Mon, 17 Sep 2001, James Ralston wrote: > If sshd always calls do_pam_session(), which will ensure that > pam_chroot will always run Have you checked CVS head? > Is this the mess you were referring to, or was it something else? Not everyone uses PAM. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Sep 18 16:46:17 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 18 Sep 2001 08:46:17 +0200 Subject: lastlog with hp-ux 10.20 In-Reply-To: <200109180233.f8I2XbY21226.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk>; from J.S.Peatfield@damtp.cam.ac.uk on Tue, Sep 18, 2001 at 03:33:38AM +0100 References: <200109180233.f8I2XbY21226.redmires.amtp.cam.ac.uk@damtp.cam.ac.uk> Message-ID: <20010918084616.A12768@serv01.aet.tu-cottbus.de> On Tue, Sep 18, 2001 at 03:33:38AM +0100, J.S.Peatfield at damtp.cam.ac.uk wrote: > Our (very old) HPs arn't on maintenence any more so we can only apply > security patches.... [At least that is what HP told us]. Oddly the > compilers we have was installed from the last CDs they shipped us in > November 1999, which is more recent than 2.5 years ago so I wonder why > that patch wasn't already applied... :-) Patches for HP-UX are freely available: - by registering at HP's electronic support. This includes the patch search function and the access to the security documents, but not to other support documents - if you know what you are looking for from ftp://ftp.itrc.hp.com/hp-ux_patches/ 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 akim at epita.fr Tue Sep 18 17:12:06 2001 From: akim at epita.fr (Akim Demaille) Date: 18 Sep 2001 09:12:06 +0200 Subject: autoconf cleanup for AC_FUNC_GETPGRP and GETPGRP_VOID In-Reply-To: <200109171756.f8HHu9I24071@shade.twinsun.com> References: <001201c13ea2$63f1ce60$54f8e0d5@pandora.be> <200109171756.f8HHu9I24071@shade.twinsun.com> Message-ID: >>>>> "Paul" == Paul Eggert writes: Paul> So here is a patch to simplify this ancient cruft so that it Paul> works the way that Vile does things. This patch shouldn't Paul> require any change to any of the programs I looked into, but Paul> I'll CC: this to bug-bash, bug-gawk, and openssh-unix-dev to Paul> give them a heads-up. Install whenever you want. Thanks! From markus at openbsd.org Tue Sep 18 17:41:06 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 18 Sep 2001 09:41:06 +0200 Subject: keypair auth and limiting access to sftp In-Reply-To: ; from qralston+ml.openssh-unix-dev@andrew.cmu.edu on Mon, Sep 17, 2001 at 05:06:42PM -0400 References: Message-ID: <20010918094106.A15593@faui02.informatik.uni-erlangen.de> On Mon, Sep 17, 2001 at 05:06:42PM -0400, James Ralston wrote: > Making sftp inaccessable to chroot'ed accounts is certainly one way to > prevent chroot'ed accounts from using sftp to break out of their > chroot jails, yes. how is this related to command="xxx" ? > But it's not a very useful one. ? this not related to chroot. -m From vinschen at redhat.com Tue Sep 18 18:38:41 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Sep 2001 10:38:41 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010915110650.C28361@folly>; from markus@openbsd.org on Sat, Sep 15, 2001 at 11:06:51AM +0200 References: <20010904212559.F15127@cygbert.vinschen.de> <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> <20010915015702.A2694@cygbert.vinschen.de> <20010915110650.C28361@folly> Message-ID: <20010918103841.J22900@cygbert.vinschen.de> On Sat, Sep 15, 2001 at 11:06:51AM +0200, Markus Friedl wrote: > On Sat, Sep 15, 2001 at 01:57:02AM +0200, Corinna Vinschen wrote: > > On Fri, Sep 14, 2001 at 07:54:05PM +0200, Markus Friedl wrote: > > > because 2.5 had a 'broken' implementation like the older ssh > > > servers. it was 'fixed' in 2.9, now you see this behaviour > > > against older, broken servers. the problem is that > > > the drafts for the protocol have changed since 1997. > > > > Shouldn't 2.9 behave `broken' when it knows that it communicates > > with an old `broken' server? > > > > > > in contrast to 2.5.2p2 as client using the same server? And > > > > how can I workaround that using 2.9p2? I'm not that keen to > > > > stick with 2.5.2p2 on that machine... > > > > Otherwise there's neither a workaround nor a sort of a compatibility > > mode in 2.9. Which means I'm stuck with 2.5.2 unless the server > > side decides to upgrade :-( > > look at compat.c, we have many emulations of 'broken' code. > i'll look into this, but i think it's too ugly. Could you give me some hints what I have to look at? I'm a bit lost since I haven't found a documentation of the supported bugs in compat.c. What is the change between 2.5.2 and 2.9 which results in 2.9 not keeping the connection when communicating with old servers? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From markus at openbsd.org Tue Sep 18 18:43:29 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 18 Sep 2001 10:43:29 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010918103841.J22900@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Sep 18, 2001 at 10:38:41AM +0200 References: <20010912124254.E12133@folly> <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> <20010915015702.A2694@cygbert.vinschen.de> <20010915110650.C28361@folly> <20010918103841.J22900@cygbert.vinschen.de> Message-ID: <20010918104329.A16974@faui02.informatik.uni-erlangen.de> On Tue, Sep 18, 2001 at 10:38:41AM +0200, Corinna Vinschen wrote: > On Sat, Sep 15, 2001 at 11:06:51AM +0200, Markus Friedl wrote: > > On Sat, Sep 15, 2001 at 01:57:02AM +0200, Corinna Vinschen wrote: > > > On Fri, Sep 14, 2001 at 07:54:05PM +0200, Markus Friedl wrote: > > > > because 2.5 had a 'broken' implementation like the older ssh > > > > servers. it was 'fixed' in 2.9, now you see this behaviour > > > > against older, broken servers. the problem is that > > > > the drafts for the protocol have changed since 1997. > > > > > > Shouldn't 2.9 behave `broken' when it knows that it communicates > > > with an old `broken' server? > > > > > > > > in contrast to 2.5.2p2 as client using the same server? And > > > > > how can I workaround that using 2.9p2? I'm not that keen to > > > > > stick with 2.5.2p2 on that machine... > > > > > > Otherwise there's neither a workaround nor a sort of a compatibility > > > mode in 2.9. Which means I'm stuck with 2.5.2 unless the server > > > side decides to upgrade :-( > > > > look at compat.c, we have many emulations of 'broken' code. > > i'll look into this, but i think it's too ugly. > > Could you give me some hints what I have to look at? I'm a bit lost > since I haven't found a documentation of the supported bugs in compat.c. > What is the change between 2.5.2 and 2.9 which results in 2.9 not > keeping the connection when communicating with old servers? in 2.5 the client requested a 'session' for -N, but did not execute anything. however the 'session' this is not necessary at all. From vinschen at redhat.com Tue Sep 18 19:01:14 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Sep 2001 11:01:14 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010918104329.A16974@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Tue, Sep 18, 2001 at 10:43:29AM +0200 References: <20010912133740.B7308@cygbert.vinschen.de> <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> <20010915015702.A2694@cygbert.vinschen.de> <20010915110650.C28361@folly> <20010918103841.J22900@cygbert.vinschen.de> <20010918104329.A16974@faui02.informatik.uni-erlangen.de> Message-ID: <20010918110114.L22900@cygbert.vinschen.de> On Tue, Sep 18, 2001 at 10:43:29AM +0200, Markus Friedl wrote: > On Tue, Sep 18, 2001 at 10:38:41AM +0200, Corinna Vinschen wrote: > > Could you give me some hints what I have to look at? I'm a bit lost > > since I haven't found a documentation of the supported bugs in compat.c. > > What is the change between 2.5.2 and 2.9 which results in 2.9 not > > keeping the connection when communicating with old servers? > > in 2.5 the client requested a 'session' for -N, > but did not execute anything. > > however the 'session' this is not necessary at all. It seems to be necessary with old servers, isn't it? Is there a way in 2.9 to open a session anyway with -N so that the server doesn't close the connection? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Tue Sep 18 19:04:55 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Sep 2001 11:04:55 +0200 Subject: Call for testers. In-Reply-To: ; from djm@mindrot.org on Sun, Sep 16, 2001 at 05:32:00PM +1000 References: <20010915222317.G666@salem.getuid.de> Message-ID: <20010918110455.M22900@cygbert.vinschen.de> On Sun, Sep 16, 2001 at 05:32:00PM +1000, Damien Miller wrote: > Have you regenerated and rerun configure after cvs updating? The > definition of u_char in defines.h should be contingent on an autoconf > test. I have updated to the latest from CVS today, then I've called autoconf and tried to build. I'm getting the following error now: config.status: creating scard/Makefile config.status: error: cannot find input file: scard/Makefile.in which isn't a surprise since there's no subdir `scard'. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From markus at openbsd.org Tue Sep 18 19:55:24 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 18 Sep 2001 11:55:24 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010918110114.L22900@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Sep 18, 2001 at 11:01:14AM +0200 References: <20010912140053.B11601@faui02.informatik.uni-erlangen.de> <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> <20010915015702.A2694@cygbert.vinschen.de> <20010915110650.C28361@folly> <20010918103841.J22900@cygbert.vinschen.de> <20010918104329.A16974@faui02.informatik.uni-erlangen.de> <20010918110114.L22900@cygbert.vinschen.de> Message-ID: <20010918115523.B16974@faui02.informatik.uni-erlangen.de> On Tue, Sep 18, 2001 at 11:01:14AM +0200, Corinna Vinschen wrote: > It seems to be necessary with old servers, isn't it? it's only necessary if the connection should stay open :) > Is there a way in 2.9 to open a session anyway with -N so that > the server doesn't close the connection? i think all you need to do is ssh_session2() should call ssh_session2_command() for old servers even if no_shell_flag is set ssh_session2_command should not register a callback in this case. can you try this? From vinschen at redhat.com Tue Sep 18 21:42:30 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Sep 2001 13:42:30 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010918115523.B16974@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Tue, Sep 18, 2001 at 11:55:24AM +0200 References: <20010912143359.Q1285@cygbert.vinschen.de> <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> <20010915015702.A2694@cygbert.vinschen.de> <20010915110650.C28361@folly> <20010918103841.J22900@cygbert.vinschen.de> <20010918104329.A16974@faui02.informatik.uni-erlangen.de> <20010918110114.L22900@cygbert.vinschen.de> <20010918115523.B16974@faui02.informatik.uni-erlangen.de> Message-ID: <20010918134230.Q22900@cygbert.vinschen.de> On Tue, Sep 18, 2001 at 11:55:24AM +0200, Markus Friedl wrote: > On Tue, Sep 18, 2001 at 11:01:14AM +0200, Corinna Vinschen wrote: > > It seems to be necessary with old servers, isn't it? > > it's only necessary if the connection should stay open :) > > > Is there a way in 2.9 to open a session anyway with -N so that > > the server doesn't close the connection? > > i think all you need to do is > ssh_session2() should call ssh_session2_command() > for old servers even if no_shell_flag is set > > ssh_session2_command should not register a callback > in this case. > > can you try this? It works. Thanks! However, I don't know which servers are all so called `old servers' with respect to that behaviour. So in the following patch to compat.c the flags are more or less a guess. Could you check if they are ok? Again, thanks for the hint which allowed me to create that patch. Corinna Index: compat.c =================================================================== RCS file: /cvs/openssh_cvs/compat.c,v retrieving revision 1.51 diff -u -p -r1.51 compat.c --- compat.c 2001/09/18 05:55:10 1.51 +++ compat.c 2001/09/18 11:45:18 @@ -69,42 +69,49 @@ compat_datafellows(const char *version) } check[] = { { "^OpenSSH[-_]2\\.[012]", SSH_OLD_SESSIONID|SSH_BUG_BANNER| - SSH_OLD_DHGEX|SSH_BUG_NOREKEY }, + SSH_OLD_DHGEX|SSH_BUG_NOREKEY| + SSH_BUG_CLOSECONN }, { "^OpenSSH_2\\.3\\.0", SSH_BUG_BANNER|SSH_BUG_BIGENDIANAES| - SSH_OLD_DHGEX|SSH_BUG_NOREKEY}, + SSH_OLD_DHGEX|SSH_BUG_NOREKEY| + SSH_BUG_CLOSECONN }, { "^OpenSSH_2\\.3\\.", SSH_BUG_BIGENDIANAES|SSH_OLD_DHGEX| - SSH_BUG_NOREKEY}, + SSH_BUG_NOREKEY|SSH_BUG_CLOSECONN }, { "^OpenSSH_2\\.5\\.[01]p1", SSH_BUG_BIGENDIANAES|SSH_OLD_DHGEX| - SSH_BUG_NOREKEY }, + SSH_BUG_NOREKEY|SSH_BUG_CLOSECONN }, { "^OpenSSH_2\\.5\\.[012]", - SSH_OLD_DHGEX|SSH_BUG_NOREKEY }, + SSH_OLD_DHGEX|SSH_BUG_NOREKEY| + SSH_BUG_CLOSECONN }, { "^OpenSSH_2\\.5\\.3", - SSH_BUG_NOREKEY }, + SSH_BUG_NOREKEY|SSH_BUG_CLOSECONN }, { "^OpenSSH", 0 }, { "MindTerm", 0 }, { "^2\\.1\\.0", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID|SSH_BUG_DEBUG| - SSH_BUG_RSASIGMD5|SSH_BUG_HBSERVICE }, + SSH_BUG_RSASIGMD5|SSH_BUG_HBSERVICE| + SSH_BUG_CLOSECONN }, { "^2\\.1 ", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID|SSH_BUG_DEBUG| - SSH_BUG_RSASIGMD5|SSH_BUG_HBSERVICE }, + SSH_BUG_RSASIGMD5|SSH_BUG_HBSERVICE| + SSH_BUG_CLOSECONN }, { "^2\\.0\\.1[3-9]", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID|SSH_BUG_DEBUG| SSH_BUG_PKSERVICE|SSH_BUG_X11FWD| SSH_BUG_PKOK|SSH_BUG_RSASIGMD5| - SSH_BUG_HBSERVICE|SSH_BUG_OPENFAILURE }, + SSH_BUG_HBSERVICE|SSH_BUG_OPENFAILURE| + SSH_BUG_CLOSECONN }, { "^2\\.0\\.1[1-2]", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID|SSH_BUG_DEBUG| SSH_BUG_PKSERVICE|SSH_BUG_X11FWD| SSH_BUG_PKAUTH|SSH_BUG_PKOK| - SSH_BUG_RSASIGMD5|SSH_BUG_OPENFAILURE }, + SSH_BUG_RSASIGMD5|SSH_BUG_OPENFAILURE| + SSH_BUG_CLOSECONN }, { "^2\\.0\\.", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID|SSH_BUG_DEBUG| SSH_BUG_PKSERVICE|SSH_BUG_X11FWD| SSH_BUG_PKAUTH|SSH_BUG_PKOK| SSH_BUG_RSASIGMD5|SSH_BUG_OPENFAILURE| - SSH_BUG_DERIVEKEY }, + SSH_BUG_DERIVEKEY|SSH_BUG_CLOSECONN }, { "^2\\.[23]\\.0", SSH_BUG_HMAC|SSH_BUG_DEBUG| SSH_BUG_RSASIGMD5 }, { "^2\\.3\\.", SSH_BUG_DEBUG|SSH_BUG_RSASIGMD5 }, Index: compat.h =================================================================== RCS file: /cvs/openssh_cvs/compat.h,v retrieving revision 1.26 diff -u -p -r1.26 compat.h --- compat.h 2001/07/04 04:46:57 1.26 +++ compat.h 2001/09/18 11:45:18 @@ -50,6 +50,7 @@ #define SSH_BUG_HBSERVICE 0x00010000 #define SSH_BUG_OPENFAILURE 0x00020000 #define SSH_BUG_DERIVEKEY 0x00040000 +#define SSH_BUG_CLOSECONN 0x00100000 void enable_compat13(void); void enable_compat20(void); Index: ssh.c =================================================================== RCS file: /cvs/openssh_cvs/ssh.c,v retrieving revision 1.116 diff -u -p -r1.116 ssh.c --- ssh.c 2001/09/12 18:32:20 1.116 +++ ssh.c 2001/09/18 11:45:20 @@ -1163,7 +1163,8 @@ ssh_session2(void) /* XXX should be pre-session */ ssh_init_forwarding(); - id = no_shell_flag ? -1 : ssh_session2_command(); + id = no_shell_flag && !(datafellows & SSH_BUG_CLOSECONN) ? + -1 : ssh_session2_command(); /* If requested, let ssh continue in the background. */ if (fork_after_authentication_flag) From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Sep 18 21:52:15 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 18 Sep 2001 13:52:15 +0200 Subject: Call for testers. In-Reply-To: <20010918110455.M22900@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Sep 18, 2001 at 11:04:55AM +0200 References: <20010915222317.G666@salem.getuid.de> <20010918110455.M22900@cygbert.vinschen.de> Message-ID: <20010918135215.A17563@serv01.aet.tu-cottbus.de> On Tue, Sep 18, 2001 at 11:04:55AM +0200, Corinna Vinschen wrote: > On Sun, Sep 16, 2001 at 05:32:00PM +1000, Damien Miller wrote: > > Have you regenerated and rerun configure after cvs updating? The > > definition of u_char in defines.h should be contingent on an autoconf > > test. > > I have updated to the latest from CVS today, then I've called > autoconf and tried to build. I'm getting the following error > now: > > config.status: creating scard/Makefile > config.status: error: cannot find input file: scard/Makefile.in > > which isn't a surprise since there's no subdir `scard'. Did you "cvs update -d"? I had the same problem, as without the -d option cvs will not create new directories. Anyway, it seems that some binary is delivered in scart/ (in uuencoded form which is unpacked when doing make install). My HP-UX box, which installs with the "-s" (strip) option, delivers an error message, as the strip command obviously cannot handle this binary (Ssh.bin). 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 pmenage at ensim.com Tue Sep 18 21:50:59 2001 From: pmenage at ensim.com (Paul Menage) Date: Tue, 18 Sep 2001 04:50:59 -0700 Subject: SIGCHLD race condition? Message-ID: We use ssh (RedHat 2.5.2p2-5) heavily in non-interactive mode, for managing servers from central controllers, and transferring applications/ data around networks. Very occasionally we've seen the situation where the ssh client and server are both stuck in select, both selecting on only the tcp socket of the connection, and with no timeout. No children of sshd remain (even as zombies), and it has no other interesting open fds. If you send a SIGCHLD to the hung sshd, it wakes up and exits. As far as I can see, there's a race condition in wait_until_can_do_something(), both in RedHat 2.5.2p2-5 and in the latest CVS sources. It tests child_terminated, and sets a non-zero timeout if so, before calling select(). However, there is a very small window (between checking child_terminated and calling select() in which a SIGCHLD can arrive and set child_terminated. If this happens, and there is no other activity from the client or the child fds, sshd can hang indefinitely in the select(). Catching this bug in the wild is not easy, as the window for the race condition is so small. However, it can be fairly easily reproduced under the following slightly artificial conditions, by using gdb to pause sshd within the window for long enough to kill the child: Run ssh -T -x localhost 'sleep 30s; echo X; exec >&- 2>&- <&- sleep 5h' Find the sshd serving this connection, and connect to it with gdb. It will be in the middle of the actual select() system call. Set a breakpoint at the start of libc select() and continue. When the first sleep completes, the shell will print X, and sshd will hit the breakpoint in select(). Continue once, and the X will get printed out at the client end of the connection, and sshd will hit the breakpoint again. By this time, the child shell has closed its fds and exec'd itself as "sleep 5h". Since the breakpoint is at the start of libc select(), sshd has checked child_terminated, but not yet invoked the select() system call. Send a SIGKILL to the child "sleep" process. A SIGCHLD becomes pending for sshd. Quit gdb, detaching from the process. At this point, sshd receives the SIGCHLD, sets child_terminated, and enters the select() system call. In the absence of any external events, the client/server are now deadlocked, even though the child has exited. In this situation, the child is clearly visible as a zombie; we have also seen the situation where there is no zombie child. I've not been able to reproduce this situation. I think that the correct way to fix this would probably be to use something like SIGIO and sigtimedwait() rather than select(), but that would be a substantial change. A simple fix for this problem would be to set a maximum timeout on the select() call of e.g. 15s. Are there any complications or bugs that could be introduced by such a change? Paul From markus at openbsd.org Tue Sep 18 22:01:33 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 18 Sep 2001 14:01:33 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010918134230.Q22900@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Sep 18, 2001 at 01:42:30PM +0200 References: <20010913113542.B16130@folly> <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> <20010915015702.A2694@cygbert.vinschen.de> <20010915110650.C28361@folly> <20010918103841.J22900@cygbert.vinschen.de> <20010918104329.A16974@faui02.informatik.uni-erlangen.de> <20010918110114.L22900@cygbert.vinschen.de> <20010918115523.B16974@faui02.informatik.uni-erlangen.de> <20010918134230.Q22900@cygbert.vinschen.de> Message-ID: <20010918140133.A26342@faui02.informatik.uni-erlangen.de> On Tue, Sep 18, 2001 at 01:42:30PM +0200, Corinna Vinschen wrote: > i think you only need these > { "^2\\.0\\.1[3-9]", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > { "^2\\.0\\.1[1-2]", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > { "^2\\.0\\.", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > Index: ssh.c > =================================================================== > RCS file: /cvs/openssh_cvs/ssh.c,v > retrieving revision 1.116 > diff -u -p -r1.116 ssh.c > --- ssh.c 2001/09/12 18:32:20 1.116 > +++ ssh.c 2001/09/18 11:45:20 > @@ -1163,7 +1163,8 @@ ssh_session2(void) > /* XXX should be pre-session */ > ssh_init_forwarding(); > > - id = no_shell_flag ? -1 : ssh_session2_command(); > + id = no_shell_flag && !(datafellows & SSH_BUG_CLOSECONN) ? > + -1 : ssh_session2_command(); > > /* If requested, let ssh continue in the background. */ > if (fork_after_authentication_flag) ^^^ you also need to make sure that ssh_session2_command() does not install a callback if no_shell_flag is set. From yuliy at mobiltel.bg Tue Sep 18 22:23:34 2001 From: yuliy at mobiltel.bg (Yuliy Minchev) Date: Tue, 18 Sep 2001 15:23:34 +0300 (EEST) Subject: Call for testers. In-Reply-To: <20010918135215.A17563@serv01.aet.tu-cottbus.de> Message-ID: hi I've downloaded openssh-SNAP-20010918.tar.gz. It compiles fine on RH 7.0, AIX 4.2/4.3, HP-UX 11. On AIX and HP-UX there were some warinings (but I think they always were there). I've tested only ssh - it works. yuliy -- Yuliy Minchev, UNIX Administrator From Kyle_Chapman at G1.com Tue Sep 18 22:39:11 2001 From: Kyle_Chapman at G1.com (Chapman, Kyle) Date: Tue, 18 Sep 2001 08:39:11 -0400 Subject: openssh compile errors on hpux 11.00 Message-ID: <47CE319ED137D411BDCE00D0B774BF5501872A57@mail.g1.com> OS: hpux 11.00 800, with native cc and with gcc-3.0.1 openssh ver: 2.9p2 openssl: 0.9.7 (snapshot) getting errors on cipher.c: error 1718: Types are not assignment-compatible. warning 563: Argument #2 is not the correct type. argument 2 happens to be: cc->u.des.key (or a variation..) its expecting it to be des_key_schedule, which cc->u.des.key is!! i know i need patches for libc on hpux, but this error comes up on openssh 2.5.2, 2.9p1 and 2.9p2... is gcc not type checking pointers as well as hpux's native cc? anybody else see this problem on hpux? or is this from using the 0.9.7 snapshot.. only reason i was using openssl snapshot was for the shared lib support that is much improved with out patches to openssl 0.9.6x -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010918/43c2d5d2/attachment.html From abartlet at pcug.org.au Tue Sep 18 23:01:35 2001 From: abartlet at pcug.org.au (Andrew Bartlett) Date: Tue, 18 Sep 2001 23:01:35 +1000 Subject: making openssh work with chroot()'ed accounts? References: Message-ID: <3BA745AF.DC136299@bartlett.house> James Ralston wrote: > > On Mon, 17 Sep 2001 mouring at etoh.eviladmin.org wrote: > > > Yes. Maintaining such machinery [replicated programs/libraries for > > chroot'ed directory structures] is nasty, IMHO.. =) But I tend to > > deploy chroot() sparingly. > > To some degree, I agree, but IMO it's a small price to pay for being > able to run something in a chroot() environment. > > > Sorry, I will not claim to understand PAM in some respects. I know > > that PAM does not always act the same on every platform (Seems HP/UX > > vs Solaris to be the major waring parties. =). > > Well, let me ask this: do you approve of this method? > > I don't think it will too difficult to patch sshd to always use > do_pam_session, and do it appropriately (famous last words, I know). > It might work, it might not; I'll have to test it to see. It appears to be fixed in current CVS, as there was a in 'interesting' discussion on Bugtraq about this a couple of months ago :-), and various mailing and patches from people on this list before that. Andrew Bartlett -- Andrew Bartlett abartlet at pcug.org.au Samba Team member, Build Farm maintainer abartlet at samba.org Student Network Administrator, Hawker College abartlet at hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net From mouring at etoh.eviladmin.org Tue Sep 18 23:19:09 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Tue, 18 Sep 2001 08:19:09 -0500 (CDT) Subject: SIGCHLD race condition? In-Reply-To: Message-ID: Can you test against 2.9p2 or the current snapshots.. There has been some SIGCHLD changes since 2.5.2pX series. - Ben On Tue, 18 Sep 2001, Paul Menage wrote: > > We use ssh (RedHat 2.5.2p2-5) heavily in non-interactive mode, for > managing servers from central controllers, and transferring applications/ > data around networks. > > Very occasionally we've seen the situation where the ssh client and > server are both stuck in select, both selecting on only the tcp socket > of the connection, and with no timeout. No children of sshd remain (even > as zombies), and it has no other interesting open fds. > > If you send a SIGCHLD to the hung sshd, it wakes up and exits. > > As far as I can see, there's a race condition in > wait_until_can_do_something(), both in RedHat 2.5.2p2-5 and in the > latest CVS sources. It tests child_terminated, and sets a non-zero > timeout if so, before calling select(). However, there is a very small > window (between checking child_terminated and calling select() in which > a SIGCHLD can arrive and set child_terminated. If this happens, and > there is no other activity from the client or the child fds, sshd can > hang indefinitely in the select(). > > Catching this bug in the wild is not easy, as the window for the race > condition is so small. However, it can be fairly easily reproduced under > the following slightly artificial conditions, by using gdb to pause sshd > within the window for long enough to kill the child: > > Run ssh -T -x localhost 'sleep 30s; echo X; exec >&- 2>&- <&- sleep 5h' > > Find the sshd serving this connection, and connect to it with gdb. It > will be in the middle of the actual select() system call. > > Set a breakpoint at the start of libc select() and continue. When the > first sleep completes, the shell will print X, and sshd will hit the > breakpoint in select(). > > Continue once, and the X will get printed out at the client end of the > connection, and sshd will hit the breakpoint again. > > By this time, the child shell has closed its fds and exec'd itself as > "sleep 5h". Since the breakpoint is at the start of libc select(), sshd > has checked child_terminated, but not yet invoked the select() system > call. > > Send a SIGKILL to the child "sleep" process. A SIGCHLD becomes pending > for sshd. > > Quit gdb, detaching from the process. At this point, sshd receives the > SIGCHLD, sets child_terminated, and enters the select() system call. In > the absence of any external events, the client/server are now > deadlocked, even though the child has exited. > > In this situation, the child is clearly visible as a zombie; we have > also seen the situation where there is no zombie child. I've not been > able to reproduce this situation. > > I think that the correct way to fix this would probably be to use > something like SIGIO and sigtimedwait() rather than select(), but that > would be a substantial change. A simple fix for this problem would be to > set a maximum timeout on the select() call of e.g. 15s. Are there any > complications or bugs that could be introduced by such a change? > > Paul > > From alex at astro.su.se Tue Sep 18 23:59:56 2001 From: alex at astro.su.se (Alexey Koptsevich) Date: Tue, 18 Sep 2001 15:59:56 +0200 (MET DST) Subject: disable port forwarding in OpenSSH Message-ID: Hello, I would like to disable any port forwarding on the server, totally. How can I do this? I have seen only 'no-port-forwarding' option for 'authorized_keys' file, but this does not suit me since I will use only 'PasswordAuthentication'. Thanks, Alex PS Please cc: me your reply. From markus at openbsd.org Wed Sep 19 00:02:43 2001 From: markus at openbsd.org (Markus Friedl) Date: Tue, 18 Sep 2001 16:02:43 +0200 Subject: disable port forwarding in OpenSSH In-Reply-To: ; from alex@astro.su.se on Tue, Sep 18, 2001 at 03:59:56PM +0200 References: Message-ID: <20010918160243.C26342@faui02.informatik.uni-erlangen.de> sshd(8), AllowTcpForwarding On Tue, Sep 18, 2001 at 03:59:56PM +0200, Alexey Koptsevich wrote: > > Hello, > > I would like to disable any port forwarding on the server, totally. How > can I do this? I have seen only 'no-port-forwarding' option for > 'authorized_keys' file, but this does not suit me since I will use only > 'PasswordAuthentication'. > > Thanks, > Alex > > PS Please cc: me your reply. > From vinschen at redhat.com Wed Sep 19 00:27:55 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Sep 2001 16:27:55 +0200 Subject: 2.9p2 behaves different from 2.5.2p2 on tunneling issue In-Reply-To: <20010918140133.A26342@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Tue, Sep 18, 2001 at 02:01:33PM +0200 References: <20010913140702.U1285@cygbert.vinschen.de> <20010914195405.A21216@folly> <20010915015702.A2694@cygbert.vinschen.de> <20010915110650.C28361@folly> <20010918103841.J22900@cygbert.vinschen.de> <20010918104329.A16974@faui02.informatik.uni-erlangen.de> <20010918110114.L22900@cygbert.vinschen.de> <20010918115523.B16974@faui02.informatik.uni-erlangen.de> <20010918134230.Q22900@cygbert.vinschen.de> <20010918140133.A26342@faui02.informatik.uni-erlangen.de> Message-ID: <20010918162755.R22900@cygbert.vinschen.de> On Tue, Sep 18, 2001 at 02:01:33PM +0200, Markus Friedl wrote: > On Tue, Sep 18, 2001 at 01:42:30PM +0200, Corinna Vinschen wrote: > > > > i think you only need these > > > { "^2\\.0\\.1[3-9]", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > > { "^2\\.0\\.1[1-2]", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > > { "^2\\.0\\.", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| > > > Index: ssh.c > > =================================================================== > > RCS file: /cvs/openssh_cvs/ssh.c,v > > retrieving revision 1.116 > > diff -u -p -r1.116 ssh.c > > --- ssh.c 2001/09/12 18:32:20 1.116 > > +++ ssh.c 2001/09/18 11:45:20 > > @@ -1163,7 +1163,8 @@ ssh_session2(void) > > /* XXX should be pre-session */ > > ssh_init_forwarding(); > > > > - id = no_shell_flag ? -1 : ssh_session2_command(); > > + id = no_shell_flag && !(datafellows & SSH_BUG_CLOSECONN) ? > > + -1 : ssh_session2_command(); > > > > /* If requested, let ssh continue in the background. */ > > if (fork_after_authentication_flag) > > ^^^ you also need to make sure that ssh_session2_command() > does not install a callback if no_shell_flag is set. Thanks, is the following patch acceptable? Corinna Index: compat.c =================================================================== RCS file: /cvs/openssh_cvs/compat.c,v retrieving revision 1.51 diff -u -p -r1.51 compat.c --- compat.c 2001/09/18 05:55:10 1.51 +++ compat.c 2001/09/18 14:30:33 @@ -93,18 +93,20 @@ compat_datafellows(const char *version) SSH_OLD_SESSIONID|SSH_BUG_DEBUG| SSH_BUG_PKSERVICE|SSH_BUG_X11FWD| SSH_BUG_PKOK|SSH_BUG_RSASIGMD5| - SSH_BUG_HBSERVICE|SSH_BUG_OPENFAILURE }, + SSH_BUG_HBSERVICE|SSH_BUG_OPENFAILURE| + SSH_BUG_CLOSECONN }, { "^2\\.0\\.1[1-2]", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID|SSH_BUG_DEBUG| SSH_BUG_PKSERVICE|SSH_BUG_X11FWD| SSH_BUG_PKAUTH|SSH_BUG_PKOK| - SSH_BUG_RSASIGMD5|SSH_BUG_OPENFAILURE }, + SSH_BUG_RSASIGMD5|SSH_BUG_OPENFAILURE| + SSH_BUG_CLOSECONN }, { "^2\\.0\\.", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| SSH_OLD_SESSIONID|SSH_BUG_DEBUG| SSH_BUG_PKSERVICE|SSH_BUG_X11FWD| SSH_BUG_PKAUTH|SSH_BUG_PKOK| SSH_BUG_RSASIGMD5|SSH_BUG_OPENFAILURE| - SSH_BUG_DERIVEKEY }, + SSH_BUG_DERIVEKEY|SSH_BUG_CLOSECONN }, { "^2\\.[23]\\.0", SSH_BUG_HMAC|SSH_BUG_DEBUG| SSH_BUG_RSASIGMD5 }, { "^2\\.3\\.", SSH_BUG_DEBUG|SSH_BUG_RSASIGMD5 }, Index: compat.h =================================================================== RCS file: /cvs/openssh_cvs/compat.h,v retrieving revision 1.26 diff -u -p -r1.26 compat.h --- compat.h 2001/07/04 04:46:57 1.26 +++ compat.h 2001/09/18 14:30:33 @@ -50,6 +50,7 @@ #define SSH_BUG_HBSERVICE 0x00010000 #define SSH_BUG_OPENFAILURE 0x00020000 #define SSH_BUG_DERIVEKEY 0x00040000 +#define SSH_BUG_CLOSECONN 0x00100000 void enable_compat13(void); void enable_compat20(void); Index: ssh.c =================================================================== RCS file: /cvs/openssh_cvs/ssh.c,v retrieving revision 1.116 diff -u -p -r1.116 ssh.c --- ssh.c 2001/09/12 18:32:20 1.116 +++ ssh.c 2001/09/18 14:30:35 @@ -1149,8 +1149,10 @@ ssh_session2_command(void) debug3("ssh_session2_command: channel_new: %d", c->self); channel_send_open(c->self); - channel_register_callback(c->self, SSH2_MSG_CHANNEL_OPEN_CONFIRMATION, - ssh_session2_callback, (void *)0); + if (!no_shell_flag) + channel_register_callback(c->self, + SSH2_MSG_CHANNEL_OPEN_CONFIRMATION, + ssh_session2_callback, (void *)0); return c->self; } @@ -1163,7 +1165,8 @@ ssh_session2(void) /* XXX should be pre-session */ ssh_init_forwarding(); - id = no_shell_flag ? -1 : ssh_session2_command(); + id = no_shell_flag && !(datafellows & SSH_BUG_CLOSECONN) ? + -1 : ssh_session2_command(); /* If requested, let ssh continue in the background. */ if (fork_after_authentication_flag) From vinschen at redhat.com Wed Sep 19 00:29:18 2001 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Sep 2001 16:29:18 +0200 Subject: Call for testers. In-Reply-To: <20010918135215.A17563@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Sep 18, 2001 at 01:52:15PM +0200 References: <20010915222317.G666@salem.getuid.de> <20010918110455.M22900@cygbert.vinschen.de> <20010918135215.A17563@serv01.aet.tu-cottbus.de> Message-ID: <20010918162918.S22900@cygbert.vinschen.de> On Tue, Sep 18, 2001 at 01:52:15PM +0200, Lutz Jaenicke wrote: > On Tue, Sep 18, 2001 at 11:04:55AM +0200, Corinna Vinschen wrote: > > On Sun, Sep 16, 2001 at 05:32:00PM +1000, Damien Miller wrote: > > > Have you regenerated and rerun configure after cvs updating? The > > > definition of u_char in defines.h should be contingent on an autoconf > > > test. > > > > I have updated to the latest from CVS today, then I've called > > autoconf and tried to build. I'm getting the following error > > now: > > > > config.status: creating scard/Makefile > > config.status: error: cannot find input file: scard/Makefile.in > > > > which isn't a surprise since there's no subdir `scard'. > > Did you "cvs update -d"? I had the same problem, as without the -d Oops. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From alex at astro.su.se Wed Sep 19 00:29:37 2001 From: alex at astro.su.se (Alexey Koptsevich) Date: Tue, 18 Sep 2001 16:29:37 +0200 (MET DST) Subject: disable port forwarding in OpenSSH In-Reply-To: <20010918160243.C26342@faui02.informatik.uni-erlangen.de> Message-ID: OK, thanks! It seems I have old version of openssh which does not offer this option. One more question: in order to offer mail-only access to the server I would like to run sshd with 'AllowTcpForwarding no' and with 'pine' instead of a shell. Is it believed safe way? Would that be possible for users to access ports or any stuff other than 'pine' in this configuration? Thanks, Alex > sshd(8), AllowTcpForwarding > > On Tue, Sep 18, 2001 at 03:59:56PM +0200, Alexey Koptsevich wrote: > > > > Hello, > > > > I would like to disable any port forwarding on the server, totally. How > > can I do this? I have seen only 'no-port-forwarding' option for > > 'authorized_keys' file, but this does not suit me since I will use only > > 'PasswordAuthentication'. > > > > Thanks, > > Alex > > > > PS Please cc: me your reply. > > > From e-huss at netmeridian.com Wed Sep 19 06:35:47 2001 From: e-huss at netmeridian.com (Eric Huss) Date: Tue, 18 Sep 2001 13:35:47 -0700 (PDT) Subject: OpenSSH linkable library Message-ID: Has anyone considered making a linkable library of the OpenSSH code so that one could programatically interact with ssh? Or is there some other method to accomplish this? Thanks, -Eric From Nicolas.Williams at ubsw.com Wed Sep 19 06:51:04 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Tue, 18 Sep 2001 16:51:04 -0400 Subject: OpenSSH linkable library In-Reply-To: ; from e-huss@netmeridian.com on Tue, Sep 18, 2001 at 01:35:47PM -0700 References: Message-ID: <20010918165103.A5739@sm2p1386swk.wdr.com> I looked into the source to see what it would take. I don't recommend trying, at this time, to make a library. There's too many assumptions about having the run of a process that would step on any library consumer's toes -- like fatal errors always leading to exit() being called. An interface would have to be created too -- you'd probably not want to cons up an argv/argc when you could get/set options programmatically with a friendly interface instead. That said, it would be great if there was an SSH client (and server) library. Nico On Tue, Sep 18, 2001 at 01:35:47PM -0700, Eric Huss wrote: > Has anyone considered making a linkable library of the OpenSSH code so > that one could programatically interact with ssh? Or is there some other > method to accomplish this? > > Thanks, > -Eric > -- 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 brhamon at cisco.com Wed Sep 19 07:35:38 2001 From: brhamon at cisco.com (Brian Hamon) Date: Tue, 18 Sep 2001 16:35:38 -0500 Subject: OpenSSH linkable library In-Reply-To: Message-ID: <4.3.2.7.2.20010918162824.01aa37b8@3rdclass.cisco.com> One technique that will work is to run ssh as a coprocess, with stdin and stdout piped into your main process (similar to popen). The most important consequence is that the password prompt will not work correctly (it uses the pty directly, rather than stdin/stdout). Password authentication is therefore not usable without adding unsavory patches to the OpenSSH source code. This limitation is reasonable; however, since an automaton should really be using RSA authentication anyway. At 03:35 PM 9/18/2001, Eric Huss wrote: >Has anyone considered making a linkable library of the OpenSSH code so >that one could programatically interact with ssh? Or is there some other >method to accomplish this? > >Thanks, >-Eric From thomas at xs4all.net Wed Sep 19 08:58:38 2001 From: thomas at xs4all.net (Thomas Wouters) Date: Wed, 19 Sep 2001 00:58:38 +0200 Subject: OpenSSH linkable library In-Reply-To: <4.3.2.7.2.20010918162824.01aa37b8@3rdclass.cisco.com> References: <4.3.2.7.2.20010918162824.01aa37b8@3rdclass.cisco.com> Message-ID: <20010919005838.A2118@xs4all.nl> On Tue, Sep 18, 2001 at 04:35:38PM -0500, Brian Hamon wrote: > One technique that will work is to run ssh as a coprocess, with stdin and > stdout piped into your main process (similar to popen). The most important > consequence is that the password prompt will not work correctly (it uses > the pty directly, rather than stdin/stdout). Password authentication is > therefore not usable without adding unsavory patches to the OpenSSH source > code. This isn't really true. You can't do it by just fiddling stdin/stdout, true, but I wrote a very small Python script that allocates a pty/tty pair and just dumps the password to that. Worked for both ssh and unzip (before it grew a -P to get the password from the cmdline.) It used the 'pty' module, which is not as portable as the pty code in OpenSSH, but comes pretty close. Doing it in other languages might be a bit trickier, but is definately not impossible, and almost certainly a lot easier than rearranging OpenSSH to provide a public API ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From jason at shalott.net Wed Sep 19 09:19:47 2001 From: jason at shalott.net (Jason Stone) Date: Tue, 18 Sep 2001 16:19:47 -0700 (PDT) Subject: disable port forwarding in OpenSSH In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > One more question: in order to offer mail-only access to the server I > would like to run sshd with 'AllowTcpForwarding no' and with 'pine' > instead of a shell. Is it believed safe way? Would that be possible > for users to access ports or any stuff other than 'pine' in this > configuration? Many people have successfully used custom restricted shells that only allow one or a small number of commands to be run upon login - you shouldn't have a problem with that. In the case of pine, be sure to disable the ability to jump to a shell in the fixed config file, usually /usr/local/etc/pine.conf.fixed. (echo 'feature-list=no-enable-suspend' >> /usr/local/etc/pine.conf.fixed) Also be aware that pine has an awful history of security problems, exploitable buffer overruns, etc, and that it would probablly be pretty easy for a malicious user to send himself a message that would cause his pine to jump to a shell.... Maybe you want to consider mutt with pine-like bindings instead.... -Jason ----------------------------------------------------------------------- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE7p9aXswXMWWtptckRAmGNAKCuYWqCdDNsKAI1UFlccLlLPPPR6QCfWOfu NShNphvkSKxbkiUhKdCgm3w= =i6Hl -----END PGP SIGNATURE----- From djm at mindrot.org Wed Sep 19 09:26:17 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 19 Sep 2001 09:26:17 +1000 (EST) Subject: OpenSSH linkable library In-Reply-To: <4.3.2.7.2.20010918162824.01aa37b8@3rdclass.cisco.com> Message-ID: On Tue, 18 Sep 2001, Brian Hamon wrote: > One technique that will work is to run ssh as a coprocess, with stdin and > stdout piped into your main process (similar to popen). The most important > consequence is that the password prompt will not work correctly (it uses > the pty directly, rather than stdin/stdout). Password authentication is > therefore not usable without adding unsavory patches to the OpenSSH source > code. This limitation is reasonable; however, since an automaton should > really be using RSA authentication anyway. This isn't true - OpenSSH reads pass{words,phrases} directly from the TTY (if present) and will thus bypass stdio redirection. This is how sftp and scp work. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From pmenage at ensim.com Wed Sep 19 09:49:40 2001 From: pmenage at ensim.com (Paul Menage) Date: Tue, 18 Sep 2001 16:49:40 -0700 Subject: SIGCHLD race condition? In-Reply-To: Your message of "Tue, 18 Sep 2001 08:19:09 CDT." Message-ID: > >Can you test against 2.9p2 or the current snapshots.. There has been some >SIGCHLD changes since 2.5.2pX series. > The signal handling strategy has changed, the race condition in wait_until_can_do_something(), between checking child_terminated and calling select(), is still there. I can reproduce exactly the same lockup with RedHat/RawHide 2.9p2. Would putting a maximum timeout for select() break anything? If not, then it would at least prevent the system from deadlocking permanently, even if it's not a very elegant fix. Paul From brhamon at cisco.com Wed Sep 19 09:56:59 2001 From: brhamon at cisco.com (Brian Hamon) Date: Tue, 18 Sep 2001 18:56:59 -0500 Subject: OpenSSH linkable library In-Reply-To: References: <4.3.2.7.2.20010918162824.01aa37b8@3rdclass.cisco.com> Message-ID: <4.3.2.7.2.20010918182924.01aa37b8@3rdclass.cisco.com> You are correct, my statement about passwords not working was inaccurate. Passwords work perfectly when stdin and stdout are redirected. Unfortunately, the behavior you get is something an automaton usually does not want -- interactivity. This is an easily avoidable problem if the automaton utilizes RSA authentication instead of passwords. Using pipes and running ssh as a coprocess, in some cases, is an effective alternative to using a linkable library. Someone else suggested running a restricted shell on the remote host. That is a preferable solution in cases where the remote host has a script language, but some hosts running SSH-protocol-version-1.5-compliant daemons do not provide script languages. At 06:26 PM 9/18/2001, Damien Miller wrote: >On Tue, 18 Sep 2001, Brian Hamon wrote: > > > One technique that will work is to run ssh as a coprocess, with stdin and > > stdout piped into your main process (similar to popen). The most important > > consequence is that the password prompt will not work correctly (it uses > > the pty directly, rather than stdin/stdout). Password authentication is > > therefore not usable without adding unsavory patches to the OpenSSH source > > code. This limitation is reasonable; however, since an automaton should > > really be using RSA authentication anyway. > >This isn't true - OpenSSH reads pass{words,phrases} directly from the TTY >(if present) and will thus bypass stdio redirection. This is how sftp and >scp work. > >-d > >-- >| Damien Miller \ ``E-mail attachments are the poor man's >| http://www.mindrot.org / distributed filesystem'' - Dan Geer From Stephan.Hendl at lds.brandenburg.de Wed Sep 19 15:11:36 2001 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Wed, 19 Sep 2001 07:11:36 +0200 Subject: Antw: openssh compile errors on hpux 11.00 Message-ID: Hi Kyle, I've compiled 2.9p2 on HP-UX 11.00 with gcc-3.0.0 als well as 2.95.2 and openssl-0.9.6 and got _no_ problems. I took the openssh-package from the porting center. Some month ago I got some errors with the commercial c-compiler from HP but going back to gcc solve them. Hope that helps Stephan -- LDS Brandenburg Dr. Stephan Hendl fon: +49-(0)331-39 471 fax: +49-(0)331-27548 1187 EMail: stephan.hendl at lds.brandenburg.de >>> "Chapman, Kyle" 09/18 2:39 >>> OS: hpux 11.00 800, with native cc and with gcc-3.0.1 openssh ver: 2.9p2 openssl: 0.9.7 (snapshot) getting errors on cipher.c: error 1718: Types are not assignment-compatible. warning 563: Argument #2 is not the correct type. argument 2 happens to be: cc->u.des.key (or a variation..) its expecting it to be des_key_schedule, which cc->u.des.key is!! i know i need patches for libc on hpux, but this error comes up on openssh 2.5.2, 2.9p1 and 2.9p2... is gcc not type checking pointers as well as hpux's native cc? anybody else see this problem on hpux? or is this from using the 0.9.7 snapshot.. only reason i was using openssl snapshot was for the shared lib support that is much improved with out patches to openssl 0.9.6x From qralston+ml.openssh-unix-dev at andrew.cmu.edu Wed Sep 19 16:06:52 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Wed, 19 Sep 2001 02:06:52 -0400 (EDT) Subject: making openssh work with chroot()'ed accounts? In-Reply-To: Message-ID: On Tue, 18 Sep 2001, Damien Miller wrote: > On Mon, 17 Sep 2001, James Ralston wrote: > > > If sshd always calls do_pam_session(), which will ensure that > > pam_chroot will always run > > Have you checked CVS head? I hadn't, but I see now that this change was already made. I built from the latest snapshot, and indeed, no matter how I connect (ssh/scp/sftp), sshd opens a PAM session (which causes pam_chroot.so to load), which is exactly what I wanted. Yay! > Not everyone uses PAM. True, but that doesn't mean that PAM isn't the most appropriate place to implement chroot() restrictions et. al. on systems that have PAM. BTW, since I was building on Redhat, I examined the patches that they apply while build openssh. The comment on this one was "remove a redundant call to pam_limits": --- contrib/redhat/sshd.pam-7.x.redhat Sun Feb 11 17:34:17 2001 +++ contrib/redhat/sshd.pam-7.x Tue Sep 18 14:29:45 2001 @@ -4,5 +4,4 @@ account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth -session required /lib/security/pam_limits.so session optional /lib/security/pam_console.so They also patched ssh-add so that when given no keyfiles, it attempts to load every keyfile it can find. If you want that one, let me know. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From qralston+ml.openssh-unix-dev at andrew.cmu.edu Wed Sep 19 16:17:31 2001 From: qralston+ml.openssh-unix-dev at andrew.cmu.edu (James Ralston) Date: Wed, 19 Sep 2001 02:17:31 -0400 (EDT) Subject: keypair auth and limiting access to sftp In-Reply-To: <20010918094106.A15593@faui02.informatik.uni-erlangen.de> Message-ID: On Tue, 18 Sep 2001, Markus Friedl wrote: > On Mon, Sep 17, 2001 at 05:06:42PM -0400, James Ralston wrote: > > > Making sftp inaccessable to chroot'ed accounts is certainly one > > way to prevent chroot'ed accounts from using sftp to break out of > > their chroot jails, yes. > > how is this related to command="xxx" ? It isn't, really; Peter was addressing a different issue (that sftp bypassed command="xxx" restrictions)... -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From saju.nair at wipro.com Wed Sep 19 16:41:43 2001 From: saju.nair at wipro.com (SAJU NAIR) Date: Wed, 19 Sep 2001 12:11:43 +0530 Subject: Maximum Security References: Message-ID: <001401c140d6$25db90d0$f997a8c0@sajump> Hi All, I am looking for to restrict users with rsh shell . Is there any way to do this ? When i use rsh or rksh. ssh command is perfectly woking but scp and sftp is not. ?? or is ther any way to restrict with directory permission ?? eg: user home directory is /home/ftpdir/user1 I would like to give /home/ftpdir . as 711 or 751.So the user will not be able list the other users home directories. (chmod 751 . from /home/ftpdir ) This kind of permission is working with ssh and scp but sftp fails... ?? Anyone have idea about this ?? or any better methode ?? Thanks in advance. Saju -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010919/089f90c8/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: InterScan_Disclaimer.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010919/089f90c8/attachment.txt From mats.andersson at appgate.com Wed Sep 19 00:04:11 2001 From: mats.andersson at appgate.com (Andersson, Mats) Date: Tue, 18 Sep 2001 16:04:11 +0200 (CEST) Subject: OpenSSH linkable library In-Reply-To: <20010919005838.A2118@xs4all.nl> Message-ID: Hi, On Wed, 19 Sep 2001, Thomas Wouters wrote: > but I wrote a very small Python script that allocates a pty/tty pair > and just dumps the password to that. Worked for both ssh and unzip > > Doing it in other languages might be a bit trickier, but is definately > not impossible, and almost certainly a lot easier than rearranging We've written a set of packages in java which are meant to be used as a "library", i.e. used to write anything in java wanting to communicate over ssh2. If you ask me the code is pretty clean and very easy to use (though I might be biased :-). Check it out at http://www.appgate.com/mindterm/ Cheers, /Mats From markus at openbsd.org Wed Sep 19 17:41:57 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 19 Sep 2001 09:41:57 +0200 Subject: keypair auth and limiting access to sftp In-Reply-To: ; from qralston+ml.openssh-unix-dev@andrew.cmu.edu on Wed, Sep 19, 2001 at 02:17:31AM -0400 References: <20010918094106.A15593@faui02.informatik.uni-erlangen.de> Message-ID: <20010919094157.B9470@faui02.informatik.uni-erlangen.de> On Wed, Sep 19, 2001 at 02:17:31AM -0400, James Ralston wrote: > On Tue, 18 Sep 2001, Markus Friedl wrote: > > > On Mon, Sep 17, 2001 at 05:06:42PM -0400, James Ralston wrote: > > > > > Making sftp inaccessable to chroot'ed accounts is certainly one > > > way to prevent chroot'ed accounts from using sftp to break out of > > > their chroot jails, yes. > > > > how is this related to command="xxx" ? > > It isn't, really; Peter was addressing a different issue (that sftp > bypassed command="xxx" restrictions)... well, openssh never claimed that command="xx" applies to subsystems. From peterw at usa.net Wed Sep 19 20:55:25 2001 From: peterw at usa.net (Peter W) Date: Wed, 19 Sep 2001 06:55:25 -0400 Subject: keypair auth and limiting access to sftp In-Reply-To: <20010919094157.B9470@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Wed, Sep 19, 2001 at 09:41:57AM +0200 References: <20010918094106.A15593@faui02.informatik.uni-erlangen.de> <20010919094157.B9470@faui02.informatik.uni-erlangen.de> Message-ID: <20010919065525.A26702@usa.net> On Wed, Sep 19, 2001 at 09:41:57AM +0200, Markus Friedl wrote: > On Wed, Sep 19, 2001 at 02:17:31AM -0400, James Ralston wrote: > > On Tue, 18 Sep 2001, Markus Friedl wrote: > > > how is this related to command="xxx" ? > > > > It isn't, really; Peter was addressing a different issue (that sftp > > bypassed command="xxx" restrictions)... > > well, openssh never claimed that command="xx" applies to subsystems. Perhaps not, but to the extent that command="xx" is supposed to limit what they keypair can do, the fact that it does not stop sftp, and that there is no way to explicitly disable subsystems like sftp for each key, means that command="xx" is fundamentally unsafe in most systems. :-( There is a general consensus that the next release will be modified so that it is possible to override/disable subsystems per key, right? Thanks, -Peter From markus at openbsd.org Thu Sep 20 01:53:53 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 19 Sep 2001 17:53:53 +0200 Subject: OpenSSH linkable library In-Reply-To: ; from e-huss@netmeridian.com on Tue, Sep 18, 2001 at 01:35:47PM -0700 References: Message-ID: <20010919175353.A22110@folly> On Tue, Sep 18, 2001 at 01:35:47PM -0700, Eric Huss wrote: > Has anyone considered making a linkable library of the OpenSSH code so > that one could programatically interact with ssh? Or is there some other > method to accomplish this? depends on what do you want to use it for. From rkrug at bulletin.net Thu Sep 20 03:11:55 2001 From: rkrug at bulletin.net (Krug, Robyn) Date: Wed, 19 Sep 2001 13:11:55 -0400 Subject: Unable to run sshd after Installing Openssh 2.9p2 on Solaris 8 Message-ID: I've installed Openssh 2.9p2 on a Solaris 8 machine with tcpwrappers installed and used "./configure --with-tcp-wrappers" to configure the installation. Whenever I try to run sshd I receive the following error: sshd: Cannot find ELF Killed. Does anyone have any ideas as to what this error means and what I need to do to correct it? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010919/8dabdf71/attachment.html From tim at multitalents.net Thu Sep 20 03:34:59 2001 From: tim at multitalents.net (Tim Rice) Date: Wed, 19 Sep 2001 10:34:59 -0700 (PDT) Subject: Unable to run sshd after Installing Openssh 2.9p2 on Solaris 8 In-Reply-To: Message-ID: On Wed, 19 Sep 2001, Krug, Robyn wrote: > I've installed Openssh 2.9p2 on a Solaris 8 machine with tcpwrappers > installed and used "./configure --with-tcp-wrappers" to configure the > installation. Whenever I try to run sshd I receive the following error: > sshd: Cannot find ELF Killed. Does anyone have any ideas as to what this > error means and what I need to do to correct it? Works here. But then I also have --with-pam on my confgure line. How about some more details. Sun compiler? GCC? Do you have the Sun recomended patches installed? Perhaps truss(1) might give you more info. > > Thanks! > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From e-huss at netmeridian.com Thu Sep 20 04:54:19 2001 From: e-huss at netmeridian.com (Eric Huss) Date: Wed, 19 Sep 2001 11:54:19 -0700 (PDT) Subject: OpenSSH linkable library In-Reply-To: <20010919175353.A22110@folly> Message-ID: > > Has anyone considered making a linkable library of the OpenSSH code so > > that one could programatically interact with ssh? Or is there some other > > method to accomplish this? > > depends on what do you want to use it for. Well, specifically I'd like to have a server periodically scp files. Under normal conditions, it will be OK because it will use DSA keys. But there are some exceptions, such as if the remote host's key changes and the user doesn't update the server. I don't want to have to do TTY emulation in order to parse the output from scp. Also, what scp prints out may not be consistent from version to version. I'd like to easily detect exceptions and be able to relay the exact problem to the user. It would also be nice to be able to track the progress of the transfer. I would rather not recreate all the code in scp.c. -Eric From jmknoble at pobox.com Thu Sep 20 06:33:37 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 19 Sep 2001 16:33:37 -0400 Subject: ANNOUNCE: x11-ssh-askpass v1.2.4.1 In-Reply-To: ; from tim@multitalents.net on Tue, Sep 18, 2001 at 09:23:11PM -0700 References: <20010917212119.A1927@quipu.half.pint-stowp.cx> Message-ID: <20010919163337.B1564@zax.half.pint-stowp.cx> Circa 2001-Sep-18 21:23:11 -0700 dixit Tim Rice: : On Mon, 17 Sep 2001, Jim Knoble wrote: : : > x11-ssh-askpass version 1.2.4.1 (code name: Etouffee) is now available : > from the following locations: : > : > http://www.poboxc.com/~jmknoble/software/x11-ssh-askpass/ : ^^^^^^^^^^^^^^ : This address does not resolve. Oops. Typo. Should be: http://www.pobox.com/~jmknoble/software/x11-ssh-askpass/ ^^^ -- 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/20010919/235f562e/attachment.bin From alex at astro.su.se Thu Sep 20 06:37:07 2001 From: alex at astro.su.se (Alexey Koptsevich) Date: Wed, 19 Sep 2001 22:37:07 +0200 (MET DST) Subject: disable port forwarding in OpenSSH In-Reply-To: Message-ID: Hello, > Many people have successfully used custom restricted shells that only > allow one or a small number of commands to be run upon login - you > shouldn't have a problem with that. Can running sshd with chroot (to the directory which does not contain anything but mail folders and executables/libraries needed for sshd and mail programs) be considered more secure than running custom shell or not? I use FreeBSD. > In the case of pine, be sure to disable the ability to jump to a shell in > the fixed config file, usually /usr/local/etc/pine.conf.fixed. > (echo 'feature-list=no-enable-suspend' >> /usr/local/etc/pine.conf.fixed) Thanks! But if no shell -- no ability, right? > Also be aware that pine has an awful history of security problems, > exploitable buffer overruns, etc, and that it would probablly be pretty > easy for a malicious user to send himself a message that would cause his > pine to jump to a shell.... Maybe you want to consider mutt with > pine-like bindings instead.... Thanks!.. Best, Alex From djm at mindrot.org Thu Sep 20 10:01:06 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Sep 2001 10:01:06 +1000 (EST) Subject: OpenSSH linkable library In-Reply-To: Message-ID: On Wed, 19 Sep 2001, Eric Huss wrote: > > > Has anyone considered making a linkable library of the OpenSSH code so > > > that one could programatically interact with ssh? Or is there some other > > > method to accomplish this? > > > > depends on what do you want to use it for. > > Well, specifically I'd like to have a server periodically scp files. > Under normal conditions, it will be OK because it will use DSA keys. But > there are some exceptions, such as if the remote host's key changes and > the user doesn't update the server. I don't want to have to do TTY > emulation in order to parse the output from scp. Also, what scp prints > out may not be consistent from version to version. > > I'd like to easily detect exceptions and be able to relay the exact > problem to the user. > > It would also be nice to be able to track the progress of the transfer. I > would rather not recreate all the code in scp.c. You probably want to use the sftp protocol for this. You can reuse the connection infrastrcuture from sftp.c and the protocol routines in sftp-client.c and sftp-common.c. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From bwelling at xbill.org Thu Sep 20 10:04:51 2001 From: bwelling at xbill.org (Brian Wellington) Date: Wed, 19 Sep 2001 17:04:51 -0700 (PDT) Subject: Patch to allow local port forwarding from an existing connection Message-ID: Hi. Attached is a patch that introduces a new escape character (~c) that opens a command line. From the command line, a command of the form: -L port:host:hostport can be entered, which will forward the local port, as if the same option has been provided on the command line. I attempted to allow remote port forwards to be specified similarly, but the server disconnects with a protocol error (and the code is disabled now). This is a bit of a hack, but it works, and it's something that I've been hoping would be added to ssh for a few years now. The patch is against openssh-2.9p2. Comments? Any chance this will get integrated? Brian ----- --- clientloop.c.old Fri Apr 20 05:50:51 2001 +++ clientloop.c Wed Sep 19 16:51:40 2001 @@ -67,6 +67,7 @@ #include "xmalloc.h" #include "packet.h" #include "buffer.h" +#include "cli.h" #include "compat.h" #include "channels.h" #include "dispatch.h" @@ -465,6 +466,75 @@ } } +void +process_cmdline(Buffer *bin, Buffer *bout, Buffer *berr) +{ + char string[1024]; + void (*handler)(int); + char *s; + u_short fwd_port, fwd_host_port; + char buf[256]; + int local = 0; + char *msg; + int n; + + leave_raw_mode(); + handler = signal(SIGINT, SIG_IGN); + fprintf(stderr, "\r\n> "); + s = fgets(string, sizeof string, stdin); + if (s == NULL) { + msg = NULL; + goto out; + } + + while (*s && isspace(*s)) + s++; + + if (*s == 0) + goto out; + + if (strlen(s) < 2 || s[0] != '-' || !(s[1] == 'L' || s[1] == 'R')) { + msg = "Invalid command"; + goto out; + } + if (s[1] == 'L') + local = 1; + else { + msg = "Remote forwarding doesn't work"; + goto out; + } + + s += 2; + + if (sscanf(s, "%hu/%255[^/]/%hu", &fwd_port, buf, &fwd_host_port) != 3 + && + sscanf(s, "%hu:%255[^:]:%hu", &fwd_port, buf, &fwd_host_port) != 3) + { + msg = "Invalid port forward"; + goto out; + } + if (local) { + n = channel_request_local_forwarding(fwd_port, buf, + fwd_host_port, + options.gateway_ports); + if (n <= 0) { + msg = "Port forwarding failed"; + goto out; + } + } + else + channel_request_remote_forwarding(fwd_port, buf, fwd_host_port); + + msg = "Forwarding port"; + out: + signal(SIGINT, handler); + enter_raw_mode(); + if (msg) { + snprintf(string, sizeof string, "%s\r\n", msg); + buffer_append(berr, string, strlen(string)); + } +} + /* process the characters one by one */ int process_escapes(Buffer *bin, Buffer *bout, Buffer *berr, char *buf, int len) @@ -570,6 +640,7 @@ ~^Z - suspend ssh\r\n\ ~# - list forwarded connections\r\n\ ~& - background ssh (when waiting for connections to terminate)\r\n\ +~c - open a command line\r\n ~? - this message\r\n\ ~~ - send the escape character by typing it twice\r\n\ (Note that escapes are only recognized immediately after newline.)\r\n", @@ -583,6 +654,10 @@ s = channel_open_message(); buffer_append(berr, s, strlen(s)); xfree(s); + continue; + + case 'c': + process_cmdline(bin, bout, berr); continue; default: From jason at shalott.net Thu Sep 20 10:20:43 2001 From: jason at shalott.net (Jason Stone) Date: Wed, 19 Sep 2001 17:20:43 -0700 (PDT) Subject: disable port forwarding in OpenSSH In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Many people have successfully used custom restricted shells that only > > allow one or a small number of commands to be run upon login - you > > shouldn't have a problem with that. > > Can running sshd with chroot (to the directory which does not contain > anything but mail folders and executables/libraries needed for sshd and > mail programs) be considered more secure than running custom shell or not? > I use FreeBSD. chroot is almost certainly more secure. Unless you're root, it's usually not possible to get out of a chroot. However, chroot is a lot harder to manage, so sometimes admins try to do "clever" tricks which end up subverting their security rather than enhancing it. A restricted shell is way easier to build and manage and is frequently secure enough for most people. > > In the case of pine, be sure to disable the ability to jump to a shell in > > the fixed config file, usually /usr/local/etc/pine.conf.fixed. > > (echo 'feature-list=no-enable-suspend' >> /usr/local/etc/pine.conf.fixed) > > Thanks! But if no shell -- no ability, right? I'm not sure I understand. The user has to have some "shell" that can be invoked as " -c pine" and do the right thing. If you don't disable suspend in the pine.conf.fixed, then pine will either fork a new instance of (which is safe if is a restricted shell which just exits when invoked without "-c pine") or else it will try to detach from the restricted shell, which won't work right. Also, the lack of a real shell won't prevent a sophisticated attacker from still executing arbitrary code by exploiting a buffer overrun in pine, if that's your question. -Jason ----------------------------------------------------------------------- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE7qTZfswXMWWtptckRAuYPAKCz1GAzNmeGvoYeO5/uCdS41MUe3wCfQqHH nixy1IypD0aFhnt7l67vf5Q= =w4ce -----END PGP SIGNATURE----- From tomh at po.crl.go.jp Thu Sep 20 11:31:06 2001 From: tomh at po.crl.go.jp (Tom Holroyd) Date: Thu, 20 Sep 2001 10:31:06 +0900 (JST) Subject: vis.[ch] Message-ID: Does anybody use openbsd-compat/vis.c? Not at the moment I think: % find . -name '*.[ch]' -exec grep -l "vis *(" {} \; ./openbsd-compat/vis.c ./openbsd-compat/vis.h % find . -name '*.[ch]' -exec grep -l VIS_ {} \; ./includes.h ./openbsd-compat/vis.c ./openbsd-compat/vis.h The reason I ask is, AT&T's graphviz package includes a vis.h, and when I try to compile openssh I get errors because configure finds that one and tries to include it during the build. It used to be, I could just -Iopenbsd-compat, but that doesn't work anymore because now getopt.h is in there, and that fails to compile during configure because config.h doesn't exist (yet). So, if nobody is using vis.*, can we get rid of it? As a separate problem, I note that lots of the mainline codes in openssh do explicit extern int optind; etc., rather than relying on getopt.h. That's probably wrong. (Why doesn't openssh use unistd.h for that, by the way?) Dr. Tom Holroyd "I am, as I said, inspired by the biological phenomena in which chemical forces are used in repetitious fashion to produce all kinds of weird effects (one of which is the author)." -- Richard Feynman, _There's Plenty of Room at the Bottom_ From mouring at etoh.eviladmin.org Thu Sep 20 11:38:52 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 19 Sep 2001 20:38:52 -0500 (CDT) Subject: vis.[ch] In-Reply-To: Message-ID: On Thu, 20 Sep 2001, Tom Holroyd wrote: > Does anybody use openbsd-compat/vis.c? Not at the moment I think: > Don't think anything depends on it any more. This I believe came dead wood when we switched to readpassphrase(). I can't find any hint of usage anywhere. So unless someone has a quarms I think it should go on the chopping block. - Ben From djm at mindrot.org Thu Sep 20 12:03:03 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Sep 2001 12:03:03 +1000 (EST) Subject: vis.[ch] In-Reply-To: Message-ID: On Wed, 19 Sep 2001 mouring at etoh.eviladmin.org wrote: > On Thu, 20 Sep 2001, Tom Holroyd wrote: > > > Does anybody use openbsd-compat/vis.c? Not at the moment I think: > > > > Don't think anything depends on it any more. This I believe came dead > wood when we switched to readpassphrase(). > > I can't find any hint of usage anywhere. So unless someone has a quarms I > think it should go on the chopping block. No argument here. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From matthew at debian.org Thu Sep 20 19:04:41 2001 From: matthew at debian.org (Matthew Vernon) Date: 20 Sep 2001 10:04:41 +0100 Subject: ssh argv[0] support In-Reply-To: Nicolas Williams's message of Fri, 14 Sep 2001 16:32:02 GMT References: <15264.64962.70051.11362@ming.empire.pick.ucam.org> <84vgim2bv6.fsf@rjk.greenend.org.uk> <20010914115935.Z5739@sm2p1386swk.wdr.com> Message-ID: <5bg09insgm.fsf@chiark.greenend.org.uk> Nicolas Williams writes: > > Why would you want this feature anyways??? > > It doesn't scale, for one, and is just ugly, not to mention the fact > that it pollutes the command namespace and that namespace collisions > could break your scripts? This feature is desired, AIUI, at least partly because rsh did it, and people expect ssh to be a drop-in replacement to some extent (in the same way as rcp/scp, for example). Matthew [1]I wouldn't use it myself, but apparantly Debian users do. -- "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 Sep 20 20:04:42 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 20 Sep 2001 12:04:42 +0200 Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: ; from bwelling@xbill.org on Wed, Sep 19, 2001 at 05:04:51PM -0700 References: Message-ID: <20010920120442.A27002@folly> On Wed, Sep 19, 2001 at 05:04:51PM -0700, Brian Wellington wrote: > Hi. Attached is a patch that introduces a new escape character (~c) that > opens a command line. From the command line, a command of the form: > > -L port:host:hostport > > can be entered, which will forward the local port, as if the same option > has been provided on the command line. I attempted to allow remote port > forwards to be specified similarly, but the server disconnects with a > protocol error (and the code is disabled now). > > This is a bit of a hack, but it works, and it's something that I've been > hoping would be added to ssh for a few years now. > > The patch is against openssh-2.9p2. > > Comments? Any chance this will get integrated? > + fprintf(stderr, "\r\n> "); > + s = fgets(string, sizeof string, stdin); i don't think reading from stdin is correct. you need to read from the same FD as bin. can you get the command line from 'bin' ? or perhaps use readpass.[ch] from -current with echo enabled? -m From jmknoble at pobox.com Thu Sep 20 06:55:38 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 19 Sep 2001 16:55:38 -0400 Subject: Correction (was: Re: ANNOUNCE: x11-ssh-askpass v1.2.4.1) Message-ID: <20010919165538.D1564@zax.half.pint-stowp.cx> : A message that you sent could not be delivered to one or more of its : recipients. This is a permanent error. The following address(es) failed: : : openssh-announce at zax.half.pint-stowp.cx : unknown local-part "openssh-announce" in domain "zax.half.pint-stowp.cx" [I seem to be having an unlucky day today]. See below for the correction. ------ This is a copy of the message, including all the headers. ------ Date: Wed, 19 Sep 2001 16:33:37 -0400 From: Jim Knoble To: openssh-announce at zax.half.pint-stowp.cx Cc: OpenSSH Unix Dev Subject: Re: ANNOUNCE: x11-ssh-askpass v1.2.4.1 Message-ID: <20010919163337.B1564 at zax.half.pint-stowp.cx> Circa 2001-Sep-18 21:23:11 -0700 dixit Tim Rice: : On Mon, 17 Sep 2001, Jim Knoble wrote: : : > x11-ssh-askpass version 1.2.4.1 (code name: Etouffee) is now available : > from the following locations: : > : > http://www.poboxc.com/~jmknoble/software/x11-ssh-askpass/ : ^^^^^^^^^^^^^^ : This address does not resolve. Oops. Typo. Should be: http://www.pobox.com/~jmknoble/software/x11-ssh-askpass/ ^^^ -- 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/20010919/0c39e79d/attachment.bin From alex at astro.su.se Thu Sep 20 21:57:19 2001 From: alex at astro.su.se (Alexey Koptsevich) Date: Thu, 20 Sep 2001 13:57:19 +0200 (MET DST) Subject: disable port forwarding in OpenSSH In-Reply-To: Message-ID: > chroot is almost certainly more secure. Unless you're root, it's usually > not possible to get out of a chroot. However, chroot is a lot harder to > manage, so sometimes admins try to do "clever" tricks which end up > subverting their security rather than enhancing it. A restricted shell is > way easier to build and manage and is frequently secure enough for most > people. OK, I see. But I do not do any tricks. I just copy all binaries needed, then all libraries and all config files needed for those binaries, to the direcrtory which contains mail folders. Then I chroot to it. > > Thanks! But if no shell -- no ability, right? > > I'm not sure I understand. The user has to have some "shell" that can be > invoked as " -c pine" and do the right thing. If you don't disable > suspend in the pine.conf.fixed, then pine will either fork a new instance > of (which is safe if is a restricted shell which just > exits when invoked without "-c pine") or else it will try to detach from > the restricted shell, which won't work right. OK, but if I set /usr/local/bin/pine (or /usr/local/bin/mutt) as a shell in the /etc/passwd and do not copy any shell to the chroot-ed directory at all -- there is no ability to run it, that's what I meant. Of course, if one excludes buffer overflow possibility... Thanks, Alex From peterw at usa.net Thu Sep 20 22:22:19 2001 From: peterw at usa.net (Peter W) Date: Thu, 20 Sep 2001 08:22:19 -0400 Subject: email apps as user shells (disable port forwarding in OpenSSH) In-Reply-To: ; from alex@astro.su.se on Thu, Sep 20, 2001 at 01:57:19PM +0200 References: Message-ID: <20010920082219.B816@usa.net> On Thu, Sep 20, 2001 at 01:57:19PM +0200, Alexey Koptsevich wrote: > > > Thanks! But if no shell -- no ability, right? > > > > I'm not sure I understand. The user has to have some "shell" that can be > > invoked as " -c pine" and do the right thing. If you don't disable > > suspend in the pine.conf.fixed, then pine will either fork a new instance > > of (which is safe if is a restricted shell which just > > exits when invoked without "-c pine") or else it will try to detach from > > the restricted shell, which won't work right. > > OK, but if I set /usr/local/bin/pine (or /usr/local/bin/mutt) as a shell > in the /etc/passwd and do not copy any shell to the chroot-ed directory at > all -- there is no ability to run it, that's what I meant. 1) isn't this outside the scope of the OpenSSH *development* list? 2) this can be easily and quickly tested, right? 3) [despite 1)]: email apps are powerful things, especially because they tend to include file browsers and full text editors 4) see 1): at the very least, I think this should be on a -users list, unless you see current behavior of OpenSSH that you wish to modify via source code changes -Peter From mouring at etoh.eviladmin.org Thu Sep 20 23:17:16 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 20 Sep 2001 08:17:16 -0500 (CDT) Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: <20010920120442.A27002@folly> Message-ID: On Thu, 20 Sep 2001, Markus Friedl wrote: > On Wed, Sep 19, 2001 at 05:04:51PM -0700, Brian Wellington wrote: > > Hi. Attached is a patch that introduces a new escape character (~c) that > > opens a command line. From the command line, a command of the form: > > > > -L port:host:hostport > > > > can be entered, which will forward the local port, as if the same option > > has been provided on the command line. I attempted to allow remote port > > forwards to be specified similarly, but the server disconnects with a > > protocol error (and the code is disabled now). > > > > This is a bit of a hack, but it works, and it's something that I've been > > hoping would be added to ssh for a few years now. > > > > The patch is against openssh-2.9p2. > > > > Comments? Any chance this will get integrated? > > + fprintf(stderr, "\r\n> "); > > + s = fgets(string, sizeof string, stdin); > > i don't think reading from stdin is correct. > you need to read from the same FD as bin. > > can you get the command line from 'bin' ? > > or perhaps use readpass.[ch] from -current with echo enabled? > Ermm.. I'm leary of this. By using readpass.[ch] base code with echo on. Can I be assured that no one can send control characters down my ssh pipe and enable new forwardings without my consent? I can just see people embeding stuff into an email as a form of attack. - Ben From pramod at redback.com Fri Sep 21 04:39:18 2001 From: pramod at redback.com (Pramod Srinivasan) Date: Thu, 20 Sep 2001 11:39:18 -0700 Subject: SFTP References: Message-ID: <3BAA37D6.4621B357@redback.com> HI, I am facing a problem when I try to sftp. It looks like ssh major protocol versions on the client and server is 2 and 1, so I get this message "Protocol major versions differ: 2 vs. 1" and " Couldn't read packet: Resource temporarily unavailable". In the sftp code, sftp is forcing protocol 2 when it is forking of ssh, and when I tried not to force version 2, ssh exits with the message "Exit status 1" and sftp throws "Couldn't read packet: Resource temporarily unavailable" Can someone help me solve this problem. Thanks, --Pramod From bwelling at xbill.org Fri Sep 21 04:43:59 2001 From: bwelling at xbill.org (Brian Wellington) Date: Thu, 20 Sep 2001 11:43:59 -0700 (PDT) Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: <20010920120442.A27002@folly> Message-ID: On Thu, 20 Sep 2001, Markus Friedl wrote: > On Wed, Sep 19, 2001 at 05:04:51PM -0700, Brian Wellington wrote: > > Hi. Attached is a patch that introduces a new escape character (~c) that > > opens a command line. From the command line, a command of the form: > > > > -L port:host:hostport > > > > can be entered, which will forward the local port, as if the same option > > has been provided on the command line. I attempted to allow remote port > > forwards to be specified similarly, but the server disconnects with a > > protocol error (and the code is disabled now). > > > > This is a bit of a hack, but it works, and it's something that I've been > > hoping would be added to ssh for a few years now. > > > > The patch is against openssh-2.9p2. > > > > Comments? Any chance this will get integrated? > > + fprintf(stderr, "\r\n> "); > > + s = fgets(string, sizeof string, stdin); > > i don't think reading from stdin is correct. > you need to read from the same FD as bin. >From what I can tell, process_escapes is called from client_process_input, and stdin_buffer is passed in as 'bin'. The fd is hardcoded as 'fileno(stdin)' in client_process_input. > can you get the command line from 'bin' ? Probably not easily. Calling fgets() blocks, and making the commandline handling non-blocking would require more state to be kept around, so that the commandline handler would be called at the end of the line. Using 'bin' would require it to be filled from the event loop. I don't like the fact that it's making a blocking call, but I don't know enough about the code to do it any other way. If you or someone else would like to, please do. > or perhaps use readpass.[ch] from -current with echo enabled? Using read_passphrase() would probably work. Does it offer any benefits over fgets()? I can't try this, since -current likely won't compile on a non-openbsd machine. Brian From stevesk at pobox.com Fri Sep 21 04:52:53 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 20 Sep 2001 11:52:53 -0700 (PDT) Subject: vis.[ch] In-Reply-To: Message-ID: On Thu, 20 Sep 2001, Tom Holroyd wrote: :As a separate problem, I note that lots of the mainline codes in :openssh do explicit : extern int optind; :etc., rather than relying on getopt.h. That's probably wrong. :(Why doesn't openssh use unistd.h for that, by the way?) it certainly isn't wrong, and it makes sense in portable programs because different systems may or may not declare optind and friends in certain header files. From mouring at etoh.eviladmin.org Fri Sep 21 05:06:32 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 20 Sep 2001 14:06:32 -0500 (CDT) Subject: SFTP In-Reply-To: <3BAA37D6.4621B357@redback.com> Message-ID: On Thu, 20 Sep 2001, Pramod Srinivasan wrote: > HI, > > I am facing a problem when I try to sftp. It looks like ssh major protocol > versions on the client and server is 2 and 1, so I get this message "Protocol > major versions differ: 2 vs. 1" and " Couldn't read packet: Resource > temporarily unavailable". > > In the sftp code, sftp is forcing protocol 2 when it is forking of ssh, and > when I tried not to force version 2, ssh exits with the message "Exit status 1" > and sftp throws "Couldn't read packet: Resource temporarily unavailable" > sftp is a v2 concept. You can do sftp -1 to foce a v1 connection, but you MUST MUST MUST have a sftp-server in the correct location (not unlike scp setup). - Ben From mouring at etoh.eviladmin.org Fri Sep 21 05:09:17 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 20 Sep 2001 14:09:17 -0500 (CDT) Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: Message-ID: [..] > > or perhaps use readpass.[ch] from -current with echo enabled? > > Using read_passphrase() would probably work. Does it offer any benefits > over fgets()? I can't try this, since -current likely won't compile on a > non-openbsd machine. > Why? OpenSSH portable snapshot compile from Linux to NeXT so far. http://www.openbsd.com/portable.html look under 'snapshots' and pick up the most recently version. And we should almost insync with the OpenBSD tree. - Ben From bwelling at xbill.org Fri Sep 21 05:42:28 2001 From: bwelling at xbill.org (Brian Wellington) Date: Thu, 20 Sep 2001 12:42:28 -0700 (PDT) Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: Message-ID: On Thu, 20 Sep 2001 mouring at etoh.eviladmin.org wrote: > [..] > > > or perhaps use readpass.[ch] from -current with echo enabled? > > > > Using read_passphrase() would probably work. Does it offer any benefits > > over fgets()? I can't try this, since -current likely won't compile on a > > non-openbsd machine. > > > > Why? OpenSSH portable snapshot compile from Linux to NeXT so far. > http://www.openbsd.com/portable.html look under 'snapshots' and pick up > the most recently version. And we should almost insync with the OpenBSD > tree. Sorry. I didn't know about the portable snapshots. Brian From bwelling at xbill.org Fri Sep 21 06:49:20 2001 From: bwelling at xbill.org (Brian Wellington) Date: Thu, 20 Sep 2001 13:49:20 -0700 (PDT) Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: <20010920120442.A27002@folly> Message-ID: On Thu, 20 Sep 2001, Markus Friedl wrote: > or perhaps use readpass.[ch] from -current with echo enabled? I just changed it to use readpassphrase(), although I honestly don't see any advantages. New patch appended, now against last night's portable snapshot. Brian ------- --- clientloop.c.old Mon Sep 17 22:51:14 2001 +++ clientloop.c Thu Sep 20 13:46:23 2001 @@ -467,6 +467,71 @@ } } +static void +process_cmdline(Buffer *bin, Buffer *bout, Buffer *berr) +{ + char string[1024]; + void (*handler)(int); + char *s; + u_short fwd_port, fwd_host_port; + char buf[256]; + int local = 0; + char *msg = NULL; + int n; + + leave_raw_mode(); + handler = signal(SIGINT, SIG_IGN); + s = readpassphrase("\r\n> ", string, sizeof string, RPP_ECHO_ON); + if (s == NULL) + goto out; + + while (*s && isspace(*s)) + s++; + + if (*s == 0) + goto out; + + if (strlen(s) < 2 || s[0] != '-' || !(s[1] == 'L' || s[1] == 'R')) { + msg = "Invalid command"; + goto out; + } + if (s[1] == 'L') + local = 1; + else { + msg = "Remote forwarding doesn't work"; + goto out; + } + + s += 2; + + if (sscanf(s, "%hu/%255[^/]/%hu", &fwd_port, buf, &fwd_host_port) != 3 + && + sscanf(s, "%hu:%255[^:]:%hu", &fwd_port, buf, &fwd_host_port) != 3) + { + msg = "Invalid port forward"; + goto out; + } + if (local) { + n = channel_request_local_forwarding(fwd_port, buf, + fwd_host_port, + options.gateway_ports); + if (n <= 0) { + msg = "Port forwarding failed"; + goto out; + } + } + else + channel_request_remote_forwarding(fwd_port, buf, fwd_host_port); + + msg = "Forwarding port"; + out: + signal(SIGINT, handler); + enter_raw_mode(); + if (msg) { + snprintf(string, sizeof string, "%s\r\n", msg); + buffer_append(berr, string, strlen(string)); + } +} /* process the characters one by one */ static int process_escapes(Buffer *bin, Buffer *bout, Buffer *berr, char *buf, int len) @@ -585,6 +650,10 @@ s = channel_open_message(); buffer_append(berr, s, strlen(s)); xfree(s); + continue; + + case 'c': + process_cmdline(bin, bout, berr); continue; default: From stevesk at pobox.com Fri Sep 21 09:35:03 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 20 Sep 2001 16:35:03 -0700 (PDT) Subject: SFTP In-Reply-To: Message-ID: On Thu, 20 Sep 2001 mouring at etoh.eviladmin.org wrote: :sftp is a v2 concept. You can do sftp -1 to foce a v1 connection, but you :MUST MUST MUST have a sftp-server in the correct location (not unlike scp :setup). i've attempted to document this for the next release; you can use -s for this: $ sftp -1 jenny Connecting to jenny... bash: /usr/libexec/sftp-server: No such file or directory Connection closed $ sftp -s /opt/openssh-CVS/libexec/sftp-server -1 jenny Connecting to jenny... sftp> -s subsystem | sftp_server Specifies the SSH2 subsystem or the path for an sftp server on the remote host. A path is useful for using sftp over protocol version 1, or when the remote sshd does not have an sftp subsys- tem configured. From djm at mindrot.org Fri Sep 21 10:32:53 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Sep 2001 10:32:53 +1000 (EST) Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: Message-ID: On Thu, 20 Sep 2001, Brian Wellington wrote: > On Thu, 20 Sep 2001, Markus Friedl wrote: > > > or perhaps use readpass.[ch] from -current with echo enabled? > > I just changed it to use readpassphrase(), although I honestly don't see > any advantages. New patch appended, now against last night's portable > snapshot. readpassphrase() reads directly from the process' controlling tty (if it has one). -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From markus at openbsd.org Fri Sep 21 17:42:23 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 21 Sep 2001 09:42:23 +0200 Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: ; from bwelling@xbill.org on Thu, Sep 20, 2001 at 11:43:59AM -0700 References: <20010920120442.A27002@folly> Message-ID: <20010921094223.C3804@faui02.informatik.uni-erlangen.de> On Thu, Sep 20, 2001 at 11:43:59AM -0700, Brian Wellington wrote: > On Thu, 20 Sep 2001, Markus Friedl wrote: > > > On Wed, Sep 19, 2001 at 05:04:51PM -0700, Brian Wellington wrote: > > > Hi. Attached is a patch that introduces a new escape character (~c) that > > > opens a command line. From the command line, a command of the form: > > > > > > -L port:host:hostport > > > > > > can be entered, which will forward the local port, as if the same option > > > has been provided on the command line. I attempted to allow remote port > > > forwards to be specified similarly, but the server disconnects with a > > > protocol error (and the code is disabled now). > > > > > > This is a bit of a hack, but it works, and it's something that I've been > > > hoping would be added to ssh for a few years now. > > > > > > The patch is against openssh-2.9p2. > > > > > > Comments? Any chance this will get integrated? > > > + fprintf(stderr, "\r\n> "); > > > + s = fgets(string, sizeof string, stdin); > > > > i don't think reading from stdin is correct. > > you need to read from the same FD as bin. > > >From what I can tell, process_escapes is called from client_process_input, > and stdin_buffer is passed in as 'bin'. The fd is hardcoded as > 'fileno(stdin)' in client_process_input. no. this is only true for ssh1. From markus at openbsd.org Sat Sep 22 01:53:58 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 21 Sep 2001 17:53:58 +0200 Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: ; from mouring@etoh.eviladmin.org on Thu, Sep 20, 2001 at 02:09:17PM -0500 References: Message-ID: <20010921175358.A29342@faui02.informatik.uni-erlangen.de> i thought about read_passphrase: Index: clientloop.c =================================================================== RCS file: /home/markus/cvs/ssh/clientloop.c,v retrieving revision 1.82 diff -u -r1.82 clientloop.c --- clientloop.c 2001/09/17 20:52:47 1.82 +++ clientloop.c 2001/09/21 11:56:04 @@ -81,6 +81,7 @@ #include "atomicio.h" #include "sshtty.h" #include "misc.h" +#include "readpass.h" /* import options */ extern Options options; @@ -467,6 +468,68 @@ } } +static void +process_cmdline(Buffer *xbin, Buffer *xbout, Buffer *xberr) +{ + u_short fwd_port, fwd_host_port; + char buf[1024], sfwd_port[6], sfwd_host_port[6]; + char *s, *cmd; + int n, local = 0; + + leave_raw_mode(); + + cmd = s = read_passphrase("\r\n> ", RP_ECHO); + if (s == NULL) + goto out; + while (*s && isspace(*s)) + s++; + if (*s == 0) + goto out; + if (strlen(s) < 2 || s[0] != '-' || !(s[1] == 'L' || s[1] == 'R')) { + log("Invalid command"); + goto out; + } + if (s[1] == 'L') { + local = 1; + } + if (!local && !compat20) { + log("Not supported for SSH protocol version 1"); + goto out; + } + s += 2; + while (*s && isspace(*s)) + s++; + if (*s == 0) + goto out; + if (sscanf(s, "%5[0-9]:%255[^:]:%5[0-9]", sfwd_port, buf, sfwd_host_port) + != 3 && + sscanf(s, "%5[0-9]/%255[^/]/%5[0-9]", sfwd_port, buf, sfwd_host_port) + != 3) { + log("Bad forwarding specification"); + goto out; + } + if ((fwd_port = a2port(sfwd_port)) == 0 || + (fwd_host_port = a2port(sfwd_host_port)) == 0) { + log("Bad forwarding port(s)"); + goto out; + } + if (local) { + n = channel_request_local_forwarding(fwd_port, buf, + fwd_host_port, options.gateway_ports); + if (n <= 0) { + log("Port forwarding failed"); + goto out; + } + } else { + channel_request_remote_forwarding(fwd_port, buf, fwd_host_port); + } + log("Forwarding port"); +out: + enter_raw_mode(); + if (cmd) + xfree(cmd); +} + /* process the characters one by one */ static int process_escapes(Buffer *bin, Buffer *bout, Buffer *berr, char *buf, int len) @@ -585,6 +648,10 @@ s = channel_open_message(); buffer_append(berr, s, strlen(s)); xfree(s); + continue; + + case 'c': + process_cmdline(bin, bout, berr); continue; default: From neale at woozle.org Sat Sep 22 04:49:26 2001 From: neale at woozle.org (Neale Pickett) Date: 21 Sep 2001 11:49:26 -0700 Subject: adding a pause utility in the distribution Message-ID: This is going to look silly, but I've seen it asked so many times that I'm starting to think it should be included in the OpenSSH distribution. People want to set up persistent tunnels without having to keep a shell open. The following program can be used with -f to do just that: #include int main() { pause(); return 0; } Any chance of this making it into the OpenSSH distribution (and maybe man page)? Neale From peterw at usa.net Sat Sep 22 05:56:05 2001 From: peterw at usa.net (Peter W) Date: Fri, 21 Sep 2001 15:56:05 -0400 Subject: adding a pause utility in the distribution In-Reply-To: ; from neale@woozle.org on Fri, Sep 21, 2001 at 11:49:26AM -0700 References: Message-ID: <20010921155605.B27244@usa.net> On Fri, Sep 21, 2001 at 11:49:26AM -0700, Neale Pickett wrote: > This is going to look silly, but I've seen it asked so many times that > I'm starting to think it should be included in the OpenSSH distribution. > People want to set up persistent tunnels without having to keep a shell > open. The following program can be used with -f to do just that: > > #include > int main() > { > pause(); > return 0; > } Yes, it does look kinda silly. :-) Users can always install similar apps on the target machine and do ssh me at otherhost /path/to/that/pause/app Plus tunnels that go through NAT devices and stateful firewalls tend to collapse if there's no data, so your approach would not even be universally useful; some users might need something like #include #include int main() { while (1) { sleep(120); printf("."); } return 0; } to maintain a tunnel. Since tunnel preservation techniques vary depending on the network configuration, IMO adding this sort of thing to OpenSSH doesn't sound like a great idea. -Peter From bradshaw at staff.crosswalk.com Sat Sep 22 07:50:22 2001 From: bradshaw at staff.crosswalk.com (Mark Bradshaw) Date: Fri, 21 Sep 2001 17:50:22 -0400 Subject: MaxStartups Confusion Message-ID: <911C684A29ACD311921800508B7293BA010A8D8B@cnmail> I would like some clarification regarding the use of MaxStartups. I have always used the three colon separated value that enables the random drop capabilities, but the documentation for sshd says that MaxStartups can also take a single value which sets a max and leaves random drops off. When I try this, sshd tells me that it got an illegal integer. Looking at the code, in servconf.c it looks like it'll only accept the three value parameter type. Am I reading the documentation incorrectly, has the functionality been discontinued, or was there a coding mix-up there? Mark From stevesk at pobox.com Sat Sep 22 08:09:48 2001 From: stevesk at pobox.com (Kevin Steves) Date: Fri, 21 Sep 2001 15:09:48 -0700 (PDT) Subject: MaxStartups Confusion In-Reply-To: <911C684A29ACD311921800508B7293BA010A8D8B@cnmail> Message-ID: On Fri, 21 Sep 2001, Mark Bradshaw wrote: :I would like some clarification regarding the use of MaxStartups. I have :always used the three colon separated value that enables the random drop :capabilities, but the documentation for sshd says that MaxStartups can also :take a single value which sets a max and leaves random drops off. : :When I try this, sshd tells me that it got an illegal integer. Looking at :the code, in servconf.c it looks like it'll only accept the three value :parameter type. Am I reading the documentation incorrectly, has the :functionality been discontinued, or was there a coding mix-up there? there was a bug which has been fixed for the next release; see: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/servconf.c.diff?r1=1.86&r2=1.87 From bwelling at xbill.org Sat Sep 22 10:26:16 2001 From: bwelling at xbill.org (Brian Wellington) Date: Fri, 21 Sep 2001 17:26:16 -0700 (PDT) Subject: Patch to allow local port forwarding from an existing connection In-Reply-To: <20010921175358.A29342@faui02.informatik.uni-erlangen.de> Message-ID: On Fri, 21 Sep 2001, Markus Friedl wrote: > i thought about read_passphrase: I'm still not convinced that read_passphrase is a good idea. Hitting ^C and Enter from the command line causes ssh to quit. The signal handling stuff in my first patch prevents this by simply ignoring ^C when fgets is called. Ignoring ^C might not be the best idea, but having ^C terminate ssh is worse. Maybe the right solution is to add a flag like RP_IGNORESIGNALS to read_passphrase, which ignores SIGINT instead of blocking it. Presumably ^Z should be handled the same way, since suspending ssh after the command is entered is also not desirable. Brian From info at ninosdepapel.org Sun Sep 23 00:42:48 2001 From: info at ninosdepapel.org (Niños de Papel) Date: Sat, 22 Sep 2001 09:42:48 -0500 Subject: Tarjetas Solidarias para esta Navidad Message-ID: <200109221110546.SM00178@computer> ***** This is an HTML Message ! ***** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010922/0b5f3698/attachment.html From alex at astro.su.se Sun Sep 23 05:39:34 2001 From: alex at astro.su.se (Alexey Koptsevich) Date: Sat, 22 Sep 2001 21:39:34 +0200 (MET DST) Subject: openssh with s/keys Message-ID: Hello, I am going to upgrade my openssh installation and would like to know some details about its support of s/keys, which are not clear for me from the on-line manual. - Am I right that 'challenge response authentication' is actually s/key authentication? - Is it possible to enable s/key authentication but disable password authentication? It was not allowed in OpenSSH_2.2.0/FreeBSD which I use now. Thanks, Alex PS Please cc: me your reply From kiev_r at svitonline.com Sun Sep 23 22:32:47 2001 From: kiev_r at svitonline.com (kiev_r at svitonline.com) Date: Sun, 23 Sep 2001 14:32:47 +0200 Subject: Kiev_VS Message-ID: -------------- next part -------------- A non-text attachment was scrubbed... Name: K_VED.doc Type: application/octet-stream Size: 34304 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010923/7061fb5d/attachment.obj From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Sep 25 21:18:43 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 25 Sep 2001 13:18:43 +0200 Subject: Today's CVS trouble (HP-UX 10.20) Message-ID: <20010925131843.A23491@serv01.aet.tu-cottbus.de> Hi! I have just updated some hosts to todays CVS version of OpenSSH portable, now flagged as 2.9.9p1. I now find the following error messages in my logfiles: Sep 25 12:16:38 ws01 sshd[17610]: wtmp_get_entry: read of /var/adm/wtmp failed: Bad file number Sep 25 12:17:11 ws01 sshd[17659]: wtmp_get_entry: read of /var/adm/wtmp failed: No such device or address These do not occur with 2.9p2. On the host in question I have been running last weeks (Thursday?) CVS without trouble. After distributing the latest CVS version to other hosts (previously running 2.9p2) I also see the same error messages popping up. In the Changelog I don't see any hint on what to look for. Any hints? 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 djm at mindrot.org Tue Sep 25 22:26:58 2001 From: djm at mindrot.org (Damien Miller) Date: Tue, 25 Sep 2001 22:26:58 +1000 (EST) Subject: Today's CVS trouble (HP-UX 10.20) In-Reply-To: <20010925131843.A23491@serv01.aet.tu-cottbus.de> Message-ID: On Tue, 25 Sep 2001, Lutz Jaenicke wrote: > I have just updated some hosts to todays CVS version of OpenSSH portable, > now flagged as 2.9.9p1. > > I now find the following error messages in my logfiles: > Sep 25 12:16:38 ws01 sshd[17610]: wtmp_get_entry: read of /var/adm/wtmp failed: > Bad file number > Sep 25 12:17:11 ws01 sshd[17659]: wtmp_get_entry: read of /var/adm/wtmp failed: > No such device or address > > These do not occur with 2.9p2. On the host in question I have been running > last weeks (Thursday?) CVS without trouble. After distributing the latest > CVS version to other hosts (previously running 2.9p2) I also see the same > error messages popping up. > In the Changelog I don't see any hint on what to look for. Any hints? I can't see what could be causing this - nothing has changed in this area recently. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Lutz.Jaenicke at aet.TU-Cottbus.DE Tue Sep 25 23:18:48 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 25 Sep 2001 15:18:48 +0200 Subject: Today's CVS trouble (HP-UX 10.20) In-Reply-To: ; from djm@mindrot.org on Tue, Sep 25, 2001 at 10:26:58PM +1000 References: <20010925131843.A23491@serv01.aet.tu-cottbus.de> Message-ID: <20010925151848.A26330@serv01.aet.tu-cottbus.de> On Tue, Sep 25, 2001 at 10:26:58PM +1000, Damien Miller wrote: > On Tue, 25 Sep 2001, Lutz Jaenicke wrote: > > I now find the following error messages in my logfiles: > > Sep 25 12:16:38 ws01 sshd[17610]: wtmp_get_entry: read of /var/adm/wtmp failed: > > Bad file number > > Sep 25 12:17:11 ws01 sshd[17659]: wtmp_get_entry: read of /var/adm/wtmp failed: > > No such device or address > > > > These do not occur with 2.9p2. On the host in question I have been running > > last weeks (Thursday?) CVS without trouble. After distributing the latest > > CVS version to other hosts (previously running 2.9p2) I also see the same > > error messages popping up. > > In the Changelog I don't see any hint on what to look for. Any hints? > > I can't see what could be causing this - nothing has changed in this area > recently. That was also my impression. I had a look into loginrec.c and could not see any particular reason. while (!found) { if (atomicio(read, fd, &ut, sizeof(ut)) != sizeof(ut)) { log("wtmp_get_entry: read of %s failed: %s", WTMP_FILE, strerror(errno)); close (fd); return 0; } The log entry "No such device or address" does not make sense in this context. The conclusion would be, that the condition (atomicio(read, fd, &ut, sizeof(ut)) != sizeof(ut)) is true, but it was not an error that occured. Does this mean, that the of bytes read from wtmp was not sizeof(ut)? Have to find out, whether there is something odd with /var/adm/wtmp going on... (I am using OpenSSH since it was released and never had any problem like this before...) 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 alex at astro.su.se Tue Sep 25 23:46:12 2001 From: alex at astro.su.se (Alexey Koptsevich) Date: Tue, 25 Sep 2001 15:46:12 +0200 (MET DST) Subject: email apps as user shells (disable port forwarding in OpenSSH) -- sorry Message-ID: Hello, I am very sorry that disturbed you. Unfortunately, I have not found -users list at http://www.openssh.org/list.html, only -announce and -dev, that's why I wrote to -dev. I beg your pardon. Alex On 2001-09-20 12:22:19, Peter W wrote: > > > Thanks! But if no shell -- no ability, right? > > > > I'm not sure I understand. The user has to have some "shell" that can be > > invoked as " -c pine" and do the right thing. If you don't disable > > suspend in the pine.conf.fixed, then pine will either fork a new instance > > of (which is safe if is a restricted shell which just > > exits when invoked without "-c pine") or else it will try to detach from > > the restricted shell, which won't work right. > > OK, but if I set /usr/local/bin/pine (or /usr/local/bin/mutt) as a shell > in the /etc/passwd and do not copy any shell to the chroot-ed directory at > all -- there is no ability to run it, that's what I meant. 1) isn't this outside the scope of the OpenSSH *development* list? 2) this can be easily and quickly tested, right? 3) [despite 1)]: email apps are powerful things, especially because they tend to include file browsers and full text editors 4) see 1): at the very least, I think this should be on a -users list, unless you see current behavior of OpenSSH that you wish to modify via source code changes -Peter From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Sep 26 01:47:46 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 25 Sep 2001 17:47:46 +0200 Subject: Today's CVS trouble (HP-UX 10.20) In-Reply-To: <20010925151848.A26330@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Sep 25, 2001 at 03:18:48PM +0200 References: <20010925131843.A23491@serv01.aet.tu-cottbus.de> <20010925151848.A26330@serv01.aet.tu-cottbus.de> Message-ID: <20010925174746.A28912@serv01.aet.tu-cottbus.de> On Tue, Sep 25, 2001 at 03:18:48PM +0200, Lutz Jaenicke wrote: > That was also my impression. I had a look into loginrec.c and could not > see any particular reason. > while (!found) { > if (atomicio(read, fd, &ut, sizeof(ut)) != sizeof(ut)) { > log("wtmp_get_entry: read of %s failed: %s", > WTMP_FILE, strerror(errno)); > close (fd); > return 0; > } > The log entry "No such device or address" does not make sense in this > context. The conclusion would be, that the condition > (atomicio(read, fd, &ut, sizeof(ut)) != sizeof(ut)) > is true, but it was not an error that occured. Does this mean, that > the of bytes read from wtmp was not sizeof(ut)? Following up to myself: with some instrumenting, atomicio does return 0: Sep 25 17:41:29 ws01 sshd[24763]: wtmp_get_entry: read of /var/adm/wtmp failed: Bad file number, result=0 (sizeof(ut)=60, fd=3) Don't know (yet?) what this means, however :-) 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 dschiebe at cisco.com Wed Sep 26 02:55:39 2001 From: dschiebe at cisco.com (Schieber, Dustin) Date: Tue, 25 Sep 2001 12:55:39 -0400 Subject: fix for hang on exit Message-ID: Apologies if this is documented somewhere, but I could not find it. I'm wondering if there will be a fix for the hang on exit problem in the next release. We are currently using 2.9p1 and this issue is creating a lot of problems. Currently using the workaround that is described in the FAQ, but this is not ideal for many reasons. We see this problem on both Solaris and HP-UX. thx, -das From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Sep 26 06:12:13 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Tue, 25 Sep 2001 22:12:13 +0200 Subject: Today's CVS trouble (HP-UX 10.20) In-Reply-To: <20010925174746.A28912@serv01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Tue, Sep 25, 2001 at 05:47:46PM +0200 References: <20010925131843.A23491@serv01.aet.tu-cottbus.de> <20010925151848.A26330@serv01.aet.tu-cottbus.de> <20010925174746.A28912@serv01.aet.tu-cottbus.de> Message-ID: <20010925221213.A1524@serv01.aet.tu-cottbus.de> On Tue, Sep 25, 2001 at 05:47:46PM +0200, Lutz Jaenicke wrote: > On Tue, Sep 25, 2001 at 03:18:48PM +0200, Lutz Jaenicke wrote: > > That was also my impression. I had a look into loginrec.c and could not > > see any particular reason. > > while (!found) { > > if (atomicio(read, fd, &ut, sizeof(ut)) != sizeof(ut)) { > > log("wtmp_get_entry: read of %s failed: %s", > > WTMP_FILE, strerror(errno)); > > close (fd); > > return 0; > > } Some further analysis: Sep 25 18:16:23 ws01 sshd[29512]: wtmp_get_entry: read of /var/adm/wtmp failed: Bad file number, result=0 (sizeof(ut)=60, fd=3) attempt=1, distance=0, offset=569280 The atomicio() already fails in the first round (attempt=1), so the problem must be located earlier in the code. Just above the offending loop there is (slightly modified for testing): /* Seek to the start of the last struct utmp */ distance = lseek(fd, (off_t)(0 - sizeof(struct utmp)), SEEK_END); if (distance == -1) { /* Looks like we've got a fresh wtmp file */ close(fd); return 0; } As you can see from the log excerpt above, "distance=0", so the lseek() already seems to be suspicious. The only candidate in the lseek() must be the distance, (as fd and SEEK_END do not offer anything), so I included a printout of the "(off_t)(0 - sizeof(struct utmp))" into the logging: if (result != sizeof(ut)) { log("wtmp_get_entry: read of %s failed: %s, result=%d (sizeof(ut)=%d, fd=%d) attempt=%d, distance=%d, offset=%d", WTMP_FILE, strerror(errno), result, sizeof(ut), fd, counter, distance, (off_t)(0-sizeof(struct utmp))); Printing off_t with %d looks fishy, and the printed result (569280) does not look nice, so the printout in the logfile is not that trustworthy. Based on this printout I had a look into HP-UX header files and found, that off_t is defined differently with LARGEFILE support, which directly falls together with the point, that the problem just appeared with today's CVS: 20010925 - (djm) Add AC_SYS_LARGEFILE configure test ... checking for _FILE_OFFSET_BITS value needed for large files... 64 checking for _LARGE_FILES value needed for large files... no ... After removing AC_SYS_LARGEFILE from configure.in, the problem disappears. I do use 2.52, if that matters... 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 atrivedi at iPolicyNet.COM Wed Sep 26 08:23:40 2001 From: atrivedi at iPolicyNet.COM (Trivedi, Ashish) Date: Tue, 25 Sep 2001 15:23:40 -0700 Subject: Haning problems in signature generation Message-ID: Hi, I am trying to port a ssh deamon for nucleus RTOS. I am having trouble in calculating signature and I am getting error in BN_mod_inverse of the crypto lib. What I have done is rather then reading the keys from file I am updating the keys reading it from strings and converting them into bytes. I am updating the p, q, g, pub_key and priv_key members of the structure DSA. Can any body help me on this. Regards, Ashish From djm at mindrot.org Wed Sep 26 08:44:14 2001 From: djm at mindrot.org (Damien Miller) Date: Wed, 26 Sep 2001 08:44:14 +1000 (EST) Subject: Today's CVS trouble (HP-UX 10.20) In-Reply-To: <20010925221213.A1524@serv01.aet.tu-cottbus.de> Message-ID: On Tue, 25 Sep 2001, Lutz Jaenicke wrote: > After removing AC_SYS_LARGEFILE from configure.in, the problem disappears. > I do use 2.52, if that matters... Are you running autoconf yourself or using configure from the tarballs? I am using autoconf=2.52d -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From voltaic at thcnet.net Wed Sep 26 09:55:36 2001 From: voltaic at thcnet.net (voltaic) Date: Tue, 25 Sep 2001 16:55:36 -0700 (PDT) Subject: question Message-ID: according to the openssh mailing list page, this is the spot to report/discuss bugs and i have a potential one. on the other hand, it is probably something i am not doing correctly. the system is red hat linux 6.2 (yuk) running the openssh rpm i grabbed off of the portable openssh site listing, with sshd version OpenSSH_2.9p2 i have it installed via rpm and when i go to launch sshd it gives me this error: Could not load host key: /etc/ssh/ssh_host_key Could not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_dsa_key Disabling protocol version 1. Could not load host key Disabling protocol version 2. Could not load host key sshd: no hostkeys available -- exiting. the "issue" is that those files are there. peep the listing: [root at nbws1 ssh]# pwd /etc/ssh [root at nbws1 ssh]# ls -al total 68 drwxr-xr-x 2 root root 4096 Sep 25 16:33 . drwxr-xr-x 30 root root 4096 Sep 25 15:52 .. -rw-r--r-- 1 root root 26287 Jun 16 21:51 primes -rw-r--r-- 1 root root 1050 Jun 16 21:51 ssh_config -rw------- 1 root root 736 Sep 25 16:08 ssh_host_dsa_key -rw-r--r-- 1 root root 600 Sep 25 16:08 ssh_host_dsa_key.pub -rw------- 1 root root 525 Sep 25 16:06 ssh_host_key -rw-r--r-- 1 root root 329 Sep 25 16:06 ssh_host_key.pub -rw------- 1 root root 951 Sep 25 16:07 ssh_host_rsa_key -rw-r--r-- 1 root root 220 Sep 25 16:07 ssh_host_rsa_key.pub -rw-r--r-- 1 root root 1780 Sep 25 16:50 sshd_config [root at nbws1 ssh]# all of the host key files were generated as recommended on the openssh portable "how to install" web page, which shows this: ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N "" ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" the only things i did differently are that i inserted passphrases in the above ssh-keygen command lines (between the quotes) and that i edited the sshd_config file to change PermitRootLogin to no. ssh client is fine. sshd finds the keys if i set them world readable but (as it should) declines to use them. so the files are definitely there. what is wrong with my setup? why won't sshd find those keys? the only thing i can think is that sshd doesn't want to run as root (i am launching it from the cli as root) and then it can't read those files. in this case, what is the user that sshd tries to launch as? i cannot find the user name in any documentation. From mhw at wittsend.com Wed Sep 26 10:20:53 2001 From: mhw at wittsend.com (Michael H. Warfield) Date: Tue, 25 Sep 2001 20:20:53 -0400 Subject: question In-Reply-To: References: Message-ID: <20010925202053.A24328@alcove.wittsend.com> On Tue, Sep 25, 2001 at 04:55:36PM -0700, voltaic wrote: > according to the openssh mailing list page, this is the spot to > report/discuss bugs and i have a potential one. on the other hand, it is > probably something i am not doing correctly. > the system is red hat linux 6.2 (yuk) running the openssh rpm i grabbed off > of the portable openssh site listing, with sshd version OpenSSH_2.9p2 > i have it installed via rpm and when i go to launch sshd it gives me this > error: > Could not load host key: /etc/ssh/ssh_host_key > Could not load host key: /etc/ssh/ssh_host_rsa_key > Could not load host key: /etc/ssh/ssh_host_dsa_key > Disabling protocol version 1. Could not load host key > Disabling protocol version 2. Could not load host key > sshd: no hostkeys available -- exiting. > the "issue" is that those files are there. peep the listing: > [root at nbws1 ssh]# pwd > /etc/ssh > [root at nbws1 ssh]# ls -al > total 68 > drwxr-xr-x 2 root root 4096 Sep 25 16:33 . > drwxr-xr-x 30 root root 4096 Sep 25 15:52 .. > -rw-r--r-- 1 root root 26287 Jun 16 21:51 primes > -rw-r--r-- 1 root root 1050 Jun 16 21:51 ssh_config > -rw------- 1 root root 736 Sep 25 16:08 ssh_host_dsa_key > -rw-r--r-- 1 root root 600 Sep 25 16:08 ssh_host_dsa_key.pub > -rw------- 1 root root 525 Sep 25 16:06 ssh_host_key > -rw-r--r-- 1 root root 329 Sep 25 16:06 ssh_host_key.pub > -rw------- 1 root root 951 Sep 25 16:07 ssh_host_rsa_key > -rw-r--r-- 1 root root 220 Sep 25 16:07 ssh_host_rsa_key.pub > -rw-r--r-- 1 root root 1780 Sep 25 16:50 sshd_config > [root at nbws1 ssh]# > all of the host key files were generated as recommended on the openssh > portable "how to install" web page, which shows this: > ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N "" > ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" > ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" > the only things i did differently are that i inserted passphrases in the > above ssh-keygen command lines (between the quotes) and that i edited the > sshd_config file to change PermitRootLogin to no. ??? I don't think setting passphrases on the host keys is going to work. Try it without. I'll bet that's it. > ssh client is fine. sshd finds the keys if i set them world readable but > (as it should) declines to use them. so the files are definitely there. > what is wrong with my setup? why won't sshd find those keys? > the only thing i can think is that sshd doesn't want to run as root (i am > launching it from the cli as root) and then it can't read those files. in > this case, what is the user that sshd tries to launch as? i cannot find the > user name in any documentation. I'll bet it's the passphrases. I don't know anyone who has tried host keys with passphrases and I don't know anything you might gain, even if you were always going to start sshd manually and enter all three passphrases at startup. Anyone who could read the key files would have broken root on your system and can access kernel memory and/or trojan the binary and later steal the unencrypted key and/or passphrase. Even then, it would only be good for spoofing your system for a MITM attack which would STILL require effort to play games with a box he had already busted and rooted to the core. Not worth the effort for the value that key has. Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From voltaic at thcnet.net Wed Sep 26 10:29:31 2001 From: voltaic at thcnet.net (voltaic) Date: Tue, 25 Sep 2001 17:29:31 -0700 (PDT) Subject: question In-Reply-To: <20010925202053.A24328@alcove.wittsend.com> Message-ID: On Tue, 25 Sep 2001, Michael H. Warfield wrote: > > i have it installed via rpm and when i go to launch sshd it gives me this > > error: > > > Could not load host key: /etc/ssh/ssh_host_key > > Could not load host key: /etc/ssh/ssh_host_rsa_key > > Could not load host key: /etc/ssh/ssh_host_dsa_key > > Disabling protocol version 1. Could not load host key > > Disabling protocol version 2. Could not load host key > > sshd: no hostkeys available -- exiting. > > ??? I don't think setting passphrases on the host keys is going > to work. Try it without. I'll bet that's it. > > I'll bet it's the passphrases. I don't know anyone who has > tried host keys with passphrases and I don't know anything you might > gain, even if you were always going to start sshd manually and enter > all three passphrases at startup. Anyone who could read the key files > would have broken root on your system and can access kernel memory and/or > trojan the binary and later steal the unencrypted key and/or passphrase. > Even then, it would only be good for spoofing your system for a MITM > attack which would STILL require effort to play games with a box > he had already busted and rooted to the core. Not worth the effort > for the value that key has. > > Mike > -- > Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com > (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ > NIC whois: MHW9 | An optimist believes we live in the best of all > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! hey great call michael, that fixed it. thanks much! From jmknoble at pobox.com Wed Sep 26 10:34:59 2001 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 25 Sep 2001 20:34:59 -0400 Subject: question In-Reply-To: ; from voltaic@thcnet.net on Tue, Sep 25, 2001 at 04:55:36PM -0700 References: Message-ID: <20010925203459.D5846@zax.half.pint-stowp.cx> Circa 2001-Sep-25 16:55:36 -0700 dixit voltaic: : according to the openssh mailing list page, this is the spot to : report/discuss bugs and i have a potential one. on the other hand, : it is probably something i am not doing correctly. Correct. See below. : the system is red hat linux 6.2 (yuk) running the openssh rpm i : grabbed off of the portable openssh site listing, with sshd version : OpenSSH_2.9p2 : : i have it installed via rpm and when i go to launch sshd it gives me : this error: : : Could not load host key: /etc/ssh/ssh_host_key : Could not load host key: /etc/ssh/ssh_host_rsa_key : Could not load host key: /etc/ssh/ssh_host_dsa_key : Disabling protocol version 1. Could not load host key : Disabling protocol version 2. Could not load host key : sshd: no hostkeys available -- exiting. : : the "issue" is that those files are there. peep the listing: [...] : all of the host key files were generated as recommended on the openssh : portable "how to install" web page, which shows this: : : ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N "" : ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" : ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" : : the only things i did differently are that i inserted passphrases in the : above ssh-keygen command lines (between the quotes) Don't do that. Host keys may not have passphrases. Sshd can't load them if they do (as you've found). You should use passphrases with your per-user keys, but not with host keys. Note that /etc/rc.d/initd/sshd generates the host keypairs automagically when sshd first starts, if the keys don't exist. You can simply remove the passphrased host keys, then start sshd: su rm /etc/ssh/ssh*_key* /etc/rc.d/init.d/sshd start The initscript generates new host keypairs, then starts sshd. : and that i edited the sshd_config file to change PermitRootLogin to : no. : : ssh client is fine. sshd finds the keys if i set them world : readable but (as it should) declines to use them. so the files are : definitely there. : : what is wrong with my setup? why won't sshd find those keys? [Answer above.] : the only thing i can think is that sshd doesn't want to run as root : (i am launching it from the cli as root) and then it can't read : those files. in this case, what is the user that sshd tries to : launch as? i cannot find the user name in any documentation. Sshd must start as root, for two main reasons: (1) By default, it listens on a privileged port (portnumber 22). (While you can tell sshd to listen on a non-privileged, port, it still must run as root for reason [2] below). (2) In order to run as the user who logs in (or runs a command) via ssh, sshd uses seteuid(), setuid(), and other system calls which require privilege. -- 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/20010925/0c778bc7/attachment.bin From pmenage at ensim.com Wed Sep 26 10:43:41 2001 From: pmenage at ensim.com (Paul Menage) Date: Tue, 25 Sep 2001 17:43:41 -0700 Subject: SIGCHLD race condition? (fwd) Message-ID: Can anyone offer any advice on this issue? We've tried patching sshd to have a maximum 10 second timeout when calling select() in serverloop.c, and this doesn't appear to have had any ill effects. Thanks, Paul ------- Forwarded Message Date: Tue, 18 Sep 2001 16:49:40 -0700 From: Paul Menage To: mouring at etoh.eviladmin.org cc: Paul Menage , openssh-unix-dev at mindrot.org Subject: Re: SIGCHLD race condition? > >Can you test against 2.9p2 or the current snapshots.. There has been some >SIGCHLD changes since 2.5.2pX series. > The signal handling strategy has changed, but the race condition in wait_until_can_do_something(), between checking child_terminated and calling select(), is still there. I can reproduce exactly the same lockup with RedHat/RawHide 2.9p2. Would putting a maximum timeout for select() break anything? If not, then it would at least prevent the system from deadlocking permanently, even if it's not a very elegant fix. Paul ------- End of Forwarded Message From pkocks at portal.com Wed Sep 26 10:58:48 2001 From: pkocks at portal.com (Peter Kocks) Date: Tue, 25 Sep 2001 17:58:48 -0700 Subject: Protocol 2 remote port forwarding Message-ID: Hi all, I'm using openssh-2.9p2 on Solaris 2.8. I can get remote port forwarding to work using the -R flag, but only with ssh protocol 1 not ssh protocol 2. I've read that remote forwarding protocol 2 was not supported in earlier versions of openssh, but I'm wondering if this is still the case. Jarno Huuskonen [Jarno.Huuskonen at uku.fi], posted a patch in 2000 to add support for -R in protocol 2. Is -R supported in portocol 2 in openssh? If so, is any special configuation needed? Thanks! --PK From Leakin at dfw.Nostrum.com Wed Sep 26 11:26:58 2001 From: Leakin at dfw.Nostrum.com (Lee Eakin) Date: Tue, 25 Sep 2001 20:26:58 -0500 Subject: Protocol 2 remote port forwarding In-Reply-To: References: Message-ID: <20010925202657.A30111@japh.itg.ti.com> The -R is broken in 2.9p2, fixed in the current CVS tree. -L works properly. Here is the patch against 2.9p2 (posted to the list some time back). diff -u channels.c.orig channels.c --- channels.c.orig Wed Jun 13 14:18:05 2001 +++ channels.c Thu Aug 2 20:26:25 2001 @@ -773,8 +773,9 @@ rtype = (c->type == SSH_CHANNEL_RPORT_LISTENER) ? "forwarded-tcpip" : "direct-tcpip"; - nextstate = (c->host_port == 0) ? SSH_CHANNEL_DYNAMIC : - SSH_CHANNEL_OPENING; + nextstate = (c->host_port == 0 && + c->type != SSH_CHANNEL_RPORT_LISTENER) ? + SSH_CHANNEL_DYNAMIC : SSH_CHANNEL_OPENING; addrlen = sizeof(addr); newsock = accept(c->sock, &addr, &addrlen); ---begin quoted text--- > Delivered-To: openssh-unix-dev-list-93873 at shitei.mindrot.org > From: Peter Kocks > To: "'openssh-unix-dev at mindrot.org'" > Subject: Protocol 2 remote port forwarding > Date: Tue, 25 Sep 2001 17:58:48 -0700 > X-Mailer: Internet Mail Service (5.5.2650.21) > > Hi all, > > I'm using openssh-2.9p2 on Solaris 2.8. I can get remote port forwarding to > work using the -R flag, but only with ssh protocol 1 not ssh protocol 2. > > I've read that remote forwarding protocol 2 was not supported in earlier > versions of openssh, but I'm wondering if this is still the case. Jarno > Huuskonen [Jarno.Huuskonen at uku.fi], posted a patch in 2000 to add support > for -R in protocol 2. > > Is -R supported in portocol 2 in openssh? > > If so, is any special configuation needed? > > Thanks! > > --PK ---end quoted text--- -- Lee Eakin - leakin at dfw.nostrum.com Wyszkowski's Second Law: Anything can be made to work if you fiddle with it long enough. From mcurtis9 at csc.com.au Tue Sep 25 12:09:57 2001 From: mcurtis9 at csc.com.au (mcurtis9 at csc.com.au) Date: Tue, 25 Sep 2001 12:09:57 +1000 Subject: Intermittent port forwarding problems openssh 2.9.2p and up Message-ID: Hi all, I'm now using openssh 2.9.9p1 (after having the same problem with 2.9.2p), currently on two redhat Linux 6.2 machines and I am getting some intermittent port forwarding problems. To provide some background, the two machines sit on separate networks and talk through a firewall. I am trying to get an application to talk through the ssh connection to a remote machine. ie ssh -N 1500:remote_machine:1500 linux_machine This is kicked off from inittab and works fine, the problem is that the first time a user uses the application after they have logged in, or after about 5 minutes of leaving their terminal idle the application will fail to work properly, after some investigation it seems it has hung waiting on some data from the socket never to arrive. I have used ethereal on both ends of the tunnel (ie the loopback interface on the localhost and eth0 on the remote host), and have found that the first packet after the syn, syn-ack, ack handshake sent from the localhost (a psh-ack with some data), fails to appear on the other end of the tunnel. Yet when the application is closed, the connection goes through the normal fin, fin-ack stages of closing. Which to me seems like the connection is being managed properly, it's just a problem transmitting the data. Run the application again, and then all the data starts appearing on both sides correctly and the application works fine. The only difference I can see between this applications activity and say telnet or sendmail, is that there is no banner message from the server after the initial tcp handshake, the client is the first one to send any data. why this should affect anything I do not know, but there may be some assumption of this type in the code. If anyone can provide some help on this as it would be nice to fix it, or requires some more information please let me know, I can provide some dumps of the network activity that is occurring at each end (I realise the traffic between will be gibberish, that is the point after all), and it is easy enough to upgrade or patch the code to try things out. I'm running last night's snapshot (25/9/2001), after seeing some e-mails in the archive about various problems with port forwarding. I should point out, telnet, etc seems to work fine if I try them, and the application works fine after you try once and quit, and then start it again... It builds a new socket connection each time as well, so it's not some problem with the application using the socket too quickly and it's fully established by the time we retry the application. BTW could you please cc me in on the reply, as I am not subscribed to this mailing list. Thanks in advance, Mark Curtis. --------------------------------------------------------------------------------------------------------------- Unix/DB Administrator CSC Five Islands Road, Port Kembla Ph: +61-2-42757968 Fax: +61-2-42757801 E-mail: mcurtis9 at csc.com.au Quidquid latine dictum sit, altum videtur. Whatever is said in Latin sounds profound. From tomh at po.crl.go.jp Wed Sep 26 13:44:03 2001 From: tomh at po.crl.go.jp (Tom Holroyd) Date: Wed, 26 Sep 2001 12:44:03 +0900 (JST) Subject: SNAP-20010926 configuration Message-ID: 1) configure: AC_SYS_LARGEFILE: command not found Is autoconf 2.5x now required? I use 2.52 and it builds just fine following autoconf; autoheader. 2) make [very|dist]clean does not remove scard/Makefile Dr. Tom From markus at openbsd.org Wed Sep 26 17:43:21 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Sep 2001 09:43:21 +0200 Subject: SIGCHLD race condition? (fwd) In-Reply-To: ; from pmenage@ensim.com on Tue, Sep 25, 2001 at 05:43:41PM -0700 References: Message-ID: <20010926094321.B26693@faui02.informatik.uni-erlangen.de> On Tue, Sep 25, 2001 at 05:43:41PM -0700, Paul Menage wrote: > Can anyone offer any advice on this issue? We've tried patching sshd to > have a maximum 10 second timeout when calling select() in serverloop.c, > and this doesn't appear to have had any ill effects. hm, i'd prefer to fix the real bug... From pmenage at ensim.com Wed Sep 26 17:54:41 2001 From: pmenage at ensim.com (Paul Menage) Date: Wed, 26 Sep 2001 00:54:41 -0700 Subject: SIGCHLD race condition? (fwd) In-Reply-To: Your message of "Wed, 26 Sep 2001 09:43:21 +0200." <20010926094321.B26693@faui02.informatik.uni-erlangen.de> Message-ID: >On Tue, Sep 25, 2001 at 05:43:41PM -0700, Paul Menage wrote: >> Can anyone offer any advice on this issue? We've tried patching sshd to >> have a maximum 10 second timeout when calling select() in serverloop.c, >> and this doesn't appear to have had any ill effects. > >hm, i'd prefer to fix the real bug... > Agreed. But in this case it's not clear if there's a particularly nice way to do it. I don't think that you can specify that a signal be blocked until you next call select(). The two possibilities that come to mind are: - Hold on to both ends of a pipe, the read end of which gets included in the select() set. As well as setting child_terminated to 1, the signal handler writes a single byte to the pipe (non-blocking, and doesn't mind if it gets EAGAIN). That way the select() will return if the parent hasn't processed child_terminated yet. (In fact, the pipe could possibly replace the child_terminated variable entirely.) - Switch to using queued signals for network readiness events, then use sigtimedwait() or similar instead of select(). I imagine that this would be a fairly major overhaul of the networking code. Paul From Lutz.Jaenicke at aet.TU-Cottbus.DE Wed Sep 26 20:12:20 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 26 Sep 2001 12:12:20 +0200 Subject: Today's CVS trouble (HP-UX 10.20) In-Reply-To: ; from djm@mindrot.org on Wed, Sep 26, 2001 at 08:44:14AM +1000 References: <20010925221213.A1524@serv01.aet.tu-cottbus.de> Message-ID: <20010926121220.A9459@serv01.aet.tu-cottbus.de> On Wed, Sep 26, 2001 at 08:44:14AM +1000, Damien Miller wrote: > On Tue, 25 Sep 2001, Lutz Jaenicke wrote: > > > After removing AC_SYS_LARGEFILE from configure.in, the problem disappears. > > I do use 2.52, if that matters... > > Are you running autoconf yourself or using configure from the tarballs? > > I am using autoconf=2.52d I have been using autoconf myself on the CVS version. I am using autoconf 2.52. 2.52d is only available via alpha.gnu.org. I will update my systems to 2.9.9p2 for production use. Largefile support is left for later investigation... 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 martin at fatbob.nu Wed Sep 26 21:40:02 2001 From: martin at fatbob.nu (Martin Johansson) Date: Wed, 26 Sep 2001 13:40:02 +0200 Subject: [PATCH] random SSH_MSG_IGNORE packets Message-ID: <20010926134002.A8295@fatbob.nu> Hi! The following patch adds ability to configure the ssh client to send SSH[2]_MSG_IGNORE packets of random length at random times whithin a user-specified interval. The function is configured by setting the config-file options BogusTrafficIntervalMax and BogusTrafficIntervalMin, which defines the interval in seconds in which the packets are randomly sent. It is disabled by default. It suffices to set the Max value to enable the function. The Min then defaults to 0. The packet size is not configurable, but hardcoded to be random between 1-64 bytes. The patch does not include any man-page update, but if this is something that may go into the main tree, I could put something together. The gains of this functionality is not only to fool traffic analysis; I'm sitting behind a firewall at work that does connection tracking of TCP connections. The firewall has an idletimeout of TCP connections of between 30-40 minutes. After the timeout expires it just drops the packets related to that connection, and the ssh session is dead. The random packets functionality remedies this annoyance. Yes, sshd can do ClientAlive, but one isn't always in control of the system one is connecting to. Firewall reconfiguration is no easy option when dealing with a Windows NT-centric IT-department... Patch against openssh-2.9p2. /Martin diff -ur openssh-2.9p2/clientloop.c openssh-2.9p2.servalive/clientloop.c --- openssh-2.9p2/clientloop.c Fri Apr 20 14:50:51 2001 +++ openssh-2.9p2.servalive/clientloop.c Wed Sep 26 12:58:38 2001 @@ -324,6 +324,9 @@ client_wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, int rekeying) { + struct timeval tv, *tvp = &tv; + int ret; + /* Add any selections by the channel mechanism. */ channel_prepare_select(readsetp, writesetp, maxfdp, rekeying); @@ -356,13 +359,29 @@ /* * Wait for something to happen. This will suspend the process until * some selected descriptor can be read, written, or has some other - * event pending. Note: if you want to implement SSH_MSG_IGNORE - * messages to fool traffic analysis, this might be the place to do - * it: just have a random timeout for the select, and send a random - * SSH_MSG_IGNORE packet when the timeout expires. + * event pending. + * Set a random timeout for the select, and send a random SSH_MSG_IGNORE + * packet when the timeout expires to fool traffic analysis. */ - - if (select((*maxfdp)+1, *readsetp, *writesetp, NULL, NULL) < 0) { + if (options.bogus_traffic_interval_max) { + u_int32_t rand = arc4random(); + u_int64_t timeusec; + static u_int64_t timebase = 0; + u_int32_t interval_min = options.bogus_traffic_interval_min; + u_int32_t interval_max = options.bogus_traffic_interval_max; + + if (!timebase) + timebase = (interval_max - interval_min) * 1000000; + timeusec = timebase * rand / 0xffffffff; + timeusec += interval_min * 1000000; + tv.tv_sec = timeusec / 1000000; + tv.tv_usec = timeusec % 1000000; + debug3("Will send SSH_MSG_IGNORE in %lu.%lu s", tv.tv_sec, tv.tv_usec); + } + else tvp = NULL; + + ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp); + if (ret < 0) { char buf[100]; /* @@ -379,6 +398,17 @@ snprintf(buf, sizeof buf, "select: %s\r\n", strerror(errno)); buffer_append(&stderr_buffer, buf, strlen(buf)); quit_pending = 1; + } + else if (ret == 0) { + /* + * select() timed out. Send a SSH[2]_MSG_IGNORE packet of random + * size between 1 - 64 bytes. + */ + u_int32_t rand = arc4random(); + packet_send_ignore((rand & 0x3f) + 1); + packet_send(); + packet_write_wait(); + debug3("Sent SSH_MSG_IGNORE of size %d", (rand & 0x3f) + 1); } } diff -ur openssh-2.9p2/readconf.c openssh-2.9p2.servalive/readconf.c --- openssh-2.9p2/readconf.c Tue Apr 17 20:11:37 2001 +++ openssh-2.9p2.servalive/readconf.c Wed Sep 26 10:14:25 2001 @@ -111,7 +111,7 @@ oGlobalKnownHostsFile2, oUserKnownHostsFile2, oPubkeyAuthentication, oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, - oHostKeyAlgorithms + oHostKeyAlgorithms, oBogusTrafficIntervalMax, oBogusTrafficIntervalMin } OpCodes; /* Textual representations of the tokens. */ @@ -172,6 +172,8 @@ { "compression", oCompression }, { "compressionlevel", oCompressionLevel }, { "keepalive", oKeepAlives }, + { "BogusTrafficIntervalMax", oBogusTrafficIntervalMax }, + { "BogusTrafficIntervalMin", oBogusTrafficIntervalMin }, { "numberofpasswordprompts", oNumberOfPasswordPrompts }, { "loglevel", oLogLevel }, { "dynamicforward", oDynamicForward }, @@ -394,6 +396,42 @@ intptr = &options->keepalives; goto parse_flag; + case oBogusTrafficIntervalMax: + intptr = &options->bogus_traffic_interval_max; + arg = strdelim(&s); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing argument.", filename, linenum); + if (arg[0] < '0' || arg[0] > '9') + fatal("%.200s line %d: Bad number.", filename, linenum); + + /* Octal, decimal, or hex format? */ + value = strtol(arg, &endofnumber, 0); + if (arg == endofnumber) + fatal("%.200s line %d: Bad number.", filename, linenum); + if (*activep && *intptr == -1) + *intptr = value; + if (options->bogus_traffic_interval_min >= value) + fatal("%.200s line %d: Bad value.", filename, linenum); + break; + + case oBogusTrafficIntervalMin: + intptr = &options->bogus_traffic_interval_min; + arg = strdelim(&s); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing argument.", filename, linenum); + if (arg[0] < '0' || arg[0] > '9') + fatal("%.200s line %d: Bad number.", filename, linenum); + + /* Octal, decimal, or hex format? */ + value = strtol(arg, &endofnumber, 0); + if (arg == endofnumber) + fatal("%.200s line %d: Bad number.", filename, linenum); + if (*activep && *intptr == -1) + *intptr = value; + if (options->bogus_traffic_interval_max <= value) + fatal("%.200s line %d: Bad value.", filename, linenum); + break; + case oNumberOfPasswordPrompts: intptr = &options->number_of_password_prompts; goto parse_int; @@ -738,6 +776,8 @@ options->strict_host_key_checking = -1; options->compression = -1; options->keepalives = -1; + options->bogus_traffic_interval_max = -1; + options->bogus_traffic_interval_min = -1; options->compression_level = -1; options->port = -1; options->connection_attempts = -1; @@ -825,6 +865,10 @@ options->compression = 0; if (options->keepalives == -1) options->keepalives = 1; + if (options->bogus_traffic_interval_max == -1) + options->bogus_traffic_interval_max = 0; + if (options->bogus_traffic_interval_min == -1) + options->bogus_traffic_interval_min = 0; if (options->compression_level == -1) options->compression_level = 6; if (options->port == -1) diff -ur openssh-2.9p2/readconf.h openssh-2.9p2.servalive/readconf.h --- openssh-2.9p2/readconf.h Tue Apr 17 20:11:37 2001 +++ openssh-2.9p2.servalive/readconf.h Wed Sep 26 13:36:16 2001 @@ -62,6 +62,14 @@ int compression_level; /* Compression level 1 (fast) to 9 * (best). */ int keepalives; /* Set SO_KEEPALIVE. */ + int bogus_traffic_interval_max; /* + * max time value of SSH_MSG_IGNORE + * interval + */ + int bogus_traffic_interval_min; /* + * min time value of SSH_MSG_IGNORE + * interval + */ LogLevel log_level; /* Level for logging. */ int port; /* Port to connect. */ From mouring at etoh.eviladmin.org Thu Sep 27 00:26:07 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 26 Sep 2001 09:26:07 -0500 (CDT) Subject: SIGCHLD race condition? (fwd) In-Reply-To: Message-ID: On Wed, 26 Sep 2001, Paul Menage wrote: > - Switch to using queued signals for network readiness events, then use > sigtimedwait() or similar instead of select(). I imagine that this would > be a fairly major overhaul of the networking code. > And how does one emulate sigtimedwait() for those older platforms that lack it? I don't remember seeing it listed in the NeXTStep manpages. - Ben From djm at mindrot.org Thu Sep 27 00:45:46 2001 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Sep 2001 00:45:46 +1000 (EST) Subject: [PATCH] random SSH_MSG_IGNORE packets In-Reply-To: <20010926134002.A8295@fatbob.nu> Message-ID: On Wed, 26 Sep 2001, Martin Johansson wrote: > Hi! > > The following patch adds ability to configure the ssh client to > send SSH[2]_MSG_IGNORE packets of random length at random times > whithin a user-specified interval. The function is configured by > setting the config-file options BogusTrafficIntervalMax and > BogusTrafficIntervalMin, which defines the interval in seconds in > which the packets are randomly sent. It is disabled by default. It > suffices to set the Max value to enable the function. The Min then > defaults to 0. The packet size is not configurable, but hardcoded to > be random between 1-64 bytes. > > The patch does not include any man-page update, but if this is > something that may go into the main tree, I could put something > together. It won't fool traffic analysis very well - most interactive packets will elicit a reply from the other end as keystrokes are echoed. If you want to defeat traffic analysis you must also fake this. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From pmenage at ensim.com Thu Sep 27 03:30:42 2001 From: pmenage at ensim.com (Paul Menage) Date: Wed, 26 Sep 2001 10:30:42 -0700 Subject: SIGCHLD race condition? In-Reply-To: Your message of "Wed, 26 Sep 2001 09:26:07 CDT." Message-ID: > > >On Wed, 26 Sep 2001, Paul Menage wrote: > >> - Switch to using queued signals for network readiness events, then use >> sigtimedwait() or similar instead of select(). I imagine that this would >> be a fairly major overhaul of the networking code. >> > >And how does one emulate sigtimedwait() for those older platforms that >lack it? I don't remember seeing it listed in the NeXTStep manpages. So scrap that idea then - it's more of a change than I'd think people would want anyway. How about the pipe solution? That should be relatively portable. Paul From Nicolas.Williams at ubsw.com Thu Sep 27 03:44:38 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 26 Sep 2001 13:44:38 -0400 Subject: SIGCHLD race condition? In-Reply-To: ; from pmenage@ensim.com on Wed, Sep 26, 2001 at 10:30:42AM -0700 References: Message-ID: <20010926134430.C5739@sm2p1386swk.wdr.com> How about: - selecting for exceptions -- remove dead fildeses from the read/write select masks (will this catch ptys where the child has close its stdio?) - if select() will be called only with the client connection socket, then the child must have closed its stdio -- either check wether the child is alive or add a timeout to the select() or plain and simply exit. Nico On Wed, Sep 26, 2001 at 10:30:42AM -0700, Paul Menage wrote: > > > > > >On Wed, 26 Sep 2001, Paul Menage wrote: > > > >> - Switch to using queued signals for network readiness events, then use > >> sigtimedwait() or similar instead of select(). I imagine that this would > >> be a fairly major overhaul of the networking code. > >> > > > >And how does one emulate sigtimedwait() for those older platforms that > >lack it? I don't remember seeing it listed in the NeXTStep manpages. > > So scrap that idea then - it's more of a change than I'd think people > would want anyway. > > How about the pipe solution? That should be relatively portable. > > Paul -- 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 pmenage at ensim.com Thu Sep 27 04:07:27 2001 From: pmenage at ensim.com (Paul Menage) Date: Wed, 26 Sep 2001 11:07:27 -0700 Subject: SIGCHLD race condition? In-Reply-To: Your message of "Wed, 26 Sep 2001 13:44:38 EDT." <20010926134430.C5739@sm2p1386swk.wdr.com> Message-ID: >How about: > > - selecting for exceptions -- remove dead fildeses from the read/write > select masks (will this catch ptys where the child has close its > stdio?) > > - if select() will be called only with the client connection socket, > then the child must have closed its stdio -- either check wether the > child is alive or add a timeout to the select() or plain and simply > exit. > In the situation in question, both channels to the child have been closed, and the server knows this. wait_until_can_do_something() does check whether the child has exited, but there's a window between the check and the call to select() that can cause lockups. The server can't exit until it knows that the child has exited, as otherwise it can't return the child's exit status to the client. Adding a maximum 10 second timeout to select() is the temporary solution that we're using, as the problem occurs rarely enough that waiting 10 seconds occasionally isn't a problem. Paul From Nicolas.Williams at ubsw.com Thu Sep 27 04:20:48 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Wed, 26 Sep 2001 14:20:48 -0400 Subject: SIGCHLD race condition? In-Reply-To: ; from Paul Menage on Wed, Sep 26, 2001 at 11:07:27AM -0700 References: <20010926134430.C5739@sm2p1386swk.wdr.com> Message-ID: <20010926142048.S26615@wdr.com> I see. Well, it seems that the fundamental problem is that select() can't be interrupted when the child exits, no? You can't have SIGCHLD unblock when select() is called... The pipe solution looks like it would be the most elegant... The 10 second select() timeout is not too ugly a solution either. It's only needed when the child fds are closed and you're waiting for input from the client and for the child to exit. Nico On Wed, Sep 26, 2001 at 11:07:27AM -0700, Paul Menage wrote: > >How about: > > > > - selecting for exceptions -- remove dead fildeses from the read/write > > select masks (will this catch ptys where the child has close its > > stdio?) > > > > - if select() will be called only with the client connection socket, > > then the child must have closed its stdio -- either check wether the > > child is alive or add a timeout to the select() or plain and simply > > exit. > > > > In the situation in question, both channels to the child have been > closed, and the server knows this. wait_until_can_do_something() does > check whether the child has exited, but there's a window between the > check and the call to select() that can cause lockups. > > The server can't exit until it knows that the child has exited, as > otherwise it can't return the child's exit status to the client. Adding > a maximum 10 second timeout to select() is the temporary solution that > we're using, as the problem occurs rarely enough that waiting 10 seconds > occasionally isn't a problem. > > Paul -- -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 stevesk at pobox.com Thu Sep 27 04:37:45 2001 From: stevesk at pobox.com (Kevin Steves) Date: Wed, 26 Sep 2001 11:37:45 -0700 (PDT) Subject: Today's CVS trouble (HP-UX 10.20) In-Reply-To: <20010926121220.A9459@serv01.aet.tu-cottbus.de> Message-ID: On Wed, 26 Sep 2001, Lutz Jaenicke wrote: :I will update my systems to 2.9.9p2 for production use. Largefile support :is left for later investigation... can people tracking CVS try this? Index: loginrec.c =================================================================== RCS file: /var/cvs/openssh/loginrec.c,v retrieving revision 1.34 diff -u -r1.34 loginrec.c --- loginrec.c 2001/08/06 23:29:17 1.34 +++ loginrec.c 2001/09/26 18:30:22 @@ -1095,7 +1095,7 @@ } /* Seek to the start of the last struct utmp */ - if (lseek(fd, (off_t)(0 - sizeof(struct utmp)), SEEK_END) == -1) { + if (lseek(fd, -(off_t)sizeof(struct utmp), SEEK_END) == -1) { /* Looks like we've got a fresh wtmp file */ close(fd); return 0; @@ -1128,7 +1128,7 @@ continue; } /* Seek back 2 x struct utmp */ - if (lseek(fd, (off_t)(0-2*sizeof(struct utmp)), SEEK_CUR) == -1) { + if (lseek(fd, -(off_t)(2 * sizeof(struct utmp)), SEEK_CUR) == -1) { /* We've found the start of the file, so quit */ close (fd); return 0; @@ -1251,7 +1251,7 @@ } /* Seek to the start of the last struct utmpx */ - if (lseek(fd, (off_t)(0-sizeof(struct utmpx)), SEEK_END) == -1 ) { + if (lseek(fd, -(off_t)sizeof(struct utmpx), SEEK_END) == -1 ) { /* probably a newly rotated wtmpx file */ close(fd); return 0; @@ -1281,7 +1281,7 @@ # endif continue; } - if (lseek(fd, (off_t)(0-2*sizeof(struct utmpx)), SEEK_CUR) == -1) { + if (lseek(fd, -(off_t)(2 * sizeof(struct utmpx)), SEEK_CUR) == -1) { close (fd); return 0; } @@ -1424,7 +1424,7 @@ if (type == LL_FILE) { /* find this uid's offset in the lastlog file */ - offset = (off_t) ( (long)li->uid * sizeof(struct lastlog)); + offset = (off_t) ((long)li->uid * sizeof(struct lastlog)); if ( lseek(*fd, offset, SEEK_SET) != offset ) { log("lastlog_openseek: %s->lseek(): %s", From pmenage at ensim.com Thu Sep 27 04:34:58 2001 From: pmenage at ensim.com (Paul Menage) Date: Wed, 26 Sep 2001 11:34:58 -0700 Subject: SIGCHLD race condition? In-Reply-To: Your message of "Wed, 26 Sep 2001 14:20:48 EDT." <20010926142048.S26615@wdr.com> Message-ID: >I see. Well, it seems that the fundamental problem is that select() >can't be interrupted when the child exits, no? You can't have SIGCHLD >unblock when select() is called... The SIGCHLD has already arrived by the time select() is called - it arrives in the gap between checking child_terminated and calling select(). It's a very small race, but one that we've seen occur sometimes. (Or if this isn't the race that's biting us, there's another race that can produce exactly the same symptoms.) Paul From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Sep 27 05:59:51 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Wed, 26 Sep 2001 21:59:51 +0200 Subject: Today's CVS trouble (HP-UX 10.20) In-Reply-To: ; from stevesk@pobox.com on Wed, Sep 26, 2001 at 11:37:45AM -0700 References: <20010926121220.A9459@serv01.aet.tu-cottbus.de> Message-ID: <20010926215951.A18255@serv01.aet.tu-cottbus.de> On Wed, Sep 26, 2001 at 11:37:45AM -0700, Kevin Steves wrote: > On Wed, 26 Sep 2001, Lutz Jaenicke wrote: > :I will update my systems to 2.9.9p2 for production use. Largefile support > :is left for later investigation... > > can people tracking CVS try this? Looks good. The error message is gone. 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 markus at openbsd.org Thu Sep 27 07:05:19 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Sep 2001 23:05:19 +0200 Subject: OpenSSH 2.9.9 Message-ID: <20010926230519.A4478@folly> OpenSSH 2.9.9 has just been uploaded. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH 2.9.9 fixes a weakness in the key file option handling, including source IP based access control. 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. Security Notes: =============== This release fixes weakness in the source IP based access control for SSH protocol v2 public key authentication: Versions of OpenSSH between 2.5 and 2.9.9 are affected if they use the 'from=' key file option in combination with both RSA and DSA keys in ~/.ssh/authorized_keys2. Depending on the order of the user keys in ~/.ssh/authorized_keys2 sshd might fail to apply the source IP based access control restriction (e.g. from="10.0.0.1") to the correct key: If a source IP restricted key (e.g. DSA key) is immediately followed by a key of a different type (e.g. RSA key), then key options for the second key are applied to both keys, which includes 'from='. This means that users can circumvent the system policy and login from disallowed source IP addresses. Important Changes: ================== OpenSSH 2.9.9 might have upgrade issues introduced by the long time between releases, which may affect people in unforseen ways: 1) 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 is still used for authentication and hostkeys are still read from the known_hosts2. However, old files are considered 'readonly'. Future releases are likely to not read these files. 2) The CheckMail option in sshd_config is deprecated, sshd no longer checks for new mail. 3) X11 cookies are stored in $HOME OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller and Ben Lindstrom. From markus at openbsd.org Thu Sep 27 07:18:23 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Sep 2001 23:18:23 +0200 Subject: OpenSSH Security Advisory (adv.option) Message-ID: <20010926231823.A15229@folly> Weakness in OpenSSH's source IP based access control for SSH protocol v2 public key authentication. 1. Systems affected: Versions of OpenSSH between 2.5.x and 2.9.x using the 'from=' key file option in combination with both RSA and DSA keys in ~/.ssh/authorized_keys2. 2. Description: Depending on the order of the user keys in ~/.ssh/authorized_keys2 sshd might fail to apply the source IP based access control restriction (e.g. from="10.0.0.1") to the correct key: If a source IP restricted key (e.g. DSA key) is immediately followed by a key of a different type (e.g. RSA key), then key options for the second key are applied to both keys, which includes 'from='. 3. Impact: Users can circumvent the system policy and login from disallowed source IP addresses. 4. Solution: Apply the following patch. This bug is fixed in OpenSSH 2.9.9 5. Credits: None. Appendix: Index: key.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/key.c,v retrieving revision 1.31 retrieving revision 1.32 diff -u -p -IRCSID -r1.31 -r1.32 --- key.c 2001/09/17 20:50:22 1.31 +++ key.c 2001/09/19 13:23:29 1.32 @@ -358,7 +358,7 @@ write_bignum(FILE *f, BIGNUM *num) return 1; } -/* returns 1 ok, -1 error, 0 type mismatch */ +/* returns 1 ok, -1 error */ int key_read(Key *ret, char **cpp) { @@ -413,7 +413,7 @@ key_read(Key *ret, char **cpp) } else if (ret->type != type) { /* is a key, but different type */ debug3("key_read: type mismatch"); - return 0; + return -1; } len = 2*strlen(cp); blob = xmalloc(len); From Austin.David at wink.com Thu Sep 27 08:07:00 2001 From: Austin.David at wink.com (Austin.David at wink.com) Date: Wed, 26 Sep 2001 15:07:00 -0700 Subject: openssh-2.9.9p2 session.c fails on Solaris 7,8 w/ SunPro C Message-ID: FYI-- session.c fails from openSSH 2.9.9p2 with SunPro C compiler on Solaris 7, 8. The function do_pre_login had to be moved to before its use in do_exec_pty (a predeclaration would work). It does appear to work correctly, given the above fix. Still having the largefile problem (argh), so if anyone can help with /that/ ... -- Austin David -- Sr. Systems Architect Wink Communications Austin.David at Wink.com (510) 337-6334 From simon at sxw.org.uk Thu Sep 27 10:34:15 2001 From: simon at sxw.org.uk (Simon Wilkinson) Date: Thu, 27 Sep 2001 01:34:15 +0100 Subject: Kerberos in OpenSsh 2.9.9p2 Message-ID: <01092701341509.04795@loki.dcs.ed.ac.uk> I note with interest that Kerberos support is now available (for the version 1 protocol, at least) in OpenSSH 2.9.9p2. However, it does not build with MIT Kerberos, due to the usual Heimdal/MIT library differences. These look, by and large, like the same problems I encountered when porting Dan Kouril's patch to MIT Kerberos - so I'm having a go at fixing them (my GSSAPI patches need to use the KRB5 define too :-) If I package these fixes up and submit them, is there any likelihood of them making it into the portable code (suitably #ifdef'd, of course)? Cheers, Simon. -- Simon Wilkinson http://www.sxw.org.uk "I have never made but one prayer to God, a very short one: 'O Lord, make my enemies ridiculous.' And God granted it" - Voltaire From wayned at users.sourceforge.net Thu Sep 27 10:44:35 2001 From: wayned at users.sourceforge.net (Wayne Davison) Date: Wed, 26 Sep 2001 17:44:35 -0700 (PDT) Subject: openssh-2.9.9p2 session.c fails on Solaris 7,8 w/ SunPro C In-Reply-To: Message-ID: On Wed, 26 Sep 2001 Austin.David at wink.com wrote: > session.c fails from openSSH 2.9.9p2 with SunPro C compiler on Solaris 7, > 8. The function do_pre_login had to be moved to before its use in > do_exec_pty (a predeclaration would work). Yeah, I mentioned this problem on the list before 2.9.9 was released (along with some changes that have been languishing since June), but sadly, none of my patches were applied to the source. This is very frustrating. It often feels like I'm talking in an empty room. [Tapping on the mike] Hello? Is this thing on? ..wayne.. From mouring at etoh.eviladmin.org Thu Sep 27 11:26:30 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Wed, 26 Sep 2001 20:26:30 -0500 (CDT) Subject: Kerberos in OpenSsh 2.9.9p2 In-Reply-To: <01092701341509.04795@loki.dcs.ed.ac.uk> Message-ID: Sure.. - Ben On Thu, 27 Sep 2001, Simon Wilkinson wrote: > > I note with interest that Kerberos support is now available (for the version > 1 protocol, at least) in OpenSSH 2.9.9p2. However, it does not build with MIT > Kerberos, due to the usual Heimdal/MIT library differences. These look, by > and large, like the same problems I encountered when porting Dan Kouril's > patch to MIT Kerberos - so I'm having a go at fixing them (my GSSAPI patches > need to use the KRB5 define too :-) > > If I package these fixes up and submit them, is there any likelihood of them > making it into the portable code (suitably #ifdef'd, of course)? > > Cheers, > > Simon. > -- > Simon Wilkinson http://www.sxw.org.uk > "I have never made but one prayer to God, a very short one: 'O Lord, make my > enemies ridiculous.' And God granted it" - Voltaire > > From sfrost at snowman.net Thu Sep 27 12:14:10 2001 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 26 Sep 2001 22:14:10 -0400 Subject: Kerberos in OpenSsh 2.9.9p2 In-Reply-To: ; from mouring@etoh.eviladmin.org on Wed, Sep 26, 2001 at 08:26:30PM -0500 References: <01092701341509.04795@loki.dcs.ed.ac.uk> Message-ID: <20010926221410.C25841@ns> * mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) wrote: > > Sure.. And please do... :) Stephen, who doesn't have any say in it, but uses the patches from your website (Thanks!). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20010926/21dc6d47/attachment.bin From openssh-unix-dev at progressive-comp.com Thu Sep 27 14:57:32 2001 From: openssh-unix-dev at progressive-comp.com (Hank Leininger) Date: Thu, 27 Sep 2001 00:57:32 -0400 Subject: OpenSSH 2.9.9 Message-ID: <200109270457.AAA10595@mailer.progressive-comp.com> On 2001-09-26, Markus Friedl wrote: > OpenSSH 2.9.9 has just been uploaded. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. [snip] > Security Notes: > =============== > > This release fixes weakness in the source IP based access control > for SSH protocol v2 public key authentication: I think it's worth mentioning that (according to changelog entries from 20010914) this release also includes the 'keys restricted with command=xxx still allow subsystems such as sftp' fix. -- Hank Leininger From hin at stacken.kth.se Thu Sep 27 18:17:16 2001 From: hin at stacken.kth.se (Hans Insulander) Date: 27 Sep 2001 10:17:16 +0200 Subject: Kerberos in OpenSsh 2.9.9p2 In-Reply-To: Simon Wilkinson's message of "Thu, 27 Sep 2001 01:34:15 +0100" References: <01092701341509.04795@loki.dcs.ed.ac.uk> Message-ID: <86bsjx82ur.fsf@stacken.kth.se> Simon Wilkinson writes: > I note with interest that Kerberos support is now available (for the version > 1 protocol, at least) in OpenSSH 2.9.9p2. However, it does not build with MIT > Kerberos, due to the usual Heimdal/MIT library differences. These look, by > and large, like the same problems I encountered when porting Dan Kouril's > patch to MIT Kerberos - so I'm having a go at fixing them (my GSSAPI patches > need to use the KRB5 define too :-) > > If I package these fixes up and submit them, is there any likelihood of them > making it into the portable code (suitably #ifdef'd, of course)? Please get the MIT people, Heimdal people and the Kerberos community to define and implement a common API instead. Maintaining #ifdefs is a RPITA. -- --- Hans Insulander , SM0UTY ----------------------- Lazy bum bum slacker -- Theo de Raadt From markus at openbsd.org Thu Sep 27 18:48:28 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 27 Sep 2001 10:48:28 +0200 Subject: OpenSSH 2.9.9 In-Reply-To: <200109270457.AAA10595@mailer.progressive-comp.com>; from openssh-unix-dev@progressive-comp.com on Thu, Sep 27, 2001 at 12:57:32AM -0400 References: <200109270457.AAA10595@mailer.progressive-comp.com> Message-ID: <20010927104828.A28032@folly> On Thu, Sep 27, 2001 at 12:57:32AM -0400, Hank Leininger wrote: > On 2001-09-26, Markus Friedl wrote: > > > OpenSSH 2.9.9 has just been uploaded. It will be available from the > > mirrors listed at http://www.openssh.com/ shortly. > [snip] > > Security Notes: > > =============== > > > > This release fixes weakness in the source IP based access control > > for SSH protocol v2 public key authentication: > > I think it's worth mentioning that (according to changelog entries from > 20010914) this release also includes the 'keys restricted with command=xxx > still allow subsystems such as sftp' fix. not all bug fixes are mentioned in the annoucement. From hlein at progressive-comp.com Thu Sep 27 20:03:19 2001 From: hlein at progressive-comp.com (Hank Leininger) Date: Thu, 27 Sep 2001 06:03:19 -0400 (EDT) Subject: OpenSSH 2.9.9 In-Reply-To: <20010927104828.A28032@folly> Message-ID: <010109270549380.28346-100000@marc1.theaimsgroup.com> On Thu, 27 Sep 2001, Markus Friedl wrote: > On Thu, Sep 27, 2001 at 12:57:32AM -0400, Hank Leininger wrote: > > I think it's worth mentioning that (according to changelog entries > > from 20010914) this release also includes the 'keys restricted with > > command=xxx still allow subsystems such as sftp' fix. > > not all bug fixes are mentioned in the annoucement. No, true ;) But in my environments anyway, the bypassing of command="" restrictions had much larger potential impact than the bug in from="" restrictions, even if the former was arguably not even a bug, just an interestingly undocumented feature/commonly misunderstood interaction ;) Thus I was surprised it was not mentioned in the announcement (which actually says 'fixes a weakness in the key file option handling...' ^^^), did the homework to confirm it was indeed in (and hadn't been pulled, or not merged from the OpenBSD version in time for some reason, or whatever) and thought I'd save other inquiring minds the trouble. Maybe I just need more sleep. :-P Thanks, Hank Leininger E407 AEF4 761E D39C D401 D4F4 22F8 EF11 861A A6F1 From simon at sxw.org.uk Thu Sep 27 20:11:28 2001 From: simon at sxw.org.uk (Simon Wilkinson) Date: Thu, 27 Sep 2001 11:11:28 +0100 Subject: Kerberos in OpenSsh 2.9.9p2 In-Reply-To: <86bsjx82ur.fsf@stacken.kth.se> References: <01092701341509.04795@loki.dcs.ed.ac.uk> <86bsjx82ur.fsf@stacken.kth.se> Message-ID: <0109271111280B.04795@loki.dcs.ed.ac.uk> On Thursday 27 September 2001 09:17, Hans Insulander wrote: > Please get the MIT people, Heimdal people and the Kerberos community to > define and implement a common API instead. Maintaining #ifdefs is a RPITA. But easier in the short term :-) I think that there are two issues. The first is functions that exist in both the MIT code and the Heimdal code, but take different arguments. There are also data structures with the same name, but different structures. This obviously needs fixing. The second is that Heimdal has a number of "helper" functions which MIT Kerberos doesn't have - these perform the actions of a number of MIT library calls in one handy function. It is possible to code without using these, and instead use the MIT compatible calls. In any case, I've now got a patch that compiles - it just requires further testing. There are some interesting bits in the code - for instance Kerberos authentication appears to be only enabled if a Kerberos 4 srvtab is found (servconf.c). I'm also concerned about the credentials cache handling. It appears to create a file based credentials cache before the users permission to access the system has been established. Is it not better to use a memory cache whilst proving the users identity, and only copy the credentials to disk once the krb5_kuserok checks have been satisfied? Cheers, Simon. -- Simon Wilkinson http://www.sxw.org.uk "I love deadlines. I like the whooshing sound they make as they fly by. " - Douglas Adams From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Sep 27 20:33:36 2001 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 27 Sep 2001 12:33:36 +0200 Subject: OpenSSH 2.9.9 In-Reply-To: <20010926230519.A4478@folly>; from markus@openbsd.org on Wed, Sep 26, 2001 at 11:05:19PM +0200 References: <20010926230519.A4478@folly> Message-ID: <20010927123336.A20742@ws01.aet.tu-cottbus.de> On Wed, Sep 26, 2001 at 11:05:19PM +0200, Markus Friedl wrote: ... > OpenSSH 2.9.9 might have upgrade issues introduced by the long time > between releases, which may affect people in unforseen ways: > > 1) 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 is still used for > authentication and hostkeys are still read from the known_hosts2. > However, old files are considered 'readonly'. Future releases are > likely to not read these files. Therefore I should do (symbolically): cat /etc/ssh/ssh_known_hosts /etc/ssh/ssh_known_hosts2 >/etc/ssh/ssh_known_hosts !? 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 markus at openbsd.org Thu Sep 27 20:59:07 2001 From: markus at openbsd.org (Markus Friedl) Date: Thu, 27 Sep 2001 12:59:07 +0200 Subject: OpenSSH 2.9.9 In-Reply-To: <20010927123336.A20742@ws01.aet.tu-cottbus.de>; from Lutz.Jaenicke@aet.TU-Cottbus.DE on Thu, Sep 27, 2001 at 12:33:36PM +0200 References: <20010926230519.A4478@folly> <20010927123336.A20742@ws01.aet.tu-cottbus.de> Message-ID: <20010927125907.B11782@faui02.informatik.uni-erlangen.de> On Thu, Sep 27, 2001 at 12:33:36PM +0200, Lutz Jaenicke wrote: > Therefore I should do (symbolically): > > cat /etc/ssh/ssh_known_hosts /etc/ssh/ssh_known_hosts2 >/etc/ssh/ssh_known_hosts yes. and rm -f /etc/ssh/ssh_known_hosts2 From chombier at mac.com Thu Sep 27 21:33:07 2001 From: chombier at mac.com (Jean-Pierre) Date: Thu, 27 Sep 2001 13:33:07 +0200 Subject: OpenSSH 2.9p2 bugs Message-ID: <3bb30e763bb98044@antholoma.wanadoo.fr> (added by antholoma.wanadoo.fr) Howdy, I've found two bugs in the OpenSSH 2.9p2 source code. I had a look into the latest source-tree available at openssh.com, and they seem still there: -- 'incoming_stream' is used in place of 'outgoing_stream', file compress.c, line 36: void buffer_compress_init_send(int level) { if (compress_init_send_called == 1) deflateEnd(&incoming_stream); ****** should be &outgoing_stream compress_init_send_called = 1; debug("Enabling compression at level %d.", level); if (level < 1 || level > 9) fatal("Bad compression level %d.", level); deflateInit(&outgoing_stream, level); } -- 'called' is never set, file packet.c, line 1325: int packet_set_maxsize(int s) { static int called = 0; if (called) { log("packet_set_maxsize: called twice: old %d new %d", max_packet_size, s); return -1; } if (s < 4 * 1024 || s > 1024 * 1024) { log("packet_set_maxsize: bad size %d", s); return -1; } ****** missing: called = 1; log("packet_set_maxsize: setting to %d", s); max_packet_size = s; return s; } cheers, - Jean-Pierre. From carson at taltos.org Thu Sep 27 23:40:09 2001 From: carson at taltos.org (Carson Gaspar) Date: Thu, 27 Sep 2001 09:40:09 -0400 Subject: SIGCHLD race condition? In-Reply-To: References: Message-ID: <133337148.1001583608@CJECW95G6PXXT> There is another race (from serverloop.c): if (child_terminated) { while ((pid = waitpid(-1, &status, WNOHANG)) > 0) session_close_by_pid(pid, status); child_terminated = 0; } It is possible to loose a child under the following situation: - wait for all children - receive SIGCHLD, handler sets child_terminated to 1 - main code sets child_terminated to 0 You must block SIGCHLD delivery before the while loop, and unblock after the assignment. NOTE: You'll _probably_ only ever see this race on SMP systems, and even then the race is very small. -- Carson From Nicolas.Williams at ubsw.com Thu Sep 27 23:45:32 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 27 Sep 2001 09:45:32 -0400 Subject: Kerberos in OpenSsh 2.9.9p2 In-Reply-To: <01092701341509.04795@loki.dcs.ed.ac.uk>; from simon@sxw.org.uk on Thu, Sep 27, 2001 at 01:34:15AM +0100 References: <01092701341509.04795@loki.dcs.ed.ac.uk> Message-ID: <20010927094531.D5739@sm2p1386swk.wdr.com> Look in the Linux-PAM CVS repository at SourceForge. In the devl branch of the PAM_KRB5 module you'll find some Heimdal/MIT compatibility shims. This module is dual licensed, GPL/BSD (or will be soon -- I think the devl COPYRIGHT file has the MIT license currently). Nico On Thu, Sep 27, 2001 at 01:34:15AM +0100, Simon Wilkinson wrote: > > I note with interest that Kerberos support is now available (for the version > 1 protocol, at least) in OpenSSH 2.9.9p2. However, it does not build with MIT > Kerberos, due to the usual Heimdal/MIT library differences. These look, by > and large, like the same problems I encountered when porting Dan Kouril's > patch to MIT Kerberos - so I'm having a go at fixing them (my GSSAPI patches > need to use the KRB5 define too :-) > > If I package these fixes up and submit them, is there any likelihood of them > making it into the portable code (suitably #ifdef'd, of course)? > > Cheers, > > Simon. > -- > Simon Wilkinson http://www.sxw.org.uk > "I have never made but one prayer to God, a very short one: 'O Lord, make my > enemies ridiculous.' And God granted it" - Voltaire -- 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 djm at mindrot.org Fri Sep 28 00:18:54 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 28 Sep 2001 00:18:54 +1000 (EST) Subject: libsectok and sectok RPMs Message-ID: For people interested in playing with the Smartcard support in recent OpenSSH, I have built source RPMs of libsectok and sectok. Currently only the Todos reader driver is included, but I am happy to accept patches :) http://www.mindrot.org/~djm/sectok/ The RPMS build, install and function on Redhat Roswell (7.2 beta) YMMV -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From pekkas at netcore.fi Fri Sep 28 01:50:41 2001 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 27 Sep 2001 18:50:41 +0300 (EEST) Subject: RHL: %noreplace sshd_config [Re: Call for testers.] In-Reply-To: Message-ID: On Sat, 15 Sep 2001, Damien Miller wrote: > On Sat, 15 Sep 2001, Pekka Savola wrote: > > > 1) it would be nice if the init scripts took advantage of the new sshd -t > > feature. Patch attached. The failure will look like: > > APplied. Now that '-t' is in use in the updated /etc/rc.d/init.d/sshd:restart, I think it's getting safe to go back to %attr(noreplace) sshd_config. -- 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 -------------- next part -------------- Index: openssh.spec =================================================================== RCS file: /cvs/openssh_cvs/contrib/redhat/openssh.spec,v retrieving revision 1.86 diff -u -r1.86 openssh.spec --- openssh.spec 2001/09/26 14:24:21 1.86 +++ openssh.spec 2001/09/27 15:51:33 @@ -264,8 +264,7 @@ %attr(0755,root,root) %{_libexecdir}/openssh/sftp-server %attr(0644,root,root) %{_mandir}/man8/sshd.8* %attr(0644,root,root) %{_mandir}/man8/sftp-server.8* -#%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config -%attr(0600,root,root) %config %{_sysconfdir}/sshd_config +%attr(0600,root,root) %config(noreplace) %{_sysconfdir}/sshd_config %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd %attr(0755,root,root) %config /etc/rc.d/init.d/sshd From rschultz at triton-network.com Fri Sep 28 02:03:03 2001 From: rschultz at triton-network.com (Robert W. Schultz) Date: Thu, 27 Sep 2001 09:03:03 -0700 Subject: Logging authorized key info Message-ID: <3BB34DB7.FD6B6189@triton-network.com> Hi, I would like to be able to log the key/fingerprint/comment field or even line number (pick one) from the authorized_keys file of the account connected to. So I would get a syslog entry something like this... [ID 800047 auth.info] Accepted rsa for ROOT from 127.0.0.1 port 34352 instead of [ID 800047 auth.info] Accepted rsa for ROOT from 127.0.0.1 port 34352 I know this has been discussed before, there is a patch to do this for version 1.something but I can't fathom how this moved into version 2.anything. Any help would be greatly appreciated. Thanks Bob From Nicolas.Williams at ubsw.com Fri Sep 28 02:27:23 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Thu, 27 Sep 2001 12:27:23 -0400 Subject: Logging authorized key info In-Reply-To: <3BB34DB7.FD6B6189@triton-network.com>; from rschultz@triton-network.com on Thu, Sep 27, 2001 at 09:03:03AM -0700 References: <3BB34DB7.FD6B6189@triton-network.com> Message-ID: <20010927122722.E5739@sm2p1386swk.wdr.com> The key name field from the authorized_keys entry (or, missing that, the public key fingerprint) should be logged. Also, whichever is logged should be set as the value of some environment variable. This is what I do in my named keys patch for OpenSSH w/ Simon Wilkinson's GSS-API patch for OpenSSH. It's quite useful, particularly for command= authorized_keys entries. Nico On Thu, Sep 27, 2001 at 09:03:03AM -0700, Robert W. Schultz wrote: > Hi, > > I would like to be able to log the key/fingerprint/comment field or even > line number (pick one) from the authorized_keys file of the account > connected to. So I would get a syslog entry something like this... > > [ID 800047 auth.info] Accepted rsa for > ROOT from 127.0.0.1 port 34352 > > instead of > > [ID 800047 auth.info] Accepted rsa for ROOT from 127.0.0.1 port 34352 > > I know this has been discussed before, there is a patch to do this for > version 1.something but I can't fathom how this moved into version > 2.anything. > > Any help would be greatly appreciated. > > > Thanks > > Bob -- 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 peterw at usa.net Fri Sep 28 02:48:51 2001 From: peterw at usa.net (Peter W) Date: Thu, 27 Sep 2001 12:48:51 -0400 Subject: Logging authorized key info In-Reply-To: <20010927122722.E5739@sm2p1386swk.wdr.com>; from Nicolas.Williams@ubsw.com on Thu, Sep 27, 2001 at 12:27:23PM -0400 References: <3BB34DB7.FD6B6189@triton-network.com> <20010927122722.E5739@sm2p1386swk.wdr.com> Message-ID: <20010927124851.D24044@usa.net> On Thu, Sep 27, 2001 at 12:27:23PM -0400, Nicolas Williams wrote: > The key name field from the authorized_keys entry (or, missing that, the > public key fingerprint) should be logged. Do you mean the comment field? Since that's user-supplied, is there any concern about mischievous values? A hex-encoded fingerprint value on the other hand would always be safe/predictable & relatively short. > Also, whichever is logged should be set as the value of some environment > variable. I like this idea. Currently I have some command= tools that have hard links and behave differently based on the name referenced in command=. It would be cleaner if I had only one file name, but the behavior depended on the identity being used to invoke the tool. -Peter > It's quite useful, particularly for command= authorized_keys entries. > On Thu, Sep 27, 2001 at 09:03:03AM -0700, Robert W. Schultz wrote: > > I would like to be able to log the key/fingerprint/comment field or even > > line number (pick one) from the authorized_keys file of the account > > connected to. So I would get a syslog entry something like this... > > > > [ID 800047 auth.info] Accepted rsa for > > ROOT from 127.0.0.1 port 34352 From f_mohr at yahoo.de Fri Sep 28 03:35:16 2001 From: f_mohr at yahoo.de (Frank Mohr) Date: Thu, 27 Sep 2001 19:35:16 +0200 Subject: Logging authorized key info References: <3BB34DB7.FD6B6189@triton-network.com> <20010927122722.E5739@sm2p1386swk.wdr.com> <20010927124851.D24044@usa.net> Message-ID: <3BB36354.4E2DE3ED@yahoo.de> Peter W wrote: > > On Thu, Sep 27, 2001 at 12:27:23PM -0400, Nicolas Williams wrote: > > > The key name field from the authorized_keys entry (or, missing that, the > > public key fingerprint) should be logged. > > Do you mean the comment field? Since that's user-supplied, is there any > concern about mischievous values? A hex-encoded fingerprint value on the > other hand would always be safe/predictable & relatively short. > It's not in all cases user supplied - On our servers we use a nightly root cron job to fill the authorized_keys files from an LDAP server and set the comment field to unique values. The authorized_keys is only writable for root. I've patched the server to log that comment field to syslog and to set an environment variable (SSH_ORIGINAL_USER) to that value (I use that variable for a command="" started relay software) I still have to split my patch file into logical pieces (logging, AIX SRC and some data type fixes) .. I'll post it after my holidays. Nevertheless an additional fingerprint log would be nice. (not only to give something new to our "security auditing department" ;-) Frank From eggert at twinsun.com Fri Sep 28 04:03:21 2001 From: eggert at twinsun.com (Paul Eggert) Date: Thu, 27 Sep 2001 11:03:21 -0700 (PDT) Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX Message-ID: <200109271803.f8RI3LE02609@shade.twinsun.com> openssh-2.9.9p2/configure.in says: # Disabled until it works on SCO and HPUX #AC_SYS_LARGEFILE As an autoconf maintainer I'd like to fix this. Can you please explain what's broken on SCO and HPUX? I'm puzzled by the comment, as AC_SYS_LARGEFILE is a feature introduced in autoconf 2.50, whereas openssh-2.9.9p2/configure was built with autoconf 2.13. Anyway, some older GNU software came with implementations of AC_SYS_LARGEFILE that had problems on HPUX, but these problems should all be fixed in the current autoconf version. I don't know of any SCO problems, but I'd like to have them fixed too, if they're still there. Thanks. From david-bronder at uiowa.edu Fri Sep 28 04:17:16 2001 From: david-bronder at uiowa.edu (David Bronder) Date: Thu, 27 Sep 2001 13:17:16 -0500 (CDT) Subject: AIX lastlog change? Message-ID: <200109271817.f8RIHGe43348@fire.its.uiowa.edu> 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. =Dave -- 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 stevesk at pobox.com Fri Sep 28 04:35:31 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 27 Sep 2001 11:35:31 -0700 (PDT) Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX In-Reply-To: <200109271803.f8RI3LE02609@shade.twinsun.com> Message-ID: On Thu, 27 Sep 2001, Paul Eggert wrote: :openssh-2.9.9p2/configure.in says: : : # Disabled until it works on SCO and HPUX : #AC_SYS_LARGEFILE : :As an autoconf maintainer I'd like to fix this. Can you please cool. :explain what's broken on SCO and HPUX? there are two issues. first, there were some conversion problems in the utmp code when using 64-bit off_t. there's a patch for that. that is not an autoconf problem. next, i have problems with autoconf >=2.50 on hp-ux 11.11. it will not complete make check, and it seems very, very slow when building configure. http://mail.gnu.org/pipermail/bug-autoconf/2001-September/001045.html i've tried 2.52d and have a similar loop. i'd like to figure out what's going on here but haven't had time to dig deeper. :I'm puzzled by the comment, as AC_SYS_LARGEFILE is a feature :introduced in autoconf 2.50, whereas openssh-2.9.9p2/configure was :built with autoconf 2.13. 2.9.9p1 used 2.52 with AC_SYS_LARGEFILE and exposed the utmp bug mentioned above. :Anyway, some older GNU software came with implementations of :AC_SYS_LARGEFILE that had problems on HPUX, but these problems should :all be fixed in the current autoconf version. I don't know of any SCO :problems, but I'd like to have them fixed too, if they're still there. i'm using the slow and make check failing 2.52 on hp-ux now with the utmp patch and AC_SYS_LARGEFILE enabled and it appears to be working. From stevesk at pobox.com Fri Sep 28 04:58:14 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 27 Sep 2001 11:58:14 -0700 (PDT) Subject: openssh-2.9.9p2 session.c fails on Solaris 7,8 w/ SunPro C In-Reply-To: Message-ID: On Wed, 26 Sep 2001 Austin.David at wink.com wrote: :session.c fails from openSSH 2.9.9p2 with SunPro C compiler on Solaris 7, :8. The function do_pre_login had to be moved to before its use in :do_exec_pty (a predeclaration would work). yes, unfortunately that was missed. i will commit wayne's patch. :It does appear to work correctly, given the above fix. Still having the :largefile problem (argh), so if anyone can help with /that/ ... this should fix type conversion problems exposed when using 64-bit off_t. can folks test? Index: loginrec.c =================================================================== RCS file: /var/cvs/openssh/loginrec.c,v retrieving revision 1.34 diff -u -r1.34 loginrec.c --- loginrec.c 2001/08/06 23:29:17 1.34 +++ loginrec.c 2001/09/27 18:53:33 @@ -1095,7 +1095,7 @@ } /* Seek to the start of the last struct utmp */ - if (lseek(fd, (off_t)(0 - sizeof(struct utmp)), SEEK_END) == -1) { + if (lseek(fd, -(off_t)sizeof(struct utmp), SEEK_END) == -1) { /* Looks like we've got a fresh wtmp file */ close(fd); return 0; @@ -1128,7 +1128,7 @@ continue; } /* Seek back 2 x struct utmp */ - if (lseek(fd, (off_t)(0-2*sizeof(struct utmp)), SEEK_CUR) == -1) { + if (lseek(fd, -(off_t)(2 * sizeof(struct utmp)), SEEK_CUR) == -1) { /* We've found the start of the file, so quit */ close (fd); return 0; @@ -1251,7 +1251,7 @@ } /* Seek to the start of the last struct utmpx */ - if (lseek(fd, (off_t)(0-sizeof(struct utmpx)), SEEK_END) == -1 ) { + if (lseek(fd, -(off_t)sizeof(struct utmpx), SEEK_END) == -1 ) { /* probably a newly rotated wtmpx file */ close(fd); return 0; @@ -1281,7 +1281,7 @@ # endif continue; } - if (lseek(fd, (off_t)(0-2*sizeof(struct utmpx)), SEEK_CUR) == -1) { + if (lseek(fd, -(off_t)(2 * sizeof(struct utmpx)), SEEK_CUR) == -1) { close (fd); return 0; } @@ -1424,7 +1424,7 @@ if (type == LL_FILE) { /* find this uid's offset in the lastlog file */ - offset = (off_t) ( (long)li->uid * sizeof(struct lastlog)); + offset = (off_t) ((long)li->uid * sizeof(struct lastlog)); if ( lseek(*fd, offset, SEEK_SET) != offset ) { log("lastlog_openseek: %s->lseek(): %s", From eggert at twinsun.com Fri Sep 28 05:22:39 2001 From: eggert at twinsun.com (Paul Eggert) Date: Thu, 27 Sep 2001 12:22:39 -0700 (PDT) Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX In-Reply-To: (stevesk@pobox.com) References: Message-ID: <200109271922.f8RJMdo02816@shade.twinsun.com> > Date: Thu, 27 Sep 2001 11:35:31 -0700 (PDT) > From: Kevin Steves > > i have problems with autoconf >=2.50 on hp-ux 11.11. it will not > complete make check OK, I see. I just read http://mail.gnu.org/pipermail/bug-autoconf/2001-September/001050.html and I would like to see the output of: top_srcdir=$top_srcdir sh -x ./configure That is, I'd like to see what shell commands that instance of './configure' is running. This bug might be related to the bug that was fixed in: http://mail.gnu.org/pipermail/autoconf-patches/2001-September/007791.html but the evidence is pretty slim here, so I'd like to see more. > and it seems very, very slow when building configure. The slowness is a known problem and I think it is being worked on, but I don't consider it to be a fatal objection. There's a tradeoff between speed and portability, and autoconf tries to be portable. (You might find it a bit faster if you ran autoconf on a GNU/Linux box. :-) > i'm using the slow and make check failing 2.52 on hp-ux now with the utmp > patch and AC_SYS_LARGEFILE enabled and it appears to be working. Sounds good, then. By the way, that 'make check' problem indicates a potential problem with cross-compiling only. Native compilation should be fine. From dveeravalli at telica.com Fri Sep 28 05:25:47 2001 From: dveeravalli at telica.com (Deepa Nemmili Veeravalli) Date: Thu, 27 Sep 2001 15:25:47 -0400 Subject: sftp error on LynxOs Message-ID: <7AC90049E901D511A8CA009027289AEA8EBE79@wench> I am trying to initiate an sftp session from a Linux (Redhat) to a LynxOs machine (where i have ported opnessh-2.9p1) and configured without PAM support (as I was not able to find PAM version for LynxOS operating system) I get the following error: $ sftp -P /home/telica -l telica -v ben select: Bad file descriptor read: Input/output error sftp> Can somebody help me asap on this? Thanks,Deepa. Deepa N V Technical Support Engineer Telica Inc Marlborough,MA (W)508-804-8197 From matthew at debian.org Fri Sep 28 05:37:36 2001 From: matthew at debian.org (Matthew Vernon) Date: 27 Sep 2001 20:37:36 +0100 Subject: [PATCH] remove /etc/rc references from ssh-keygen.1 Message-ID: <5bbsjwa0hr.fsf@chiark.greenend.org.uk> Hi, Some systems (sysvinit-using ones, at least, such as linux) do not have /etc/rc, so the references to it in ssh-keygen.1 are not very helpful. Here's a quick patch to remove those references. Cheers, Matthew --- ssh-keygen.1.orig Thu Sep 27 20:31:48 2001 +++ ssh-keygen.1 Thu Sep 27 20:34:34 2001 @@ -99,8 +99,7 @@ or .Pa $HOME/.ssh/id_rsa . Additionally, the system administrator may use this to generate host keys, -as seen in -.Pa /etc/rc . +as seen in initialization scripts on some systems. .Pp Normally this program generates the key and asks for a file in which to store the private key. @@ -178,9 +177,7 @@ .It Fl q Silence .Nm ssh-keygen . -Used by -.Pa /etc/rc -when creating a new key. +Scripts that create keys often use this option. .It Fl y This option will read a private OpenSSH format file and print an OpenSSH public key to stdout. -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at debian.org Fri Sep 28 05:43:20 2001 From: matthew at debian.org (Matthew Vernon) Date: 27 Sep 2001 20:43:20 +0100 Subject: [PATCH] document inability to change v2 keys' comments with ssh-keygen Message-ID: <5badzga087.fsf@chiark.greenend.org.uk> Hi, ssh-keygen is unable to change version 2 keys' comments (this was true in 2.9p2, and the changelog doesn't make me think this has changed), so I think this should be documented. Here's a patch to ssh-keygen.1 (It's based on an ssh-keygen patched with my previous patch). Cheers, Matthew --- ssh-keygen.1.orig Thu Sep 27 20:31:48 2001 +++ ssh-keygen.1 Thu Sep 27 20:40:32 2001 @@ -149,6 +148,7 @@ Requests changing the comment in the private and public key files. The program will prompt for the file containing the private keys, for the passphrase if the key has one, and for the new comment. +The comment can only be changed if the key is an RSA1 key. .It Fl e This option will read a private or public OpenSSH key file and print the key in a @@ -267,6 +265,9 @@ where the user wishes to log in using public key authentication. There is no need to keep the contents of this file secret. .El +.Sh BUGS +While it is possible to give an RSA or DSA key (that is a version 2 +key) a comment when creating it there is no way to change it. .Sh AUTHORS OpenSSH is a derivative of the original and free ssh 1.2.12 release by Tatu Ylonen. -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From dveeravalli at telica.com Fri Sep 28 06:02:14 2001 From: dveeravalli at telica.com (Deepa Nemmili Veeravalli) Date: Thu, 27 Sep 2001 16:02:14 -0400 Subject: sftp error on LynxOs Message-ID: <7AC90049E901D511A8CA009027289AEA8EBE7A@wench> I have the debug output from the server side below. Any help or pointer will be greatly appreciated as I have been blocked with this. debug1: Server will not fork when running in debugging mode. Connection from 10.0.0.11 port 1020 debug1: Client protocol version 2.0; client software version OpenSSH_2.3.0p1 debug1: match: OpenSSH_2.3.0p1 pat ^OpenSSH_2\.3\.0 Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.9p1 debug2: Original cipher proposal: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: Compat cipher proposal: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour debug2: Original cipher proposal: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: Compat cipher proposal: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour debug1: list_hostkey_types: ssh-rsa,ssh-dss 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: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-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: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com 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: mac_init: found hmac-sha1 debug1: kex: server->client 3des-cbc hmac-sha1 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 204/384 debug1: bits set: 1037/2049 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 967/2049 debug1: sig size 20 20 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent 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: KEX done debug1: userauth-request for user telica service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for telica debug2: input_userauth_request: try method none Failed none for telica from 10.0.0.11 port 1020 ssh2 debug1: userauth-request for user telica service ssh-connection method publickey debug1: attempt 1 failures 1 debug2: input_userauth_request: try method publickey debug1: temporarily_use_uid: 604/500 (e=0) debug1: matching key found: file /home/telica/.ssh/authorized_keys2, line 1 debug1: restore_uid debug1: len 55 datafellows 53376 debug1: ssh_dss_verify: signature correct debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss Accepted publickey for telica from 10.0.0.11 port 1020 ssh2 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 32768 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug2: callback start debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request x11-req reply 0 debug1: X11 forwarding disabled in server configuration file. debug2: callback done debug2: callback start debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 channel 0 request exec reply 0 debug1: fd 6 setting O_NONBLOCK debug1: fd 6 IS O_NONBLOCK debug1: fd 11 setting O_NONBLOCK debug2: callback done debug2: channel 0: read 195 from efd 11 debug2: channel 0: rwin 65536 elen 195 euse 1 debug2: channel 0: sent ext data 195 debug1: Received SIGCHLD. debug1: session_by_pid: pid 32 debug1: session_exit_message: session 0 channel 0 pid 32 debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: output open -> closed debug1: channel 0: close_write debug1: session_free: session 0 pid 32 debug1: channel 0: read<=0 rfd 6 len 0 debug1: channel 0: read failed debug1: channel 0: input open -> drain debug1: channel 0: close_read debug1: channel 0: input: no drain shortcut debug1: channel 0: ibuf empty debug1: channel 0: input drain -> closed debug1: channel 0: send eof debug2: channel 0: read 61 from efd 11 debug2: channel 0: active efd: 11 len 61 type read debug2: channel 0: rwin 65341 elen 61 euse 1 debug2: channel 0: sent ext data 61 debug1: channel 0: send close debug2: channel 0: read 0 from efd 11 debug2: channel 0: closing read-efd 11 debug2: channel 0: no data after CLOSE Connection closed by remote host. Closing connection to 10.0.0.11 debug1: writing PRNG seed to file //.ssh/prng_seed -----Original Message----- From: Deepa Nemmili Veeravalli [mailto:dveeravalli at telica.com] Sent: Thursday, September 27, 2001 3:26 PM To: openssh-unix-dev at mindrot.org Subject: sftp error on LynxOs I am trying to initiate an sftp session from a Linux (Redhat) to a LynxOs machine (where i have ported opnessh-2.9p1) and configured without PAM support (as I was not able to find PAM version for LynxOS operating system) I get the following error: $ sftp -P /home/telica -l telica -v ben select: Bad file descriptor read: Input/output error sftp> Can somebody help me asap on this? Thanks,Deepa. From mouring at etoh.eviladmin.org Fri Sep 28 06:12:11 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 27 Sep 2001 15:12:11 -0500 (CDT) Subject: sftp error on LynxOs In-Reply-To: <7AC90049E901D511A8CA009027289AEA8EBE79@wench> Message-ID: On Thu, 27 Sep 2001, Deepa Nemmili Veeravalli wrote: > I am trying to initiate an sftp session from a Linux (Redhat) to a LynxOs > machine (where i have ported opnessh-2.9p1) and configured without PAM > support (as I was not able to find PAM version for LynxOS operating system) > > I get the following error: > $ sftp -P /home/telica -l telica -v ben OpenSSH's sftp does not support -P, nor -l - Ben From matthew at debian.org Fri Sep 28 06:31:00 2001 From: matthew at debian.org (Matthew Vernon) Date: 27 Sep 2001 21:31:00 +0100 Subject: [PATCH] document scp -r better Message-ID: <5b8zf09y0r.fsf@chiark.greenend.org.uk> Hi, Patch from Adam McKenna (via Debian BTS) to improve how we document scp -r: --- scp.1.orig Thu Sep 27 21:28:12 2001 +++ scp.1 Thu Sep 27 21:29:22 2001 @@ -72,7 +72,9 @@ Preserves modification times, access times, and modes from the original file. .It Fl r -Recursively copy entire directories. +Recursively copy entire directories. A trailing slash (/) on a source file +name means "copy the contents of this directory". Without a trailing slash +it means "copy the directory and all of its contents". .It Fl v Verbose mode. Causes Cheers, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From mouring at etoh.eviladmin.org Fri Sep 28 06:42:37 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 27 Sep 2001 15:42:37 -0500 (CDT) Subject: sftp error on LynxOs In-Reply-To: <7AC90049E901D511A8CA009027289AEA8EBE7A@wench> Message-ID: do a: ssh site /bin/true does ssh give you any banners or anything running that command.. if so subsystems will fail. - Ben On Thu, 27 Sep 2001, Deepa Nemmili Veeravalli wrote: > I have the debug output from the server side below. > Any help or pointer will be greatly appreciated as I have been blocked with > this. > > > debug1: Server will not fork when running in debugging mode. > Connection from 10.0.0.11 port 1020 > debug1: Client protocol version 2.0; client software version OpenSSH_2.3.0p1 > debug1: match: OpenSSH_2.3.0p1 pat ^OpenSSH_2\.3\.0 > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-1.99-OpenSSH_2.9p1 > debug2: Original cipher proposal: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r > ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > debug2: Compat cipher proposal: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > debug2: Original cipher proposal: > aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r > ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > debug2: Compat cipher proposal: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > debug1: list_hostkey_types: ssh-rsa,ssh-dss > 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: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,cast128-cbc,arcfour > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm > ac-md5-96 > debug2: kex_parse_kexinit: > hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm > ac-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: kex_parse_kexinit: > diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-dss > debug2: kex_parse_kexinit: > 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,r > ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: > 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,r > ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ripemd160 at openssh.com > 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: mac_init: found hmac-sha1 > debug1: kex: server->client 3des-cbc hmac-sha1 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received > debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent > debug1: dh_gen_key: priv key bits set: 204/384 > debug1: bits set: 1037/2049 > debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT > debug1: bits set: 967/2049 > debug1: sig size 20 20 > debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent > 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: KEX done > debug1: userauth-request for user telica service ssh-connection method none > debug1: attempt 0 failures 0 > debug2: input_userauth_request: setting up authctxt for telica > debug2: input_userauth_request: try method none > Failed none for telica from 10.0.0.11 port 1020 ssh2 > debug1: userauth-request for user telica service ssh-connection method > publickey > debug1: attempt 1 failures 1 > debug2: input_userauth_request: try method publickey > debug1: temporarily_use_uid: 604/500 (e=0) > debug1: matching key found: file /home/telica/.ssh/authorized_keys2, line 1 > debug1: restore_uid > debug1: len 55 datafellows 53376 > debug1: ssh_dss_verify: signature correct > debug2: userauth_pubkey: authenticated 1 pkalg ssh-dss > Accepted publickey for telica from 10.0.0.11 port 1020 ssh2 > debug1: Entering interactive session for SSH2. > debug1: server_init_dispatch_20 > debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 32768 > debug1: input_session_request > debug1: channel 0: new [server-session] > debug1: session_new: init > debug1: session_new: session 0 > debug1: session_open: channel 0 > debug1: session_open: session 0: link with channel 0 > debug1: server_input_channel_open: confirm session > debug2: callback start > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 channel 0 request x11-req reply > 0 > debug1: X11 forwarding disabled in server configuration file. > debug2: callback done > debug2: callback start > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 channel 0 request exec reply 0 > debug1: fd 6 setting O_NONBLOCK > debug1: fd 6 IS O_NONBLOCK > debug1: fd 11 setting O_NONBLOCK > debug2: callback done > debug2: channel 0: read 195 from efd 11 > debug2: channel 0: rwin 65536 elen 195 euse 1 > debug2: channel 0: sent ext data 195 > debug1: Received SIGCHLD. > debug1: session_by_pid: pid 32 > debug1: session_exit_message: session 0 channel 0 pid 32 > debug1: session_exit_message: release channel 0 > debug1: channel 0: write failed > debug1: channel 0: output open -> closed > debug1: channel 0: close_write > debug1: session_free: session 0 pid 32 > debug1: channel 0: read<=0 rfd 6 len 0 > debug1: channel 0: read failed > debug1: channel 0: input open -> drain > debug1: channel 0: close_read > debug1: channel 0: input: no drain shortcut > debug1: channel 0: ibuf empty > debug1: channel 0: input drain -> closed > debug1: channel 0: send eof > debug2: channel 0: read 61 from efd 11 > debug2: channel 0: active efd: 11 len 61 type read > debug2: channel 0: rwin 65341 elen 61 euse 1 > debug2: channel 0: sent ext data 61 > debug1: channel 0: send close > debug2: channel 0: read 0 from efd 11 > debug2: channel 0: closing read-efd 11 > debug2: channel 0: no data after CLOSE > Connection closed by remote host. > Closing connection to 10.0.0.11 > debug1: writing PRNG seed to file //.ssh/prng_seed > > -----Original Message----- > From: Deepa Nemmili Veeravalli [mailto:dveeravalli at telica.com] > Sent: Thursday, September 27, 2001 3:26 PM > To: openssh-unix-dev at mindrot.org > Subject: sftp error on LynxOs > > > I am trying to initiate an sftp session from a Linux (Redhat) to a LynxOs > machine (where i have ported opnessh-2.9p1) and configured without PAM > support (as I was not able to find PAM version for LynxOS operating system) > > I get the following error: > $ sftp -P /home/telica -l telica -v ben > select: Bad file descriptor > read: Input/output error > sftp> > > > Can somebody help me asap on this? > > Thanks,Deepa. > From Dmitri.Smirnov at RoundHeaven.com Fri Sep 28 06:44:54 2001 From: Dmitri.Smirnov at RoundHeaven.com (Dmitri Smirnov) Date: Thu, 27 Sep 2001 13:44:54 -0700 Subject: SecurID support in 2.9.9 Message-ID: Hello, is anybody know what is happened with RSA SecurID support in 2.9.9? It was a part of 2.9 (auth-securid.c) but not in 2.9.9 anymore. Dmitri From matthew at debian.org Fri Sep 28 06:46:06 2001 From: matthew at debian.org (Matthew Vernon) Date: 27 Sep 2001 21:46:06 +0100 Subject: [PATCH] scp fixes Message-ID: <5b7kuk9xbl.fsf@chiark.greenend.org.uk> Hi, The following patch does two things (which you may choose to take separatly if you don't like one or t'other). Firstly, I add a -1 and -2 option, since a) it's convenient b) people keep asking for it c) it's hardly a big fix, nor does it break backwards compatibility and d) I don't accept any slippery slope arguments. Secondly, I check for and ignore filenames with \n in the filename, since these break the rcp/scp protocol. Cheers, Matthew --- scp.c.orig Thu Sep 27 21:32:32 2001 +++ scp.c Thu Sep 27 21:41:06 2001 @@ -242,9 +242,11 @@ addargs(&args, "-oClearAllForwardings yes"); fflag = tflag = 0; - while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q46S:o:F:")) != -1) + while ((ch = getopt(argc, argv, "dfprtvBCc:i:P:q1246S:o:F:")) != -1) switch (ch) { /* User-visible flags. */ + case '1': + case '2': case '4': case '6': case 'C': @@ -505,6 +507,12 @@ name[--len] = '\0'; if ((fd = open(name, O_RDONLY, 0)) < 0) goto syserr; + /*Check for filename containing a newline*/ + if ((last = strchr(name, '\n')) != NULL) { + run_err("%s: filename contains a newline, ignoring it", + name); + goto next; + } if (fstat(fd, &stb) < 0) { syserr: run_err("%s: %s", name, strerror(errno)); goto next; -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From matthew at debian.org Fri Sep 28 06:49:30 2001 From: matthew at debian.org (Matthew Vernon) Date: 27 Sep 2001 21:49:30 +0100 Subject: [PATCH] ssh-copy-id should do chmod go-w Message-ID: <5b66a49x5x.fsf@chiark.greenend.org.uk> Hi, quick patch to ssh-copy-id to make it set the file modes more correctly. Thanks, Matthew --- contrib/ssh-copy-id.orig Thu Sep 27 21:47:44 2001 +++ contrib/ssh-copy-id Thu Sep 27 21:47:52 2001 @@ -33,7 +33,7 @@ exit 1 fi -{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >> .ssh/authori zed_keys ; chmod g-w . .ssh .ssh/authorized_keys" +{ eval "$GET_ID" ; } | ssh $1 "test -d .ssh || mkdir .ssh ; cat >> .ssh/authori zed_keys ; chmod go-w . .ssh .ssh/authorized_keys" cat < Message-ID: securid was never part of OpenSSH. - Ben On Thu, 27 Sep 2001, Dmitri Smirnov wrote: > Hello, > > is anybody know what is happened with RSA SecurID support in 2.9.9? It was a > part of 2.9 (auth-securid.c) but not in 2.9.9 anymore. > > Dmitri > From matthew at debian.org Fri Sep 28 06:55:40 2001 From: matthew at debian.org (Matthew Vernon) Date: 27 Sep 2001 21:55:40 +0100 Subject: Purpose of check_openssl_version? Message-ID: <5b4rpo9wvn.fsf@chiark.greenend.org.uk> Hi, Debian have #defined out this function in entropy.c for some time (since it causes things to break too often, given I don't maintain openssl). Does it serve a useful function security-wise? Thanks, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org From tim at multitalents.net Fri Sep 28 07:02:39 2001 From: tim at multitalents.net (Tim Rice) Date: Thu, 27 Sep 2001 14:02:39 -0700 (PDT) Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX In-Reply-To: <200109271803.f8RI3LE02609@shade.twinsun.com> Message-ID: On Thu, 27 Sep 2001, Paul Eggert wrote: > openssh-2.9.9p2/configure.in says: > > # Disabled until it works on SCO and HPUX > #AC_SYS_LARGEFILE > > As an autoconf maintainer I'd like to fix this. Can you please > explain what's broken on SCO and HPUX? [snip] > all be fixed in the current autoconf version. I don't know of any SCO > problems, but I'd like to have them fixed too, if they're still there. The problem on SCO (Open Server 3, aka. 3.2v4.2) is the sed scripts produced by autoconf make sed choke. The configure script worked fine on SCO Open Server 5 ..... checking if your system defines WTMPX_FILE... no configure: creating ./config.status sed: command garbled: s,^[ ]*#[ ]*define[ ][ ]*\(\([^ (][^ (]*\)([^)]*)\)[ ]*\(.*\)$,${ac_dA}\2${ac_dB}\1${ac_dC}\3${ac_dD},gp config.status: creating Makefile ..... If the autoconf testsuite.log is of any interest, I can e-mail it to you or grab it from ftp://ftp.multitalents.net/pub/testsuite.log http://www.multitalents.net/testsuite.log > > Thanks. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From mouring at etoh.eviladmin.org Fri Sep 28 07:05:37 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Thu, 27 Sep 2001 16:05:37 -0500 (CDT) Subject: Purpose of check_openssl_version? In-Reply-To: <5b4rpo9wvn.fsf@chiark.greenend.org.uk> Message-ID: The problem we had is people would compile OpenSSH dynamically against one release of OpenSSL. And then attempt to run it on another box with a different release of OpenSSL. Which causes a lot of unexplained problems with OpenSSH failing randomly. - Ben On 27 Sep 2001, Matthew Vernon wrote: > Hi, > > Debian have #defined out this function in entropy.c for some time > (since it causes things to break too often, given I don't maintain > openssl). Does it serve a useful function security-wise? > > Thanks, > > Matthew > > -- > "At least you know where you are with Microsoft." > "True. I just wish I'd brought a paddle." > http://www.debian.org > From Michael.Jenkins at disney.com Fri Sep 28 07:15:19 2001 From: Michael.Jenkins at disney.com (Jenkins, Michael) Date: Thu, 27 Sep 2001 17:15:19 -0400 Subject: openssh-2.9.9p2, solaris pkg build fails Message-ID: s/primes/moduli/ in build-pkg, postinstall.in, and prototype. $ ./build-pkg Building Solaris package of OpenSSH 2.9.9p2 in /home/mike/src/openssh/openssh-2.9.9p2/contrib/solaris/build-SSH-package. Binaries were compiled for Solaris 2.6 (sparc) The installable package will be named OPENssh-2.9.9p2-sol2.6-sparc-local. When installed, the package will be located under /usr/local. Cleaning up old build files... Setting up build directories... Populating build directories... cp: cannot access ../../../primes Creating compile-dependent files from their prototypes Stripping binaries Building Package ## Building pkgmap from package prototype file. ERROR in prototype: no object for found in root directory pkgmk: ERROR: unable to build pkgmap from prototype file ## Packaging was not successful. Error performing pkgmk--cannot continue. From alaric at babcom.com Fri Sep 28 07:26:14 2001 From: alaric at babcom.com (Phil Stracchino) Date: Thu, 27 Sep 2001 14:26:14 -0700 Subject: ssh2 key passphrase problems in 2.9.9 on Linux Message-ID: <20010927142614.A6096@babylon5.babcom.com> I've just compiled and installed openssh-2.9.9p2 (compiled against openssl-0.9.6b using gcc-3.0.0) on a Slackware 7-based Linux machine (kernel 2.4.6ac2). The previously installed version was 2.9p2, compiled against openssl-0.9.6a, also with gcc-3.0.0, but with a different build of gcc-3.0.0. Everything seems to work fine except for one problem: passphrase matching for ssh2 keys *always* fails. I've run ssh-add under gdb several times trying to see what's going wrong, so far without learning anything particularly enlightening. Has anyone else encountered this problem? I have a possible theory that it's compiler-related, but I haven't been able to verify the theory yet. (My previous gcc-3.0.0 was compiled with gcc-2.95.3, while the current one was compiled with a gcc-3.0.1 installation that I subsequently backed out after discovering it wouldn't compile a kernel. Although I did a full 3-stage bootstrap when I rebuilt 3.0.0, I beginning to wonder whether I still somehow got a subtly bad build.) -- Linux Now! .........Because friends don't let friends use Microsoft. phil stracchino :: alaric at babcom.com :: halmayne at sourceforge.net unix ronin :::: renaissance man :::: mystic zen biker geek 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From djm at mindrot.org Fri Sep 28 10:48:44 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 28 Sep 2001 10:48:44 +1000 (EST) Subject: AIX lastlog change? In-Reply-To: <200109271817.f8RIHGe43348@fire.its.uiowa.edu> Message-ID: 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 From djm at mindrot.org Fri Sep 28 10:53:38 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 28 Sep 2001 10:53:38 +1000 (EST) Subject: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: <20010927142614.A6096@babylon5.babcom.com> Message-ID: On Thu, 27 Sep 2001, Phil Stracchino wrote: > > I've just compiled and installed openssh-2.9.9p2 (compiled against > openssl-0.9.6b using gcc-3.0.0) on a Slackware 7-based Linux machine > (kernel 2.4.6ac2). The previously installed version was 2.9p2, compiled > against openssl-0.9.6a, also with gcc-3.0.0, but with a different build of > gcc-3.0.0. > > Everything seems to work fine except for one problem: passphrase matching > for ssh2 keys *always* fails. I've run ssh-add under gdb several times > trying to see what's going wrong, so far without learning anything > particularly enlightening. Are you using ssh-askpass or entering the passphrase from a tty? -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From stevesk at pobox.com Fri Sep 28 10:51:25 2001 From: stevesk at pobox.com (Kevin Steves) Date: Thu, 27 Sep 2001 17:51:25 -0700 (PDT) Subject: [PATCH] document scp -r better In-Reply-To: <5b8zf09y0r.fsf@chiark.greenend.org.uk> Message-ID: On 27 Sep 2001, Matthew Vernon wrote: :Patch from Adam McKenna (via Debian BTS) to improve how we document :scp -r: : :--- scp.1.orig Thu Sep 27 21:28:12 2001 :+++ scp.1 Thu Sep 27 21:29:22 2001 :@@ -72,7 +72,9 @@ : Preserves modification times, access times, and modes from the : original file. : .It Fl r :-Recursively copy entire directories. :+Recursively copy entire directories. A trailing slash (/) on a :source file :+name means "copy the contents of this directory". Without a trailing :slash :+it means "copy the directory and all of its contents". : .It Fl v : Verbose mode. : Causes where in the scp code is this functionality? From alaric at babcom.com Fri Sep 28 11:15:11 2001 From: alaric at babcom.com (Phil Stracchino) Date: Thu, 27 Sep 2001 18:15:11 -0700 Subject: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: ; from djm@mindrot.org on Fri, Sep 28, 2001 at 10:53:38AM +1000 References: <20010927142614.A6096@babylon5.babcom.com> Message-ID: <20010927181511.A4363@babylon5.babcom.com> On Fri, Sep 28, 2001 at 10:53:38AM +1000, Damien Miller wrote: > On Thu, 27 Sep 2001, Phil Stracchino wrote: > > Everything seems to work fine except for one problem: passphrase matching > > for ssh2 keys *always* fails. I've run ssh-add under gdb several times > > trying to see what's going wrong, so far without learning anything > > particularly enlightening. > > Are you using ssh-askpass or entering the passphrase from a tty? Entering from a tty, thus far, since I'm testing from a terminal and don't know any way to force ssh-add (for example) to use ssh-askpass. It's working fine on the Ultra1 next to me, which is running solaris 8 ahd has the same versions of gcc, openssh and openssl. On the theory that it's a gcc problem, I've just bootstrapped a new gcc build and I'm now recompiling to see if that solves the problem. -- Linux Now! .........Because friends don't let friends use Microsoft. phil stracchino :: alaric at babcom.com :: halmayne at sourceforge.net unix ronin :::: renaissance man :::: mystic zen biker geek 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From alaric at babcom.com Fri Sep 28 11:32:06 2001 From: alaric at babcom.com (Phil Stracchino) Date: Thu, 27 Sep 2001 18:32:06 -0700 Subject: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: <20010927181511.A4363@babylon5.babcom.com>; from alaric@babcom.com on Thu, Sep 27, 2001 at 06:15:11PM -0700 References: <20010927142614.A6096@babylon5.babcom.com> <20010927181511.A4363@babylon5.babcom.com> Message-ID: <20010927183206.A13972@babylon5.babcom.com> On Thu, Sep 27, 2001 at 06:15:11PM -0700, Phil Stracchino wrote: > On the theory that it's a gcc problem, I've just bootstrapped a new gcc > build and I'm now recompiling to see if that solves the problem. (It didn't.) -- Linux Now! .........Because friends don't let friends use Microsoft. phil stracchino :: alaric at babcom.com :: halmayne at sourceforge.net unix ronin :::: renaissance man :::: mystic zen biker geek 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From kaukasoi at elektroni.ee.tut.fi Fri Sep 28 16:10:46 2001 From: kaukasoi at elektroni.ee.tut.fi (Petri Kaukasoina) Date: Fri, 28 Sep 2001 09:10:46 +0300 Subject: OpenSSH_2.9.9p2 and client config Message-ID: <20010928091046.A7247@elektroni.ee.tut.fi> Hi I think there is a problem is OpenSSH_2.9.9p2. Suppose I have in /etc/ssh/ssh_config just this and nothing more: Host * ForwardX11 yes and in ~/.ssh/config: Host * ForwardX11 no ssh -v tells they are read ok: debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Reading configuration data /home/kaukasoi/.ssh/config debug1: Applying options for * but still it opens the X channel: debug1: Requesting X11 forwarding with authentication spoofing. OpenSSH_2.9p1 didn't do that. From alaric at babcom.com Fri Sep 28 16:26:21 2001 From: alaric at babcom.com (Phil Stracchino) Date: Thu, 27 Sep 2001 23:26:21 -0700 Subject: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: <20010927142614.A6096@babylon5.babcom.com>; from alaric@babcom.com on Thu, Sep 27, 2001 at 02:26:14PM -0700 References: <20010927142614.A6096@babylon5.babcom.com> Message-ID: <20010927232621.A24206@babylon5.babcom.com> On Thu, Sep 27, 2001 at 02:26:14PM -0700, Phil Stracchino wrote: > I've just compiled and installed openssh-2.9.9p2 (compiled against > openssl-0.9.6b using gcc-3.0.0) on a Slackware 7-based Linux machine > (kernel 2.4.6ac2). The previously installed version was 2.9p2, compiled > against openssl-0.9.6a, also with gcc-3.0.0, but with a different build of > gcc-3.0.0. > > Everything seems to work fine except for one problem: passphrase matching > for ssh2 keys *always* fails. I've run ssh-add under gdb several times > trying to see what's going wrong, so far without learning anything > particularly enlightening. I have finally managed to isolate this down to the following: For SSH2 DSA and RSA keys, the OpenSSL PEM_read_PrivateKey() macro, called from authfile.c line 448: pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase); is consistently failing and always returns NULL, whereas it should be returning a EVP_PKEY struct with pk->type containing either EVP_PKEY_RSA or EVP_PKEY_DSA. As far as I can see from the OpenSSL code, this means that BIO_new(BIO_s_file()) has to be returning NULL, but that's as far as I can figure it out; the internals of OpenSSL are utterly impenetrable to me. Any suggestions, anyone? I think I've taken this problem about as far as I can diagnose it myself. OpenSSL was configured using the following options: --prefix=/usr shared threads -D_REENTRANT. Recompiling with no-threads out of constructive paranoia made no difference. OpenSSH was configured with: configure --prefix=/usr --with-tcp-wrappers --with-md5-passwords --with-ipv4-default --sysconfdir=/etc The same key files are handled correctly on a Solaris 2.8 machine with the same OpenSSL and OpenSSH versions, configured identically except for no --with-md5-passwords because Solaris still doesn't support md5crypt. Bad Sun, bad. No donut. -- Linux Now! .........Because friends don't let friends use Microsoft. phil stracchino :: alaric at babcom.com :: halmayne at sourceforge.net unix ronin :::: renaissance man :::: mystic zen biker geek 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From eggert at twinsun.com Fri Sep 28 16:38:13 2001 From: eggert at twinsun.com (Paul Eggert) Date: Thu, 27 Sep 2001 23:38:13 -0700 (PDT) Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX In-Reply-To: (tim@multitalents.net) References: Message-ID: <200109280638.f8S6cDW18421@sic.twinsun.com> > Date: Thu, 27 Sep 2001 14:02:39 -0700 (PDT) > From: Tim Rice > > The problem on SCO (Open Server 3, aka. 3.2v4.2) is the sed scripts > produced by autoconf make sed choke. > The configure script worked fine on SCO Open Server 5 > > ..... > checking if your system defines WTMPX_FILE... no > configure: creating ./config.status > sed: command garbled: s,^[ ]*#[ ]*define[ ][ ]*\(\([^ (][^ (]*\)([^)]*)\)[ ]*\(.*\)$,${ac_dA}\2${ac_dB}\1${ac_dC}\3${ac_dD},gp > config.status: creating Makefile > ..... > > If the autoconf testsuite.log is of any interest, > I can e-mail it to you or grab it from > ftp://ftp.multitalents.net/pub/testsuite.log > http://www.multitalents.net/testsuite.log This reminds me of the bug fix suggested by Philippe De Muyter in http://mail.gnu.org/pipermail/bug-autoconf/2000-May/000413.html Is there any reason why that bug fix wasn't installed? (I'll CC: this to bug-autoconf to see.) Can you please try the following shell script on the troublesome host? You'll need to cut and paste, to get the exact set of tabs. If the first 'sed' fails, but the second one succeeds, it suggests that the autoconf bug fix should be installed, and that it will fix your problem. echo '#define x(y) z' | sed -n 's,^[ ]*#[ ]*define[ ][ ]*\(\([^ (][^ (]*\)([^)]*)\)[ ]*\(.*\)$,${ac_dA}\2${ac_dB}\1${ac_dC}\3${ac_dD},gp' echo xxxxx echo '#define x(y) z' | sed -n 's,^[ ]*#[ ]*define[ ][ ]*\([^ (][^ (]*\)\(([^)]*)\)[ ]*\(.*\)$,${ac_dA}\1${ac_dB}\1\2${ac_dC}\3${ac_dD},gp' Here's what the output should look like for a host with a working 'sed': ${ac_dA}x${ac_dB}x(y)${ac_dC}z${ac_dD} xxxxx ${ac_dA}x${ac_dB}x(y)${ac_dC}z${ac_dD} but my theory is that you'll get an error message instead. From strube at physik3.gwdg.de Fri Sep 28 18:46:13 2001 From: strube at physik3.gwdg.de (Hans Werner Strube) Date: Fri, 28 Sep 2001 10:46:13 +0200 (MET DST) Subject: openssh-2.9p2, auth2.c Message-ID: <200109280846.KAA17501@marc.physik3.gwdg.de> Even with option "HostbasedUsesNameFromPacketOnly yes", the trailing dot in chost should be stripped before auth_rhosts2() is called from hostbased_key_allowed(). Hans Werner Strube strube at physik3.gwdg.de Drittes Physikalisches Institut, Univ. Goettingen Buergerstr. 42-44, D-37073 Goettingen, Germany Suggested change: *** auth2.c.ORI Wed Apr 25 14:44:15 2001 --- auth2.c Fri Sep 28 10:27:34 2001 *************** *** 801,815 **** debug2("userauth_hostbased: chost %s resolvedname %s ipaddr %s", chost, resolvedname, ipaddr); if (options.hostbased_uses_name_from_packet_only) { if (auth_rhosts2(pw, cuser, chost, chost) == 0) 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", --- 801,816 ---- debug2("userauth_hostbased: chost %s resolvedname %s ipaddr %s", chost, resolvedname, ipaddr); + if (((len = strlen(chost)) > 0) && chost[len - 1] == '.') { + debug2("stripping trailing dot from chost %s", chost); + chost[len - 1] = '\0'; + } + if (options.hostbased_uses_name_from_packet_only) { if (auth_rhosts2(pw, cuser, chost, chost) == 0) return 0; lookup = chost; } else { if (strcasecmp(resolvedname, chost) != 0) log("userauth_hostbased mismatch: " "client sends %s, but we resolve %s to %s", From gert at greenie.muc.de Fri Sep 28 19:41:40 2001 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 28 Sep 2001 11:41:40 +0200 Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX In-Reply-To: <200109280638.f8S6cDW18421@sic.twinsun.com>; from Paul Eggert on Thu, Sep 27, 2001 at 11:38:13PM -0700 References: <200109280638.f8S6cDW18421@sic.twinsun.com> Message-ID: <20010928114140.C9542@greenie.muc.de> Hi, On Thu, Sep 27, 2001 at 11:38:13PM -0700, Paul Eggert wrote: > Can you please try the following shell script on the troublesome host? [..] Tried it on SCO 3.2v4.2, and I got: sed: command garbled: s,^[ ]*#[ ]*define[ ][ ]*\(\([^ (][^ (]*\)([^)]*)\)[ ]*\(.*\)$,${ac_dA}\2${ac_dB}\1${ac_dC}\3${ac_dD},gp xxxxx ${ac_dA}x${ac_dB}x(y)${ac_dC}z${ac_dD} > but my theory is that you'll get an error message instead. So it is. 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 Sep 28 20:04:36 2001 From: djm at mindrot.org (Damien Miller) Date: Fri, 28 Sep 2001 20:04:36 +1000 (EST) Subject: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: <20010927232621.A24206@babylon5.babcom.com> Message-ID: On Thu, 27 Sep 2001, Phil Stracchino wrote: > I have finally managed to isolate this down to the following: For SSH2 > DSA and RSA keys, the OpenSSL PEM_read_PrivateKey() macro, called from > authfile.c line 448: > > pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase); > > is consistently failing and always returns NULL, whereas it should be > returning a EVP_PKEY struct with pk->type containing either EVP_PKEY_RSA > or EVP_PKEY_DSA. As far as I can see from the OpenSSL code, this means > that BIO_new(BIO_s_file()) has to be returning NULL, but that's as far as > I can figure it out; the internals of OpenSSL are utterly impenetrable to > me. > > Any suggestions, anyone? I think I've taken this problem about as far as > I can diagnose it myself. Have you ruled out corruption of the keyfile itself? Did OpenSSL pass its own self-tests? When you compiled OpenSSL or OpenSSH, did you have any old OpenSSL header files lying around? These are a frequent cause of weird problems. You could try putting a printf() before the above call to see if the correct passphrase is getting passed to OpenSSL. -d -- | Damien Miller \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer From Nicolas.Williams at ubsw.com Fri Sep 28 23:39:55 2001 From: Nicolas.Williams at ubsw.com (Nicolas Williams) Date: Fri, 28 Sep 2001 09:39:55 -0400 Subject: Logging authorized key info In-Reply-To: <20010927124851.D24044@usa.net>; from peterw@usa.net on Thu, Sep 27, 2001 at 12:48:51PM -0400 References: <3BB34DB7.FD6B6189@triton-network.com> <20010927122722.E5739@sm2p1386swk.wdr.com> <20010927124851.D24044@usa.net> Message-ID: <20010928093953.F5739@sm2p1386swk.wdr.com> On Thu, Sep 27, 2001 at 12:48:51PM -0400, Peter W wrote: > On Thu, Sep 27, 2001 at 12:27:23PM -0400, Nicolas Williams wrote: > > > The key name field from the authorized_keys entry (or, missing that, the > > public key fingerprint) should be logged. > > Do you mean the comment field? Since that's user-supplied, is there any > concern about mischievous values? A hex-encoded fingerprint value on the > other hand would always be safe/predictable & relatively short. Yes, but the name field is controlled by the same person who controls authorized_keys. What matters it that that person make it a *meaningful* value. > > Also, whichever is logged should be set as the value of some environment > > variable. > > I like this idea. Currently I have some command= tools that have hard links > and behave differently based on the name referenced in command=. It would be > cleaner if I had only one file name, but the behavior depended on the > identity being used to invoke the tool. I use this now. Here's an example, using GSS-API/KerberosV (thanks to Simon Wilkinson!): foo at somehost[87]% kinit foo/superroot Password for foo/superroot at FOOBAR.COM: foo at somehost[88]% ssh -l root someotherhost Last login: Thu Aug 23 08:08:08 2001 from somehost # env|grep SSH SSH_AUTH_EXT_NAME=foo/superroot at FOOBAR.COM SSH_AUTH_EXT_NAME_TYPE=krb5 SSH_AUTH_SOCK=/tmp/ssh-nRSm3742/agent.3742 SSH_CLIENT=10.11.12.13 33244 22 SSH_TTY=/dev/pts/38 # cat ~root/.ssh/authorized_keys2 ssh-ext-name-pat:krb5 */superroot at FOOBAR.COM # See? > -Peter My patch for this can be found in the archives of this list at MARC. 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 djast at cs.toronto.edu Sat Sep 29 00:13:50 2001 From: djast at cs.toronto.edu (Dan Astoorian) Date: Fri, 28 Sep 2001 10:13:50 -0400 Subject: OpenSSH (portable) and entropy gathering In-Reply-To: Your message of "Thu, 27 Sep 2001 20:41:05 EDT." Message-ID: <01Sep28.101355edt.453144-11860@jane.cs.toronto.edu> On Thu, 27 Sep 2001 20:41:05 EDT, Damien Miller writes: > On Thu, 27 Sep 2001, Dan Astoorian wrote: > > > > > It would (IMHO) be useful if there were a way to optionally configure > > that code to fall back to the internal entropy gathering routines in the > > event that EGD was not available; as it is, the routines simply fail if > > EGD is unavailable at the time the ssh daemon or client is invoked. > > > > Is this a feature the OpenSSH Portability Team would consider > > worthwhile? > > Probably not - in fact we want to deprecate the built in entropy > collection in favor of the use of a daemon or subprocess. I can understand that desire, and I don't mean to be argumentative, but I'm looking at it from the standpoint of a sysadmin. Right now, my systems use the internal entropy gathering. I _want_ to move to PRNGD. However, I don't want my systems to stop working entirely if PRNGD isn't running or if its socket gets clobbered. For instance, I need the ability to run ssh *clients* from the console in single-user mode, before PRNGD has started up. By not having an option to fall back, it's making it more difficult to justify the case for installing PRNGD, because functionality takes precedence over efficiency. I don't see a downside to having a configure-time option (off by default) like "--with-entropy-fallback" to use the built-in code if (and only if) the daemon were unreachable, unless the OpenSSH Portability Team considers it better to fail completely than to use the deprecated code. Am I missing something? I'd be willing to code the change. -- 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 strube at physik3.gwdg.de Sat Sep 29 00:19:50 2001 From: strube at physik3.gwdg.de (Hans Werner Strube) Date: Fri, 28 Sep 2001 16:19:50 +0200 (MET DST) Subject: openssh-2.9p2, short hostnames Message-ID: <200109281419.QAA17926@marc.physik3.gwdg.de> For systems where the local hostname is obtained as a short name without domain, there should be a ssh_config option "DefaultDomain" as in ssh-3.x from ssh.com. For the server, there might be a corresponding option in order to strip the domain name from the remote client name (if it matches the server's DefaultDomain) for use in auth_rhost2, since netgroups usually contain short names in this case. These applies especially to Solaris with NIS hosts and netgroup maps. Hans Werner Strube strube at physik3.gwdg.de Drittes Physikalisches Institut, Univ. Goettingen Buergerstr. 42-44, D-37073 Goettingen, Germany From ehrlich at edison.ee.psu.edu Sat Sep 29 01:15:55 2001 From: ehrlich at edison.ee.psu.edu (Daniel Ehrlich) Date: Fri, 28 Sep 2001 11:15:55 -0400 (EDT) Subject: Small buglet in openssh-2.9.9p2/session.c Message-ID: <200109281515.f8SFFtB28376@nyquist.ee.psu.edu> Trying to use something before it is defined. *** session.c- Fri Sep 28 11:13:25 2001 --- session.c Fri Sep 28 10:05:48 2001 *************** *** 139,144 **** --- 139,148 ---- static void session_close(Session *); static int session_pty_req(Session *); + #ifdef LOGIN_NEEDS_UTMPX + static void do_pre_login(Session *s); + #endif /* LOGIN_NEEDS_UTMPX */ + /* import */ extern ServerOptions options; extern char *__progname; -- Dan Ehrlich Electrical Engineering Penn State University ehrlich at ee.psu.edu From David.Thiede at pnl.gov Sat Sep 29 01:26:02 2001 From: David.Thiede at pnl.gov (Dave Thiede) Date: Fri, 28 Sep 2001 08:26:02 -0700 (PDT) Subject: Not enough entropy in RNG Message-ID: I have been experiencing problems with remote data collection systems reporting not enough entropy in RNG. It mostly seems to be self correcting since a retry of the data transport succeeds. One system however shows the following everytime an ssh connection is attempted. Interactive commands do not seem to be affected. I have perused the code but the entropy gatherer seems to be fairly simple and I see no reason for the commands to be mostly timing out. There must be some kind of timer in the ssh code to cause this that I haven't found yet. This system is running Solaris 5.7 with a really old version of openSSH as you can see. There are no X windows on these sysetms nor usually any keyboard interaction. I have a task to upgrade these systems but from the release notes, I don't have a very high confidence that an upgrade will solve this specific problem. Can anyone shed some light on this situation or provide some pointers to better ssh system administration information? I have seen this subject pop up before and haven't been able to find a satisfactory explaination or solution to entropy problems. Dave SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0. Compiled with SSL (0x0090581f). debug: Reading configuration data ~user/.ssh/config debug: ssh_connect: getuid 100 geteuid 0 anon 0 debug: Connecting to remote-site [ip-address] port 22. debug: Command 'ls -alni /var/adm' timed out debug: Command 'ls -alni /var/mail' exit status was 2 debug: Command 'ls -alni /proc' timed out debug: Command 'ls -alni /tmp' timed out debug: Command 'netstat -an' timed out debug: Command 'netstat -in' timed out debug: Command 'netstat -rn' timed out debug: Command 'netstat -pn' timed out debug: Command 'netstat -s' timed out debug: Command 'arp -a -n' timed out debug: Command 'ifconfig -a' timed out debug: Command 'ps -al' timed out debug: Command 'ps -efl' timed out debug: Command 'w' timed out debug: Command 'last' timed out debug: Command 'df' timed out debug: Command 'vmstat' timed out debug: Command 'ipcs -a' timed out debug: Command 'tail -200 /var/log/syslog' timed out debug: Command 'tail -200 /var/adm/messages' timed out debug: Seeded RNG with 8 bytes from programs debug: Seeded RNG with 3 bytes from system calls Not enough entropy in RNG debug: Calling cleanup 0x4b530(0x0) debug: writing PRNG seed to file ~user/.ssh/prng_seed --------------------------------------------------------------------- To unsubscribe, e-mail: secureshell-unsubscribe at securityfocus.com For additional commands, e-mail: secureshell-help at securityfocus.com From markus at openbsd.org Sat Sep 29 01:41:55 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 28 Sep 2001 17:41:55 +0200 Subject: OpenSSH_2.9.9p2 and client config In-Reply-To: <20010928091046.A7247@elektroni.ee.tut.fi>; from kaukasoi@elektroni.ee.tut.fi on Fri, Sep 28, 2001 at 09:10:46AM +0300 References: <20010928091046.A7247@elektroni.ee.tut.fi> Message-ID: <20010928174155.A28279@faui02.informatik.uni-erlangen.de> that's a bug. 2.9.9 reads system config first. On Fri, Sep 28, 2001 at 09:10:46AM +0300, Petri Kaukasoina wrote: > Hi > > I think there is a problem is OpenSSH_2.9.9p2. Suppose I have in > /etc/ssh/ssh_config just this and nothing more: > > Host * > ForwardX11 yes > > and in ~/.ssh/config: > > Host * > ForwardX11 no > > ssh -v tells they are read ok: > > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Reading configuration data /home/kaukasoi/.ssh/config > debug1: Applying options for * > > but still it opens the X channel: > > debug1: Requesting X11 forwarding with authentication spoofing. > > OpenSSH_2.9p1 didn't do that. From markus at openbsd.org Sat Sep 29 01:44:44 2001 From: markus at openbsd.org (Markus Friedl) Date: Fri, 28 Sep 2001 17:44:44 +0200 Subject: openssh-2.9p2, auth2.c In-Reply-To: <200109280846.KAA17501@marc.physik3.gwdg.de>; from strube@physik3.gwdg.de on Fri, Sep 28, 2001 at 10:46:13AM +0200 References: <200109280846.KAA17501@marc.physik3.gwdg.de> Message-ID: <20010928174444.A27429@folly> On Fri, Sep 28, 2001 at 10:46:13AM +0200, Hans Werner Strube wrote: > Even with option "HostbasedUsesNameFromPacketOnly yes", the trailing > dot in chost should be stripped before auth_rhosts2() is called from > hostbased_key_allowed(). why? From strube at physik3.gwdg.de Sat Sep 29 01:50:01 2001 From: strube at physik3.gwdg.de (Hans Werner Strube) Date: Fri, 28 Sep 2001 17:50:01 +0200 (MET DST) Subject: openssh-2.9p2, auth2.c Message-ID: <200109281550.RAA18163@marc.physik3.gwdg.de> > On Fri, Sep 28, 2001 at 10:46:13AM +0200, Hans Werner Strube wrote: > > Even with option "HostbasedUsesNameFromPacketOnly yes", the trailing > > dot in chost should be stripped before auth_rhosts2() is called from > > hostbased_key_allowed(). > > why? > Because otherwise the host names in /etc/hosts.equiv, .shosts etc. would also have to be terminated by a dot to match. From alaric at babcom.com Sat Sep 29 02:07:56 2001 From: alaric at babcom.com (Phil Stracchino) Date: Fri, 28 Sep 2001 09:07:56 -0700 Subject: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: ; from djm@mindrot.org on Fri, Sep 28, 2001 at 08:04:36PM +1000 References: <20010927232621.A24206@babylon5.babcom.com> Message-ID: <20010928090756.A4045@babylon5.babcom.com> On Fri, Sep 28, 2001 at 08:04:36PM +1000, Damien Miller wrote: > On Thu, 27 Sep 2001, Phil Stracchino wrote: > > > I have finally managed to isolate this down to the following: For SSH2 > > DSA and RSA keys, the OpenSSL PEM_read_PrivateKey() macro, called from > > authfile.c line 448: > > > > pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase); > > > > is consistently failing and always returns NULL, whereas it should be > > returning a EVP_PKEY struct with pk->type containing either EVP_PKEY_RSA > > or EVP_PKEY_DSA. As far as I can see from the OpenSSL code, this means > > that BIO_new(BIO_s_file()) has to be returning NULL, but that's as far as > > I can figure it out; the internals of OpenSSL are utterly impenetrable to > > me. > > > > Any suggestions, anyone? I think I've taken this problem about as far as > > I can diagnose it myself. > > Have you ruled out corruption of the keyfile itself? I have. The keyfile works fine on the Solaris machine next to me. > Did OpenSSL pass its own self-tests? All of them, I believe. On the last install I paid particular attention to the PEM tests, and they all passed. > When you compiled OpenSSL or OpenSSH, did you have any old OpenSSL header > files lying around? These are a frequent cause of weird problems. Probably the installed headers, yes, though at this point I've installed 0.9.6b about six times and one would think they'd all been replaced by now. > You could try putting a printf() before the above call to see if the > correct passphrase is getting passed to OpenSSL. I've traced the execution in gdb, and as far as I can tell everything is correct right up to that PEM_read_PrivateKey call. -- Linux Now! .........Because friends don't let friends use Microsoft. phil stracchino :: alaric at babcom.com :: halmayne at sourceforge.net unix ronin :::: renaissance man :::: mystic zen biker geek 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From eggert at twinsun.com Sat Sep 29 04:21:47 2001 From: eggert at twinsun.com (Paul Eggert) Date: Fri, 28 Sep 2001 11:21:47 -0700 (PDT) Subject: openssh-2.9.9p2 session.c uses two undeclared void functions Message-ID: <200109281821.f8SILlo04582@shade.twinsun.com> I found this problem on 32-bit Solaris 8 sparc. session.c uses two void functions without declaring them first; this violates the C standard, which requires declarations for such functions. Here's a patch. 2001-09-28 Paul Eggert * session.c (do_pre_login, record_utmp_only): Add missing declarations. =================================================================== RCS file: session.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- session.c 2001/09/16 22:17:15 2.9.9.2 +++ session.c 2001/09/28 18:17:11 2.9.9.2.0.1 @@ -126,6 +126,9 @@ static void session_pty_cleanup(void *); void session_proctitle(Session *); int session_setup_x11fwd(Session *); void do_exec_pty(Session *, const char *); +#ifdef LOGIN_NEEDS_UTMPX +static void do_pre_login(Session *s); +#endif void do_exec_no_pty(Session *, const char *); void do_exec(Session *, const char *); void do_login(Session *, const char *); @@ -147,6 +150,7 @@ extern int debug_flag; extern u_int utmp_len; extern int startup_pipe; extern void destroy_sensitive_data(void); +extern void record_utmp_only(pid_t, const char *, const char *, const char *, struct sockaddr *); /* original command from peer. */ const char *original_command = NULL; From eggert at twinsun.com Sat Sep 29 03:46:16 2001 From: eggert at twinsun.com (Paul Eggert) Date: Fri, 28 Sep 2001 10:46:16 -0700 (PDT) Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX In-Reply-To: <20010928114140.C9542@greenie.muc.de> (gert@greenie.muc.de) References: <200109280638.f8S6cDW18421@sic.twinsun.com> <20010928114140.C9542@greenie.muc.de> Message-ID: <200109281746.f8SHkGm04399@shade.twinsun.com> > From: Gert Doering > Date: Fri, 28 Sep 2001 11:41:40 +0200 > > > my theory is that you'll get an error message instead. > So it is. In that case, here is an (untested) patch to a recent Autoconf snapshot that should fix the problem. 2001-09-28 Paul Eggert * doc/autoconf.texi (Limitations of Usual Tools): Document that some older sed implementations can't handle nested parenthesization. * lib/autoconf/status.m4 (AC_OUTPUT_MAKE_DEFS): Don't use nested parenthesization. This patch was originally suggested to bug-autoconf by Philippe De Muyter on 2000-05-28, but somehow it didn't get incorporated then. diff -pru autoconf-fiy0/doc/autoconf.texi autoconf-fiy1/doc/autoconf.texi --- autoconf-fiy0/doc/autoconf.texi Thu Sep 27 12:17:00 2001 +++ autoconf-fiy1/doc/autoconf.texi Fri Sep 28 10:19:26 2001 @@ -9129,6 +9129,9 @@ deletes only lines that contain the lite Anchors (@samp{^} and @samp{$}) inside groups are not portable. +Nested parenthesization in patterns (e.g., @samp{\(\(a*\)b*)\)}) is not +supported by some older @command{sed} implementations like SVR3. + Nested groups are extremely portable, but there is at least one @command{sed} (System V/68 Base Operating System R3V7.1) that does not support it. diff -pru autoconf-fiy0/lib/autoconf/status.m4 autoconf-fiy1/lib/autoconf/status.m4 --- autoconf-fiy0/lib/autoconf/status.m4 Wed Sep 26 14:50:10 2001 +++ autoconf-fiy1/lib/autoconf/status.m4 Fri Sep 28 10:25:32 2001 @@ -545,7 +545,7 @@ dnl Double quote for `[ ]' and `define'. 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 eggert at twinsun.com Sat Sep 29 04:47:04 2001 From: eggert at twinsun.com (Paul Eggert) Date: Fri, 28 Sep 2001 11:47:04 -0700 (PDT) Subject: openssh-2.9.9p2 assumes pid_t, uid_t, etc. are not 'long' Message-ID: <200109281847.f8SIl4504616@shade.twinsun.com> openssh-2.9.9p2 assumes that pid_t, uid_t, gid_t, and mode_t are no wider than int. GCC complains about this assumption on 32-bit Solaris 8 sparc, where these types are 'long', not 'int'. This isn't an actual problem at runtime on this host, as long and int are the same width, but it is a problem on other hosts where pid_t is wider than int. E.g., I've heard that 64-bit AIX has 64-bit pid_t in some compilation environments. Here is a patch. 2001-09-28 Paul Eggert * authfile.c (key_perm_ok): Work even if system integer types are 'long', not 'int'. * entropy.c (prng_check_seedfile, prng_write_seedfile, prng_read_seedfile): Likewise. * serverloop.c (server_loop, server_loop2): Likewise. * session.c (session_dump, session_by_pid, session_exit_message, session_close_by_pid, session_have_children, session_close_by_channel): Likewise. * ssh-agent.c, sshd.c (main): Likewise. * sshpty.c (pty_setowner): Likewise. * uidswap.c: (temporarily_use_uid): Likewise. =================================================================== RCS file: authfile.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- authfile.c 2001/09/23 13:53:22 2.9.9.2 +++ authfile.c 2001/09/28 18:37:50 2.9.9.2.0.1 @@ -501,7 +501,7 @@ key_perm_ok(int fd, const char *filename error("@ WARNING: UNPROTECTED PRIVATE KEY FILE! @"); error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"); error("Permissions 0%3.3o for '%s' are too open.", - st.st_mode & 0777, filename); + (int) (st.st_mode & 0777), filename); error("It is recommended that your private key files are NOT accessible by others."); error("This private key will be ignored."); return 0; =================================================================== RCS file: entropy.c,v retrieving revision 2.9 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9 -r2.9.9.2.0.1 --- entropy.c 2001/08/06 06:51:49 2.9 +++ entropy.c 2001/09/28 18:37:50 2.9.9.2.0.1 @@ -596,8 +596,8 @@ prng_check_seedfile(char *filename) { /* mode 0600, owned by root or the current user? */ if (((st.st_mode & 0177) != 0) || !(st.st_uid == original_uid)) { - debug("WARNING: PRNG seedfile %.100s must be mode 0600, owned by uid %d", - filename, getuid()); + debug("WARNING: PRNG seedfile %.100s must be mode 0600, owned by uid %ld", + filename, (long)getuid()); return(0); } @@ -621,8 +621,8 @@ prng_write_seedfile(void) { pw = getpwuid(original_uid); if (pw == NULL) - fatal("Couldn't get password entry for current user (%i): %s", - original_uid, strerror(errno)); + fatal("Couldn't get password entry for current user (%ld): %s", + (long)original_uid, strerror(errno)); /* Try to ensure that the parent directory is there */ snprintf(filename, sizeof(filename), "%.512s/%s", pw->pw_dir, @@ -660,8 +660,8 @@ prng_read_seedfile(void) { pw = getpwuid(original_uid); if (pw == NULL) - fatal("Couldn't get password entry for current user (%i): %s", - original_uid, strerror(errno)); + fatal("Couldn't get password entry for current user (%ld): %s", + (long)original_uid, strerror(errno)); snprintf(filename, sizeof(filename), "%.512s/%s", pw->pw_dir, SSH_PRNG_SEED_FILE); =================================================================== RCS file: serverloop.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- serverloop.c 2001/09/18 05:53:13 2.9.9.2 +++ serverloop.c 2001/09/28 18:37:50 2.9.9.2.0.1 @@ -631,8 +631,8 @@ server_loop(pid_t pid, int fdin_arg, int if (wait_pid == -1) packet_disconnect("wait: %.100s", strerror(errno)); else if (wait_pid != pid) - error("Strange, wait returned pid %d, expected %d", - wait_pid, pid); + error("Strange, wait returned pid %ld, expected %ld", + (long)wait_pid, (long)pid); /* Check if it exited normally. */ if (WIFEXITED(wait_status)) { @@ -730,7 +730,7 @@ server_loop2(Authctxt *authctxt) if (pid > 0) session_close_by_pid(pid, status); else { - error("waitpid returned %d: %s", pid, strerror(errno)); + error("waitpid returned %ld: %s", (long)pid, strerror(errno)); break; } } =================================================================== RCS file: session.c,v retrieving revision 2.9.9.2.0.1 retrieving revision 2.9.9.2.0.2 diff -pu -r2.9.9.2.0.1 -r2.9.9.2.0.2 --- session.c 2001/09/28 18:17:11 2.9.9.2.0.1 +++ session.c 2001/09/28 18:37:50 2.9.9.2.0.2 @@ -1539,12 +1539,12 @@ session_dump(void) int i; for(i = 0; i < MAX_SESSIONS; i++) { Session *s = &sessions[i]; - debug("dump: used %d session %d %p channel %d pid %d", + debug("dump: used %d session %d %p channel %d pid %ld", s->used, s->self, s, s->chanid, - s->pid); + (long)s->pid); } } @@ -1586,13 +1586,13 @@ static Session * session_by_pid(pid_t pid) { int i; - debug("session_by_pid: pid %d", pid); + debug("session_by_pid: pid %ld", (long)pid); for(i = 0; i < MAX_SESSIONS; i++) { Session *s = &sessions[i]; if (s->used && s->pid == pid) return s; } - error("session_by_pid: unknown pid %d", pid); + error("session_by_pid: unknown pid %ld", (long)pid); session_dump(); return NULL; } @@ -1874,8 +1874,8 @@ session_exit_message(Session *s, int sta if (c == NULL) fatal("session_exit_message: session %d: no channel %d", s->self, s->chanid); - debug("session_exit_message: session %d channel %d pid %d", - s->self, s->chanid, s->pid); + debug("session_exit_message: session %d channel %d pid %ld", + s->self, s->chanid, (long)s->pid); if (WIFEXITED(status)) { channel_request_start(s->chanid, @@ -1916,7 +1916,7 @@ session_exit_message(Session *s, int sta static void session_close(Session *s) { - debug("session_close: session %d pid %d", s->self, s->pid); + debug("session_close: session %d pid %ld", s->self, (long)s->pid); if (s->ttyfd != -1) { fatal_remove_cleanup(session_pty_cleanup, (void *)s); session_pty_cleanup(s); @@ -1938,7 +1938,7 @@ session_close_by_pid(pid_t pid, int stat { Session *s = session_by_pid(pid); if (s == NULL) { - debug("session_close_by_pid: no session for pid %d", pid); + debug("session_close_by_pid: no session for pid %ld", (long)pid); return; } if (s->chanid != -1) @@ -1954,7 +1954,7 @@ session_have_children(void) for(i = 0; i < MAX_SESSIONS; i++) { Session *s = &sessions[i]; if (s->used && s->pid != -1) { - debug("session_have_children: id %d pid %d", i, s->pid); + debug("session_have_children: id %d pid %ld", i, (long)s->pid); return 1; } } @@ -1978,15 +1978,15 @@ session_close_by_channel(int id, void *a channel_cancel_cleanup(s->chanid); s->chanid = -1; - debug("session_close_by_channel: channel %d kill %d", id, s->pid); + debug("session_close_by_channel: channel %d kill %ld", id, (long)s->pid); if (s->pid == 0) { /* close session immediately */ session_close(s); } else { /* notify child, delay session cleanup */ if (kill(s->pid, (s->ttyfd == -1) ? SIGTERM : SIGHUP) < 0) - error("session_close_by_channel: kill %d: %s", - s->pid, strerror(errno)); + error("session_close_by_channel: kill %ld: %s", + (long)s->pid, strerror(errno)); } } =================================================================== RCS file: ssh-agent.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- ssh-agent.c 2001/08/06 22:06:35 2.9.9.2 +++ ssh-agent.c 2001/09/28 18:37:50 2.9.9.2.0.1 @@ -912,7 +912,7 @@ main(int ac, char **av) format = c_flag ? "unsetenv %s;\n" : "unset %s;\n"; printf(format, SSH_AUTHSOCKET_ENV_NAME); printf(format, SSH_AGENTPID_ENV_NAME); - printf("echo Agent pid %d killed;\n", pid); + printf("echo Agent pid %ld killed;\n", (long)pid); exit(0); } parent_pid = getpid(); @@ -965,7 +965,7 @@ main(int ac, char **av) format = c_flag ? "setenv %s %s;\n" : "%s=%s; export %s;\n"; printf(format, SSH_AUTHSOCKET_ENV_NAME, socket_name, SSH_AUTHSOCKET_ENV_NAME); - printf("echo Agent pid %d;\n", parent_pid); + printf("echo Agent pid %ld;\n", (long)parent_pid); goto skip; } pid = fork(); @@ -982,7 +982,7 @@ main(int ac, char **av) SSH_AUTHSOCKET_ENV_NAME); printf(format, SSH_AGENTPID_ENV_NAME, pidstrbuf, SSH_AGENTPID_ENV_NAME); - printf("echo Agent pid %d;\n", pid); + printf("echo Agent pid %ld;\n", (long)pid); exit(0); } if (setenv(SSH_AUTHSOCKET_ENV_NAME, socket_name, 1) == -1 || =================================================================== RCS file: sshd.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- sshd.c 2001/09/18 04:03:04 2.9.9.2 +++ sshd.c 2001/09/28 18:37:50 2.9.9.2.0.1 @@ -1068,7 +1068,7 @@ main(int ac, char **av) if (pid < 0) error("fork: %.100s", strerror(errno)); else - debug("Forked child %d.", pid); + debug("Forked child %ld.", (long)pid); close(startup_p[1]); =================================================================== RCS file: sshpty.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- sshpty.c 2001/08/14 20:41:35 2.9.9.2 +++ sshpty.c 2001/09/28 18:37:50 2.9.9.2.0.1 @@ -381,12 +381,12 @@ pty_setowner(struct passwd *pw, const ch if (chown(ttyname, pw->pw_uid, gid) < 0) { if (errno == EROFS && (st.st_uid == pw->pw_uid || st.st_uid == 0)) - error("chown(%.100s, %d, %d) failed: %.100s", - ttyname, pw->pw_uid, gid, + error("chown(%.100s, %ld, %ld) failed: %.100s", + ttyname, (long)pw->pw_uid, (long)gid, strerror(errno)); else - fatal("chown(%.100s, %d, %d) failed: %.100s", - ttyname, pw->pw_uid, gid, + fatal("chown(%.100s, %ld, %ld) failed: %.100s", + ttyname, (long)pw->pw_uid, (long)gid, strerror(errno)); } } @@ -395,11 +395,11 @@ pty_setowner(struct passwd *pw, const ch if (chmod(ttyname, mode) < 0) { if (errno == EROFS && (st.st_mode & (S_IRGRP | S_IROTH)) == 0) - error("chmod(%.100s, 0%o) failed: %.100s", - ttyname, mode, strerror(errno)); + error("chmod(%.100s, 0%lo) failed: %.100s", + ttyname, (long)mode, strerror(errno)); else - fatal("chmod(%.100s, 0%o) failed: %.100s", - ttyname, mode, strerror(errno)); + fatal("chmod(%.100s, 0%lo) failed: %.100s", + ttyname, (long)mode, strerror(errno)); } } } =================================================================== RCS file: uidswap.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- uidswap.c 2001/08/15 23:17:22 2.9.9.2 +++ uidswap.c 2001/09/28 18:37:50 2.9.9.2.0.1 @@ -52,8 +52,8 @@ temporarily_use_uid(struct passwd *pw) #ifdef SAVED_IDS_WORK_WITH_SETEUID saved_euid = geteuid(); saved_egid = getegid(); - debug("temporarily_use_uid: %d/%d (e=%d)", - pw->pw_uid, pw->pw_gid, saved_euid); + debug("temporarily_use_uid: %ld/%ld (e=%ld)", + (long)pw->pw_uid, (long)pw->pw_gid, (long)saved_euid); if (saved_euid != 0) { privileged = 0; return; From eggert at twinsun.com Sat Sep 29 05:01:41 2001 From: eggert at twinsun.com (Paul Eggert) Date: Fri, 28 Sep 2001 12:01:41 -0700 (PDT) Subject: openssh-2.9.9p2 subscript violation problems with ctype macros Message-ID: <200109281901.f8SJ1f804623@shade.twinsun.com> In several places, openssh-2.9.9p2 passes a 'char' value to a ctype macro like 'isdigit'. This has undefined behavior on hosts with signed characters, if the character value happens to be negative. For example, isdigit('\200') expands to an array access that is a subscript error on hosts with signed characters where '\200' == -128. This leads to incorrect results, and possibly even core dumps. The C standard says that isdigit(X) has undefined behavior unless X == EOF || X == (unsigned char)X. Here is a patch. This patch occasionally uses '0'<=X && X<='9' rather than isdigit(X), as it's faster on most modern hosts (a subtract and a compare, rather than a reference through memory and then a test). 2001-09-28 Paul Eggert * canohost.c (get_remote_hostname): Don't pass negative chars to ctype macros. * match.c (match_hostname): Likewise. * openbsd-compat/base64.c (b64_ntop): Likewise. * openbsd-compat/inet_aton.c (inet_aton): Likewise. * openbsd-compat/mktemp.c (_gettemp): Likewise. * openbsd-compat/readpassphrase.c (readpassphrase): Likewise. * scp.c (sink): Likewise. * sshconnect.c (sshconnect.c): Likewise. =================================================================== RCS file: canohost.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- canohost.c 2001/06/25 05:01:24 2.9.9.2 +++ canohost.c 2001/09/28 18:48:11 2.9.9.2.0.1 @@ -87,8 +87,8 @@ get_remote_hostname(int socket, int reve * of this software). */ for (i = 0; name[i]; i++) - if (isupper(name[i])) - name[i] = tolower(name[i]); + if (isupper((unsigned char)name[i])) + name[i] = tolower((unsigned char)name[i]); if (!reverse_mapping_check) return xstrdup(name); =================================================================== RCS file: match.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- match.c 2001/07/04 04:56:46 2.9.9.2 +++ match.c 2001/09/28 18:48:11 2.9.9.2.0.1 @@ -134,7 +134,7 @@ match_hostname(const char *host, const c for (subi = 0; i < len && subi < sizeof(sub) - 1 && pattern[i] != ','; subi++, i++) - sub[subi] = isupper(pattern[i]) ? tolower(pattern[i]) : pattern[i]; + sub[subi] = isupper((unsigned char)pattern[i]) ? tolower((unsigned char)pattern[i]) : pattern[i]; /* If subpattern too long, return failure (no match). */ if (subi >= sizeof(sub) - 1) return 0; =================================================================== RCS file: openbsd-compat/base64.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- openbsd-compat/base64.c 2001/01/31 21:52:03 2.9.9.2 +++ openbsd-compat/base64.c 2001/09/28 18:48:11 2.9.9.2.0.1 @@ -199,7 +199,8 @@ b64_ntop(u_char const *src, size_t srcle int b64_pton(char const *src, u_char *target, size_t targsize) { - int tarindex, state, ch; + int tarindex, state; + unsigned char ch; char *pos; state = 0; =================================================================== RCS file: openbsd-compat/inet_aton.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- openbsd-compat/inet_aton.c 2001/01/31 21:52:03 2.9.9.2 +++ openbsd-compat/inet_aton.c 2001/09/28 18:48:11 2.9.9.2.0.1 @@ -114,7 +114,7 @@ inet_aton(const char *cp, struct in_addr * Values are specified as for C: * 0x=hex, 0=octal, isdigit=decimal. */ - if (!isdigit(c)) + if (! ('0' <= c && c <= '9')) return (0); val = 0; base = 10; if (c == '0') { @@ -125,12 +125,14 @@ inet_aton(const char *cp, struct in_addr base = 8; } for (;;) { - if (isascii(c) && isdigit(c)) { + if ('0' <= c && c <= '9') { val = (val * base) + (c - '0'); c = *++cp; - } else if (base == 16 && isascii(c) && isxdigit(c)) { - val = (val << 4) | - (c + 10 - (islower(c) ? 'a' : 'A')); + } else if (base == 16 && 'a' <= c && c <= 'f') { + val = (val << 4) | (c + 10 - 'a'); + c = *++cp; + } else if (base == 16 && 'A' <= c && c <= 'F') { + val = (val << 4) | (c + 10 - 'A'); c = *++cp; } else break; @@ -152,7 +154,7 @@ inet_aton(const char *cp, struct in_addr /* * Check for trailing characters. */ - if (c != '\0' && (!isascii(c) || !isspace(c))) + if (c != '\0' && (!isascii(c) || !isspace((unsigned char)c))) return (0); /* * Concoct the address according to =================================================================== RCS file: openbsd-compat/mktemp.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- openbsd-compat/mktemp.c 2001/01/31 21:52:03 2.9.9.2 +++ openbsd-compat/mktemp.c 2001/09/28 18:48:11 2.9.9.2.0.1 @@ -164,7 +164,7 @@ _gettemp(path, doopen, domkdir, slen) return (0); *trv++ = 'a'; } else { - if (isdigit(*trv)) + if ('0' <= *trv && *trv <= '9') *trv = 'a'; else if (*trv == 'z') /* inc from z to A */ *trv = 'A'; =================================================================== RCS file: openbsd-compat/readpassphrase.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- openbsd-compat/readpassphrase.c 2001/06/29 12:35:13 2.9.9.2 +++ openbsd-compat/readpassphrase.c 2001/09/28 18:48:11 2.9.9.2.0.1 @@ -118,11 +118,11 @@ readpassphrase(prompt, buf, bufsiz, flag if (p < end) { if ((flags & RPP_SEVENBIT)) ch &= 0x7f; - if (isalpha(ch)) { + if (isalpha((unsigned char)ch)) { if ((flags & RPP_FORCELOWER)) - ch = tolower(ch); + ch = tolower((unsigned char)ch); if ((flags & RPP_FORCEUPPER)) - ch = toupper(ch); + ch = toupper((unsigned char)ch); } *p++ = ch; } =================================================================== RCS file: scp.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- scp.c 2001/09/20 00:57:56 2.9.9.2 +++ scp.c 2001/09/28 18:48:11 2.9.9.2.0.1 @@ -761,7 +761,7 @@ sink(argc, argv) if (*cp++ != ' ') SCREWUP("mode not delimited"); - for (size = 0; isdigit(*cp);) + for (size = 0; '0' <= *cp && *cp <= '9';) size = size * 10 + (*cp++ - '0'); if (*cp++ != ' ') SCREWUP("size not delimited"); =================================================================== RCS file: sshconnect.c,v retrieving revision 2.9.9.2 retrieving revision 2.9.9.2.0.1 diff -pu -r2.9.9.2 -r2.9.9.2.0.1 --- sshconnect.c 2001/08/07 22:29:09 2.9.9.2 +++ sshconnect.c 2001/09/28 18:48:11 2.9.9.2.0.1 @@ -881,8 +881,8 @@ ssh_login(Key **keys, int nkeys, const c /* Convert the user-supplied hostname into all lowercase. */ host = xstrdup(orighost); for (cp = host; *cp; cp++) - if (isupper(*cp)) - *cp = tolower(*cp); + if (isupper((unsigned char)*cp)) + *cp = tolower((unsigned char)*cp); /* Exchange protocol version identification strings with the server. */ ssh_exchange_identification(); From brent at phys.ufl.edu Sat Sep 29 06:24:53 2001 From: brent at phys.ufl.edu (Brent A Nelson) Date: Fri, 28 Sep 2001 16:24:53 -0400 (EDT) Subject: 2.9.9p2 bug in PAM support Message-ID: With OpenSSH 2.9.9p2 as the server, I'm not able to do scp or "ssh machinename command" in general to any of my Suns! I tracked this down a bit; the problem occurs only when PAM support is enabled. However, if I remove line 430 of session.c, "do_pam_session(s->pw->pw_name, NULL);" inside of do_exec_no_pty, the problem goes away. It looks like the following entry in the Changelog may be responsible: 20010627 - (djm) Reintroduce pam_session call for non-pty sessions. Let me know if you need any additional info to track this down. Thanks, Brent Nelson Director of Computing Dept. of Physics University of Florida From bowman at math.ualberta.ca Sat Sep 29 07:10:47 2001 From: bowman at math.ualberta.ca (John Bowman) Date: 28 Sep 2001 21:10:47 -0000 Subject: [PATCH] fix for Linux hang on exit bug in 2.9.9p2 Message-ID: <20010928211047.2637.qmail@wizard.math.ualberta.ca> As you are now probably aware, the portability team for openssh still has not fixed the hang-on-exit bug in the 2.9.9p2 release. Attached is a patch for 2.9.9p2 that fixes the hang-on-exit bug for Linux systems. It also adds a useful exit delay feature that has also not yet been incorporated into the main sources. For more information, see the SNFS (secure NFS) web page: http://www.math.ualberta.ca/imaging/snfs -- John Bowman University of Alberta diff -u openssh-2.9.9p2/channels.c openssh-2.9.9p2J/channels.c --- openssh-2.9.9p2/channels.c Mon Sep 17 23:53:12 2001 +++ openssh-2.9.9p2J/channels.c Thu Sep 27 22:12:43 2001 @@ -1527,8 +1527,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); + } if (chan_is_dead(c)) { /* * we have to remove the fd's from the select mask diff -u openssh-2.9.9p2/channels.h openssh-2.9.9p2J/channels.h --- openssh-2.9.9p2/channels.h Mon Sep 17 23:51:14 2001 +++ openssh-2.9.9p2J/channels.h Thu Sep 27 22:16:44 2001 @@ -219,6 +219,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 -u openssh-2.9.9p2/clientloop.c openssh-2.9.9p2J/clientloop.c --- openssh-2.9.9p2/clientloop.c Mon Sep 17 23:51:14 2001 +++ openssh-2.9.9p2J/clientloop.c Fri Sep 28 12:47:09 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,11 +349,12 @@ 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()) { if (!packet_have_data_to_write()) return; } else { - FD_SET(connection_in, *readsetp); + FD_SET(connection_in, *readsetp); } } @@ -364,7 +371,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]; /* @@ -381,7 +398,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 @@ -442,9 +460,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; } @@ -753,7 +774,7 @@ if (id != session_ident) error("client_channel_closed: id %d != session_ident %d", id, session_ident); - session_closed = 1; + session_status = (options.sleep >= 0) ? SessionWait : SessionClose; if (in_raw_mode()) leave_raw_mode(); } @@ -778,6 +799,7 @@ start_time = get_current_time(); /* Initialize variables. */ + if(!have_pty) session_status=SessionWait; escape_pending = 0; last_was_cr = 1; exit_status = -1; @@ -842,7 +864,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 -u openssh-2.9.9p2/nchan.c openssh-2.9.9p2J/nchan.c --- openssh-2.9.9p2/nchan.c Thu Sep 20 13:33:33 2001 +++ openssh-2.9.9p2J/nchan.c Thu Sep 27 22:09:31 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 @@ -524,7 +524,7 @@ c->self, c->wfd, strerror(errno)); } } -static void +void chan_shutdown_read(Channel *c) { if (compat20 && c->type == SSH_CHANNEL_LARVAL) diff -u openssh-2.9.9p2/readconf.c openssh-2.9.9p2J/readconf.c --- openssh-2.9.9p2/readconf.c Wed Sep 19 18:57:56 2001 +++ openssh-2.9.9p2J/readconf.c Thu Sep 27 22:17:56 2001 @@ -115,7 +115,7 @@ oKbdInteractiveAuthentication, oKbdInteractiveDevices, oHostKeyAlias, oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, - oClearAllForwardings + oClearAllForwardings, oSleep } OpCodes; /* Textual representations of the tokens. */ @@ -186,6 +186,7 @@ { "bindaddress", oBindAddress }, { "smartcarddevice", oSmartcardDevice }, { "clearallforwardings", oClearAllForwardings }, + { "sleep", oSleep }, { NULL, 0 } }; @@ -523,6 +524,10 @@ intptr = &options->connection_attempts; goto parse_int; + case oSleep: + intptr = &options->sleep; + goto parse_int; + case oCipher: intptr = &options->cipher; arg = strdelim(&s); @@ -793,6 +798,7 @@ options->preferred_authentications = NULL; options->bind_address = NULL; options->smartcard_device = NULL; + options->sleep = -1; } /* diff -u openssh-2.9.9p2/readconf.h openssh-2.9.9p2J/readconf.h --- openssh-2.9.9p2/readconf.h Wed Sep 19 18:57:56 2001 +++ openssh-2.9.9p2J/readconf.h Thu Sep 27 22:01:07 2001 @@ -101,6 +101,7 @@ int num_remote_forwards; Forward remote_forwards[SSH_MAX_FORWARDS_PER_DIRECTION]; int clear_forwardings; + int sleep; /* Exit delay in seconds */ } Options; diff -u openssh-2.9.9p2/session.c openssh-2.9.9p2J/session.c --- openssh-2.9.9p2/session.c Sun Sep 16 16:17:15 2001 +++ openssh-2.9.9p2J/session.c Thu Sep 27 22:01:07 2001 @@ -1906,6 +1906,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 -u openssh-2.9.9p2/ssh.c openssh-2.9.9p2J/ssh.c --- openssh-2.9.9p2/ssh.c Mon Sep 24 16:04:03 2001 +++ openssh-2.9.9p2J/ssh.c Thu Sep 27 22:04:49 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) { From alaric at babcom.com Sat Sep 29 08:03:30 2001 From: alaric at babcom.com (Phil Stracchino) Date: Fri, 28 Sep 2001 15:03:30 -0700 Subject: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: <20010928110025.A8067@babylon5.babcom.com>; from alaric@babcom.com on Fri, Sep 28, 2001 at 11:00:25AM -0700 References: <20010927232621.A24206@babylon5.babcom.com> <20010928090756.A4045@babylon5.babcom.com> <3BB4B196.84437501@celocom.com> <20010928110025.A8067@babylon5.babcom.com> Message-ID: <20010928150330.A24342@babylon5.babcom.com> On Fri, Sep 28, 2001 at 11:00:25AM -0700, Phil Stracchino wrote: > On Fri, Sep 28, 2001 at 06:21:26PM +0100, Dr S N Henson wrote: > > Read the bit in the FAQ about adding an ERR_print_errors_fp() call then > > see what it says is the cause. I tried using ERR_print_errors_fp() in the appropriate location and it reported nothing. I therefore took a slightly different tack. I changed the error detection code in key_load_private_pem() in authfile.c from this: pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase); if (pk == NULL) { debug("PEM_read_PrivateKey failed"); (void)ERR_get_error(); } else if (pk->type == EVP_PKEY_RSA && .... to this: pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase); if (pk == NULL) { error("PEM_read_PrivateKey failed"); while (ERR_peek_error()) error("PEM error %ld: %s", ERR_peek_error(), ERR_error_string(ERR_get_error(), NULL)); } else if (pk->type == EVP_PKEY_RSA && .... Right up to the point at which that PEM_read_PrivateKey() call is executed, everything appears to be working perfectly. At the moment of making this call: filename is "/root/.ssh/id_dsa" passphrase contains the correct password fp is valid, and _IO_read_base points at the string: "-----BEGIN DSA PRIVATE KEY-----\nProc-Type: 4,ENCRYPTED\n DEK-Info: DES-EDE3-CBC," The passphrase supplied is known to be correct, and successfully unlocks this keyfile on a Solaris 8 machine which is running the same version of both OpenSSH and OpenSSL. Nevertheless, PEM_read_PrivateKey returns NULL, but according to ERR_peek_error(), no error has occurred. I am unable to trace into the PEM_read_PrivateKey() call using gdb. -- Linux Now! .........Because friends don't let friends use Microsoft. phil stracchino :: alaric at babcom.com :: halmayne at sourceforge.net unix ronin :::: renaissance man :::: mystic zen biker geek 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From abartlet at pcug.org.au Sat Sep 29 09:57:48 2001 From: abartlet at pcug.org.au (Andrew Bartlett) Date: Sat, 29 Sep 2001 09:57:48 +1000 Subject: 2.9.9p2 bug in PAM support References: Message-ID: <3BB50E7C.2B75643A@bartlett.house> Brent A Nelson wrote: > > With OpenSSH 2.9.9p2 as the server, I'm not able to do scp or "ssh > machinename command" in general to any of my Suns! > > I tracked this down a bit; the problem occurs only when PAM support is > enabled. However, if I remove line 430 of session.c, > "do_pam_session(s->pw->pw_name, NULL);" inside of do_exec_no_pty, the > problem goes away. > > It looks like the following entry in the Changelog may be responsible: > > 20010627 > - (djm) Reintroduce pam_session call for non-pty sessions. > > Let me know if you need any additional info to track this down. What happens if you define PAM_TTY_KLUDGE and recompile? There are a number of bugs in some PAM modules (pam_time.so notably) where they really object when you don't give them a TTY. This define just makes OpenSSH give 'ssh' as the tty. (The OpenSSH team are really in a bind here, as they have one group of people - like me - who want those session modules used, and another group for whome it locks them out. As you noted the previous version changed in your favor, but it was changed back on complaints from other users and a 'discussion' on BugTraq). Hope this helps, Andrew Bartlett -- Andrew Bartlett abartlet at pcug.org.au Samba Team member, Build Farm maintainer abartlet at samba.org Student Network Administrator, Hawker College abartlet at hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net From greg at cheers.bungi.com Sat Sep 29 11:21:18 2001 From: greg at cheers.bungi.com (Greg) Date: Fri, 28 Sep 2001 18:21:18 -0700 Subject: 2.9.9p2 bug in PAM support References: Message-ID: <3BB5220E.3080301@cheers.bungi.com> On 09/28/01 01:24 PM, Brent A Nelson wrote: > With OpenSSH 2.9.9p2 as the server, I'm not able to do scp or "ssh > machinename command" in general to any of my Suns! Me too. > I tracked this down a bit; the problem occurs only when PAM support is > enabled. However, if I remove line 430 of session.c, > "do_pam_session(s->pw->pw_name, NULL);" inside of do_exec_no_pty, the > problem goes away. > > It looks like the following entry in the Changelog may be responsible: > > 20010627 > - (djm) Reintroduce pam_session call for non-pty sessions. > > Let me know if you need any additional info to track this down. FYI. If pam_unix is used then at least one of PAM_TTY or PAM_RHOST must be set before calling pam_open_session or it's considered a PAM_SESSION_ERR. Cheers!greg From jurgen at botz.org Sat Sep 29 11:58:55 2001 From: jurgen at botz.org (Jurgen Botz) Date: Fri, 28 Sep 2001 18:58:55 -0700 Subject: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: Message from Phil Stracchino of "Thu, 27 Sep 2001 18:15:11 PDT." <20010927181511.A4363@babylon5.babcom.com> Message-ID: <200109290158.f8T1wt724966@nova.botz.org> Phil Stracchino wrote: > Entering from a tty, thus far, since I'm testing from a terminal and don't > know any way to force ssh-add (for example) to use ssh-askpass. [...] ssh-add < /dev/null (if stdin is not a tty it'll try ssh-askpass.) -- 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 openssh-unix-dev at thewrittenword.com Sat Sep 29 13:44:15 2001 From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com) Date: Fri, 28 Sep 2001 22:44:15 -0500 Subject: Fix to openbsd-compat/sigact.c for AC_SYS_LARGEFILE Message-ID: <20010928224415.A23714@oolong.il.thewrittenword.com> When AC_SYS_LARGEFILE comes back, it is important that "config.h" is included first. The patch below fixes this for openbsd-compat/sigact.c. -- albert chin (china at thewrittenword.com) -- snip snip --- openbsd-compat/sigact.c.orig Thu Sep 27 01:18:13 2001 +++ openbsd-compat/sigact.c Thu Sep 27 01:18:17 2001 @@ -33,8 +33,8 @@ * and: Eric S. Raymond * ****************************************************************************/ -#include #include "config.h" +#include #include "sigact.h" /* This file provides sigaction() emulation using sigvec() */ From openssh-unix-dev at thewrittenword.com Sat Sep 29 13:48:55 2001 From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com) Date: Fri, 28 Sep 2001 22:48:55 -0500 Subject: configure.in fixes for 2.9.9p2 Message-ID: <20010928224855.B23714@oolong.il.thewrittenword.com> configure.in patches for 2.9.9p2: 1. Allow --with-pcre to take a path specifying the root of the PCRE install (ROOT/include, ROOT/lib) 2. Ditto for --with-zlib 3. $no_libnsl and $no_libsocket can be determined programmatically 4. Check for innetgr, getspnam, and util in the default $LIBS before checking in -lrpc, -lgen, and -lutil, respectively 5. dirname() is in -lgen on some systems (Solaris 2.5.1, IRIX) -- albert chin (china at thewrittenword.com) -- snip snip --- configure.in.orig Thu Sep 27 01:16:56 2001 +++ configure.in Thu Sep 27 10:11:04 2001 @@ -320,34 +308,59 @@ ) AC_ARG_WITH(pcre, - [ --with-pcre Override built in regex library with pcre], + [ --with-pcre[[=PATH]] Override built in regex library with pcre + (optionally in PATH)], [ + case "$withval" in + no) ;; + *) + if test "x$withval" != "xyes"; then + CPPFLAGS="${CPPFLAGS} -I$withval/include" + LDFLAGS="${LDFLAGS} -L$withval/lib" + fi - AC_CHECK_LIB(pcre, pcre_info, - [ - AC_DEFINE(HAVE_LIBPCRE) - LIBS="$LIBS -lpcreposix -lpcre" - no_comp_check="yes" - ], - [ AC_MSG_ERROR([*** Can not locate pcre libraries.]) ] - ) + AC_CHECK_HEADER(pcreposix.h, + AC_CHECK_LIB(pcre, pcre_info,[ + AC_DEFINE(HAVE_LIBPCRE) + LIBS="$LIBS -lpcreposix -lpcre" + no_comp_check=yes], + AC_MSG_ERROR([*** unable to locate pcre library ***])), + AC_MSG_ERROR([*** unable to locate pcreposix.h include file ***])) + ;; + esac ] ) # Checks for libraries. -if test -z "$no_libnsl" ; then - AC_CHECK_LIB(nsl, yp_match, , ) -fi -if test -z "$no_libsocket" ; then - AC_CHECK_LIB(socket, main, , ) -fi +AC_CHECK_FUNC(yp_match, , AC_CHECK_LIB(nsl, yp_match)) +AC_CHECK_FUNC(setsockopt, , AC_CHECK_LIB(socket, setsockopt)) dnl SCO OS3 needs this for libwrap -AC_CHECK_LIB(rpc, innetgr, LIBS="-lrpc -lyp -lrpc $LIBS" , , -lyp -lrpc) +AC_CHECK_FUNC(innetgr, , + AC_CHECK_LIB(rpc, innetgr, LIBS="-lrpc -lyp -lrpc $LIBS" , , -lyp -lrpc)) + +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, + [ --with-zlib=PATH Use zlib in PATH], + [ + if test -d "$withval"; then + CPPFLAGS="${CPPFLAGS} -I$withval/include" + LDFLAGS="${LDFLAGS} -L$withval/lib" + fi + ] +) + +AC_CHECK_HEADER(zlib.h, + AC_CHECK_LIB(z, gzread, , + AC_MSG_ERROR([*** zlib missing. install first or check config.log ***])), + AC_MSG_ERROR([*** zlib missing. install first or check config.log ***])) -AC_CHECK_LIB(gen, getspnam, LIBS="$LIBS -lgen") -AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([*** zlib missing - please install first or check config.log ***])) -AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil") # We don't want to check if we did an pcre override. if test -z "$no_comp_check" ; then @@ -481,7 +494,14 @@ ) dnl Checks for library functions. -AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock dirname fchown fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getopt getnameinfo getrlimit getrusage getttyent glob inet_aton inet_ntoa inet_ntop innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty readpassphrase realpath rresvport_af setdtablesize setenv setegid seteuid setlogin setproctitle setresgid setreuid setrlimit setsid setvbuf sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep sysconf tcgetpgrp utimes vsnprintf vhangup waitpid _getpty __b64_ntop) +AC_CHECK_FUNCS(arc4random atexit b64_ntop bcopy bindresvport_sa clock fchown fchmod freeaddrinfo futimes gai_strerror getcwd getaddrinfo getgrouplist getopt getnameinfo getrlimit getrusage getttyent glob inet_aton inet_ntoa inet_ntop innetgr login_getcapbool md5_crypt memmove mkdtemp on_exit openpty readpassphrase realpath rresvport_af setdtablesize setenv setegid seteuid setlogin setproctitle setresgid setreuid setrlimit setsid setvbuf sigaction sigvec snprintf strerror strlcat strlcpy strmode strsep sysconf tcgetpgrp utimes vsnprintf vhangup waitpid _getpty __b64_ntop) + +dnl IRIX and Solaris 2.5.1 have dirname() in libgen +AC_CHECK_FUNCS(dirname, ,[ + AC_CHECK_LIB(gen, dirname,[ + LIBS="$LIBS -lgen" + AC_DEFINE(HAVE_DIRNAME)])]) + dnl Checks for time functions AC_CHECK_FUNCS(gettimeofday time) dnl Checks for libutil functions From openssh-unix-dev at thewrittenword.com Sat Sep 29 13:54:46 2001 From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com) Date: Fri, 28 Sep 2001 22:54:46 -0500 Subject: Better socklen_t test for 2.9.9p2 Message-ID: <20010928225446.A24671@oolong.il.thewrittenword.com> Better test for socklen_t equivalent (stolen from cURL). It requires autoconf 2.50. Against 2.9.9p2. -- albert chin (china at thewrittenword.com) -- snip snip --- aclocal.m4.orig Fri Sep 28 22:50:42 2001 +++ aclocal.m4 Thu Sep 27 01:53:23 2001 @@ -43,3 +43,43 @@ AC_SUBST($1) ]) +dnl Check for socklen_t: historically on BSD it is an int, and in +dnl POSIX 1g it is a type of its own, but some platforms use different +dnl types for the argument to getsockopt, getpeername, etc. So we +dnl have to test to find something that will work. +AC_DEFUN([TYPE_SOCKLEN_T], +[ + AC_CHECK_TYPE([socklen_t], ,[ + AC_MSG_CHECKING([for socklen_t equivalent]) + AC_CACHE_VAL([curl_cv_socklen_t_equiv], + [ + # Systems have either "struct sockaddr *" or + # "void *" as the second argument to getpeername + curl_cv_socklen_t_equiv= + for arg2 in "struct sockaddr" void; do + for t in int size_t unsigned long "unsigned long"; do + AC_TRY_COMPILE([ + #include + #include + + int getpeername (int, $arg2 *, $t *); + ],[ + $t len; + getpeername(0,0,&len); + ],[ + curl_cv_socklen_t_equiv="$t" + break + ]) + done + done + + if test "x$curl_cv_socklen_t_equiv" = x; then + AC_MSG_ERROR([Cannot find a type to use in place of socklen_t]) + fi + ]) + AC_MSG_RESULT($curl_cv_socklen_t_equiv) + AC_DEFINE_UNQUOTED(socklen_t, $curl_cv_socklen_t_equiv, + [type to use in place of socklen_t if not defined])], + [#include +#include ]) +]) --- configure.in.orig Thu Sep 27 01:16:56 2001 +++ configure.in Thu Sep 27 10:11:04 2001 @@ -929,20 +993,7 @@ AC_DEFINE(HAVE_U_CHAR) fi -AC_CACHE_CHECK([for socklen_t], ac_cv_have_socklen_t, [ - AC_TRY_COMPILE( - [ -#include -#include - ], - [socklen_t foo; foo = 1235;], - [ ac_cv_have_socklen_t="yes" ], - [ ac_cv_have_socklen_t="no" ] - ) -]) -if test "x$ac_cv_have_socklen_t" = "xyes" ; then - AC_DEFINE(HAVE_SOCKLEN_T) -fi +TYPE_SOCKLEN_T AC_CACHE_CHECK([for size_t], ac_cv_have_size_t, [ AC_TRY_COMPILE( --- defines.h.orig Thu Sep 27 01:54:38 2001 +++ defines.h Thu Sep 27 01:54:44 2001 @@ -243,11 +243,6 @@ # define HAVE_U_CHAR #endif /* HAVE_U_CHAR */ -#ifndef HAVE_SOCKLEN_T -typedef unsigned int socklen_t; -# define HAVE_SOCKLEN_T -#endif /* HAVE_SOCKLEN_T */ - #ifndef HAVE_SIZE_T typedef unsigned int size_t; # define HAVE_SIZE_T --- acconfig.h.orig Thu Sep 27 01:30:35 2001 +++ acconfig.h Thu Sep 27 01:54:33 2001 @@ -251,7 +251,6 @@ #undef HAVE_INT64_T #undef HAVE_U_INT64_T #undef HAVE_U_CHAR -#undef HAVE_SOCKLEN_T #undef HAVE_SIZE_T #undef HAVE_SSIZE_T #undef HAVE_CLOCK_T From mouring at etoh.eviladmin.org Sat Sep 29 14:09:48 2001 From: mouring at etoh.eviladmin.org (mouring at etoh.eviladmin.org) Date: Fri, 28 Sep 2001 23:09:48 -0500 (CDT) Subject: Better socklen_t test for 2.9.9p2 In-Reply-To: <20010928225446.A24671@oolong.il.thewrittenword.com> Message-ID: This is not directly cURL code, but cURL is under MIT/X or MPL licenses which are both semi-conflict with BSD license. We really should get someone at the project to give an ok to put the fragment under BSD. - Ben On Fri, 28 Sep 2001 openssh-unix-dev at thewrittenword.com wrote: > Better test for socklen_t equivalent (stolen from cURL). It requires > autoconf 2.50. Against 2.9.9p2. > > -- > albert chin (china at thewrittenword.com) > > -- snip snip > --- aclocal.m4.orig Fri Sep 28 22:50:42 2001 > +++ aclocal.m4 Thu Sep 27 01:53:23 2001 > @@ -43,3 +43,43 @@ > AC_SUBST($1) > ]) > > +dnl Check for socklen_t: historically on BSD it is an int, and in > +dnl POSIX 1g it is a type of its own, but some platforms use different > +dnl types for the argument to getsockopt, getpeername, etc. So we > +dnl have to test to find something that will work. > +AC_DEFUN([TYPE_SOCKLEN_T], > +[ > + AC_CHECK_TYPE([socklen_t], ,[ > + AC_MSG_CHECKING([for socklen_t equivalent]) > + AC_CACHE_VAL([curl_cv_socklen_t_equiv], > + [ > + # Systems have either "struct sockaddr *" or > + # "void *" as the second argument to getpeername > + curl_cv_socklen_t_equiv= > + for arg2 in "struct sockaddr" void; do > + for t in int size_t unsigned long "unsigned long"; do > + AC_TRY_COMPILE([ > + #include > + #include > + > + int getpeername (int, $arg2 *, $t *); > + ],[ > + $t len; > + getpeername(0,0,&len); > + ],[ > + curl_cv_socklen_t_equiv="$t" > + break > + ]) > + done > + done > + > + if test "x$curl_cv_socklen_t_equiv" = x; then > + AC_MSG_ERROR([Cannot find a type to use in place of socklen_t]) > + fi > + ]) > + AC_MSG_RESULT($curl_cv_socklen_t_equiv) > + AC_DEFINE_UNQUOTED(socklen_t, $curl_cv_socklen_t_equiv, > + [type to use in place of socklen_t if not defined])], > + [#include > +#include ]) > +]) > --- configure.in.orig Thu Sep 27 01:16:56 2001 > +++ configure.in Thu Sep 27 10:11:04 2001 > @@ -929,20 +993,7 @@ > AC_DEFINE(HAVE_U_CHAR) > fi > > -AC_CACHE_CHECK([for socklen_t], ac_cv_have_socklen_t, [ > - AC_TRY_COMPILE( > - [ > -#include > -#include > - ], > - [socklen_t foo; foo = 1235;], > - [ ac_cv_have_socklen_t="yes" ], > - [ ac_cv_have_socklen_t="no" ] > - ) > -]) > -if test "x$ac_cv_have_socklen_t" = "xyes" ; then > - AC_DEFINE(HAVE_SOCKLEN_T) > -fi > +TYPE_SOCKLEN_T > > AC_CACHE_CHECK([for size_t], ac_cv_have_size_t, [ > AC_TRY_COMPILE( > --- defines.h.orig Thu Sep 27 01:54:38 2001 > +++ defines.h Thu Sep 27 01:54:44 2001 > @@ -243,11 +243,6 @@ > # define HAVE_U_CHAR > #endif /* HAVE_U_CHAR */ > > -#ifndef HAVE_SOCKLEN_T > -typedef unsigned int socklen_t; > -# define HAVE_SOCKLEN_T > -#endif /* HAVE_SOCKLEN_T */ > - > #ifndef HAVE_SIZE_T > typedef unsigned int size_t; > # define HAVE_SIZE_T > --- acconfig.h.orig Thu Sep 27 01:30:35 2001 > +++ acconfig.h Thu Sep 27 01:54:33 2001 > @@ -251,7 +251,6 @@ > #undef HAVE_INT64_T > #undef HAVE_U_INT64_T > #undef HAVE_U_CHAR > -#undef HAVE_SOCKLEN_T > #undef HAVE_SIZE_T > #undef HAVE_SSIZE_T > #undef HAVE_CLOCK_T > From openssh-unix-dev at thewrittenword.com Sat Sep 29 14:31:44 2001 From: openssh-unix-dev at thewrittenword.com (openssh-unix-dev at thewrittenword.com) Date: Fri, 28 Sep 2001 23:31:44 -0500 Subject: Better socklen_t test for 2.9.9p2 In-Reply-To: ; from mouring@etoh.eviladmin.org on Fri, Sep 28, 2001 at 11:09:48PM -0500 References: <20010928225446.A24671@oolong.il.thewrittenword.com> Message-ID: <20010928233144.A24788@oolong.il.thewrittenword.com> On Fri, Sep 28, 2001 at 11:09:48PM -0500, mouring at etoh.eviladmin.org wrote: > This is not directly cURL code, but cURL is under MIT/X or MPL licenses > which are both semi-conflict with BSD license. We really should get > someone at the project to give an ok to put the fragment under BSD. TYPE_SOCKLEN_T originally came from the rsync project (sorry). I contributed it so own the copyright. The original patch can be found at: http://lists.samba.org/pipermail/rsync/2001-August/004690.html You have my permission to use it under the same license as OpenSSH. Let me know if there is anything else that needs to be done to get TYPE_SOCKLEN_T included. It is part of Rsync and cURL and has been tested successfully on: Solaris 2.5.1, 2.6, 7, 8/SPARC, HP-UX 10.20, 11.00, Tru64 UNIX 4.0D, 5.0A, 5.1, IRIX 6.2, 6.5, AIX 4.3.2. > - Ben > > On Fri, 28 Sep 2001 openssh-unix-dev at thewrittenword.com wrote: > > > Better test for socklen_t equivalent (stolen from cURL). It requires > > autoconf 2.50. Against 2.9.9p2. > > > > -- > > albert chin (china at thewrittenword.com) > > > > -- snip snip > > --- aclocal.m4.orig Fri Sep 28 22:50:42 2001 > > +++ aclocal.m4 Thu Sep 27 01:53:23 2001 > > @@ -43,3 +43,43 @@ > > AC_SUBST($1) > > ]) > > > > +dnl Check for socklen_t: historically on BSD it is an int, and in > > +dnl POSIX 1g it is a type of its own, but some platforms use different > > +dnl types for the argument to getsockopt, getpeername, etc. So we > > +dnl have to test to find something that will work. > > +AC_DEFUN([TYPE_SOCKLEN_T], > > +[ > > + AC_CHECK_TYPE([socklen_t], ,[ > > + AC_MSG_CHECKING([for socklen_t equivalent]) > > + AC_CACHE_VAL([curl_cv_socklen_t_equiv], > > + [ > > + # Systems have either "struct sockaddr *" or > > + # "void *" as the second argument to getpeername > > + curl_cv_socklen_t_equiv= > > + for arg2 in "struct sockaddr" void; do > > + for t in int size_t unsigned long "unsigned long"; do > > + AC_TRY_COMPILE([ > > + #include > > + #include > > + > > + int getpeername (int, $arg2 *, $t *); > > + ],[ > > + $t len; > > + getpeername(0,0,&len); > > + ],[ > > + curl_cv_socklen_t_equiv="$t" > > + break > > + ]) > > + done > > + done > > + > > + if test "x$curl_cv_socklen_t_equiv" = x; then > > + AC_MSG_ERROR([Cannot find a type to use in place of socklen_t]) > > + fi > > + ]) > > + AC_MSG_RESULT($curl_cv_socklen_t_equiv) > > + AC_DEFINE_UNQUOTED(socklen_t, $curl_cv_socklen_t_equiv, > > + [type to use in place of socklen_t if not defined])], > > + [#include > > +#include ]) > > +]) > > --- configure.in.orig Thu Sep 27 01:16:56 2001 > > +++ configure.in Thu Sep 27 10:11:04 2001 > > @@ -929,20 +993,7 @@ > > AC_DEFINE(HAVE_U_CHAR) > > fi > > > > -AC_CACHE_CHECK([for socklen_t], ac_cv_have_socklen_t, [ > > - AC_TRY_COMPILE( > > - [ > > -#include > > -#include > > - ], > > - [socklen_t foo; foo = 1235;], > > - [ ac_cv_have_socklen_t="yes" ], > > - [ ac_cv_have_socklen_t="no" ] > > - ) > > -]) > > -if test "x$ac_cv_have_socklen_t" = "xyes" ; then > > - AC_DEFINE(HAVE_SOCKLEN_T) > > -fi > > +TYPE_SOCKLEN_T > > > > AC_CACHE_CHECK([for size_t], ac_cv_have_size_t, [ > > AC_TRY_COMPILE( > > --- defines.h.orig Thu Sep 27 01:54:38 2001 > > +++ defines.h Thu Sep 27 01:54:44 2001 > > @@ -243,11 +243,6 @@ > > # define HAVE_U_CHAR > > #endif /* HAVE_U_CHAR */ > > > > -#ifndef HAVE_SOCKLEN_T > > -typedef unsigned int socklen_t; > > -# define HAVE_SOCKLEN_T > > -#endif /* HAVE_SOCKLEN_T */ > > - > > #ifndef HAVE_SIZE_T > > typedef unsigned int size_t; > > # define HAVE_SIZE_T > > --- acconfig.h.orig Thu Sep 27 01:30:35 2001 > > +++ acconfig.h Thu Sep 27 01:54:33 2001 > > @@ -251,7 +251,6 @@ > > #undef HAVE_INT64_T > > #undef HAVE_U_INT64_T > > #undef HAVE_U_CHAR > > -#undef HAVE_SOCKLEN_T > > #undef HAVE_SIZE_T > > #undef HAVE_SSIZE_T > > #undef HAVE_CLOCK_T > > -- albert chin (china at thewrittenword.com) From abartlet at pcug.org.au Sat Sep 29 16:02:05 2001 From: abartlet at pcug.org.au (Andrew Bartlett) Date: Sat, 29 Sep 2001 16:02:05 +1000 Subject: Better socklen_t test for 2.9.9p2 References: <20010928225446.A24671@oolong.il.thewrittenword.com> <20010928233144.A24788@oolong.il.thewrittenword.com> Message-ID: <3BB563DD.6D68F884@bartlett.house> openssh-unix-dev at thewrittenword.com wrote: > > On Fri, Sep 28, 2001 at 11:09:48PM -0500, mouring at etoh.eviladmin.org wrote: > > This is not directly cURL code, but cURL is under MIT/X or MPL licenses > > which are both semi-conflict with BSD license. We really should get > > someone at the project to give an ok to put the fragment under BSD. > > TYPE_SOCKLEN_T originally came from the rsync project (sorry). I > contributed it so own the copyright. The original patch can be found > at: > http://lists.samba.org/pipermail/rsync/2001-August/004690.html > > You have my permission to use it under the same license as OpenSSH. > Let me know if there is anything else that needs to be done to get > TYPE_SOCKLEN_T included. It is part of Rsync and cURL and has been > tested successfully on: > Solaris 2.5.1, 2.6, 7, 8/SPARC, HP-UX 10.20, 11.00, > Tru64 UNIX 4.0D, 5.0A, 5.1, IRIX 6.2, 6.5, AIX 4.3.2. Rsync also features on the Samba build farm (see below), building and testing on over 20 platforms, so its safe to say its portable... Andrew Bartlett -- Andrew Bartlett abartlet at pcug.org.au Samba Team member, Build Farm maintainer abartlet at samba.org Student Network Administrator, Hawker College abartlet at hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net From alaric at babcom.com Sat Sep 29 17:58:25 2001 From: alaric at babcom.com (Phil Stracchino) Date: Sat, 29 Sep 2001 00:58:25 -0700 Subject: SOLVED: ssh2 key passphrase problems in 2.9.9 on Linux In-Reply-To: <20010928181043.A17534@babylon5.babcom.com>; from alaric@babcom.com on Fri, Sep 28, 2001 at 06:10:43PM -0700 References: <20010927232621.A24206@babylon5.babcom.com> <20010928090756.A4045@babylon5.babcom.com> <3BB4B196.84437501@celocom.com> <20010928110025.A8067@babylon5.babcom.com> <20010928150330.A24342@babylon5.babcom.com> <3BB4F7F7.9845F0BF@celocom.com> <20010928170259.A26369@babylon5.babcom.com> <3BB51463.E3D51242@celocom.com> <20010928181043.A17534@babylon5.babcom.com> Message-ID: <20010929005825.A22615@babylon5.babcom.com> On Fri, Sep 28, 2001 at 06:10:43PM -0700, Phil Stracchino wrote: > On Sat, Sep 29, 2001 at 01:22:59AM +0100, Dr S N Henson wrote: > > This is starting to look like a compiler bug. > > I've been suspecting that myself. The curious thing is that OpenSSH 2.9p2 > and OpenSSL 0.9.6a were working fine. Compiler bug it is. I haven't yet managed to rebuild a gcc-2.95,3, but I installed an old egcs-1.1.2 (gcc-2.91.66) and recompiled OpenSSL and OpenSSH with that, and suddenly it all worked. There was one minor quirk: 'ssh-agent > file' no longer produced any output to . However, 'VAR=`ssh-agent`; echo $VAR > file' worked fine. Go figure. I then recompiled OpenSSH-2.9.9 with gcc-3.0, and that worked fine, and the ssh-agent > file quirk vanished. Go figure. So, be it officially known: gcc-3.0 will NOT correctly compile OpenSSL v0.9.6 on Linux, but compiles OpenSSH 2.9.9 without any problems against a known-good OpenSSL installation. -- Linux Now! .........Because friends don't let friends use Microsoft. phil stracchino :: alaric at babcom.com :: halmayne at sourceforge.net unix ronin :::: renaissance man :::: mystic zen biker geek 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From markus at openbsd.org Sat Sep 29 20:02:04 2001 From: markus at openbsd.org (Markus Friedl) Date: Sat, 29 Sep 2001 12:02:04 +0200 Subject: [PATCH] fix for Linux hang on exit bug in 2.9.9p2 In-Reply-To: <20010928211047.2637.qmail@wizard.math.ualberta.ca>; from bowman@math.ualberta.ca on Fri, Sep 28, 2001 at 09:10:47PM -0000 References: <20010928211047.2637.qmail@wizard.math.ualberta.ca> Message-ID: <20010929120204.A12105@faui02.informatik.uni-erlangen.de> please don't call chan_shutdown_read() as it will lead to data loss. > --- openssh-2.9.9p2/session.c Sun Sep 16 16:17:15 2001 > +++ openssh-2.9.9p2J/session.c Thu Sep 27 22:01:07 2001 > @@ -1906,6 +1906,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 kaukasoi at elektroni.ee.tut.fi Sat Sep 29 21:30:14 2001 From: kaukasoi at elektroni.ee.tut.fi (Petri Kaukasoina) Date: Sat, 29 Sep 2001 14:30:14 +0300 Subject: OpenSSH_2.9.9p2 and client config In-Reply-To: <20010928174155.A28279@faui02.informatik.uni-erlangen.de>; from markus@openbsd.org on Fri, Sep 28, 2001 at 05:41:55PM +0200 References: <20010928091046.A7247@elektroni.ee.tut.fi> <20010928174155.A28279@faui02.informatik.uni-erlangen.de> Message-ID: <20010929143014.B23181@elektroni.ee.tut.fi> (Sorry, I sent this to the wrong address. Now to the list...) On Fri, Sep 28, 2001 at 05:41:55PM +0200, Markus Friedl wrote: > that's a bug. > > 2.9.9 reads system config first. Yes, a bug with security consequeces because it breaks the policy the user had set. So, this is the right fix? Shouldn't there be a new distribution tar ball ASAP? --- ssh.c.orig Tue Sep 25 01:04:03 2001 +++ ssh.c Sat Sep 29 14:16:00 2001 @@ -628,8 +628,8 @@ _PATH_SSH_USER_CONFFILE); /* Read systemwide configuration file. */ - (void)read_config_file(_PATH_HOST_CONFIG_FILE, host, &options); (void)read_config_file(buf, host, &options); + (void)read_config_file(_PATH_HOST_CONFIG_FILE, host, &options); } /* Fill configuration defaults. */ From akim at epita.fr Sat Sep 29 22:43:33 2001 From: akim at epita.fr (Akim Demaille) Date: 29 Sep 2001 14:43:33 +0200 Subject: openssh-2.9.9p2, AC_SYS_LARGEFILE, SCO, and HPUX In-Reply-To: <200109281746.f8SHkGm04399@shade.twinsun.com> References: <200109280638.f8S6cDW18421@sic.twinsun.com> <20010928114140.C9542@greenie.muc.de> <200109281746.f8SHkGm04399@shade.twinsun.com> Message-ID: Wow! I'm choked! I really thought we had fixed that horror! Please Paul, note that the paragraph you wrote in the doc is the same as the one I wrote which is just after it (visible in the context of the diff). Since mine was not clear enough, please merge them together or get rid of mine. From lhecking at nmrc.ie Sun Sep 30 01:39:07 2001 From: lhecking at nmrc.ie (Lars Hecking) Date: Sat, 29 Sep 2001 16:39:07 +0100 Subject: scp 2.9.9p2 doesn't work Message-ID: <20010929163907.A11804@nmrc.ie> I just upgraded openssh on my Solaris 8 boxes from 2.9p2 to 2.9.9p2, and scp has stopped working. Remote logins with ssh do work, though. Both client and server run 2.9.9p2. Please let me know if you need more information (configure options, config files etc.). I'm not on the list, so CC's would be appreciated. Thanks! $ scp vsftpd-0.9.2.tar.gz user at server:/usr/local/src/misc/ftp user at server's password: Connection to server closed by remote host. lost connection $ scp -v vsftpd-0.9.2.tar.gz user at server:/usr/local/src/misc/ftp SH_2.9.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090602f debug1: Reading configuration data /etc/ssh_config debug1: Reading configuration data /home/lhecking/.ssh/config debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 640 geteuid 0 anon 1 debug1: Connecting to server [192.168.1.1] port 22. debug1: temporarily_use_uid: 640/15 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 640/15 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug1: identity file /home/lhecking/.ssh/identity type 0 debug1: identity file /home/lhecking/.ssh/id_rsa type -1 debug1: identity file /home/lhecking/.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 debug1: Local version string SSH-1.5-OpenSSH_2.9.9p2 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug1: Host 'server' is known and matches the RSA1 host key. debug1: Found key in /home/lhecking/.ssh/known_hosts:10 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication with key '/home/lhecking/.ssh/identity' debug1: Server refused our key. debug1: Doing challenge reponse authentication. debug1: No challenge. debug1: Doing password authentication. user at server's password: debug1: Sending command: scp -v -t /usr/local/src/misc/ftp debug1: Entering interactive session. debug1: fd 0 setting O_NONBLOCK debug1: fd 1 setting O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Connection to server closed by remote host. debug1: Transferred: stdin 0, stdout 0, stderr 46 bytes in 0.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 6696.7 debug1: Exit status -1 lost connection $ From greg at cheers.bungi.com Sun Sep 30 04:53:59 2001 From: greg at cheers.bungi.com (Greg) Date: Sat, 29 Sep 2001 11:53:59 -0700 Subject: scp 2.9.9p2 doesn't work References: <20010929163907.A11804@nmrc.ie> Message-ID: <3BB618C7.6060601@cheers.bungi.com> On 09/29/01 08:39 AM, Lars Hecking wrote: > I just upgraded openssh on my Solaris 8 boxes from 2.9p2 to 2.9.9p2, > and scp has stopped working. Remote logins with ssh do work, though. > Both client and server run 2.9.9p2. See the "2.9.9p2 bug in PAM support" thread started on 9/28. Configure without PAM or try the one line change suggested by Brent Nelson. Cheers!greg From wayned at users.sourceforge.net Sun Sep 30 06:06:35 2001 From: wayned at users.sourceforge.net (Wayne Davison) Date: Sat, 29 Sep 2001 13:06:35 -0700 (PDT) Subject: openssh-2.9.9p2 assumes pid_t, uid_t, etc. are not 'long' In-Reply-To: <200109281847.f8SIl4504616@shade.twinsun.com> Message-ID: On Fri, 28 Sep 2001, Paul Eggert wrote: > openssh-2.9.9p2 assumes that pid_t, uid_t, gid_t, and mode_t are no > wider than int. I submitted a patch for this back on April 4th and it has yet to be applied. At the time I heard an objection that these types are required to be "int" by POSIX, but from everything I can see, that is not the case. For instance, check out this page from the SUS2 spec (a superset of POSIX) that is available online (unlike POSIX): http://www.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html The key spot on that page is this: blksize_t, pid_t and ssize_t are signed integral types This is consistent with what I've heard from people who have the POSIX spec as a reference. So, I still believe that this patch needs to be applied. If the portable branch wants to keep things close to the BSD version, then we should get the BSD version to apply this patch -- it may not be needed for BSD, but it won't hurt the BSD version to cast an int to a long and use %ld. ..wayne.. From markus at openbsd.org Thu Sep 27 07:18:23 2001 From: markus at openbsd.org (Markus Friedl) Date: Wed, 26 Sep 2001 23:18:23 +0200 Subject: OpenSSH Security Advisory (adv.option) Message-ID: <20010926231823.A15229@folly> Weakness in OpenSSH's source IP based access control for SSH protocol v2 public key authentication. 1. Systems affected: Versions of OpenSSH between 2.5.x and 2.9.x using the 'from=' key file option in combination with both RSA and DSA keys in ~/.ssh/authorized_keys2. 2. Description: Depending on the order of the user keys in ~/.ssh/authorized_keys2 sshd might fail to apply the source IP based access control restriction (e.g. from="10.0.0.1") to the correct key: If a source IP restricted key (e.g. DSA key) is immediately followed by a key of a different type (e.g. RSA key), then key options for the second key are applied to both keys, which includes 'from='. 3. Impact: Users can circumvent the system policy and login from disallowed source IP addresses. 4. Solution: Apply the following patch. This bug is fixed in OpenSSH 2.9.9 5. Credits: None. Appendix: Index: key.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/key.c,v retrieving revision 1.31 retrieving revision 1.32 diff -u -p -IRCSID -r1.31 -r1.32 --- key.c 2001/09/17 20:50:22 1.31 +++ key.c 2001/09/19 13:23:29 1.32 @@ -358,7 +358,7 @@ write_bignum(FILE *f, BIGNUM *num) return 1; } -/* returns 1 ok, -1 error, 0 type mismatch */ +/* returns 1 ok, -1 error */ int key_read(Key *ret, char **cpp) { @@ -413,7 +413,7 @@ key_read(Key *ret, char **cpp) } else if (ret->type != type) { /* is a key, but different type */ debug3("key_read: type mismatch"); - return 0; + return -1; } len = 2*strlen(cp); blob = xmalloc(len);