From buytenh at wantstofly.org Tue Mar 1 00:46:36 2005 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Mon, 28 Feb 2005 14:46:36 +0100 Subject: openssh 3.9p1 problems on big-endian ARM platform Message-ID: <20050228134636.GA9084@xi.wantstofly.org> (please CC, I'm not on the list.) Hi all, I'm having some trouble with openssh 3.9p1 on a big-endian ARM platform. Everything appears to build and run okay, but I can only shell to the box itself or to other big-endian ARM boxes. Shelling to an x86 box gives me: Disconnecting: Corrupted MAC on input. and shelling from an x86 to the ARM gives me the same message. What's odd is that the RSA fingerprints are reported differently if I'm shelling from the x86 or from the ARM. From the ARM I get: [buytenh at enp2611 ~]$ ssh localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is 09:ee:a8:21:21:dc:82:bd:3a:49:1d:25:a3:c4:ad:eb. Are you sure you want to continue connecting (yes/no)? yes >From the x86 I get: pi% ssh enp2611 The authenticity of host 'enp2611 (10.0.0.31)' can't be established. RSA key fingerprint is 36:01:dc:80:71:5f:12:cd:26:ec:4d:31:bb:82:5e:01. Are you sure you want to continue connecting (yes/no)? yes Any ideas where to look first? Most ARM boxes are little-endian, so I thought that maybe openssh was assuming that arm is always little-endian, like many other packages do, but that doesn't seem to be it. cheers, Lennert From dan at lightwave.net.ru Tue Mar 1 01:56:37 2005 From: dan at lightwave.net.ru (Dan Yefimov) Date: Mon, 28 Feb 2005 17:56:37 +0300 (MSK) Subject: openssh 3.9p1 problems on big-endian ARM platform In-Reply-To: <20050228134636.GA9084@xi.wantstofly.org> Message-ID: On Mon, 28 Feb 2005, Lennert Buytenhek wrote: > I'm having some trouble with openssh 3.9p1 on a big-endian ARM platform. > Everything appears to build and run okay, but I can only shell to the box > itself or to other big-endian ARM boxes. Shelling to an x86 box gives me: > > Disconnecting: Corrupted MAC on input. > > and shelling from an x86 to the ARM gives me the same message. > > What's odd is that the RSA fingerprints are reported differently if I'm > shelling from the x86 or from the ARM. From the ARM I get: > > [buytenh at enp2611 ~]$ ssh localhost > The authenticity of host 'localhost (127.0.0.1)' can't be established. > RSA key fingerprint is 09:ee:a8:21:21:dc:82:bd:3a:49:1d:25:a3:c4:ad:eb. > Are you sure you want to continue connecting (yes/no)? yes > > >From the x86 I get: > > pi% ssh enp2611 > The authenticity of host 'enp2611 (10.0.0.31)' can't be established. > RSA key fingerprint is 36:01:dc:80:71:5f:12:cd:26:ec:4d:31:bb:82:5e:01. > Are you sure you want to continue connecting (yes/no)? yes > > Any ideas where to look first? Most ARM boxes are little-endian, so I > thought that maybe openssh was assuming that arm is always little-endian, > like many other packages do, but that doesn't seem to be it. > I'm afraid you have problems with openssl that is used internally by openssh. Try upgrading to the latest openssl release. If that doesn't help, try recompiling it with platform-specific optimisations turned off. Of course, your compiler must be able to generate correct code for your particular platform. -- Sincerely Your, Dan. From rapier at psc.edu Tue Mar 1 03:09:26 2005 From: rapier at psc.edu (Christopher Rapier) Date: Mon, 28 Feb 2005 11:09:26 -0500 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <421FEF0A.3060300@mindrot.org> References: <421FEF0A.3060300@mindrot.org> Message-ID: <42234236.4050205@psc.edu> Damien Miller wrote: > Amba Giri wrote: > >> Hello >> >> I have ported OpenSSH 3.8p1 to a LynxOS platform. Recently I heard a >> report from the field that v2 is perceived to be significantly slower >> than v1. Is this a known issue? Are there any configuration parameters >> that can be modified to make v2 faster? > > > Protocol 2 is slower because it includes a real per-packet MAC instead > of a weak checksum. You can save some overhead by using a truncated MAC > like hmac-sha1-96, but there is always going to be more work per packet. I'm not sure if this is entirely true. If transfer rates were strictly CPU limited then we wouldn't see the typical 'fast on the LAN, slow on the WAN' problem. If you saw 20Mbps on the LAN then being CPU limited wouldn't explain why it would slow down to 200Kbps on the WAN. Additionally, if it was really CPU limited we'd expect to see throughput increase as we started using faster machines. Instead, on any given path, we reach a throughput plateau that is independent of the CPU powers after a certain (relatively low) threshhold. A closer analysis of the data reveals that the most significant cause of the slowdown is due to the flow control mechanisms used for SSH2 channels. This flow control is similar to TCP windows such that the maximum theoretical throughput of the connection (assuming no CPU constraints) will be determined, in large part, by the minimum of the tcp receive window and the SSH2 flow control buffer. If you update the BDP equation (as outlined in Stevens TCP/IP Illustrated) and solve for throughput we end up with bandwidth = (MIN(tcp rwin, SSH2 FC buf)) ---------------------------- RTT Since the effective SSH2 flow control buffer is 64K (its actually defined as 128K but only 1/2 of it is actually used) and most TCP receive windows are now ~80k most people will see a throughput specificially bounded by the 64K buffer. So someone on an 80ms path will see a theoretical maximum throughput of 64K/80ms or 800KB/s (6.4Mbps). Obviously, this assumes; 1) that you have a path between the two locations that isn't bottlenecked by something else, 2) that you have a reasonable processor (say a PIII). If the SSH2 flow control buffer is increased (edit the code, recompile) to some higher value you'll often see the throughput increase linearly (doubling the buffer doubles the throughput). Some simple tests can confirm this assuming that you have a fat enough network path to play with. Right now I'm typically getting 240 to 350Mbps on a 35ms path (using RC4). At these speeds I'm processor bound but with an unmodified version of OpenSSH I'm running at maybe 5 or 6% cpu according to top (only around 14 Mbps). > I have looked at implementing AES CCM, which could be much faster, > particularly on platforms with AES implemented in CPU instructions, but > it doesn't fit nicely in the cipher and MAC negotiation mechanism. That would actually be amazingly cool. Are you going to work on it at all or would it just be too much of a hack to incorporate it at this point? From deengert at anl.gov Tue Mar 1 04:00:24 2005 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 28 Feb 2005 11:00:24 -0600 Subject: OpenSSH+GSSAPI & HP/UX 11i... In-Reply-To: <421FB29B.5010500@zip.com.au> References: <42195C92.4050603@isc.org> <421E30AF.8070808@anl.gov> <421E5793.3000508@zip.com.au> <421F5425.9040002@anl.gov> <421FB29B.5010500@zip.com.au> Message-ID: <42234E28.60106@anl.gov> Darren Tucker wrote: > Douglas E. Engert wrote: > >> If configure was to just test for all the files > > > That's what it does now. Your, right. I was looking at the proposed patch to configure you sent on 2/24 that added the check_gssapi_gssapi_h_first > >> then let the >> #ifdefs in the source test and include the gssapi/xxx versions first >> then it should work. Configure would be much simpler. > > > That has exactly the same problem as currently only with the paths > reversed. > > If there is a platform that has the system headers in > /usr/include/gssapi/gssapi.h and the locally-built headers in, eg, > /usr/local/krb/include/gssapi.h then we're right back where we started. > > Now, I don't know if such a platform exists, but if it does then chances > are it's working now and your proposed change will break it. > Your configure patch is looking better, what about a --with-gssapi-include-path= option? Personally, I am willing to live with the symlink on HP. The new IETF kitten group should address some of the issues with gssapi.h and its friends. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From markus at openbsd.org Tue Mar 1 04:19:41 2005 From: markus at openbsd.org (Markus Friedl) Date: Mon, 28 Feb 2005 18:19:41 +0100 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <42234236.4050205@psc.edu> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> Message-ID: <20050228171940.GA11978@folly> On Mon, Feb 28, 2005 at 11:09:26AM -0500, Christopher Rapier wrote: > bandwidth = (MIN(tcp rwin, SSH2 FC buf)) > ---------------------------- > RTT > > Since the effective SSH2 flow control buffer is 64K (its actually > defined as 128K but only 1/2 of it is actually used) and most TCP well this can be changed. Index: channels.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.c,v retrieving revision 1.211 diff -u -r1.211 channels.c --- channels.c 29 Oct 2004 21:47:15 -0000 1.211 +++ channels.c 27 Nov 2004 14:56:18 -0000 @@ -1518,10 +1518,13 @@ static int channel_check_window(Channel *c) { - if (c->type == SSH_CHANNEL_OPEN && - !(c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD)) && - c->local_window < c->local_window_max/2 && - c->local_consumed > 0) { + if (c->type != SSH_CHANNEL_OPEN || + c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD) || + c->local_consumed <= 0) + return 1; + if ((c->local_window_max - c->local_window < + 3 * CHAN_SES_PACKET_DEFAULT) || + c->local_window < c->local_window_max/2) { packet_start(SSH2_MSG_CHANNEL_WINDOW_ADJUST); packet_put_int(c->remote_id); packet_put_int(c->local_consumed); Index: channels.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/channels.h,v retrieving revision 1.75 diff -u -r1.75 channels.h --- channels.h 29 Oct 2004 21:47:15 -0000 1.75 +++ channels.h 27 Nov 2004 14:55:27 -0000 @@ -118,7 +118,7 @@ /* default window/packet sizes for tcp/x11-fwd-channel */ #define CHAN_SES_PACKET_DEFAULT (32*1024) -#define CHAN_SES_WINDOW_DEFAULT (4*CHAN_SES_PACKET_DEFAULT) +#define CHAN_SES_WINDOW_DEFAULT (40*CHAN_SES_PACKET_DEFAULT) #define CHAN_TCP_PACKET_DEFAULT (32*1024) #define CHAN_TCP_WINDOW_DEFAULT (4*CHAN_TCP_PACKET_DEFAULT) #define CHAN_X11_PACKET_DEFAULT (16*1024) From appro at fy.chalmers.se Tue Mar 1 06:06:52 2005 From: appro at fy.chalmers.se (Andy Polyakov) Date: Mon, 28 Feb 2005 20:06:52 +0100 Subject: AES-CCM [Was: Re: Question performnace of SSH v1 vs SSH v2] In-Reply-To: <42234236.4050205@psc.edu> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> Message-ID: <42236BCC.5030705@fy.chalmers.se> >> I have looked at implementing AES CCM, which could be much faster, >> particularly on platforms with AES implemented in CPU instructions, but >> it doesn't fit nicely in the cipher and MAC negotiation mechanism. > > That would actually be amazingly cool. Keep in mind that CCM mode calls encryption function twice per each block, meaning that it's ~2 as slow as encryption alone. Therefore performance gain can be observed only if hash function is slower than AES, which is not necessarily case. At least it's not the case with currently widely used hash functions. As of now hardware AES is virtually the only occasion, when it's beneficial to favor CCM over combination with e.g. SHA1 [provided that SHA1 is implemented in software], but as new slower hash functions are adopted, CCM becomes more attractive even for software-only systems. It makes sense to implement the mode algorithm at OpenSSL level [it would be possible to optimize it at lower level in both hardware and software cases], so when/if you figure out negotiation, give me a note. A. From mstevens at cmu.edu Tue Mar 1 06:09:34 2005 From: mstevens at cmu.edu (Michael A Stevens) Date: Mon, 28 Feb 2005 14:09:34 -0500 (EST) Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <20050228171940.GA11978@folly> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> Message-ID: Its somewhat more complicated than this. The correct solution is to scale the SSH window to a value that matches the window of the protocol encapsulating the SSH data. Hard-coding window values into the binary isn't a great idea. For any given protocol stack, the windows should all match. Smaller ones will be bottlenecks, and larger ones wasting space. There also is a complication with just scaling the SSH window to a larger size because of a small bug in the channel code that grows a buffer to something larger than the buffer check allows. This really shouldn't happen though, as SSH should be able to depend on the underlying TCP buffer to hold data that it has not fetched yet. Mike On Mon, 28 Feb 2005, Markus Friedl wrote: > On Mon, Feb 28, 2005 at 11:09:26AM -0500, Christopher Rapier wrote: >> bandwidth = (MIN(tcp rwin, SSH2 FC buf)) >> ---------------------------- >> RTT >> >> Since the effective SSH2 flow control buffer is 64K (its actually >> defined as 128K but only 1/2 of it is actually used) and most TCP > > well this can be changed. > > Index: channels.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/channels.c,v > retrieving revision 1.211 > diff -u -r1.211 channels.c > --- channels.c 29 Oct 2004 21:47:15 -0000 1.211 > +++ channels.c 27 Nov 2004 14:56:18 -0000 > @@ -1518,10 +1518,13 @@ > static int > channel_check_window(Channel *c) > { > - if (c->type == SSH_CHANNEL_OPEN && > - !(c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD)) && > - c->local_window < c->local_window_max/2 && > - c->local_consumed > 0) { > + if (c->type != SSH_CHANNEL_OPEN || > + c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD) || > + c->local_consumed <= 0) > + return 1; > + if ((c->local_window_max - c->local_window < > + 3 * CHAN_SES_PACKET_DEFAULT) || > + c->local_window < c->local_window_max/2) { > packet_start(SSH2_MSG_CHANNEL_WINDOW_ADJUST); > packet_put_int(c->remote_id); > packet_put_int(c->local_consumed); > Index: channels.h > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/channels.h,v > retrieving revision 1.75 > diff -u -r1.75 channels.h > --- channels.h 29 Oct 2004 21:47:15 -0000 1.75 > +++ channels.h 27 Nov 2004 14:55:27 -0000 > @@ -118,7 +118,7 @@ > > /* default window/packet sizes for tcp/x11-fwd-channel */ > #define CHAN_SES_PACKET_DEFAULT (32*1024) > -#define CHAN_SES_WINDOW_DEFAULT (4*CHAN_SES_PACKET_DEFAULT) > +#define CHAN_SES_WINDOW_DEFAULT (40*CHAN_SES_PACKET_DEFAULT) > #define CHAN_TCP_PACKET_DEFAULT (32*1024) > #define CHAN_TCP_WINDOW_DEFAULT (4*CHAN_TCP_PACKET_DEFAULT) > #define CHAN_X11_PACKET_DEFAULT (16*1024) > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From agiri at sj.symbol.com Tue Mar 1 06:23:20 2005 From: agiri at sj.symbol.com (Amba Giri) Date: Mon, 28 Feb 2005 11:23:20 -0800 Subject: Question performnace of SSH v1 vs SSH v2 Message-ID: Should I be filing a Change Request or a bug report for this issue? It appears to me that there are ways to enhance the performance of SSH v2 from these emails and it may be useful for everyone to get the correct changes for this into the next release. Amba >>> Michael A Stevens 02/28/05 11:09AM >>> Its somewhat more complicated than this. The correct solution is to scale the SSH window to a value that matches the window of the protocol encapsulating the SSH data. Hard-coding window values into the binary isn't a great idea. For any given protocol stack, the windows should all match. Smaller ones will be bottlenecks, and larger ones wasting space. There also is a complication with just scaling the SSH window to a larger size because of a small bug in the channel code that grows a buffer to something larger than the buffer check allows. This really shouldn't happen though, as SSH should be able to depend on the underlying TCP buffer to hold data that it has not fetched yet. Mike On Mon, 28 Feb 2005, Markus Friedl wrote: > On Mon, Feb 28, 2005 at 11:09:26AM -0500, Christopher Rapier wrote: >> bandwidth = (MIN(tcp rwin, SSH2 FC buf)) >> ---------------------------- >> RTT >> >> Since the effective SSH2 flow control buffer is 64K (its actually >> defined as 128K but only 1/2 of it is actually used) and most TCP > > well this can be changed. > > Index: channels.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/channels.c,v > retrieving revision 1.211 > diff -u -r1.211 channels.c > --- channels.c 29 Oct 2004 21:47:15 -0000 1.211 > +++ channels.c 27 Nov 2004 14:56:18 -0000 > @@ -1518,10 +1518,13 @@ > static int > channel_check_window(Channel *c) > { > - if (c->type == SSH_CHANNEL_OPEN && > - !(c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD)) && > - c->local_window < c->local_window_max/2 && > - c->local_consumed > 0) { > + if (c->type != SSH_CHANNEL_OPEN || > + c->flags & (CHAN_CLOSE_SENT|CHAN_CLOSE_RCVD) || > + c->local_consumed <= 0) > + return 1; > + if ((c->local_window_max - c->local_window < > + 3 * CHAN_SES_PACKET_DEFAULT) || > + c->local_window < c->local_window_max/2) { > packet_start(SSH2_MSG_CHANNEL_WINDOW_ADJUST); > packet_put_int(c->remote_id); > packet_put_int(c->local_consumed); > Index: channels.h > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/channels.h,v > retrieving revision 1.75 > diff -u -r1.75 channels.h > --- channels.h 29 Oct 2004 21:47:15 -0000 1.75 > +++ channels.h 27 Nov 2004 14:55:27 -0000 > @@ -118,7 +118,7 @@ > > /* default window/packet sizes for tcp/x11-fwd-channel */ > #define CHAN_SES_PACKET_DEFAULT (32*1024) > -#define CHAN_SES_WINDOW_DEFAULT (4*CHAN_SES_PACKET_DEFAULT) > +#define CHAN_SES_WINDOW_DEFAULT (40*CHAN_SES_PACKET_DEFAULT) > #define CHAN_TCP_PACKET_DEFAULT (32*1024) > #define CHAN_TCP_WINDOW_DEFAULT (4*CHAN_TCP_PACKET_DEFAULT) > #define CHAN_X11_PACKET_DEFAULT (16*1024) > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > ________________________________________________________________________ This email has been scanned for computer viruses. From gert at greenie.muc.de Tue Mar 1 07:29:47 2005 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 28 Feb 2005 21:29:47 +0100 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> Message-ID: <20050228202946.GM1110@greenie.muc.de> Hi, On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: > There also is a complication with just scaling the SSH window to a larger > size because of a small bug in the channel code that grows a buffer to > something larger than the buffer check allows. This really shouldn't > happen though, as SSH should be able to depend on the underlying TCP > buffer to hold data that it has not fetched yet. If you have parallel streams, this will induce head-of-line blocking (session of one stream sits in the TCP buffer, blocking stuff for other channels). 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 at net.informatik.tu-muenchen.de From rick.jones2 at hp.com Tue Mar 1 07:46:11 2005 From: rick.jones2 at hp.com (Rick Jones) Date: Mon, 28 Feb 2005 12:46:11 -0800 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <20050228202946.GM1110@greenie.muc.de> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050228202946.GM1110@greenie.muc.de> Message-ID: <42238313.4050602@hp.com> Gert Doering wrote: > Hi, > > On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: > >>There also is a complication with just scaling the SSH window to a larger >>size because of a small bug in the channel code that grows a buffer to >>something larger than the buffer check allows. This really shouldn't >>happen though, as SSH should be able to depend on the underlying TCP >>buffer to hold data that it has not fetched yet. > > > If you have parallel streams, this will induce head-of-line blocking > (session of one stream sits in the TCP buffer, blocking stuff for > other channels). How likely is that though? Actually, that question would be both for there being more than one stream muxed over the TCP connection and for one of the streams to fully block the others. At one level at least, multiple streams over a single TCP connection sounds a bit like multiple TCP connections over a data link. Is there anything in the existing v2 code that precludes the blocking by say two of three streams over the connection anyway? Other pseudo-random thought: Additional setsockopt() calls when streams are added. May not increase the actual TCP window but it would allow the data to be buffered. From djm at mindrot.org Tue Mar 1 11:50:22 2005 From: djm at mindrot.org (Damien Miller) Date: Tue, 01 Mar 2005 11:50:22 +1100 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> Message-ID: <4223BC4E.1040306@mindrot.org> Michael A Stevens wrote: > Its somewhat more complicated than this. The correct solution is to > scale the SSH window to a value that matches the window of the protocol > encapsulating the SSH data. Hard-coding window values into the binary > isn't a great idea. Markus' patch doesn't just hard-code a larger value. It also sends window adjust packets more aggressively. -d From markus at openbsd.org Tue Mar 1 19:42:18 2005 From: markus at openbsd.org (Markus Friedl) Date: Tue, 1 Mar 2005 09:42:18 +0100 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> Message-ID: <20050301084218.GA26162@folly> On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: > Its somewhat more complicated than this. The correct solution is to scale > the SSH window to a value that matches the window of the protocol the point of the patch is not to hard-code the window but the change the only-half-window-is-used bug. From msporleder at gmail.com Wed Mar 2 01:07:24 2005 From: msporleder at gmail.com (matthew sporleder) Date: Tue, 1 Mar 2005 09:07:24 -0500 Subject: command reordering Message-ID: ssh myname at myhost 'printf %s: `hostname` ; ssh -V && printf %s: `hostname` ; php -v' Will return something like: myhost:myhost:OpenSSH_3.5etcetcetc 4.x.y Why is ssh putting the printf's together? This also works with any combination of ;/&& vs echo -n/printf. I found this site talking about rsync and getopt problems, but I haven't figured out the work-around yet: http://lists.samba.org/archive/rsync/2004-October/010831.html -- _Matt From binder at arago.de Wed Mar 2 01:19:25 2005 From: binder at arago.de (Thomas Binder) Date: Tue, 1 Mar 2005 15:19:25 +0100 Subject: command reordering In-Reply-To: References: Message-ID: <20050301141925.GA6651621@ohm.arago.de> Hi! On Tue, Mar 01, 2005 at 09:07:24AM -0500, matthew sporleder wrote: > ssh myname at myhost 'printf %s: `hostname` ; ssh -V && printf %s: > `hostname` ; php -v' > > Will return something like: > > myhost:myhost:OpenSSH_3.5etcetcetc > 4.x.y > > > Why is ssh putting the printf's together? It doesn't - you have just overlooked that ssh -V sends its output to stderr, while printf and php -v send it to stdout. Changing your command line to ssh myname at myhost 'printf %s: `hostname` ; ssh -V 2>&1 && printf %s: `hostname` ; php -v' should work. (Assuming something sh-compatible as your login shell, won't work that way with csh.) Ciao Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050301/9410746c/attachment.bin From rapier at psc.edu Wed Mar 2 02:08:01 2005 From: rapier at psc.edu (Christopher Rapier) Date: Tue, 01 Mar 2005 10:08:01 -0500 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <20050301084218.GA26162@folly> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301084218.GA26162@folly> Message-ID: <42248551.1030708@psc.edu> Markus Friedl wrote: > On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: > >>Its somewhat more complicated than this. The correct solution is to scale >>the SSH window to a value that matches the window of the protocol > > > the point of the patch is not to hard-code the window but > the change the only-half-window-is-used bug. The question is why was only half the buffer being used in the first place. I think its reasonably safe to assume that there was a reason for it being set up this way. From rapier at psc.edu Wed Mar 2 02:16:18 2005 From: rapier at psc.edu (Christopher Rapier) Date: Tue, 01 Mar 2005 10:16:18 -0500 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <42238313.4050602@hp.com> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050228202946.GM1110@greenie.muc.de> <42238313.4050602@hp.com> Message-ID: <42248742.4030700@psc.edu> Rick Jones wrote: > Gert Doering wrote: > >> If you have parallel streams, this will induce head-of-line blocking >> (session of one stream sits in the TCP buffer, blocking stuff for >> other channels). > > > How likely is that though? Actually, that question would be both for > there being more than one stream muxed over the TCP connection and for > one of the streams to fully block the others. Dunno but it might have an impact on the research that Mike Stevens and I are doing. We'll look into it soon. I personally don't think it will be a significant issue in most cases (however, I'm known to be mistaken on a regular basis :) ). From rapier at psc.edu Wed Mar 2 02:30:41 2005 From: rapier at psc.edu (Christopher Rapier) Date: Tue, 01 Mar 2005 10:30:41 -0500 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: Message-ID: <42248AA1.6030001@psc.edu> Amba Giri wrote: > Should I be filing a Change Request or a bug report for this issue? > It appears to me that there are ways to enhance the performance of > SSH v2 from these emails and it may be useful for everyone to get > the correct changes for this into the next release. You might want to check out http://www.psc.edu/networking/projects/hpn-ssh I presented the results of this work at Supercomputing 2004 (SC04). It was reasonably well received. We also got a grant from Cisco to continue work on it (to allay any concerns we aren't forking, just doing development for the HPC and HPN community we are associated with). From markus at openbsd.org Wed Mar 2 02:56:32 2005 From: markus at openbsd.org (Markus Friedl) Date: Tue, 1 Mar 2005 16:56:32 +0100 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <42248551.1030708@psc.edu> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301084218.GA26162@folly> <42248551.1030708@psc.edu> Message-ID: <20050301155632.GA7480@folly> On Tue, Mar 01, 2005 at 10:08:01AM -0500, Christopher Rapier wrote: > Markus Friedl wrote: > >On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: > > > >>Its somewhat more complicated than this. The correct solution is to scale > >>the SSH window to a value that matches the window of the protocol > > > > > >the point of the patch is not to hard-code the window but > >the change the only-half-window-is-used bug. > > The question is why was only half the buffer being used in the first > place. I think its reasonably safe to assume that there was a reason for > it being set up this way. it was considered appropriate, while we now see that it's not. so it's safe to change it. it's better to fix the real bugs, than to twiddle the symptoms. From markus at openbsd.org Wed Mar 2 02:58:02 2005 From: markus at openbsd.org (Markus Friedl) Date: Tue, 1 Mar 2005 16:58:02 +0100 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> Message-ID: <20050301155802.GB7480@folly> On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: > Its somewhat more complicated than this. The correct solution is to scale > the SSH window to a value that matches the window of the protocol > encapsulating the SSH data. it's simple to change this hardcoded application window to match the tcp send/receive window. From rapier at psc.edu Wed Mar 2 03:14:46 2005 From: rapier at psc.edu (Christopher Rapier) Date: Tue, 01 Mar 2005 11:14:46 -0500 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <20050301155802.GB7480@folly> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> Message-ID: <422494F6.6030309@psc.edu> Markus Friedl wrote: > On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: > >>Its somewhat more complicated than this. The correct solution is to scale >>the SSH window to a value that matches the window of the protocol >>encapsulating the SSH data. > > > it's simple to change this hardcoded application window > to match the tcp send/receive window. It is pretty trivial, making it work with Web100/autotuning kernels is not as trivial but not overly daunting either. It was all included in a patch we submitted to the openssh-unix-dev list last June. We've been continuing work on it and other network performance issues since. From mstevens at cmu.edu Wed Mar 2 03:47:13 2005 From: mstevens at cmu.edu (Michael A Stevens) Date: Tue, 1 Mar 2005 11:47:13 -0500 (EST) Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <422494F6.6030309@psc.edu> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> <422494F6.6030309@psc.edu> Message-ID: There is also another subtle issue of how often should the window be polled. Polling the tcp window on a WINDOW_ADJUST message could prove to be costly if they happen very often. Mike On Tue, 1 Mar 2005, Christopher Rapier wrote: > Markus Friedl wrote: >> On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: >> >>> Its somewhat more complicated than this. The correct solution is to >>> scale the SSH window to a value that matches the window of the protocol >>> encapsulating the SSH data. >> >> >> it's simple to change this hardcoded application window >> to match the tcp send/receive window. > > It is pretty trivial, making it work with Web100/autotuning kernels is not as > trivial but not overly daunting either. It was all included in a patch we > submitted to the openssh-unix-dev list last June. We've been continuing work > on it and other network performance issues since. > > From rick.jones2 at hp.com Wed Mar 2 05:03:12 2005 From: rick.jones2 at hp.com (Rick Jones) Date: Tue, 01 Mar 2005 10:03:12 -0800 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> <422494F6.6030309@psc.edu> Message-ID: <4224AE60.2090206@hp.com> Michael A Stevens wrote: > There is also another subtle issue of how often should the window be > polled. Polling the tcp window on a WINDOW_ADJUST message could prove to > be costly if they happen very often. At the very real risk of rapdily showing my ignornace of what is implied in the receipt of a WINDOW_ADJUST message... The TCP window - or rather, what gets reported in a getsockopt([SO_RCVBUF|SO_SNDBUF]) - will not change during the life of a TCP connection unless the application makes a corresponding setsockopt([SO_RCVBUF|SO_SNDBUF]) call. So once after the connection is established should suffice. Again after any setsockopt call. The reason being that while every other stack I have encountered in N years of netperf reports back what setsockopt() asked for (modulo limits) - Linux seems to report up to 2X the setsockopt() value (again modulo limits). And, if the remote makes a setsockopt() call, there is no (portable) way to get the remote's advertised window anyway - we can only see what our socket buffer sizes happen to be. rick jones BTW, unless the stack has negotiated window scaling when the TCP connection was established (wscale on the SYN segments), there will be a hard limit on the TCP window of 65535 bytes even if the socket buffer sizes are greater. I've seen that _some_ stacks will use window scaling when the window is < 64KB, but that is not universal. From rene at exactcode.de Wed Mar 2 05:45:35 2005 From: rene at exactcode.de (Rene Rebe) Date: Tue, 01 Mar 2005 19:45:35 +0100 Subject: Allow remote hosts for remote forwarded ports Message-ID: <4224B84F.5050709@exactcode.de> Hi all, I just wanted to temporarily make some new CMS I set up available to the public for testing on port 8080 of our web server forwarded via ssh to to my local, firewalled workstation: ssh me at some-host.tld -R 8080:localhost:80 However I had to notice that this only binds to the loopback interface and not to all. For -L there is the -g option to low connects to locally forwarded ports for remote hosts. As far as I can see there is no equivalent for remotely forwarded ports. Is there any reason this is not implemented? PS: Please CC since I'm not subscribed ... Yours, -- Ren? Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de/ | http://www.t2-project.org/ +49 (0)30 255 897 45 From rapier at psc.edu Wed Mar 2 06:53:32 2005 From: rapier at psc.edu (Christopher Rapier) Date: Tue, 01 Mar 2005 14:53:32 -0500 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <4224AE60.2090206@hp.com> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> <422494F6.6030309@psc.edu> <4224AE60.2090206@hp.com> Message-ID: <4224C83C.7080806@psc.edu> Rick Jones wrote: > The TCP window - or rather, what gets reported in a > getsockopt([SO_RCVBUF|SO_SNDBUF]) - will not change during the life of a > TCP connection unless the application makes a corresponding > setsockopt([SO_RCVBUF|SO_SNDBUF]) call. So once after the connection > is established should suffice. Again after any setsockopt call. The > reason being that while every other stack I have encountered in N years > of netperf reports back what setsockopt() asked for (modulo limits) - > Linux seems to report up to 2X the setsockopt() value (again modulo > limits). Actually, this isn't true. The size of the TCP window can change many times during a tcp connection *if* an autotuning stack is being used. Basically, this involves a TCP MIB that monitors the connection (window sizes, rate, loss, rtt, and so forth) and based on that information adjusts the window size to maximize performance. Now, it does this on a per connection basis - so your interactive session to the machine in the room next door won't be forced to use the same 8MB buffer you need for your 10GigE transcontinental connection. Its outlined at www.web100.org, www.net100.org and, as far as a I know, is part of the linux 2.6 kernel (but not enabled by default I think). Its a serious win in terms of maximizing network performance. Since this is developed by the guys in the office next to mine I feel obligated to make my work compatible with theirs. Well, that and the guy on the 10GigE is who I'm working for. This means that we need to sample the tcp window size multiple times during the connection - doing it when a WINDOW_ADJUST is received just seemed like the best time to do it. We think its inevitable that this sort of autotuning will be incorporated into most kernels in the next few years so it makes sense to write for it. > BTW, unless the stack has negotiated window scaling when the TCP > connection was established (wscale on the SYN segments), there will be a > hard limit on the TCP window of 65535 bytes even if the socket buffer > sizes are greater. I've seen that _some_ stacks will use window scaling > when the window is < 64KB, but that is not universal. If there is a stack that isn't negotiating window scaling correctly then thats a problem outside of the scope of our work. From jmknoble at pobox.com Wed Mar 2 07:42:38 2005 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 1 Mar 2005 15:42:38 -0500 Subject: Allow remote hosts for remote forwarded ports In-Reply-To: <4224B84F.5050709@exactcode.de> References: <4224B84F.5050709@exactcode.de> Message-ID: <20050301204238.GI27254@crawfish.ais.com> Circa 2005-03-01 19:45:35 +0100 dixit Rene Rebe: : ssh me at some-host.tld -R 8080:localhost:80 Is 'localhost' really what you want there? That forwards port 8080 on some-host to port 80 on the same machine. : However I had to notice that this only binds to the loopback interface : and not to all. For -L there is the -g option to low connects to locally : forwarded ports for remote hosts. As far as I can see there is no : equivalent for remotely forwarded ports. : : Is there any reason this is not implemented? It's implemented in sshd; you need to have 'GatewayPorts' set to 'yes' in sshd_config on the remote end. Alternatively: ssh me at some-host.tld 'ssh -N -g -L 8080:this-host:80 me at this-host' Or, if you really do mean localhost above, then: ssh me at some-host.tld 'ssh -N -g -L 8080:localhost:80 me at localhost' Strikes me you'd be better off with something else (such as an actual redirect in the remote host's firewall, or even two netcat connected by pipes.... -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: From dtucker at zip.com.au Wed Mar 2 08:17:40 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 02 Mar 2005 08:17:40 +1100 Subject: Allow remote hosts for remote forwarded ports In-Reply-To: <20050301204238.GI27254@crawfish.ais.com> References: <4224B84F.5050709@exactcode.de> <20050301204238.GI27254@crawfish.ais.com> Message-ID: <4224DBF4.4070403@zip.com.au> Jim Knoble wrote: > Circa 2005-03-01 19:45:35 +0100 dixit Rene Rebe: > > : ssh me at some-host.tld -R 8080:localhost:80 > > Is 'localhost' really what you want there? That forwards port 8080 on > some-host to port 80 on the same machine. No, it forwards port 8080 on some-host to port 80 on the machine running the ssh client. > : However I had to notice that this only binds to the loopback interface > : and not to all. For -L there is the -g option to low connects to locally > : forwarded ports for remote hosts. As far as I can see there is no > : equivalent for remotely forwarded ports. > : > : Is there any reason this is not implemented? > > It's implemented in sshd; you need to have 'GatewayPorts' set to 'yes' > in sshd_config on the remote end. Also note that recently (ie yesterday) support was added for fine-grained control of which address to bind to for remote SSH2 requests. See: http://bugzilla.mindrot.org/show_bug.cgi?id=413 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From markus at openbsd.org Wed Mar 2 08:18:15 2005 From: markus at openbsd.org (Markus Friedl) Date: Tue, 1 Mar 2005 22:18:15 +0100 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> <422494F6.6030309@psc.edu> Message-ID: <20050301211815.GA16700@folly> On Tue, Mar 01, 2005 at 11:47:13AM -0500, Michael A Stevens wrote: > There is also another subtle issue of how often should the window be > polled. Polling the tcp window on a WINDOW_ADJUST message could prove to > be costly if they happen very often. retrieving the tcp receive space once after connection establishment should be enough for almost all tcp stacks out there. From mstevens at cmu.edu Wed Mar 2 08:27:54 2005 From: mstevens at cmu.edu (Michael A Stevens) Date: Tue, 1 Mar 2005 16:27:54 -0500 (EST) Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <4224AE60.2090206@hp.com> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> <422494F6.6030309@psc.edu> <4224AE60.2090206@hp.com> Message-ID: On Tue, 1 Mar 2005, Rick Jones wrote: > Michael A Stevens wrote: >> There is also another subtle issue of how often should the window be >> polled. Polling the tcp window on a WINDOW_ADJUST message could prove to >> be costly if they happen very often. > > At the very real risk of rapdily showing my ignornace of what is implied in > the receipt of a WINDOW_ADJUST message... The WINDOW_ADJUST messages of SSH that is. Actually I meant to say upon sending of a WINDOW_ADJUST the TCP buffer should be polled. This is so you can adjust the window the sender has to send you data so that they are not limited by SSH, but by TCP. > > The TCP window - or rather, what gets reported in a > getsockopt([SO_RCVBUF|SO_SNDBUF]) - will not change during the life of a TCP > connection unless the application makes a corresponding > setsockopt([SO_RCVBUF|SO_SNDBUF]) call. So once after the connection is > established should suffice. Again after any setsockopt call. The reason As Chris mentioned autotuning stacks break this assumption, but even more so, if a general case of the window size changing can be dealt with in such a simple way as to poll it from time to time, then there really isn't much of a reason to not do it. > And, if the remote makes a setsockopt() call, there is no (portable) way to > get the remote's advertised window anyway - we can only see what our socket > buffer sizes happen to be. The TCP stack handles the sending of packets to a system so it does not send packets outside of the window. In the same way SSH2 doesn't send packets outside of the SSH window. There really isn't a need to know what the remote host's TCP window is, its just if that host wants to make use of its receive bandwidth, it needs to adjust its SSH2 window to match its TCP window. > > rick jones > > BTW, unless the stack has negotiated window scaling when the TCP connection > was established (wscale on the SYN segments), there will be a hard limit on > the TCP window of 65535 bytes even if the socket buffer sizes are greater. > I've seen that _some_ stacks will use window scaling when the window is < > 64KB, but that is not universal. Those are exactly the connections we are looking at here. When SCPing files across a 100Mbit/s coast to coast link the best performance you will see is around 16Mbit/s. With a 100ms RTT you can expect to hit the limits of the 64K window at 5Mbit/s. When you look at Gigabit links you hit limits of a 64K window at 0.0001 second latency. Mike From jmknoble at pobox.com Wed Mar 2 08:33:02 2005 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 1 Mar 2005 16:33:02 -0500 Subject: Allow remote hosts for remote forwarded ports In-Reply-To: <4224DBF4.4070403@zip.com.au> References: <4224B84F.5050709@exactcode.de> <20050301204238.GI27254@crawfish.ais.com> <4224DBF4.4070403@zip.com.au> Message-ID: <20050301213302.GJ27254@crawfish.ais.com> Circa 2005-03-02 08:17:40 +1100 dixit Darren Tucker: : Jim Knoble wrote: : >Circa 2005-03-01 19:45:35 +0100 dixit Rene Rebe: : > : >: ssh me at some-host.tld -R 8080:localhost:80 : > : >Is 'localhost' really what you want there? That forwards port 8080 on : >some-host to port 80 on the same machine. : : No, it forwards port 8080 on some-host to port 80 on the machine running : the ssh client. Urp. Darren's right, of course. I was already reading the '-L' switch into that command-line... -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: From rapier at psc.edu Wed Mar 2 08:40:42 2005 From: rapier at psc.edu (Christopher Rapier) Date: Tue, 01 Mar 2005 16:40:42 -0500 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <20050301211815.GA16700@folly> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> <422494F6.6030309@psc.edu> <20050301211815.GA16700@folly> Message-ID: <4224E15A.7050006@psc.edu> Markus Friedl wrote: > On Tue, Mar 01, 2005 at 11:47:13AM -0500, Michael A Stevens wrote: > >>There is also another subtle issue of how often should the window be >>polled. Polling the tcp window on a WINDOW_ADJUST message could prove to >>be costly if they happen very often. > > > retrieving the tcp receive space once after connection > establishment should be enough for almost all tcp > stacks out there. Actually, this isn't true. The Linux 2.6 kernel incorporate autotuning and enables it by default. The one problem is that the sysctl defaults to 128K at the moment (thats being worked on). It's also in the 2.4.27 kernel albeit broken and off by default. However, the fixed version is in the developers tree and will be part of 2.4.29. They've also had discussions with microsoft and a couple of other OSes. So yes, its only in one stack at the moment, but since its the linux stack its going to be common. From mstevens at cmu.edu Wed Mar 2 08:40:59 2005 From: mstevens at cmu.edu (Michael A Stevens) Date: Tue, 1 Mar 2005 16:40:59 -0500 (EST) Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: <20050301211815.GA16700@folly> References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> <422494F6.6030309@psc.edu> <20050301211815.GA16700@folly> Message-ID: Autotuning is becoming more common outside research enviornments, its already in the linux kernel. http://www.csm.ornl.gov/~dunigan/netperf/auto.html Mike On Tue, 1 Mar 2005, Markus Friedl wrote: > On Tue, Mar 01, 2005 at 11:47:13AM -0500, Michael A Stevens wrote: >> There is also another subtle issue of how often should the window be >> polled. Polling the tcp window on a WINDOW_ADJUST message could prove to >> be costly if they happen very often. > > retrieving the tcp receive space once after connection > establishment should be enough for almost all tcp > stacks out there. > > From rick.jones2 at hp.com Wed Mar 2 09:16:36 2005 From: rick.jones2 at hp.com (Rick Jones) Date: Tue, 01 Mar 2005 14:16:36 -0800 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: <421FEF0A.3060300@mindrot.org> <42234236.4050205@psc.edu> <20050228171940.GA11978@folly> <20050301155802.GB7480@folly> <422494F6.6030309@psc.edu> <20050301211815.GA16700@folly> Message-ID: <4224E9C4.4050001@hp.com> Michael A Stevens wrote: > Autotuning is becoming more common outside research enviornments, its > already in the linux kernel. > > http://www.csm.ornl.gov/~dunigan/netperf/auto.html Clearly I'm going to have to update the netperf documentation. Between having to tweak the registry on Windows and now knowing whether or not autotuning is enabled on Linux... add-in the dynamically tuned interrupt coalescing and we land in a maze of twisty passages all different. rick jones From agiri at sj.symbol.com Wed Mar 2 05:49:13 2005 From: agiri at sj.symbol.com (Amba Giri) Date: Tue, 01 Mar 2005 10:49:13 -0800 Subject: Question performnace of SSH v1 vs SSH v2 Message-ID: Christopher, thanks for your response. Our customers have 3.8.1p1 binaries today. What is the safest and most efficient way to get the v2 performance enhancements to them? I am not very familiar with the Open Source patch process. Is there a link for this? Should I make the changes that I see in the link that you sent manually to the source files of 3.8.1p1? Are there any risks/drawbacks to this approach? Is it better to upgrade the customer to 3.9.1p1 and,if so, does the latter binary have any v2 performance enhancements. Thank you in advance... Amba From strbenjr at yahoo.com Wed Mar 2 13:55:35 2005 From: strbenjr at yahoo.com (Ben Hacker Jr) Date: Tue, 01 Mar 2005 21:55:35 -0500 Subject: PKI and SSH (cont.) Message-ID: <42252B27.4060303@yahoo.com> Dear List... I have a similar question to the one that is copied below. I am trying to get instructions for configuring OpenSSH to use PKI based authentication. I understand that I can provide the server with the public keys of the client machines to get this working (one way) but the next step is where I would like to go... I want SSHD to authenticate my users based upon the "Root Certificate" of "My" PKI. (Say I set it up using: "CA.pl" http://www.openssl.org/docs/apps/CA.pl.html) If the client attempting to authenticate presents a certificate that has been: 1. signed by My_Root_CA 2. is not expired 3. is not revoked then SSHD will proceed with the authentication of the client. If the "client user" gets Public/private keys + certificate from some other CA (like DigSigTrust.com or Versign.com) the SSHD will NOT authenticate because the certificate used was not signed by: My_Root_CA" Can OpenSSH do this?? If not, I do not want the client user to be able to install his own public keys. Can I put a list of accepted public keys somewhere else (like: /etc/ssh/authorized_keys) or do I have to put them in each users home directory and make the ~/.ssh/authorized_keys only writable by root? Please CC: me on the reply because I am not subscribed to this list. Thanks in advance for your reply. Ben Hacker Jr -----Original Message----- From: openssh-unix-dev-bounces+libove=felines.org at mindrot.org [mailto:openssh-unix-dev-bounces+libove=felines.org at mindrot.org] On Behalf Of Gregory Seidman Sent: Monday, February 23, 2004 5:23 PM To: OpenSSH development list Subject: PKI and SSH Due to unpleasant (but arguably valid) policy changes at work, any SSH server within the work firewall must accept only PKI authentication. Unless we can convince the higher-ups otherwise, we will also have to use the commercial SSH server within the firewall. Of course, I should be able to use whatever client I like. Unfortunately, it is not clear that I can get OpenSSH to use PKI authentication. A bit of googling turns up a patch, but nothing too certain or clear. Does OpenSSH support PKI authentication? If so, how do I use it? --Greg -- Ben Hacker, Jr. Sr. Security Analyst strbenjr at yahoo.com ben_hacker at inter-op.net 703.751.3757 (w) -- -- -- http://www.coeba.org http://www.inter-op.net http://www.hackerweb.net/bthacker From djm at mindrot.org Wed Mar 2 19:42:12 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 02 Mar 2005 19:42:12 +1100 Subject: Question performnace of SSH v1 vs SSH v2 In-Reply-To: References: Message-ID: <42257C64.7000308@mindrot.org> Amba Giri wrote: > Christopher, thanks for your response. Our customers have 3.8.1p1 > binaries today. What is the safest and most efficient way to get the > v2 performance enhancements to them? I am not very familiar with the > Open Source patch process. Is there a link for this? Should I make > the changes that I see in the link that you sent manually to the > source files of 3.8.1p1? Are there any risks/drawbacks to this > approach? Is it better to upgrade the customer to 3.9.1p1 and,if so, > does the latter binary have any v2 performance enhancements. I don't know if they will help you if you, because you haven't stated what your performance problem is. These patches help for long, fat pipes and aren't likely to make much difference on a LAN. -d From lcml at pixel.it Wed Mar 2 20:35:32 2005 From: lcml at pixel.it (Lucio) Date: Wed, 2 Mar 2005 10:35:32 +0100 Subject: Port 0 forwarding implemented? Message-ID: <200503021035.33077.lcml@pixel.it> Hello everybody, I've read the ssh protocol draft http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.txt and I wonder if the feature documented in section 7.1, page 15, last paragraph, is implemented in OpenSSH or not (sshd chooses the first free non privileged port to forward when the specified port number is 0). I need this feature and, if it isn't implemented yet, I could write a patch, provided someone points me to the correct source file. Thanks in advance, Lucio. P.S: I've already subscribed to this ML, you don't need to CC. From djm at mindrot.org Wed Mar 2 20:52:08 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 02 Mar 2005 20:52:08 +1100 Subject: Port 0 forwarding implemented? In-Reply-To: <200503021035.33077.lcml@pixel.it> References: <200503021035.33077.lcml@pixel.it> Message-ID: <42258CC8.6010009@mindrot.org> Lucio wrote: > Hello everybody, > > I've read the ssh protocol draft > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.txt > > and I wonder if the feature documented in section 7.1, page 15, last > paragraph, is implemented in OpenSSH or not (sshd chooses the first free non > privileged port to forward when the specified port number is 0). I need this > feature and, if it isn't implemented yet, I could write a patch, provided > someone points me to the correct source file. No, it isn't implemented. A patch would be welcome - start by looking at the channel_setup_fwd_listener() function in channels.c and the places from which it is called. You should base your patches on CVS HEAD or the snapshot releases, because this function has changed substantially since the 3.9 release. -d From openssh at roumenpetrov.info Thu Mar 3 01:06:24 2005 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Wed, 2 Mar 2005 16:06:24 +0200 (EET) Subject: [SPAM] PKI and SSH (cont.) In-Reply-To: <42252B27.4060303@yahoo.com> References: <42252B27.4060303@yahoo.com> Message-ID: <51992.213.91.169.3.1109772384.squirrel@srv04.zergon.net> Hi Ben, For PKI support in OpenSSH, patches and etc., please visit my page http://roumenpetrov.info/openssh/ . > Dear List... > > I have a similar question to the one that is copied below. I > am trying to get instructions for configuring OpenSSH to use PKI > based authentication. > > I understand that I can provide the server with the public keys > of the client machines to get this working (one way) but the next > step is where I would like to go... > > I want SSHD to authenticate my users based upon the "Root > Certificate" of "My" PKI. (Say I set it up using: "CA.pl" > http://www.openssl.org/docs/apps/CA.pl.html) > > If the client attempting to authenticate presents a certificate > that has been: > > 1. signed by My_Root_CA > 2. is not expired > 3. is not revoked > > then SSHD will proceed with the authentication of the client. > > If the "client user" gets Public/private keys + certificate from > some other CA (like DigSigTrust.com or Versign.com) the SSHD will > NOT authenticate because the certificate used was not signed by: > My_Root_CA" > > Can OpenSSH do this?? After patch yes ;-). > > If not, I do not want the client user to be able to install his own > public keys. Can I put a list of accepted public keys somewhere else > (like: /etc/ssh/authorized_keys) or do I have to put them in each > users home directory and make the ~/.ssh/authorized_keys only > writable by root? It is discused many times in the lists. > > Please CC: me on the reply because I am not subscribed to this list. > > Thanks in advance for your reply. > Ben Hacker Jr > > -----Original Message----- > From: openssh-unix-dev-bounces+libove=felines.org at mindrot.org > [mailto:openssh-unix-dev-bounces+libove=felines.org at mindrot.org] On > Behalf Of Gregory Seidman > Sent: Monday, February 23, 2004 5:23 PM > To: OpenSSH development list > Subject: PKI and SSH > > Due to unpleasant (but arguably valid) policy changes at work, any SSH > server within the work firewall must accept only PKI authentication. > Unless we can convince the higher-ups otherwise, we will also have to > use the commercial SSH server within the firewall. Of course, I should > be able to use whatever client I like. Unfortunately, it is not clear > that I can get OpenSSH to use PKI authentication. A bit of googling > turns up a patch, but nothing too certain or clear. Does OpenSSH support > PKI authentication? If so, how do I use it? > > --Greg > > > -- > Ben Hacker, Jr. > Sr. Security Analyst > strbenjr at yahoo.com > ben_hacker at inter-op.net > 703.751.3757 (w) > -- -- -- > http://www.coeba.org > http://www.inter-op.net > http://www.hackerweb.net/bthacker > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From frank.beckmann at vodafone.com Thu Mar 3 02:18:46 2005 From: frank.beckmann at vodafone.com (Beckmann, Frank, VF-DE) Date: Wed, 2 Mar 2005 16:18:46 +0100 Subject: Ssh / sft /scp password problems, agent runs fine Message-ID: <8879E2295D4FE544A35E9C8A16D62BBEBF10B9@DEDUS-WICL01M01.vf-de.internal.vodafone.com> Hi :-) When i use scp or sftp with password login, it dont com back fbeckman at zvadm6:/home/fbeckman $ scp /etc/hosts root at devil3:/var/tmp/ Password: hosts 100% 283KB 283.4KB/s 00:00 .... ^CKilled by signal 2. fbeckman at zvadm6:/home/fbeckman $ Only Ctrl C helps Exsample 2: ssh devil3 uname -a Password: SunOS devil3 5.8 Generic_117350-02 sun4u sparc SUNW,Ultra-Enterprise ............................. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IF i use sshkeys there are no problems !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Or the Remote host use an old ssh version fbeckman at zvadm6:/home/fbeckman $ ssh -V OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004 ssh asbach1 ssh -V root at asbach1's password: OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f Runs fine... ./configure --prefix=/usr \ --sysconfdir=/etc \ --with-pid-dir=/etc \ --libexecdir=/usr/bin \ --x-libraries=/usr/openwin \ --with-pam \ --with-ssl-dir=/software/INSTALL/openssh/tree_openssl-0.9/openssl-0.9.7e \ --with-entropy-timeout=2000 \ --with-zlib=/home/fbeckman/zlib-1.2.1 \ --with-mantype=man \ --disable-wtmp \ #authlog... Solaris dont try to wrote in wtmp .. It not exsit --enable-wtmpx \ --mandir=/usr/share/man \ --without-rpath \ --with-mantype=man \ --disable-etc-default-login # umask problem... Dont use the default umask gcc --version gcc (GCC) 3.4.1 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Frank ################################################################################################################# WITHOUT KEY fbeckman at zvadm6:/home/fbeckman $ ssh -vvv devil3 uname -a OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004 debug1: Reading configuration data /home/fbeckman/.ssh/config debug1: Reading configuration data /etc/ssh_config debug3: cipher ok: blowfish-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes128-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: 3des-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: cast128-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: arcfour [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes192-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: ciphers ok: [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug2: ssh_connect: needpriv 0 debug1: Connecting to devil3 [] port 22. debug1: Connection established. debug3: Not a RSA1 key file /home/fbeckman/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/fbeckman/.ssh/id_rsa type 1 debug1: identity file /home/fbeckman/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc 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-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client blowfish-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server blowfish-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 128/256 debug2: bits set: 499/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts debug2: key_type_from_name: unknown key type '1024' debug3: key_read: missing keytype debug3: key_read: type mismatch debug3: check_host_in_hostfile: match line 1301 debug1: Host 'devil3' is known and matches the RSA host key. debug1: Found key in /etc/ssh_known_hosts:1301 debug2: bits set: 516/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/fbeckman/.ssh/id_rsa (12e308) debug2: key: /home/fbeckman/.ssh/id_dsa (0) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/fbeckman/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /home/fbeckman/.ssh/id_dsa debug3: no such identity: /home/fbeckman/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: debug3: packet_send2: adding 32 (len 24 padlen 8 extra_pad 64) debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64) debug1: Authentication succeeded (keyboard-interactive). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: x11_get_proto: /usr/openwin/bin/xauth list unix:25.0 . 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 debug2: client_session2_setup: id 0 debug1: Sending command: uname -a debug2: channel 0: request exec confirm 0 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 SunOS devil3 5.8 Generic_117350-02 sun4u sparc SUNW,Ultra-Enterprise debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed ############################################################################################################## WIHT KEY fbeckman at zvadm6:/home/fbeckman $ ssh -vvv devil3 uname -a fbeckman at zvadm6:/home/fbeckman $ getkey_admin Enter passphrase for /home/fbeckman/.ssh/tuxsparc: Identity added: /home/fbeckman/.ssh/tuxsparc (/home/fbeckman/.ssh/tuxsparc) 1024 6e:99:06:37:86:18:c8:c4:19:6b:d9:ed:fb:b8:e2:c3 /home/fbeckman/.ssh/tuxsparc (RSA) fbeckman at zvadm6:/home/fbeckman $ ssh -vvv devil3 uname -a OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004 debug1: Reading configuration data /home/fbeckman/.ssh/config debug1: Reading configuration data /etc/ssh_config debug3: cipher ok: blowfish-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes128-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: 3des-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: cast128-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: arcfour [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes192-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: ciphers ok: [blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug2: ssh_connect: needpriv 0 debug1: Connecting to devil3 [] port 22. debug1: Connection established. debug3: Not a RSA1 key file /home/fbeckman/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/fbeckman/.ssh/id_rsa type 1 debug1: identity file /home/fbeckman/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc 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-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client blowfish-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server blowfish-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 133/256 debug2: bits set: 503/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts debug2: key_type_from_name: unknown key type '1024' debug3: key_read: missing keytype debug3: key_read: type mismatch debug3: check_host_in_hostfile: match line 1301 debug1: Host 'devil3' is known and matches the RSA host key. debug1: Found key in /etc/ssh_known_hosts:1301 debug2: bits set: 501/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/fbeckman/.ssh/tuxsparc (12e3b0) debug2: key: /home/fbeckman/.ssh/id_rsa (12e308) debug2: key: /home/fbeckman/.ssh/id_dsa (0) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/fbeckman/.ssh/tuxsparc debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 149 debug2: input_userauth_pk_ok: fp 6e:99:06:37:86:18:c8:c4:19:6b:d9:ed:fb:b8:e2:c3 debug3: sign_and_send_pubkey debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: x11_get_proto: /usr/openwin/bin/xauth list unix:25.0 . 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 0 debug2: client_session2_setup: id 0 debug1: Sending command: uname -a debug2: channel 0: request exec confirm 0 debug2: fd 4 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 SunOS devil3 5.8 Generic_117350-02 sun4u sparc SUNW,Ultra-Enterprise debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 7 c -1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.3 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 0 ________________________________________ Vodafone D2 GmbH Gruppe TOIS IT-Infrastrukture Service Support Billing & Customer Care Am Seestern 4 / E2-09 D-40547 D?sseldorf Telefon: +49 (0)211-533 5758 Fax: +49 (0)211-533 1256 E-Mail: Frank.Beckmann at vodafone.com ________________________________________ Vodafone D2 GmbH Gruppe TOIS IT-Infrastrukture Service Support Billing & Customer Care Am Seestern 4 / E2-09 D-40547 D?sseldorf Telefon: +49 (0)211-533 5758 Fax: +49 (0)211-533 1256 E-Mail: Frank.Beckmann at vodafone.com From frank.beckmann at vodafone.com Thu Mar 3 02:23:57 2005 From: frank.beckmann at vodafone.com (Beckmann, Frank, VF-DE) Date: Wed, 2 Mar 2005 16:23:57 +0100 Subject: (Ssh / sft /scp password problems, agent runs fine) root Message-ID: <8879E2295D4FE544A35E9C8A16D62BBEBF10BA@DEDUS-WICL01M01.vf-de.internal.vodafone.com> Hi :-) I forgott... user -> root hangs root -> root hangs user -> user runs fine fbeckman: ssh fbeckman at devil3 uname -a Password: SunOS devil3 5.8 Generic_117350-02 sun4u sparc SUNW,Ultra-Enterprise Runs fine fbeckman: ssh root at devil3 uname -a Password: SunOS devil3 5.8 Generic_117350-02 sun4u sparc SUNW,Ultra-Enterprise HANGS Frank ________________________________________ Vodafone D2 GmbH Gruppe TOIS IT-Infrastrukture Service Support Billing & Customer Care Am Seestern 4 / E2-09 D-40547 D?sseldorf Telefon: +49 (0)211-533 5758 Fax: +49 (0)211-533 1256 E-Mail: Frank.Beckmann at vodafone.com From buytenh at wantstofly.org Thu Mar 3 03:48:17 2005 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Wed, 2 Mar 2005 17:48:17 +0100 Subject: openssh 3.9p1 problems on big-endian ARM platform In-Reply-To: References: <20050228134636.GA9084@xi.wantstofly.org> Message-ID: <20050302164817.GD20897@xi.wantstofly.org> On Mon, Feb 28, 2005 at 05:56:37PM +0300, Dan Yefimov wrote: > > I'm having some trouble with openssh 3.9p1 on a big-endian ARM platform. > > Everything appears to build and run okay, but I can only shell to the box > > itself or to other big-endian ARM boxes. Shelling to an x86 box gives me: > > > > Disconnecting: Corrupted MAC on input. > > > > and shelling from an x86 to the ARM gives me the same message. > > > > [snip] > > I'm afraid you have problems with openssl that is used internally by > openssh. Try upgrading to the latest openssl release. If that doesn't > help, try recompiling it with platform-specific optimisations turned > off. Of course, your compiler must be able to generate correct code > for your particular platform. It seems that openssl is assuming that ARM platforms are always little-endian. Recompiling openssl now, let's see if this helps. (Patch sent to openssl mailing list.) Many thanks, this helped a lot. cheers, Lennert From gert at greenie.muc.de Thu Mar 3 03:49:50 2005 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 2 Mar 2005 17:49:50 +0100 Subject: (Ssh / sft /scp password problems, agent runs fine) root In-Reply-To: <8879E2295D4FE544A35E9C8A16D62BBEBF10BA@DEDUS-WICL01M01.vf-de.internal.vodafone.com> References: <8879E2295D4FE544A35E9C8A16D62BBEBF10BA@DEDUS-WICL01M01.vf-de.internal.vodafone.com> Message-ID: <20050302164950.GW1110@greenie.muc.de> Hi, On Wed, Mar 02, 2005 at 04:23:57PM +0100, Beckmann, Frank, VF-DE wrote: > user -> root hangs > > root -> root hangs Chance is that root has something in its .profile/.kshrc/.bashrc (or whatever) which runs an application at startup that goes into the background and doesn't properly close its stdin/stdout/stderr file descriptors. 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 at net.informatik.tu-muenchen.de From djm at mindrot.org Thu Mar 3 09:54:59 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 03 Mar 2005 09:54:59 +1100 Subject: Call for release testing Message-ID: <42264443.2050805@mindrot.org> Hi, We are preparing to release another stable OpenSSH soon, so once again we are asking for your help in testing CVS snapshots. Changes include: * ssh(1) now allows the optional specification of an address to bind to in port forwarding connections (local, remote and dynamic). See the -L, -R options in the ssh(1) man page as well as LocalForward and RemoteForward options in ssh_config(5). (Bugzilla #413) * To control remote bindings while retaining backwards compatibility, sshd(8)'s GatewayPorts option has been extended. To allow client specified bind addresses for remote (-R) port forwardings, the server must be configured with "GatewayPorts clientspecified". * To support better selection of binding addresses for remote port forwardings, sshd(8) now supports the new address specification methods in draft-ietf-secsh-connect-24.txt section 7.1. In particular, the empty "" address_to_bind is recognised as meaning a wildcard bind for all supported protocols (IPv4 and IPv6) whereas "localhost" means an all-protocols loopback bind. * ssh(1) and ssh-keyscan(1) now support hashing of host names and addresses added to known_hosts files, controlled by the ssh(1) HashKnownHosts configuration directive. This option improves user privacy by hiding which hosts have been visited. For this release the option will be off by default, but may be turned on once it receives sufficient testing. * Add options for managing keys in known_hosts files to ssh-keygen(1), including the ability to search for hosts by name, delete hosts by name and convert an unhashed known_hosts file into one with hashed names. These are particularly useful for managing known_hosts files with hashed hostnames. * Improve account and password expiry support in sshd(8). Ther server will now warn in advance for both account and password expiry. * sshd(8) will now log the source of connections denied by AllowUsers, DenyUsers, AllowGroups and DenyGroups (Bugzilla #909) * Added AddressFamily option to sshd(8), to allow global control over IPv4/IPv6 usage. (Bugzilla #989) * Improved sftp(1) client, including bugfixes and optimisations for the ``ls'' command and command history and editing support using libedit. This may be enabled using the --with-libedit configure argument * Improved the handling of bad data in authorized_keys files, eliminating fatal errors on corrupt or very large keys. (Bugzilla #884) * Improved connection multiplexing support in ssh(1). Several bugs have been fixed and a new "command mode" has been added to allow the control of a running multiplexing master connection, including checking that it is up, determining its PID and asking it to exit. * Have scp(1) and sftp(1) wait for the spawned ssh to exit before they exit themselves. This prevents ssh from being unable to restore terminal modes (not normally a problem on OpenBSD but common with -Portable on POSIX platforms). (Bugzilla #950) * Portable OpenSSH: - Add *EXPERIMENTAL* BSM audit support for Solaris systems (Bugzilla #125) - Enable IPv6 on AIX where possible (see README.platform for details), working around a misfeature of AIX's getnameinfo. (Bugzilla #835) - Teach sshd(8) to write failed login records to btmp for failed auth attempts (currently only for password, kbdint and C/R, only on Linux and HP-UX) - sshd(8) now sends output from failing PAM session modules to the user before exiting, similar to the way /etc/nologin is handled - Store credentials from gssapi-with-mic authentication early enough to be available to PAM session modules when privsep=yes. * Many bug fixes and improvements, for details see the ChangeLog and http://bugzilla.mindrot.org/show_bug.cgi?id=914 The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable snapshots are available at: ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ or one of its mirrors listed at http://www.openssh.com/portable.html#ftp Please test! Running the regression tests supplied with Portable does not require installation and is a simply: $ ./configure && make tests Testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. From tim at multitalents.net Thu Mar 3 10:30:08 2005 From: tim at multitalents.net (Tim Rice) Date: Wed, 2 Mar 2005 15:30:08 -0800 (PST) Subject: drop support for SCO 3.2v4.2 In-Reply-To: References: Message-ID: I don't think the original message ever made it to the list. On Fri, 25 Feb 2005, Tim Rice wrote: > > I'm considering commiting something like this for the next release. > > -------------------------------- > --- configure.ac.old 2005-02-24 19:47:25.361190001 -0800 > +++ configure.ac 2005-02-25 12:33:35.341390018 -0800 > @@ -374,23 +374,7 @@ > ;; > # SCO UNIX and OEM versions of SCO UNIX > *-*-sco3.2v4*) > - CPPFLAGS="$CPPFLAGS -Dftruncate=chsize" > [snip next 16 deleted lines] > + AC_MSG_ERROR("This Platform is no longer supported.") > ;; > # SCO OpenServer 5.x > *-*-sco3.2v5*) > -------------------------------- > > I no longer have the time or interest in supporting OpenSSH on > the very old 3.2v4.2 platform. The TCP/IP stack is so old it's > too much of a pain to make it work. I have a OpenSSH_3.8.1p1 working > and if I remember correctly, I had a 3.9p1 working but there have been > many changes since 3.9p1 > > If anyone still needs OpenSSH on SCO3, now it the time to test > the curent snapshots and submit patches. > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Thu Mar 3 11:05:51 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 03 Mar 2005 11:05:51 +1100 Subject: Call for release testing In-Reply-To: <42264443.2050805@mindrot.org> References: <42264443.2050805@mindrot.org> Message-ID: <422654DF.2000902@zip.com.au> Damien Miller wrote: > We are preparing to release another stable OpenSSH soon, so once > again we are asking for your help in testing CVS snapshots. One thing not in Damien's list: OpenSSH Portable now has a (completely voluntary) configuration survey. It will collect information about the platform and the options OpenSSH was configured with and mail it to an archive. We tried to be careful not to collect anything that might be considered sensitive, however if anyone has any issues with the data collected then please let us know). The raw data will be available only to the development team, however we may publish summary data at some point in the future. This will help us support your platform! It will allow us to (among other things) know which combinations of options are valid on which plaforms and better target testing. This would allow us to answer questions like (and these are real examples of things we've need to know in the past): * If we make changes to realpath(), which platforms will that affect? * Are there any platforms currently in use that don't have fchdir()? * Do any platforms have both PAM and BSDauth? * and so on... You can view the data that is collected by running "make survey" and looking at the file "survey" in the build dir. The data is not sent until you explicitly request it ("make send-survey"). If you have any doubts at all then ask us (or then don't send it). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From gert at greenie.muc.de Thu Mar 3 19:34:30 2005 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 3 Mar 2005 09:34:30 +0100 Subject: drop support for SCO 3.2v4.2 In-Reply-To: References: Message-ID: <20050303083430.GY1110@greenie.muc.de> Hi, On Wed, Mar 02, 2005 at 03:30:08PM -0800, Tim Rice wrote: > I don't think the original message ever made it to the list. It did, but for some weird reason appeared only today... > On Fri, 25 Feb 2005, Tim Rice wrote: > > > > >I'm considering commiting something like this for the next release. > > > >-------------------------------- > >--- configure.ac.old 2005-02-24 19:47:25.361190001 -0800 > >+++ configure.ac 2005-02-25 12:33:35.341390018 -0800 > >@@ -374,23 +374,7 @@ > > ;; > > # SCO UNIX and OEM versions of SCO UNIX > > *-*-sco3.2v4*) > >- CPPFLAGS="$CPPFLAGS -Dftruncate=chsize" > >[snip next 16 deleted lines] > >+ AC_MSG_ERROR("This Platform is no longer supported.") >From my side: "go for it". The current snapshots don't compile anyway (ssh does, but sshd wants socketpair(), which isn't available), and my last SCO 3.2v4.2 system is going to retire "soon" anyway. 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 at net.informatik.tu-muenchen.de From vinschen at redhat.com Thu Mar 3 19:37:56 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 3 Mar 2005 09:37:56 +0100 Subject: Call for release testing In-Reply-To: <42264443.2050805@mindrot.org> References: <42264443.2050805@mindrot.org> Message-ID: <20050303083756.GA5085@cygbert.vinschen.de> On Mar 3 09:54, Damien Miller wrote: > Hi, > > We are preparing to release another stable OpenSSH soon, so once > again we are asking for your help in testing CVS snapshots. I can't test the latest from CVS, because the CVS server suddenly requires a password: $ cvs up openssh at anoncvs.be.openbsd.org's password: The home page of portable OpenSSH still tells me that no password is required. Is something broken? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From djm at mindrot.org Thu Mar 3 20:01:13 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 03 Mar 2005 20:01:13 +1100 Subject: Call for release testing In-Reply-To: <20050303083756.GA5085@cygbert.vinschen.de> References: <42264443.2050805@mindrot.org> <20050303083756.GA5085@cygbert.vinschen.de> Message-ID: <4226D259.7060502@mindrot.org> Corinna Vinschen wrote: > On Mar 3 09:54, Damien Miller wrote: > >>Hi, >> >>We are preparing to release another stable OpenSSH soon, so once >>again we are asking for your help in testing CVS snapshots. > > > I can't test the latest from CVS, because the CVS server suddenly > requires a password: > > $ cvs up > openssh at anoncvs.be.openbsd.org's password: > > The home page of portable OpenSSH still tells me that no password is > required. Is something broken? I am told that the mirror has moved. The new anoncvs server is openssh at anoncvs.at.openbsd.org The web site will be updated shortly. Thanks, Damien From vinschen at redhat.com Thu Mar 3 22:26:22 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 3 Mar 2005 12:26:22 +0100 Subject: Call for release testing In-Reply-To: <4226D259.7060502@mindrot.org> References: <42264443.2050805@mindrot.org> <20050303083756.GA5085@cygbert.vinschen.de> <4226D259.7060502@mindrot.org> Message-ID: <20050303112621.GB2839@cygbert.vinschen.de> On Mar 3 20:01, Damien Miller wrote: > Corinna Vinschen wrote: > >On Mar 3 09:54, Damien Miller wrote: > > > >>Hi, > >> > >>We are preparing to release another stable OpenSSH soon, so once > >>again we are asking for your help in testing CVS snapshots. > > > > > >I can't test the latest from CVS, because the CVS server suddenly > >requires a password: > > > > $ cvs up > > openssh at anoncvs.be.openbsd.org's password: > > > >The home page of portable OpenSSH still tells me that no password is > >required. Is something broken? > > I am told that the mirror has moved. The new anoncvs server is > openssh at anoncvs.at.openbsd.org > > The web site will be updated shortly. Yup, using anoncvs.at.* works fine. Thanks. I'll test Cygwin ASAP. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From vinschen at redhat.com Thu Mar 3 23:59:02 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 3 Mar 2005 13:59:02 +0100 Subject: Call for release testing In-Reply-To: <42264443.2050805@mindrot.org> References: <42264443.2050805@mindrot.org> Message-ID: <20050303125902.GA9636@cygbert.vinschen.de> On Mar 3 09:54, Damien Miller wrote: > Hi, > > We are preparing to release another stable OpenSSH soon, so once > again we are asking for your help in testing CVS snapshots. Built and regress-tested on Cygwin. Looks pretty good with just one exception: - The reexec.sh test is broken on Cygwin, because the test tries to copy and cmp /bin/ls, while there's only a /bin/ls.exe. This is arguably a problem in the Cygwin environment. Changing the test so that /bin/ls.exe is used let the test work just fine, so no worries here. Also one problem with the survey: There's no such command as `oslevel' on Cygwin. FWIW, I didn't find this command on Linux, too. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From openssh at roumenpetrov.info Fri Mar 4 01:52:35 2005 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 03 Mar 2005 16:52:35 +0200 Subject: Call for release testing In-Reply-To: <42264443.2050805@mindrot.org> References: <42264443.2050805@mindrot.org> Message-ID: <422724B3.2000601@roumenpetrov.info> Hi all, Please find attached file "readconf-SendEnv.patch". This small patch allow ssh to collect variables from the local environment that should be sent to the server only from the ssh_config section to this host/server. sample ssh_config: Host test1 SendEnv TEST1 Host test2 SendEnv TEST2 Without patch ssh will send TEST1 and TEST2 to all servers. Note that variables from SendEnv in global defaults for all hosts ('HOST *' section) and command line are always sent. Damien Miller wrote: > Hi, > > We are preparing to release another stable OpenSSH soon, so once > again we are asking for your help in testing CVS snapshots. > > Changes include: > > [SNIP] -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: readconf-SendEnv.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050303/1704acc5/attachment.ksh From jbasney at ncsa.uiuc.edu Fri Mar 4 03:52:17 2005 From: jbasney at ncsa.uiuc.edu (Jim Basney) Date: Thu, 03 Mar 2005 10:52:17 -0600 Subject: Call for release testing In-Reply-To: Message from Damien Miller of "Thu, 03 Mar 2005 09:54:59 +1100." <42264443.2050805@mindrot.org> Message-ID: <200503031652.j23GqH218602@mail.ncsa.uiuc.edu> Damien Miller wrote: > We are preparing to release another stable OpenSSH soon, so once > again we are asking for your help in testing CVS snapshots. Test results for openssh-SNAP-20050303.tar.gz: Debian GNU/Linux 3.1 i686: PASS ./configure --with-pam --with-kerberos5=/usr --with-privsep-path=/var/run/sshd make tests passes. PAM authentication looks good. Kerberos GSSAPI authentication and credential delegation looks good. Red Hat Enterprise Linux AS release 3 (Taroon Update 3) ia64: PASS ./configure --with-pam --with-kerberos5=/usr/kerberos make tests passes PAM authentication looks good. Kerberos GSSAPI authentication and credential delegation looks good. (Tested PAM and Kerberos for SNAP ssh but not SNAP sshd on this machine.) Mac OS X 10.3.8 PowerPC G4 Darwin Kernel Version 7.8.0: FAIL ./configure && make tests fails: run test multiplex.sh ... test connection multiplexing: envpass test connection multiplexing: transfer test connection multiplexing: status 0 test connection multiplexing: status 1 test connection multiplexing: status 4 test connection multiplexing: status 5 test connection multiplexing: status 44 Master running (pid=18137) Exit request sent. exit command failed cat: /Users/jbasney/testing/openssh/regress/pidfile: No such file or directory no sshd running failed connection multiplexing make[1]: *** [t-exec] Error 1 make: *** [tests] Error 2 Running ./configure && make tests for openssh-3.9p1.tar.gz on this machine passes. From jbasney at ncsa.uiuc.edu Fri Mar 4 04:55:27 2005 From: jbasney at ncsa.uiuc.edu (Jim Basney) Date: Thu, 03 Mar 2005 11:55:27 -0600 Subject: Call for release testing In-Reply-To: Message from Jim Basney of "Thu, 03 Mar 2005 10:52:17 CST." <200503031652.j23GqH218602@mail.ncsa.uiuc.edu> Message-ID: <200503031755.j23HtQ224799@mail.ncsa.uiuc.edu> Jim Basney wrote: > Test results for openssh-SNAP-20050303.tar.gz: > > Mac OS X 10.3.8 PowerPC G4 Darwin Kernel Version 7.8.0: FAIL > ./configure && make tests fails: > run test multiplex.sh ... > test connection multiplexing: envpass > test connection multiplexing: transfer > test connection multiplexing: status 0 > test connection multiplexing: status 1 > test connection multiplexing: status 4 > test connection multiplexing: status 5 > test connection multiplexing: status 44 > Master running (pid=18137) > Exit request sent. > exit command failed > cat: /Users/jbasney/testing/openssh/regress/pidfile: No such file or directory > no sshd running > failed connection multiplexing > make[1]: *** [t-exec] Error 1 > make: *** [tests] Error 2 Looks like '/bin/ps -p pid' for a non-existent pid exits with status 0 on Darwin. Changing multiplex.sh to use 'kill -0 pid' fixes it. With that change, './configure && make tests' succeeds. diff -Naur openssh.old/regress/multiplex.sh openssh.new/regress/multiplex.sh --- openssh.old/regress/multiplex.sh Mon Dec 6 06:12:15 2004 +++ openssh.new/regress/multiplex.sh Thu Mar 3 11:42:31 2005 @@ -88,6 +88,6 @@ # Wait for master to exit sleep 2 -ps -p $MASTER_PID >/dev/null && fail "exit command failed" +kill -0 $MASTER_PID >/dev/null 2>&1 && fail "exit command failed" cleanup From goebel at emunix.emich.edu Fri Mar 4 06:23:32 2005 From: goebel at emunix.emich.edu (Matt Goebel) Date: Thu, 3 Mar 2005 14:23:32 -0500 (EST) Subject: Question/concern about bsm auditing option on solaris Message-ID: <200503031923.j23JNWjx028651@poe.emich.edu> Hello, I downloaded and compiled the Mar 2, 2005 snapshot and compiled it with bsm auditing for solaris turned on. I've been noticing about a dozen or so of the following messages per day now. Not sure exactly what it is, or if it is a big issue. Mar 3 13:46:10 machine_name sshd[15298]: [ID 800047 auth.crit] fatal: mm_request_send: write If it matters it is running on solaris 8 sparc, with pretty current patches applied. Thanks, Matt Goebel -- Matthew Goebel : goebel at emunix.emich.edu : Unix Jockey @ EMU : Hail Eris Neo-Student, Net Lurker, Donut consumer, and procrastinating Furry Fan. "Always with the negative waves, Moriarty" - Oddball "Comfort the troubled, and trouble the comfortable." - Dietrich Bonhoeffer From Frank.Beckmann at gmx.com Fri Mar 4 06:44:47 2005 From: Frank.Beckmann at gmx.com (Frank Beckmann) Date: Thu, 3 Mar 2005 20:44:47 +0100 (MET) Subject: ssh hang problem under solaris 8 Message-ID: <27168.1109879087@www73.gmx.net> Hi :-) i have try a hang on exit patch that i found in the web for an old openssh version, but it dosent help :-( in a german gdb howto i found a tip that the backtrace output can help to analyse the problem.... is it a solaris problem ? Greetings Frank sshd: #0 0xff19d618 in _poll () from /usr/lib/libc.so.1 #1 0xff14d53c in select () from /usr/lib/libc.so.1 #2 0x000339a0 in wait_until_can_do_something (readsetp=0xffbee5dc, writesetp=0xffbee5d8, maxfdp=0xffbee5d4, nallocp=0xffbee5d0, max_time_milliseconds=0) at serverloop.c:325 #3 0x00034d6c in server_loop2 (authctxt=0x123ac8) at serverloop.c:776 #4 0x0003ae0c in do_authenticated (authctxt=0x123ac8) at session.c:2265 #5 0x0002ea78 in main (ac=1161216, av=0x11f288) at sshd.c:1719 ssh: (gdb) backtrace #0 0xff19d618 in _poll () #1 0xff14d53c in _select () #2 0x3156c in ?? () #3 0x2d048 in ?? () From dtucker at zip.com.au Fri Mar 4 07:06:56 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 04 Mar 2005 07:06:56 +1100 Subject: Question/concern about bsm auditing option on solaris In-Reply-To: <200503031923.j23JNWjx028651@poe.emich.edu> References: <200503031923.j23JNWjx028651@poe.emich.edu> Message-ID: <42276E60.4030005@zip.com.au> Matt Goebel wrote: > I downloaded and compiled the Mar 2, 2005 snapshot and compiled it with > bsm auditing for solaris turned on. I've been noticing about a dozen or > so of the following messages per day now. Not sure exactly what it is, or > if it is a big issue. > > Mar 3 13:46:10 machine_name sshd[15298]: [ID 800047 auth.crit] fatal: mm_request_send: write If that message is preceded by "unpermitted request 56" or similar then I think I know what it is: something is causing an audit event before the monitor has allowed them. I suspect it's a connection that is disconnected without supplying a username, or which supplies a username but does not attempt any auth methods. Please try this patch. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-bsm-monitor.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050304/e34e833f/attachment.ksh From deengert at anl.gov Fri Mar 4 07:28:23 2005 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 03 Mar 2005 14:28:23 -0600 Subject: Call for release testing In-Reply-To: <42264443.2050805@mindrot.org> References: <42264443.2050805@mindrot.org> Message-ID: <42277367.2080904@anl.gov> > Please test! Running the regression tests supplied with Portable > does not require installation and is a simply: > > $ ./configure && make tests > Built on Solaris 9 with Krb5-1.4.0 in AFS Had to make one change to regress/muliplex.sh since AFS does not support a socket. --- ,multiplex.sh Mon Dec 6 06:12:15 2004 +++ multiplex.sh Thu Mar 3 14:12:37 2005 @@ -1,7 +1,7 @@ # $OpenBSD: multiplex.sh,v 1.9 2004/11/07 00:32:41 djm Exp $ # Placed in the Public Domain. -CTL=$OBJ/ctl-sock +CTL=/tmp/openssh.regress.ctl-sock tid="connection multiplexing" Tested the ssh using gssspi to a 3.8 system, and it looks good. so far. > Testing on suitable non-production systems is also appreciated. > Please send reports of success or failure to > openssh-unix-dev at mindrot.org. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dtucker at zip.com.au Fri Mar 4 07:37:55 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 04 Mar 2005 07:37:55 +1100 Subject: ssh hang problem under solaris 8 In-Reply-To: <27168.1109879087@www73.gmx.net> References: <27168.1109879087@www73.gmx.net> Message-ID: <422775A3.5010704@zip.com.au> Frank Beckmann wrote: > i have try a hang on exit patch that i found in the web for an old openssh > version, but it dosent help :-( What are you doing when it hangs? Does any of this apply to your situation? http://bugzilla.mindrot.org/show_bug.cgi?id=52 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From SalasJL at LOUISVILLE.STORTEK.COM Fri Mar 4 09:06:44 2005 From: SalasJL at LOUISVILLE.STORTEK.COM (Salas, Jose L) Date: Thu, 3 Mar 2005 15:06:44 -0700 Subject: OPENSSH Question Message-ID: <3F5A6C8A25AE874F9B5AF7C9EBB156BB0242A403@EXCHVS1.louisville.stortek.com> Hi, We are in the process of implementing 15 HP Integrity Itanium servers Running HP-UX 11.23 and We would like to know if OpenSSH will work fine Like is working now on all the HP 9000 servers running HP-UX 11.11. Thanks in advance for your help! Jose Luis Salas, M.E. EDS UNIX Team @ StorageTek Office:(303) 661-5774 Page: (877) 705-5928 Mail: jose.salas at eds.com jose_salas at stortek.com 8777055928 at my2way.com From dtucker at zip.com.au Fri Mar 4 09:20:44 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 04 Mar 2005 09:20:44 +1100 Subject: OPENSSH Question In-Reply-To: <3F5A6C8A25AE874F9B5AF7C9EBB156BB0242A403@EXCHVS1.louisville.stortek.com> References: <3F5A6C8A25AE874F9B5AF7C9EBB156BB0242A403@EXCHVS1.louisville.stortek.com> Message-ID: <42278DBC.6070609@zip.com.au> Salas, Jose L wrote: > Hi, We are in the process of implementing 15 HP Integrity Itanium > servers Running HP-UX 11.23 and We would like to know if OpenSSH will > work fine Like is working now on all the HP 9000 servers running HP-UX > 11.11. Should do, (I don't have access to one but I've seen reports from people running it). The only issue I'm aware of is that sshd doesn't know how to write to the new-format login recording databases. The enhancement request is here at the URL below, although we haven't had time to look much at it: http://bugzilla.mindrot.org/show_bug.cgi?id=979 (Enabling PAM is one potential way to work around that). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From martin.dudle at mgb.ch Fri Mar 4 18:52:46 2005 From: martin.dudle at mgb.ch (Martin Dudle) Date: Fri, 04 Mar 2005 08:52:46 +0100 Subject: ssh hang problem under solaris 8 In-Reply-To: <27168.1109879087@www73.gmx.net> References: <27168.1109879087@www73.gmx.net> Message-ID: <422813CE.6080302@mgb.ch> i have encountered the same problem. the patch suggested by darren tucker did not fix the problem. thanks, -martin Frank Beckmann wrote: >Hi :-) > >i have try a hang on exit patch that i found in the web for an old openssh >version, but it dosent help :-( > >in a german gdb howto i found a tip that the backtrace output can help to >analyse the problem.... > >is it a solaris problem ? > >Greetings > >Frank > >sshd: >#0 0xff19d618 in _poll () from /usr/lib/libc.so.1 >#1 0xff14d53c in select () from /usr/lib/libc.so.1 >#2 0x000339a0 in wait_until_can_do_something (readsetp=0xffbee5dc, >writesetp=0xffbee5d8, maxfdp=0xffbee5d4, > nallocp=0xffbee5d0, max_time_milliseconds=0) at serverloop.c:325 >#3 0x00034d6c in server_loop2 (authctxt=0x123ac8) at serverloop.c:776 >#4 0x0003ae0c in do_authenticated (authctxt=0x123ac8) at session.c:2265 >#5 0x0002ea78 in main (ac=1161216, av=0x11f288) at sshd.c:1719 > >ssh: >(gdb) backtrace >#0 0xff19d618 in _poll () >#1 0xff14d53c in _select () >#2 0x3156c in ?? () >#3 0x2d048 in ?? () > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From djm at mindrot.org Fri Mar 4 19:08:52 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 04 Mar 2005 19:08:52 +1100 Subject: Call for release testing In-Reply-To: <200503031755.j23HtQ224799@mail.ncsa.uiuc.edu> References: <200503031755.j23HtQ224799@mail.ncsa.uiuc.edu> Message-ID: <42281794.1000308@mindrot.org> Jim Basney wrote: > -ps -p $MASTER_PID >/dev/null && fail "exit command failed" > +kill -0 $MASTER_PID >/dev/null 2>&1 && fail "exit command failed" Is "kill -0" standard? (it works on BSD, at least) Otherwise we could use grep -q "$PID" -d From dtucker at zip.com.au Fri Mar 4 19:18:15 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 04 Mar 2005 19:18:15 +1100 Subject: ssh hang problem under solaris 8 In-Reply-To: <422813CE.6080302@mgb.ch> References: <27168.1109879087@www73.gmx.net> <422813CE.6080302@mgb.ch> Message-ID: <422819C7.1040906@zip.com.au> Martin Dudle wrote: > i have encountered the same problem. the patch suggested by darren > tucker did not fix the problem. It appears that the problem is related to the PAM keyboard-interactive authentication method. Try disabling it ("ChallengeResponseAuthentication no" in sshd_config). I'm still not sure what the underlying cause is, though. Are you using PAM and if so which modules? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Mar 4 19:34:59 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 04 Mar 2005 19:34:59 +1100 Subject: Call for release testing In-Reply-To: <42281794.1000308@mindrot.org> References: <200503031755.j23HtQ224799@mail.ncsa.uiuc.edu> <42281794.1000308@mindrot.org> Message-ID: <42281DB3.7080103@zip.com.au> Damien Miller wrote: > Is "kill -0" standard? (it works on BSD, at least) According to my copy of Stevens' APUE, a signal of zero is defined in POSIX.1 as a null signal, so yes it's standard. It also says that it "is often used to determine if a specific process exists". Now, "will it work everywhere" is a different question. > Otherwise we could use grep -q "$PID" That's racy since it might find the argument to grep depending on the scheduling. You can use awk to pick out the right column from the ps output but then you potentiall have to deal with the different ps output formats... I vote to make it "kill -0". -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Mar 4 19:49:14 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 04 Mar 2005 19:49:14 +1100 Subject: Call for release testing In-Reply-To: <422724B3.2000601@roumenpetrov.info> References: <42264443.2050805@mindrot.org> <422724B3.2000601@roumenpetrov.info> Message-ID: <4228210A.5060706@mindrot.org> Roumen Petrov wrote: > Hi all, > > Please find attached file "readconf-SendEnv.patch". > This small patch allow ssh to collect variables from the local > environment that should be sent to the server only from the ssh_config > section to this host/server. Patch applied, thanks! -d From binder at arago.de Fri Mar 4 21:38:59 2005 From: binder at arago.de (Thomas Binder) Date: Fri, 4 Mar 2005 11:38:59 +0100 Subject: Call for release testing In-Reply-To: <42281DB3.7080103@zip.com.au> References: <200503031755.j23HtQ224799@mail.ncsa.uiuc.edu> <42281794.1000308@mindrot.org> <42281DB3.7080103@zip.com.au> Message-ID: <20050304103859.GA7104817@ohm.arago.de> Hi! On Fri, Mar 04, 2005 at 07:34:59PM +1100, Darren Tucker wrote: > > Otherwise we could use grep -q "$PID" > > That's racy since it might find the argument to grep depending > on the scheduling. Also note that not all flavours of `grep' support `-q'. At least IRIX 6.x and Solaris 7/8 don't. Ciao Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050304/4e72fb9a/attachment.bin From dtucker at zip.com.au Fri Mar 4 22:01:29 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 04 Mar 2005 22:01:29 +1100 Subject: Call for release testing In-Reply-To: <20050304103859.GA7104817@ohm.arago.de> References: <200503031755.j23HtQ224799@mail.ncsa.uiuc.edu> <42281794.1000308@mindrot.org> <42281DB3.7080103@zip.com.au> <20050304103859.GA7104817@ohm.arago.de> Message-ID: <42284009.2040305@zip.com.au> Thomas Binder wrote: > Also note that not all flavours of `grep' support `-q'. At least > IRIX 6.x and Solaris 7/8 don't. Actually, on Solaris it depends on which grep: /usr/xpg4/bin/grep understands it. But point taken, it's not portable (and the regress tests in Portable already use "grep >/dev/null" instead of "grep -q" for that reason). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From binder at arago.de Fri Mar 4 22:22:36 2005 From: binder at arago.de (Thomas Binder) Date: Fri, 4 Mar 2005 12:22:36 +0100 Subject: Call for release testing In-Reply-To: <42284009.2040305@zip.com.au> References: <200503031755.j23HtQ224799@mail.ncsa.uiuc.edu> <42281794.1000308@mindrot.org> <42281DB3.7080103@zip.com.au> <20050304103859.GA7104817@ohm.arago.de> <42284009.2040305@zip.com.au> Message-ID: <20050304112236.GA6885068@ohm.arago.de> Hi! On Fri, Mar 04, 2005 at 10:01:29PM +1100, Darren Tucker wrote: > > Also note that not all flavours of `grep' support `-q'. At > > least IRIX 6.x and Solaris 7/8 don't. > > Actually, on Solaris it depends on which grep: /usr/xpg4/bin/grep > understands it. Have to admit I didn't check that, but I avoid using commands not in a system's standard $PATH, anyway. Ciao Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050304/1628f21c/attachment.bin From Frank.Beckmann at gmx.com Sat Mar 5 00:02:52 2005 From: Frank.Beckmann at gmx.com (Frank Beckmann) Date: Fri, 4 Mar 2005 14:02:52 +0100 (MET) Subject: ssh hang problem under solaris 8 References: <422813CE.6080302@mgb.ch> Message-ID: <6592.1109941372@www24.gmx.net> Hi Martin i have yesterday worte with Daren... We fix the Problem with following entry sshd_config ChallengeResponseAuthentication no ssh_config preferredauthentications=publickey,password They have a Problem with keyboard-interactive.... I hope it helps you ! Frank > i have encountered the same problem. the patch suggested by darren > tucker did not fix the problem. > > thanks, > -martin > > Frank Beckmann wrote: > > >Hi :-) > > > >i have try a hang on exit patch that i found in the web for an old > openssh > >version, but it dosent help :-( > > > >in a german gdb howto i found a tip that the backtrace output can help to > >analyse the problem.... > > > >is it a solaris problem ? > > > >Greetings > > > >Frank > > > >sshd: > >#0 0xff19d618 in _poll () from /usr/lib/libc.so.1 > >#1 0xff14d53c in select () from /usr/lib/libc.so.1 > >#2 0x000339a0 in wait_until_can_do_something (readsetp=0xffbee5dc, > >writesetp=0xffbee5d8, maxfdp=0xffbee5d4, > > nallocp=0xffbee5d0, max_time_milliseconds=0) at serverloop.c:325 > >#3 0x00034d6c in server_loop2 (authctxt=0x123ac8) at serverloop.c:776 > >#4 0x0003ae0c in do_authenticated (authctxt=0x123ac8) at session.c:2265 > >#5 0x0002ea78 in main (ac=1161216, av=0x11f288) at sshd.c:1719 > > > >ssh: > >(gdb) backtrace > >#0 0xff19d618 in _poll () > >#1 0xff14d53c in _select () > >#2 0x3156c in ?? () > >#3 0x2d048 in ?? () > > > >_______________________________________________ > >openssh-unix-dev mailing list > >openssh-unix-dev at mindrot.org > >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > > From vinschen at redhat.com Sat Mar 5 02:09:44 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 4 Mar 2005 16:09:44 +0100 Subject: [PATCH] minor Cygwin documentation fix Message-ID: <20050304150944.GG2839@cygbert.vinschen.de> Hi, the information about how to build SSH under Cygwin isn't foolproof enough. Especially missing packet dependencies resulted in a few complaints. Could somebody please apply the beloiw patch to contrib/cygwin/README? Thanks in advance, Corinna Index: README =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/README,v retrieving revision 1.15 diff -p -u -r1.15 README --- README 9 Jul 2004 17:45:27 -0000 1.15 +++ README 4 Mar 2005 15:06:34 -0000 @@ -195,27 +195,36 @@ configure are used for the Cygwin binary --prefix=/usr \ --sysconfdir=/etc \ - --libexecdir='$(sbindir)' \ + --libexecdir='${sbindir}' \ --localstatedir=/var \ - --datadir='$(prefix)/share' \ - --mandir='$(datadir)/man' \ + --datadir='${prefix}/share' \ + --mandir='${datadir}/man' \ + --infodir='${datadir}/info' --with-tcp-wrappers If you want to create a Cygwin package, equivalent to the one in the Cygwin binary distribution, install like this: mkdir /tmp/cygwin-ssh - cd $(builddir) + cd ${builddir} make install DESTDIR=/tmp/cygwin-ssh - cd $(srcdir)/contrib/cygwin + cd ${srcdir}/contrib/cygwin make cygwin-postinstall DESTDIR=/tmp/cygwin-ssh cd /tmp/cygwin-ssh find * \! -type d | tar cvjfT my-openssh.tar.bz2 - - -You must have installed the zlib, the openssl-devel and the minires-devel -packages to be able to build OpenSSH! + +You must have installed the following packages to be able to build OpenSSH: + +- zlib +- openssl-devel +- minires-devel + +If you want to build with --with-tcp-wrappers, you also need the package + +- tcp_wrappers Please send requests, error reports etc. to cygwin at cygwin.com. + Have fun, -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From cmadams at hiwaay.net Sat Mar 5 02:25:21 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 4 Mar 2005 09:25:21 -0600 Subject: Call for release testing In-Reply-To: <42264443.2050805@mindrot.org> References: <42264443.2050805@mindrot.org> Message-ID: <20050304152521.GE686768@hiwaay.net> Once upon a time, Damien Miller said: > We are preparing to release another stable OpenSSH soon, so once > again we are asking for your help in testing CVS snapshots. I tested SNAP-20050304 on Tru64 with Enhanced Security and it passes the regression tests once I set BIN_SH=xpg4 (otherwise the reconfigure.sh gets stuck in a loop; it and the Tru64 version of the Bourne shell don't agree). Setting BIN_SH=xpg4 makes calls to /bin/sh get a POSIX compliant shell (actually Korn shell). I remember we talked about a good way to fix this before, but I guess nothing ever changed. Suggestions? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Greg.Dunkel at mail.cuny.edu Sat Mar 5 03:18:25 2005 From: Greg.Dunkel at mail.cuny.edu (Greg.Dunkel at mail.cuny.edu) Date: Fri, 4 Mar 2005 11:18:25 -0500 Subject: openssh-unix-dev Digest, Vol 23, Issue 8 -- using grep Message-ID: The following message From: Thomas Binder Subject: Re: Call for release testing To: openssh-unix-dev at mindrot.org Message-ID: <20050304103859.GA7104817 at ohm.arago.de> Content-Type: text/plain; charset="us-ascii" Hi! On Fri, Mar 04, 2005 at 07:34:59PM +1100, Darren Tucker wrote: > > Otherwise we could use grep -q "$PID" > > That's racy since it might find the argument to grep depending > on the scheduling. Also note that not all flavours of `grep' support `-q'. At least IRIX 6.x and Solaris 7/8 don't. Ciao Is not entirely accurate; there are two versions of grep on Solaris 7/8. The one in /usr/bin doesn't support -q but the one in /usr/xpg4/bin does. Need to use a complete path. /greg From torsten.foertsch at gmx.net Sat Mar 5 04:29:19 2005 From: torsten.foertsch at gmx.net (Torsten Foertsch) Date: Fri, 4 Mar 2005 18:29:19 +0100 Subject: [PATCH] controlling remote port forwarding over control path Message-ID: <200503041829.23832.torsten.foertsch@gmx.net> Hi, the attached patch implements adding and canceling of remote port forwardings by communicating with a running ssh client via a control socket. Thus, one can do this: ssh -MNfS ~/.ssh/ctl remotehost and then: ssh -S ~/.ssh/ctl -O add-rforward 2000:forward:80 localhost to add a new remote forwarding or ssh -S ~/.ssh/ctl -O cancel-rforward localhost:2000 localhost to remove it. The patch is against openssh-SNAP-20050302 so the new fine tuned forwarding code is already contained. While working on the patch a few questions/inconveniences have emerged: 1) why is mux_command in ssh.c not part of Options? 2) the current implementation allows -O to occur only once. So, to add or remove multiple channels ssh has to be called multiple times. Would it make sense to extend the code to allow it to occur multiple times? ssh -S ~/.ssh/ctl \ -O add-rforward 2000:forward:80 \ -O add-rforward 2001:forward:80 \ localhost 3) permitted_opens in channels.c is a real problem. The current code allocates a new element from the end of this array while adding a new forwarding. But when the forwarding is cancelled the element is not really freed. It is marked somehow to be not in use but the current code cannot reuse it. 4) again permitted_opens. channel_request_rforward_cancel() identifies the local side of a forwarding only by permitted_opens[i].host_to_connect and permitted_opens[i].listen_port. Since a forwarding is really a quadruple this looks a little fragile to me. In fact you can try to remove a forwarding by specifying only a port number ssh -S ~/.ssh/ctl -O cancel-rforward 2000 localhost This matches an element of permitted_opens and resets it but it does not match an open channel at the server side. So the listening socket is not closed. Now when someone tries to connect to that port the server forwards the connection to the client. Here it does not match an element of permitted_opens. Hence WARNING: Server requests forwarding for unknown listen_port 2000 is printed and the connection is closed. I have not yet changed this behaviour because it is the same code that is used when adding or canceling forwardings with the ssh command line ("~C", then "-R2000:forward:80", then "~C", then "-KR2000" yields the same result). But I think it's rather a bug than a feature. Doesn't it make more sense to represent forwardings as quadruples (remotehost, remoteport, localhost, localport) also at the client side? 5) I think I have to implement -O add-lforward and -O cancel-lforward, too. 6) Also -O list-forwards would be useful, wouldn't it? Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh.patch Type: text/x-diff Size: 5214 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050304/d71166d1/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050304/d71166d1/attachment-0001.bin From bravored at animail.net Sat Mar 5 07:48:35 2005 From: bravored at animail.net (Jijo Abraham) Date: Fri, 4 Mar 2005 15:48:35 -0500 Subject: Fwd: Sftp Logging Message-ID: Hello, Does anyone how enable the sFTP logging? I have a solaris 9 on sun blade 2500 SSh Version: ssh -V SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0. Whats all that mean? This link shows how to get the sftp logging with chroot path. http://sftplogging.sourceforge.net/download/README -------------------- Install instructions: -------------------- 1. download and expand openssh-3.x(.x)px source 2. download the patch and put it in the parent diretory of the openssh source directory 3. run "patch -p0 < openssh-3.x(.x)p.x.sftplogging.patch" 4. compile and install openssh Thanks Jijo http://www.Care2.com Free e-mail. 100MB storage. Helps charities. Make a Difference: Tell car makers to clean up their act - http://www.care2.com/go/z/cleancars From imorgan at nas.nasa.gov Sat Mar 5 08:18:23 2005 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 4 Mar 2005 13:18:23 -0800 (PST) Subject: Call for release testing Message-ID: <200503042118.j24LINXX017444@sun601.nas.nasa.gov> Hi, I've tested the 20050304 snapshot on the following platforms: Solaris 9 IRIX 6.5.24 RHEL 3 (x86) RHEL 3 (SGI Altix) All platforms except IRIX tested successfully. On IRIX, make tests fails in the following manner: run test connect.sh ... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA1 host key has just been changed. The fingerprint for the RSA1 key sent by the remote host is b8:88:7d:90:c3:2e:cb:b6:24:4c:ce:17:29:9a:3f:88. Please contact your system administrator. Add correct host key in /u/wk/imorgan/src/openssh/openssh/regress/known_hosts to get rid of this message. Offending key in /u/wk/imorgan/src/openssh/openssh/regress/known_hosts:2 RSA1 host key for localhost-with-alias has changed and you have requested strict checking. Host key verification failed. ssh connect with protocol 1 failed failed simple connect *** Error code 1 (bu21) *** Error code 1 (bu21) This happens with both gcc and the MIPSpro compiler. -- Iain Morgan From dtucker at zip.com.au Sat Mar 5 08:46:24 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 05 Mar 2005 08:46:24 +1100 Subject: Call for release testing In-Reply-To: <200503042118.j24LINXX017444@sun601.nas.nasa.gov> References: <200503042118.j24LINXX017444@sun601.nas.nasa.gov> Message-ID: <4228D730.7050503@zip.com.au> Iain Morgan wrote: > I've tested the 20050304 snapshot on the following platforms: > > Solaris 9 > IRIX 6.5.24 > RHEL 3 (x86) > RHEL 3 (SGI Altix) Thanks. > All platforms except IRIX tested successfully. > > On IRIX, make tests fails in the following manner: > > run test connect.sh ... > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ This can happen if you have an sshd running from a previous test, possibly because a previous run failed or was interrupted. (The keys are regenerated for each test). Check that you don't already have an sshd running on port 4242 ("losf -i :4242" if you have lsof, otherwise look through ps output for an errant sshd). If there is one, kill it and retry your test. If the problem is due to a test failing, you will probably see the real cause of the problem in this run. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Mar 5 08:56:57 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 05 Mar 2005 08:56:57 +1100 Subject: Call for release testing In-Reply-To: <20050304152521.GE686768@hiwaay.net> References: <42264443.2050805@mindrot.org> <20050304152521.GE686768@hiwaay.net> Message-ID: <4228D9A9.3050806@zip.com.au> Chris Adams wrote: > Once upon a time, Damien Miller said: > >>We are preparing to release another stable OpenSSH soon, so once >>again we are asking for your help in testing CVS snapshots. > > I tested SNAP-20050304 on Tru64 with Enhanced Security and it passes the > regression tests once I set BIN_SH=xpg4 Thanks. > (otherwise the reconfigure.sh > gets stuck in a loop; it and the Tru64 version of the Bourne shell don't > agree). Setting BIN_SH=xpg4 makes calls to /bin/sh get a POSIX > compliant shell (actually Korn shell). > > I remember we talked about a good way to fix this before, but I guess > nothing ever changed. Suggestions? How about somthing like the attached? (I'm not sure what uname is going to return on Tru64 and its various incarnations, but what I have is based on what config.guess looks for. Just let us know if it needs to be changed.) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-osf1-regress.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050305/fad659e3/attachment.ksh From djm at mindrot.org Sat Mar 5 09:10:05 2005 From: djm at mindrot.org (Damien Miller) Date: Sat, 05 Mar 2005 09:10:05 +1100 Subject: [PATCH] controlling remote port forwarding over control path In-Reply-To: <200503041829.23832.torsten.foertsch@gmx.net> References: <200503041829.23832.torsten.foertsch@gmx.net> Message-ID: <4228DCBD.4070803@mindrot.org> Torsten Foertsch wrote: > Hi, > > the attached patch implements adding and canceling of remote port > forwardings by communicating with a running ssh client via a control > socket. Cool, I was planning on doing something like this. However, instead of a commandline like: > ssh -S ~/.ssh/ctl -O add-rforward 2000:forward:80 localhost Which is not very getopt()ish. Could I suggest: ssh -S ~/.ssh/ctl -O add-rforward localhost 2000:forward:80 (i.e. place the forarding arguments where the command goes normally) This has the advantage of being easier to extend to multiple forwarding specifications: ssh -S ~/.ssh/ctl -O add-rforward xxx 2222:host1:22 2223:host2:22 ... > While working on the patch a few questions/inconveniences have emerged: > > 1) why is mux_command in ssh.c not part of Options? It didn't seem like a good place to put it - it is a runtime control thing like -N or -f. What do you have in mind? > 2) the current implementation allows -O to occur only once. So, to add > or remove multiple channels ssh has to be called multiple times. Would > it make sense to extend the code to allow it to occur multiple times? See above. > 3) permitted_opens in channels.c is a real problem. The current code > allocates a new element from the end of this array while adding a new > forwarding. But when the forwarding is cancelled the element is not > really freed. It is marked somehow to be not in use but the current > code cannot reuse it. Yes, it is a small leak but, worse, it makes it easier to hit the SSH_MAX_FORWARDS_PER_DIRECTION limit. Perhaps this list would be better off wrapped in functions to add/delete/check entries. > 4) again permitted_opens. channel_request_rforward_cancel() identifies > the local side of a forwarding only by > permitted_opens[i].host_to_connect and permitted_opens[i].listen_port. > Since a forwarding is really a quadruple this looks a little fragile to > me. In fact you can try to remove a forwarding by specifying only a > port number > > ssh -S ~/.ssh/ctl -O cancel-rforward 2000 localhost > > This matches an element of permitted_opens and resets it but it does not > match an open channel at the server side. So the listening socket is > not closed. Now when someone tries to connect to that port the server > forwards the connection to the client. Here it does not match an > element of permitted_opens. Hence > > WARNING: Server requests forwarding for unknown listen_port 2000 > > is printed and the connection is closed. > > I have not yet changed this behaviour because it is the same code that > is used when adding or canceling forwardings with the ssh command line > ("~C", then "-R2000:forward:80", then "~C", then "-KR2000" yields the > same result). But I think it's rather a bug than a feature. > > Doesn't it make more sense to represent forwardings as quadruples > (remotehost, remoteport, localhost, localport) also at the client side? There are a couple of things here: 1. Deleting remote forwardings by port makes sense unless you have them bound to multiple addresses. I don't think it is necessary to use quadruples to specify which remote forward to kill, because a remote forward can be uniquely identified using just the bind_address and port. Though maybe it is less confusing... 2. If we do wildcard deletes, then we should do them properly and kill all the relevant channels. So the behaviour you see on channel delete is a separate bug. > 5) I think I have to implement -O add-lforward and -O cancel-lforward, > too. That would be handy too :) Don't forget -O add-dforward :) > 6) Also -O list-forwards would be useful, wouldn't it? Yes. Could you create a bug on http://bugzilla.mindrot.org and attach your patch? We won't be able to get to this until after the imminent release, but I would like to see something like this added. Thanks, Damien Miller From djm at mindrot.org Sat Mar 5 09:10:48 2005 From: djm at mindrot.org (Damien Miller) Date: Sat, 05 Mar 2005 09:10:48 +1100 Subject: Fwd: Sftp Logging In-Reply-To: References: Message-ID: <4228DCE8.4030609@mindrot.org> Jijo Abraham wrote: > > Hello, > > Does anyone how enable the sFTP logging? > I have a solaris 9 on sun blade 2500 > SSh Version: > ssh -V > SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0. that isn't openssh. From dtucker at zip.com.au Sat Mar 5 11:33:06 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 05 Mar 2005 11:33:06 +1100 Subject: Question/concern about bsm auditing option on solaris In-Reply-To: <200503031923.j23JNWjx028651@poe.emich.edu> References: <200503031923.j23JNWjx028651@poe.emich.edu> Message-ID: <4228FE42.8030309@zip.com.au> Matt Goebel wrote: > I downloaded and compiled the Mar 2, 2005 snapshot and compiled it with > bsm auditing for solaris turned on. I've been noticing about a dozen or > so of the following messages per day now. Not sure exactly what it is, or > if it is a big issue. > > [ID 800047 auth.crit] fatal: mm_request_send: write I think I have figured out the cause of this one: it was trying to catch the connection close event during the cleanup, but by that time it may be too late as the monitor may already be shut down. If the monitor has already shut down then sending the request will fail causing the error you're seeing. Please try the attached patch (which should apply on top of the previous patch). I'll attach the patch to bug #125 too. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-audit-close.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050305/279782ec/attachment.ksh From imorgan at nas.nasa.gov Sat Mar 5 12:32:23 2005 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 4 Mar 2005 17:32:23 -0800 (PST) Subject: Call for release testing In-Reply-To: <4228D730.7050503@zip.com.au> from "Darren Tucker" at Mar 05, 2005 08:46:24 AM Message-ID: <200503050132.j251WNjI018861@sun601.nas.nasa.gov> On Fri Mar 4 13:46:24 2005, Darren Tucker wrote: > > Iain Morgan wrote: > > I've tested the 20050304 snapshot on the following platforms: > > > > Solaris 9 > > IRIX 6.5.24 > > RHEL 3 (x86) > > RHEL 3 (SGI Altix) > > Thanks. > > > All platforms except IRIX tested successfully. > > > > On IRIX, make tests fails in the following manner: > > > > run test connect.sh ... > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > This can happen if you have an sshd running from a previous test, possibly > because a previous run failed or was interrupted. (The keys are > regenerated for each test). > > Check that you don't already have an sshd running on port 4242 ("losf -i > :4242" if you have lsof, otherwise look through ps output for an errant > sshd). If there is one, kill it and retry your test. If the problem is > due to a test failing, you will probably see the real cause of the problem > in this run. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > Thanks for the advise. I checked the ps output and there aren't any errant processes. I also checked netstat -a and there's nothing listening on port 4242. I'll look more closely at this on Monday. -- Iain Morgan From tusker at tusker.org Sat Mar 5 23:14:28 2005 From: tusker at tusker.org (Damien Mascord) Date: Sat, 05 Mar 2005 20:14:28 +0800 Subject: Call for release testing In-Reply-To: <42264443.2050805@mindrot.org> References: <42264443.2050805@mindrot.org> Message-ID: <4229A2A4.5050404@tusker.org> Hi guys, Seems like there is an issue with the login grace timeout on Sourcemage Linux. I downloaded and tried: openssh-SNAP-20050305.tar.gz and the results are as follows: System information [Sourcemage/test] # uname -a Linux ordo 2.6.8.1 #1 Sun Aug 22 01:32:14 SGT 2004 i686 unknown unknown GNU/Linux openssl 0.9.7e bash 3.0 ------------- ok try ciphers run test yes-head.sh ... ok yes pipe head run test login-timeout.sh ... ssh: connect to host 127.0.0.1 port 4242: Connection refused ssh connect after login grace timeout failed without privsep failed connect after login grace timeout make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/home/tusker/openssh/regress' make: *** [tests] Error 2 Looking at netstat, there seems to be lingering connection for a short while... but it goes quite quickly... root at ordo:~# netstat -an | grep 4242 tcp 0 0 127.0.0.1:32938 127.0.0.1:4242 TIME_WAIT tcp 0 0 127.0.0.1:4242 127.0.0.1:32937 TIME_WAIT root at ordo:~# netstat -an | grep 4242 Damien From torsten.foertsch at gmx.net Sat Mar 5 23:07:42 2005 From: torsten.foertsch at gmx.net (Torsten Foertsch) Date: Sat, 5 Mar 2005 13:07:42 +0100 Subject: [PATCH] controlling remote port forwarding over control path In-Reply-To: <4228DCBD.4070803@mindrot.org> References: <200503041829.23832.torsten.foertsch@gmx.net> <4228DCBD.4070803@mindrot.org> Message-ID: <200503051307.47877.torsten.foertsch@gmx.net> On Friday 04 March 2005 23:10, Damien Miller wrote: > Could you create a bug on http://bugzilla.mindrot.org and attach your > patch? We won't be able to get to this until after the imminent > release, but I would like to see something like this added. It is added as #993. Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050305/f66e4a06/attachment.bin From torsten.foertsch at gmx.net Sun Mar 6 01:26:16 2005 From: torsten.foertsch at gmx.net (Torsten Foertsch) Date: Sat, 5 Mar 2005 15:26:16 +0100 Subject: [PATCH] controlling remote port forwarding over control path In-Reply-To: <4228DCBD.4070803@mindrot.org> References: <200503041829.23832.torsten.foertsch@gmx.net> <4228DCBD.4070803@mindrot.org> Message-ID: <200503051526.22514.torsten.foertsch@gmx.net> On Friday 04 March 2005 23:10, Damien Miller wrote: > However, instead of a commandline like: > > ?> ? ssh -S ~/.ssh/ctl -O add-rforward 2000:forward:80 localhost > > Which is not very getopt()ish. Could I suggest: > > ssh -S ~/.ssh/ctl -O add-rforward localhost 2000:forward:80 > > (i.e. place the forarding arguments where the command goes normally) > > This has the advantage of being easier to extend to multiple > forwarding specifications: > > ssh -S ~/.ssh/ctl -O add-rforward xxx 2222:host1:22 2223:host2:22 ... Your variant makes it impossible to remove one channel and add another at the same time. I'd vote for ssh -S ~/.ssh/ctl -O add-rforward 2222:host1:22 \ -O cancel-rforward 2223:host2:22 xxx Or even better, let's reuse -L, -R and -D. They are not very useful for control connections. -KL, -KR, -KD can then be used to stop forwarding. Or ssh -S ~/.ssh/ctl -R 2222:host1:22 -R 2223:host2:22 \ -K \ -R 2222:host3:22 -R 2223:host4:22 xxx first closes 2222:host3:22 and 2223:host4:22 and then opens 2222:host1:22 and 2223:host2:22. Thus, -K toggles add/removal mode. How about that? I'd favor the last variant. Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050305/82e8437a/attachment.bin From jmknoble at pobox.com Mon Mar 7 12:56:01 2005 From: jmknoble at pobox.com (Jim Knoble) Date: Sun, 6 Mar 2005 20:56:01 -0500 Subject: Call for release testing In-Reply-To: <42281DB3.7080103@zip.com.au> References: <200503031755.j23HtQ224799@mail.ncsa.uiuc.edu> <42281794.1000308@mindrot.org> <42281DB3.7080103@zip.com.au> Message-ID: <20050307015601.GP27254@crawfish.ais.com> Circa 2005-03-04 19:34:59 +1100 dixit Darren Tucker: : > Otherwise we could use grep -q "$PID" : : That's racy since it might find the argument to grep[...]. : I vote to make it "kill -0". Seconded. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: From dtucker at zip.com.au Mon Mar 7 23:08:36 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 07 Mar 2005 23:08:36 +1100 Subject: Call for release testing In-Reply-To: <200503050132.j251WNjI018861@sun601.nas.nasa.gov> References: <200503050132.j251WNjI018861@sun601.nas.nasa.gov> Message-ID: <422C4444.2090502@zip.com.au> Iain Morgan wrote: > Thanks for the advise. I checked the ps output and there aren't any errant > processes. I also checked netstat -a and there's nothing listening on port 4242. We've added a capability to log the output of the components under test, which may help in your case. Please try this with tomorrow's snapshot (20050307 or later): $ make tests LTESTS=connect TEST_SSH_LOGFILE=/tmp/regress.log then take a look in /tmp/regress.log. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From logsnaath at gmx.net Tue Mar 8 23:00:38 2005 From: logsnaath at gmx.net (Logu) Date: Tue, 8 Mar 2005 17:30:38 +0530 Subject: Call for release testing References: <42264443.2050805@mindrot.org> Message-ID: <12c701c523d6$e2a49ea0$140110ac@loguco> I have tested the openssh snapshot on HP-UX 11.0, HP-UX 11.11 and HP-UX 11.23 The Results on the platforms 11.11, 11.23 PI Total tests : 35 Total number of tests passed : 32 Total number of tests skipped : 03 Total number of tests failed : 0 The Results on the platform 11.0 Total tests : 35 Total number of tests passed : 31 Total number of tests skipped : 03 Total number of tests failed : 1 The test failed on 11.0 in "login-timeout.sh" in the following line in the package. "(echo SSH-2.0-fake; sleep 60) | telnet localhost ${PORT}" The failure occurs due to the re-execution feature of sshd. It takes long time to connect to the server when re-exec is enabled. When re-execution feature is diabled, the test passes. Thanks -logu From dtucker at zip.com.au Tue Mar 8 23:35:25 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 08 Mar 2005 23:35:25 +1100 Subject: Call for release testing In-Reply-To: <12c701c523d6$e2a49ea0$140110ac@loguco> References: <42264443.2050805@mindrot.org> <12c701c523d6$e2a49ea0$140110ac@loguco> Message-ID: <422D9C0D.2070505@zip.com.au> Logu wrote: > I have tested the openssh snapshot on HP-UX 11.0, HP-UX 11.11 and HP-UX > 11.23 Thanks. [...] > The failure occurs due to the re-execution feature of sshd. It takes > long time to connect to the server when re-exec is enabled. When > re-execution feature is diabled, the test passes. This is likely to be the reseeding of the RNG causing this. You can try running ssh-random-helper with -vvv and see if any of the entropy gathering commands take disproportionately longer than the others. If this proves to be the case then you can modify or remove that command in ssh_prng_cmds. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jason at dour.org Wed Mar 9 01:11:51 2005 From: jason at dour.org (Jason A. Dour) Date: Tue, 8 Mar 2005 09:11:51 -0500 Subject: Fwd: Sftp Logging In-Reply-To: <4228DCE8.4030609@mindrot.org> References: <4228DCE8.4030609@mindrot.org> Message-ID: <20050308141151.GQ904@dour.org> On Sat, Mar 05, 2005 at 09:10:48AM +1100, Damien Miller wrote: > Jijo Abraham wrote: > > > >Hello, > > > >Does anyone how enable the sFTP logging? > >I have a solaris 9 on sun blade 2500 > >SSh Version: > >ssh -V > >SSH Version Sun_SSH_1.0.1, protocol versions 1.5/2.0. > > that isn't openssh. Not to re-open metal containers of invertebrates, but... Yet again, the issue of SFTP logging has come up on the list. A regular occurance since a healthy number of administrators apparently desire the functionality. Healthy enough of a number that there are at least two (possibly three) patch sets providing this functionality. I personally have been revisiting the SFTP logging issue since at least 2001...almost four years have passed since I first brought up this issue on this very list. In that time, I've provided and privately maintained a patch that has been used by a number of people with great success. Others have redistributed it with their own patch sets. And now there is another recently developed patch set. Every few months the issue gets discussed, and promptly ignored. Is it possible that now is the time for the core open-ssh team to see the elephant that is in the room, and if not work on logging personally, at least define specific goals/requirements for a set of patches that would *seriously* be considered for acceptance into the core release? I think it is pretty clear to anyone who is not unduly biased on the issue that open-ssh is lacking in the area of logging for its file-tranfer sub-systems. I think it is also pretty clear that open-ssh's user-base actively desires this functionality. Again...not trying to raise hackles...just trying to help a great product become greater still... Cheers, Jason # "Jason A. Dour" http://dour.org/ From cmadams at hiwaay.net Wed Mar 9 09:53:48 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 8 Mar 2005 16:53:48 -0600 Subject: Call for release testing In-Reply-To: <4228D9A9.3050806@zip.com.au> References: <42264443.2050805@mindrot.org> <20050304152521.GE686768@hiwaay.net> <4228D9A9.3050806@zip.com.au> Message-ID: <20050308225347.GD957788@hiwaay.net> Once upon a time, Darren Tucker said: > (I'm not sure what uname is going to return on Tru64 and its various > incarnations, but what I have is based on what config.guess looks for. > Just let us know if it needs to be changed.) It returns OSF1 (upper case). With that change it works. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. > Index: regress/test-exec.sh > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/regress/test-exec.sh,v > retrieving revision 1.19 > diff -u -p -r1.19 test-exec.sh > --- regress/test-exec.sh 8 Feb 2005 09:17:17 -0000 1.19 > +++ regress/test-exec.sh 4 Mar 2005 21:53:15 -0000 > @@ -7,6 +7,13 @@ > _POSIX2_VERSION=199209 > export _POSIX2_VERSION > > +case `uname -s 2>/dev/null` in > +osf1*) > + BIN_SH=xpg4 > + export BIN_SH > + ;; > +esac > + > if [ ! -z "$TEST_SSH_PORT" ]; then > PORT="$TEST_SSH_PORT" > else From dtucker at zip.com.au Wed Mar 9 10:03:17 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 09 Mar 2005 10:03:17 +1100 Subject: Call for release testing In-Reply-To: <20050308225347.GD957788@hiwaay.net> References: <42264443.2050805@mindrot.org> <20050304152521.GE686768@hiwaay.net> <4228D9A9.3050806@zip.com.au> <20050308225347.GD957788@hiwaay.net> Message-ID: <422E2F35.2080903@zip.com.au> Chris Adams wrote: > Once upon a time, Darren Tucker said: > >>(I'm not sure what uname is going to return on Tru64 and its various >>incarnations, but what I have is based on what config.guess looks for. >>Just let us know if it needs to be changed.) > > It returns OSF1 (upper case). With that change it works. Applied with that change, thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at cvs.openbsd.org Wed Mar 9 20:54:13 2005 From: djm at cvs.openbsd.org (Damien Miller) Date: Wed, 9 Mar 2005 02:54:13 -0700 (MST) Subject: OpenSSH 4.0 released Message-ID: <200503090954.j299sDng029163@cvs.openbsd.org> OpenSSH 4.0 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or posters. We have a new design of T-shirt available, more info on http://www.openbsd.org/tshirts.html#18 For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 3.9: ============================ * ssh(1) now allows the optional specification of an address to bind to in port forwarding connections (local, remote and dynamic). Please refer to the documentation for the -L and -R options in the ssh(1) manual page and the LocalForward and RemoteForward options in the ssh_config(5) manpage. (Bugzilla #413) * To control remote bindings while retaining backwards compatibility, sshd(8)'s GatewayPorts option has been extended. To allow client specified bind addresses for remote (-R) port forwardings, the server must be configured with "GatewayPorts clientspecified". * ssh(1) and ssh-keyscan(1) now support hashing of host names and addresses added to known_hosts files, controlled by the ssh(1) HashKnownHosts configuration directive. This option improves user privacy by hiding which hosts have been visited. At present this option is off by default, but may be turned on once it receives sufficient testing. * Added options for managing keys in known_hosts files to ssh-keygen(1), including the ability to search for hosts by name, delete hosts by name and convert an unhashed known_hosts file into one with hashed names. These are particularly useful for managing known_hosts files with hashed hostnames. * Improve account and password expiry support in sshd(8). Ther server will now warn in advance for both account and password expiry. * sshd(8) will now log the source of connections denied by AllowUsers, DenyUsers, AllowGroups and DenyGroups (Bugzilla #909) * Added AddressFamily option to sshd(8) to allow global control over IPv4/IPv6 usage. (Bugzilla #989) * Improved sftp(1) client, including bugfixes and optimisations for the ``ls'' command and command history and editing support using libedit. * Improved the handling of bad data in authorized_keys files, eliminating fatal errors on corrupt or very large keys. (Bugzilla #884) * Improved connection multiplexing support in ssh(1). Several bugs have been fixed and a new "command mode" has been added to allow the control of a running multiplexing master connection, including checking that it is up, determining its PID and asking it to exit. * Have scp(1) and sftp(1) wait for the spawned ssh to exit before they exit themselves. This prevents ssh from being unable to restore terminal modes (not normally a problem on OpenBSD but common with -Portable on POSIX platforms). (Bugzilla #950) * Portable OpenSSH: - Add *EXPERIMENTAL* BSM audit support for Solaris systems (Bugzilla #125) - Enable IPv6 on AIX where possible (see README.platform for details), working around a misfeature of AIX's getnameinfo. (Bugzilla #835) - Teach sshd(8) to write failed login records to btmp for unsuccessful auth attempts. Currently this is only for password, keyboard-interactive and challenge/response authentication methods and only on Linux and HP-UX. - sshd(8) now sends output from failing PAM session modules to the user before exiting, similar to the way /etc/nologin is handled - Store credentials from gssapi-with-mic authentication early enough to be available to PAM session modules when privsep=yes. Checksums: ========== - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Ben Lindstrom, Darren Tucker and Tim Rice. From vinschen at redhat.com Wed Mar 9 22:00:14 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 9 Mar 2005 12:00:14 +0100 Subject: Call for release testing In-Reply-To: <20050303125902.GA9636@cygbert.vinschen.de> References: <42264443.2050805@mindrot.org> <20050303125902.GA9636@cygbert.vinschen.de> Message-ID: <20050309110014.GA2651@cygbert.vinschen.de> On Mar 3 13:59, Corinna Vinschen wrote: > On Mar 3 09:54, Damien Miller wrote: > > Hi, > > > > We are preparing to release another stable OpenSSH soon, so once > > again we are asking for your help in testing CVS snapshots. > > Built and regress-tested on Cygwin. Looks pretty good with just one > exception: I've just tested against the latest from CVS (checked out 10:00 UTC) and I got a new regression failure which looks pretty bogus to me. In banner.sh, the `ssh -q' test fails. The reason is that banner.out is not empty: $ cat banner.out debug1: permanently_set_uid: 18/0 18 is the uid of the SYSTEM account on Windows so the above is equivalent to `debug1: permanently_set_uid: 0/0' on other systems. What's the debug message doing in the output here? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From dtucker at zip.com.au Wed Mar 9 23:50:16 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 09 Mar 2005 23:50:16 +1100 Subject: Call for release testing In-Reply-To: <20050309110014.GA2651@cygbert.vinschen.de> References: <42264443.2050805@mindrot.org> <20050303125902.GA9636@cygbert.vinschen.de> <20050309110014.GA2651@cygbert.vinschen.de> Message-ID: <422EF108.1000307@zip.com.au> Corinna Vinschen wrote: > I've just tested against the latest from CVS (checked out 10:00 UTC) > and I got a new regression failure which looks pretty bogus to me. You're right, it's bogus. It's a problem with the test itself. > In banner.sh, the `ssh -q' test fails. The reason is that banner.out > is not empty: > > $ cat banner.out > debug1: permanently_set_uid: 18/0 > > 18 is the uid of the SYSTEM account on Windows so the above is equivalent > to `debug1: permanently_set_uid: 0/0' on other systems. > > What's the debug message doing in the output here? I bumped the loglevel in the regression tests to make easier (or even possible :-) to figure out the cause of failing tests. Normally that debug output is sent to /dev/null unless being specifically logged. That message is from the session (via the client). Not sure why it's only causing problems on Cygwin, though. Will look at it tomorrow. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Thu Mar 10 05:18:17 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 9 Mar 2005 19:18:17 +0100 Subject: OpenSSH 4.0 released In-Reply-To: <200503090954.j299sDng029163@cvs.openbsd.org> References: <200503090954.j299sDng029163@cvs.openbsd.org> Message-ID: <20050309181817.GT2839@cygbert.vinschen.de> On Mar 9 02:54, Damien Miller wrote: > OpenSSH 4.0 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. > [...] > - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 > - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 I just downloaded openssh-4.0p1.tar.gz from ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ and I'm getting another MD5 sum: $ md5sum openssh-4.0p1.tar.gz 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz I'm wondering if that's just a wrong MD5 sum inthe announcement or if the version actually differs. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From djm at cvs.openbsd.org Thu Mar 10 06:32:45 2005 From: djm at cvs.openbsd.org (Damien Miller) Date: Wed, 9 Mar 2005 12:32:45 -0700 (MST) Subject: Incorrect md5sum in portable OpenSSH 4.0p1 announcement Message-ID: <200503091932.j29JWj9m002918@cvs.openbsd.org> Hi, The release announcement for OpenSSH 4.0p1 had an incorrect md5sum for the portable tarball. The correct md5 is below, otherwise you may verify the integrity of the release using the PGP signature, contained in the file "openssh-4.0p1.tar.gz.sig" in the release directory. MD5 (openssh-4.0p1.tar.gz) = 7b36f28fc16e1b7f4ba3c1dca191ac92 Apologies for any confusion, Damien Miller From tim at multitalents.net Thu Mar 10 06:49:35 2005 From: tim at multitalents.net (Tim Rice) Date: Wed, 9 Mar 2005 11:49:35 -0800 (PST) Subject: OpenSSH 4.0 released In-Reply-To: <20050309181817.GT2839@cygbert.vinschen.de> References: <200503090954.j299sDng029163@cvs.openbsd.org> <20050309181817.GT2839@cygbert.vinschen.de> Message-ID: On Wed, 9 Mar 2005, Corinna Vinschen wrote: > On Mar 9 02:54, Damien Miller wrote: >> OpenSSH 4.0 has just been released. It will be available from the >> mirrors listed at http://www.openssh.com/ shortly. >> [...] >> - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 >> - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 > > I just downloaded openssh-4.0p1.tar.gz from > ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ and I'm getting > another MD5 sum: > > $ md5sum openssh-4.0p1.tar.gz > 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz > > I'm wondering if that's just a wrong MD5 sum inthe announcement or if > the version actually differs. I get the same MD5 sum you do. I've compared openssh-4.0p1.tar.gz to my copy of CVS and it looks fine. (a couple of $Id lines and a blank line in log.c) And "gpg --verify openssh-4.0p1.tar.gz.sig openssh-4.0p1.tar.gz" indicates it's signed by djm. It looks like Damien forgot to update the MD5 sum in the release notes after the last minute change to log.c (see ChangeLog). > > > Corinna > > -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From thesource at ldb-jab.org Thu Mar 10 06:55:36 2005 From: thesource at ldb-jab.org (Lawrence Bowie) Date: Wed, 09 Mar 2005 14:55:36 -0500 Subject: OpenSSH 4.0 released In-Reply-To: <20050309181817.GT2839@cygbert.vinschen.de> References: <200503090954.j299sDng029163@cvs.openbsd.org> <20050309181817.GT2839@cygbert.vinschen.de> Message-ID: <422F54B8.4050403@ldb-jab.org> I think someone from OpenSSH needs to officially address this as soon as possible. I the same same hash as the previous posting ... 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz Thanks, LDB Corinna Vinschen wrote: >On Mar 9 02:54, Damien Miller wrote: > > >>OpenSSH 4.0 has just been released. It will be available from the >>mirrors listed at http://www.openssh.com/ shortly. >>[...] >>- MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 >>- MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 >> >> > >I just downloaded openssh-4.0p1.tar.gz from >ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ and I'm getting >another MD5 sum: > > $ md5sum openssh-4.0p1.tar.gz > 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz > >I'm wondering if that's just a wrong MD5 sum inthe announcement or if >the version actually differs. > > >Corinna > > > From dtucker at zip.com.au Thu Mar 10 07:04:02 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Mar 2005 07:04:02 +1100 Subject: OpenSSH 4.0 released In-Reply-To: <1110388282.24846.11.camel@hh1pc14.desy.de> References: <200503090954.j299sEXY029145@cvs.openbsd.org> <1110388282.24846.11.camel@hh1pc14.desy.de> Message-ID: <20050309200402.GA2857@gate.dodgy.net.au> On Wed, Mar 09, 2005 at 06:11:22PM +0100, Rainer Peter Feller wrote: > On Wed, 2005-03-09 at 02:54 -0700, Damien Miller wrote: > > > > Checksums: > > ========== > > > > - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 > > - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 > whups! I got 7b36f28fc16e1b7f4ba3c1dca191ac92 for openssh-4.0p1.tar.gz ??? > what is wrong? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In short, the MD5 signature for the Portable tarball in the release notes is wrong. The correct signature is: 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz There was a last-minute compile fix which require a re-rolling of the release tarballs. I have confirmed that the signature in the release notes matches the signature for the tarball without that fix, that the the tarball on the FTP site contains the fix and that the only difference between the two is the aforementioned fix. I have also confirmed a good gpg signature from djm. The online version of the release notee has also been corrected and will appear at http://www.openssh.com/txt/release-4.0 shortly. Apologies to all for the confusion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (OpenBSD) iD8DBQFCL1Y4yYKAx4/0+mkRAiAAAJ9J/It/MkUrnjjBHmTV4zed/fH+jwCg1krg uchwZKbkVciEQGzB8rBXiUc= =RXLr -----END PGP SIGNATURE----- -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Mar 10 07:05:54 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Mar 2005 07:05:54 +1100 Subject: OpenSSH 4.0 released In-Reply-To: <20050309181817.GT2839@cygbert.vinschen.de> References: <200503090954.j299sDng029163@cvs.openbsd.org> <20050309181817.GT2839@cygbert.vinschen.de> Message-ID: <20050309200554.GA4945@gate.dodgy.net.au> On Wed, Mar 09, 2005 at 07:18:17PM +0100, Corinna Vinschen wrote: > On Mar 9 02:54, Damien Miller wrote: > > OpenSSH 4.0 has just been released. It will be available from the > > mirrors listed at http://www.openssh.com/ shortly. > > [...] > > - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 > > - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 > > I just downloaded openssh-4.0p1.tar.gz from > ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ and I'm getting > another MD5 sum: > > $ md5sum openssh-4.0p1.tar.gz > 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz > > I'm wondering if that's just a wrong MD5 sum inthe announcement or if > the version actually differs. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In short, the MD5 signature for the Portable tarball in the release notes is wrong. The correct signature is: 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz There was a last-minute compile fix which require a re-rolling of the release tarballs. I have confirmed that the signature in the release notes matches the signature for the tarball without that fix, that the the tarball on the FTP site contains the fix and that the only difference between the two is the aforementioned fix. I have also confirmed a good gpg signature from djm. The online version of the release notee has also been corrected and will appear at http://www.openssh.com/txt/release-4.0 shortly. Apologies to all for the confusion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (OpenBSD) iD8DBQFCL1Y4yYKAx4/0+mkRAiAAAJ9J/It/MkUrnjjBHmTV4zed/fH+jwCg1krg uchwZKbkVciEQGzB8rBXiUc= =RXLr -----END PGP SIGNATURE----- -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From imorgan at nas.nasa.gov Thu Mar 10 07:28:21 2005 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 9 Mar 2005 12:28:21 -0800 (PST) Subject: Call for release testing In-Reply-To: <422C4444.2090502@zip.com.au> from "Darren Tucker" at Mar 07, 2005 11:08:36 PM Message-ID: <200503092028.j29KSLp0023799@sun601.nas.nasa.gov> On Mon Mar 7 04:08:36 2005, Darren Tucker wrote: > > Iain Morgan wrote: > > Thanks for the advise. I checked the ps output and there aren't any errant > > processes. I also checked netstat -a and there's nothing listening on port 4242. > > We've added a capability to log the output of the components under test, > which may help in your case. Please try this with tomorrow's snapshot > (20050307 or later): > > $ make tests LTESTS=connect TEST_SSH_LOGFILE=/tmp/regress.log > > then take a look in /tmp/regress.log. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > Hi Darren, I still seem to be having the same problem with IRIX, eevn with the 4.0 release. The log output from the regression test doesn't shed much light on the issue: origin03.imorgan 77> cat /tmp/regress.out trace: generate keys trace: wait for sshd FAIL: ssh connect with protocol 1 failed origin03.imorgan 78> There's no sign of a rogue process listening on port 4242. I've tried on another IRIX box (running 6.5.23) and get teh same issue. As a sanity check, I've compared regress/rsa1.pub against regress/known_hosts and they appear to match. Has there been any other feedback, positive or negative, regarding IRIX? -- Iain Morgan From dtucker at zip.com.au Thu Mar 10 09:30:30 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Mar 2005 09:30:30 +1100 Subject: Call for release testing In-Reply-To: <20050309110014.GA2651@cygbert.vinschen.de> References: <42264443.2050805@mindrot.org> <20050303125902.GA9636@cygbert.vinschen.de> <20050309110014.GA2651@cygbert.vinschen.de> Message-ID: <422F7906.4030807@zip.com.au> Corinna Vinschen wrote: > I've just tested against the latest from CVS (checked out 10:00 UTC) > and I got a new regression failure which looks pretty bogus to me. > > In banner.sh, the `ssh -q' test fails. The reason is that banner.out > is not empty: Does the atached patch make it happy? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-regress-verbose.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050310/4259d6e7/attachment.ksh From frederik at a5.repetae.net Thu Mar 10 14:16:04 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Wed, 9 Mar 2005 19:16:04 -0800 Subject: caching Message-ID: <20050310031604.GA29384@a5.repetae.net> I'm trying to use ssh's new connection caching facilities from a wrapper script so that the caching is transparent to the user, i.e. a socket for each destination is created in the user's ~/.ssh/ directory. For the most part it works well, but I've been having some trouble. Firstly, sometimes when I create a slave connection, it hangs when the connection is created; slightly more often it hangs when I try to log out. Secondly, it seems that X11 port forwarding isn't done for slave connections. Have other people encountered these issues? If they are actual bugs, are they being worked on? Does somebody have a wrapper script which accomplishes the task I'm trying to accomplish (or is support for it planned to be included in ssh - since it seems like the main reason one would want caching in the first place)? Thanks, Frederik -- http://ofb.net/~frederik/ From openssh at roumenpetrov.info Thu Mar 10 19:32:26 2005 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 10 Mar 2005 10:32:26 +0200 Subject: X.509 certificates support for OpenSSH-4.0p1 Message-ID: <4230061A.8090903@roumenpetrov.info> I'm pleased to announce that X.509 certificates support for OpenSSH-4.0p1 is now available for download. Please visit http://roumenpetrov.info/openssh/ to get it. Best regards, Roumen Petrov From vinschen at redhat.com Thu Mar 10 20:38:45 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 10 Mar 2005 10:38:45 +0100 Subject: Call for release testing In-Reply-To: <422F7906.4030807@zip.com.au> References: <42264443.2050805@mindrot.org> <20050303125902.GA9636@cygbert.vinschen.de> <20050309110014.GA2651@cygbert.vinschen.de> <422F7906.4030807@zip.com.au> Message-ID: <20050310093845.GW2839@cygbert.vinschen.de> Hi Darren, On Mar 10 09:30, Darren Tucker wrote: > Corinna Vinschen wrote: > >I've just tested against the latest from CVS (checked out 10:00 UTC) > >and I got a new regression failure which looks pretty bogus to me. > > > >In banner.sh, the `ssh -q' test fails. The reason is that banner.out > >is not empty: > > Does the atached patch make it happy? Yes, it does. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From rz1a at nwgsm.ru Thu Mar 10 23:17:01 2005 From: rz1a at nwgsm.ru (rz1a at nwgsm.ru) Date: Thu, 10 Mar 2005 15:17:01 +0300 Subject: OpenSSH and a "handicaped" flavour of UNIX. Message-ID: <794681740.20050310151701@nwgsm.ru> Hello! Is it possible to make the sources a bit more portable? I'm on QNX4 with Watcom C v10.6B which has no support for int64. I'd like to be able to compile as many modules as do not depend on int64. (Currently I do not need SFTP that bad, the SSH is enough for me) -- Best regards, Anthony mailto:rz1a at mail.ru From openssh-unix-dev-list at list.zikzak.de Thu Mar 10 23:41:58 2005 From: openssh-unix-dev-list at list.zikzak.de (Andreas M. Kirchwitz) Date: Thu, 10 Mar 2005 12:41:58 +0000 (UTC) Subject: OpenSSH 4.0p1 segfaults on keyboard-interactive login Message-ID: Hi folks, I've compiled the new OpenSSH 4.0p1 on my Linux box running Fedora Core 2 (kernel 2.6.10) the same way as I did with 3.9p1 and all previous versions. Key-based login works fine, but if I login from a host that require me to enter my login password (keyboard-interactive), then the sshd child process segfaults. Don't know if this is specific to my system or to Linux in general. On Solaris 9 SPARC, everything works fine. The last lines displayed by "sshd -D -d -d -d -4" are: [...] debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=fubar devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for fubar from 127.0.0.1 port 51264 ssh2 debug3: Trying to reverse map address 127.0.0.1. debug1: do_cleanup And "strace -f sshd -D -4" says: [...] [pid 13387] getpeername(3, {sa_family=AF_INET, sin_port=htons(51261), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 [pid 13387] open("/etc/protocols", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 13387] getsockopt(3, SOL_IP, IP_OPTIONS, "", [0]) = 0 [pid 13387] socket(PF_FILE, SOCK_STREAM, 0) = 6 [pid 13387] connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) [pid 13387] close(6) = 0 [pid 13387] gettimeofday({1110457920, 91151}, NULL) = 0 [pid 13387] open("/etc/resolv.conf", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 13387] uname({sys="Linux", node="myhost.example", ...}) = 0 [pid 13387] open("/etc/host.conf", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 13387] open("/etc/hosts", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 13387] open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 13387] open("/lib/tls/i686/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 13387] stat64("/lib/tls/i686/sse2", 0xbff271fc) = -1 ENOENT (No such file or directory) (... lot of library stuff follows ...) [pid 13387] open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 13387] stat64("/usr/lib", 0xbff271fc) = -1 ENOENT (No such file or directory) [pid 13387] --- SIGSEGV (Segmentation fault) @ 0 (0) --- Process 13387 detached Any ideas what's wrong on my system? Greetings, Andreas From dtucker at zip.com.au Fri Mar 11 00:06:41 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 11 Mar 2005 00:06:41 +1100 Subject: OpenSSH 4.0p1 segfaults on keyboard-interactive login In-Reply-To: References: Message-ID: <42304661.6050708@zip.com.au> Andreas M. Kirchwitz wrote: > Hi folks, > > I've compiled the new OpenSSH 4.0p1 on my Linux box running > Fedora Core 2 (kernel 2.6.10) the same way as I did with 3.9p1 > and all previous versions. > > Key-based login works fine, but if I login from a host that > require me to enter my login password (keyboard-interactive), > then the sshd child process segfaults. > > Don't know if this is specific to my system or to Linux in > general. On Solaris 9 SPARC, everything works fine. I believe this is something relating to glibc and nameservice lookups in a chroot. It looks like libc tries to dynamically load some nameservice modules then blows up when it fails (because they don't exist in the chroot). If you can get a gdb backtrace of it I think you'll find it's inside libc when it dies. Try - "UseDNS no" in sshd_config. - cp -a /lib /var/empty (or wherever your sshd chroot is). You won't need all of the libraries, though. - create an /etc/nsswitch.conf inside the chroot that has only "hosts: files". -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From openssh-unix-dev-list at list.zikzak.de Fri Mar 11 02:40:27 2005 From: openssh-unix-dev-list at list.zikzak.de (Andreas M. Kirchwitz) Date: Thu, 10 Mar 2005 15:40:27 +0000 (UTC) Subject: OpenSSH 4.0p1 segfaults on keyboard-interactive login References: <42304661.6050708@zip.com.au> Message-ID: Hello! Darren Tucker wrote: >> I've compiled the new OpenSSH 4.0p1 on my Linux box running >> Fedora Core 2 (kernel 2.6.10) the same way as I did with 3.9p1 >> and all previous versions. >> >> Key-based login works fine, but if I login from a host that >> require me to enter my login password (keyboard-interactive), >> then the sshd child process segfaults. > > I believe this is something relating to glibc and nameservice lookups in > a chroot. It looks like libc tries to dynamically load some nameservice > modules then blows up when it fails (because they don't exist in the > chroot). If you can get a gdb backtrace of it I think you'll find it's > inside libc when it dies. Cool, that's a valuable hint. Sorry to say that, but I'm not good with gdb, so I first tried out some things (based on your suggestions) and found out additional interesting facts. > Try > - "UseDNS no" in sshd_config. You're right, this makes the segfault go away. > - cp -a /lib /var/empty (or wherever your sshd chroot is). You won't > need all of the libraries, though. Please don't laugh, but the mere existance of the directory "/var/empty/sshd/lib" is sufficient to make Fedora Core 2 happy. (I started with a complete copy of /lib and removed the libraries step by step to see which one I need. And to my surprise, I could safely delete everything except the "lib" directory itself.) > - create an /etc/nsswitch.conf inside the chroot that has only "hosts: > files". This doesn't seem to help, but a file "/var/empty/sshd/etc/hosts" with a line for every remote host I want to login from, also "solves" the problem. Do you have any idea what code change from OpenSSH 3.9p1 to 4.0p1 may have triggered this strange bug in system libraries? Especially the workaround with "mkdir /var/empty/sshd/lib" is, hmmm, confusing. Hopefully, this isn't a general security risk for applications that do nameservice lookups within a chroot'ed environment. Greetings and thanks for you help ... Andreas From Viet.Pham at Sun.COM Fri Mar 11 06:24:16 2005 From: Viet.Pham at Sun.COM (Viet Pham) Date: Thu, 10 Mar 2005 11:24:16 -0800 Subject: Solaris 10 support Message-ID: <42309EE0.4070102@Sun.COM> Hi Developers, This is Viet at Sun Microsystems. Does openssh support Solaris 10 spacrc, sol 10 x86, and sol 10 x64. If so, could you please point me to the link in openssh web site, not sunfreeware.com, that says so and the link to download. I need an official link to declare to Sun that you do support sol 10. Thanks. From maniac at maniac.nl Fri Mar 11 09:38:59 2005 From: maniac at maniac.nl (Mark Janssen) Date: Thu, 10 Mar 2005 23:38:59 +0100 Subject: Solaris 10 support In-Reply-To: <42309EE0.4070102@Sun.COM> References: <42309EE0.4070102@Sun.COM> Message-ID: <1110494340.5782.1.camel@localhost> On Thu, 2005-03-10 at 11:24 -0800, Viet Pham wrote: > Hi Developers, > This is Viet at Sun Microsystems. Does openssh support Solaris 10 > spacrc, sol 10 x86, and sol 10 x64. If so, could you please point me to > the link in openssh web site, not sunfreeware.com, that says so and the > link to download. I need an official link to declare to Sun that you do > support sol 10. Thanks. Doesn't sun support their own fork of openssh...called Sun-SSH (That's what's installed in solaris 9 by default). Openssh works for solaris 7-9... (that's what I use), and I assume it'll work just as well on solaris 10. -- Mark Janssen -- maniac(at)maniac.nl -- pgp: 0x357D2178 | ,''`. | Unix / Linux Open-Source and Internet Consultant @ Snow.nl | : :' : | Maniac.nl MarkJanssen.nl NerdNet.nl Unix.nl | `. `' | Skype: markmjanssen ICQ: 129696007 irc: FooBar on undernet | `- | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050310/0c984749/attachment.bin From dtucker at zip.com.au Fri Mar 11 09:58:20 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 11 Mar 2005 09:58:20 +1100 Subject: Solaris 10 support In-Reply-To: <42309EE0.4070102@Sun.COM> References: <42309EE0.4070102@Sun.COM> Message-ID: <4230D10C.4070204@zip.com.au> Viet Pham wrote: > Hi Developers, > This is Viet at Sun Microsystems. Does openssh support Solaris 10 > spacrc, sol 10 x86, and sol 10 x64. I tried it on Solaris 10 x86 on a test box before the 4.0 release and it worked. I don't see why it won't work on the other platforms (SPARC, x86-64) but I can't try it on either because I don't have access to hardware capable of running it. Feel free to try it yourself (the running the regress tests is just a matter of "make tests"). > If so, could you please point me to > the link in openssh web site, not sunfreeware.com, that says so and the > link to download. I need an official link to declare to Sun that you do > support sol 10. Thanks. http://www.openssh.com/portable.html "Solaris 10" is a subset of "Solaris". -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Mar 10 07:04:02 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Mar 2005 07:04:02 +1100 Subject: OpenSSH 4.0 released In-Reply-To: <1110388282.24846.11.camel@hh1pc14.desy.de> References: <200503090954.j299sEXY029145@cvs.openbsd.org> <1110388282.24846.11.camel@hh1pc14.desy.de> Message-ID: <20050309200402.GA2857@gate.dodgy.net.au> On Wed, Mar 09, 2005 at 06:11:22PM +0100, Rainer Peter Feller wrote: > On Wed, 2005-03-09 at 02:54 -0700, Damien Miller wrote: > > > > Checksums: > > ========== > > > > - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 > > - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 > whups! I got 7b36f28fc16e1b7f4ba3c1dca191ac92 for openssh-4.0p1.tar.gz ??? > what is wrong? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In short, the MD5 signature for the Portable tarball in the release notes is wrong. The correct signature is: 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz There was a last-minute compile fix which require a re-rolling of the release tarballs. I have confirmed that the signature in the release notes matches the signature for the tarball without that fix, that the the tarball on the FTP site contains the fix and that the only difference between the two is the aforementioned fix. I have also confirmed a good gpg signature from djm. The online version of the release notee has also been corrected and will appear at http://www.openssh.com/txt/release-4.0 shortly. Apologies to all for the confusion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (OpenBSD) iD8DBQFCL1Y4yYKAx4/0+mkRAiAAAJ9J/It/MkUrnjjBHmTV4zed/fH+jwCg1krg uchwZKbkVciEQGzB8rBXiUc= =RXLr -----END PGP SIGNATURE----- -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From tim at multitalents.net Fri Mar 11 11:31:44 2005 From: tim at multitalents.net (Tim Rice) Date: Thu, 10 Mar 2005 16:31:44 -0800 (PST) Subject: Solaris 10 support In-Reply-To: <4230D10C.4070204@zip.com.au> References: <42309EE0.4070102@Sun.COM> <4230D10C.4070204@zip.com.au> Message-ID: On Fri, 11 Mar 2005, Darren Tucker wrote: > Viet Pham wrote: >> Hi Developers, >> This is Viet at Sun Microsystems. Does openssh support Solaris 10 >> spacrc, sol 10 x86, and sol 10 x64. > > I tried it on Solaris 10 x86 on a test box before the 4.0 release and it > worked. I don't see why it won't work on the other platforms (SPARC, x86-64) > but I can't try it on either because I don't have access to hardware capable > of running it. My Solaris 8 box is an Ultra 10. The sun web site says Solaris 10 runs on the Ultra 10. If Sun wants to donate a spare disk drive and media kit, I'd be glad to make sure it runs on Solaris 10. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Fri Mar 11 12:00:37 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Mar 2005 20:00:37 -0500 Subject: OpenSSH 4.0 released In-Reply-To: <1110388282.24846.11.camel@hh1pc14.desy.de> References: <200503090954.j299sEXY029145@cvs.openbsd.org> <1110388282.24846.11.camel@hh1pc14.desy.de> Message-ID: <000b01c525d5$bcdbcb70$1402a8c0@netcentric.local> On Wed, Mar 09, 2005 at 06:11:22PM +0100, Rainer Peter Feller wrote: > On Wed, 2005-03-09 at 02:54 -0700, Damien Miller wrote: > > > > Checksums: > > ========== > > > > - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 > > - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 > whups! I got 7b36f28fc16e1b7f4ba3c1dca191ac92 for openssh-4.0p1.tar.gz ??? > what is wrong? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In short, the MD5 signature for the Portable tarball in the release notes is wrong. The correct signature is: 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz There was a last-minute compile fix which require a re-rolling of the release tarballs. I have confirmed that the signature in the release notes matches the signature for the tarball without that fix, that the the tarball on the FTP site contains the fix and that the only difference between the two is the aforementioned fix. I have also confirmed a good gpg signature from djm. The online version of the release notee has also been corrected and will appear at http://www.openssh.com/txt/release-4.0 shortly. Apologies to all for the confusion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (OpenBSD) iD8DBQFCL1Y4yYKAx4/0+mkRAiAAAJ9J/It/MkUrnjjBHmTV4zed/fH+jwCg1krg uchwZKbkVciEQGzB8rBXiUc= =RXLr -----END PGP SIGNATURE----- -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From stuge-openssh-unix-dev at cdy.org Fri Mar 11 18:09:39 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 11 Mar 2005 08:09:39 +0100 Subject: Dynamic smartcard support? Message-ID: <20050311070939.GB5020@foo.birdnet.se> Hi all, and thanks for everyone's work on the 4.0 release! There's been recent discussion on the OpenSC mailing list about getting better/updated smartcard support into OpenSSH. Originating from an OpenSSH package maintainer's desire to keep dependencies to a minimum, the idea to load OpenSC dynamically popped up. Now the question is whether this is an approach that would be favored by the OpenSSH maintainers? Do all of the portable platforms even support dynamic loading? //Peter From dtucker at zip.com.au Fri Mar 11 12:30:58 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Mar 2005 20:30:58 -0500 Subject: OpenSSH 4.0 released In-Reply-To: <1110388282.24846.11.camel@hh1pc14.desy.de> References: <200503090954.j299sEXY029145@cvs.openbsd.org> <1110388282.24846.11.camel@hh1pc14.desy.de> Message-ID: <000001c525d9$f9de3ef0$1402a8c0@netcentric.local> On Wed, Mar 09, 2005 at 06:11:22PM +0100, Rainer Peter Feller wrote: > On Wed, 2005-03-09 at 02:54 -0700, Damien Miller wrote: > > > > Checksums: > > ========== > > > > - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 > > - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 > whups! I got 7b36f28fc16e1b7f4ba3c1dca191ac92 for openssh-4.0p1.tar.gz ??? > what is wrong? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In short, the MD5 signature for the Portable tarball in the release notes is wrong. The correct signature is: 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz There was a last-minute compile fix which require a re-rolling of the release tarballs. I have confirmed that the signature in the release notes matches the signature for the tarball without that fix, that the the tarball on the FTP site contains the fix and that the only difference between the two is the aforementioned fix. I have also confirmed a good gpg signature from djm. The online version of the release notee has also been corrected and will appear at http://www.openssh.com/txt/release-4.0 shortly. Apologies to all for the confusion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (OpenBSD) iD8DBQFCL1Y4yYKAx4/0+mkRAiAAAJ9J/It/MkUrnjjBHmTV4zed/fH+jwCg1krg uchwZKbkVciEQGzB8rBXiUc= =RXLr -----END PGP SIGNATURE----- -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Mar 11 12:46:08 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Mar 2005 20:46:08 -0500 Subject: OpenSSH 4.0 released In-Reply-To: <1110388282.24846.11.camel@hh1pc14.desy.de> References: <200503090954.j299sEXY029145@cvs.openbsd.org> <1110388282.24846.11.camel@hh1pc14.desy.de> Message-ID: <000701c525dc$185f78b0$1402a8c0@netcentric.local> On Wed, Mar 09, 2005 at 06:11:22PM +0100, Rainer Peter Feller wrote: > On Wed, 2005-03-09 at 02:54 -0700, Damien Miller wrote: > > > > Checksums: > > ========== > > > > - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 > > - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 > whups! I got 7b36f28fc16e1b7f4ba3c1dca191ac92 for openssh-4.0p1.tar.gz ??? > what is wrong? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In short, the MD5 signature for the Portable tarball in the release notes is wrong. The correct signature is: 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz There was a last-minute compile fix which require a re-rolling of the release tarballs. I have confirmed that the signature in the release notes matches the signature for the tarball without that fix, that the the tarball on the FTP site contains the fix and that the only difference between the two is the aforementioned fix. I have also confirmed a good gpg signature from djm. The online version of the release notee has also been corrected and will appear at http://www.openssh.com/txt/release-4.0 shortly. Apologies to all for the confusion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (OpenBSD) iD8DBQFCL1Y4yYKAx4/0+mkRAiAAAJ9J/It/MkUrnjjBHmTV4zed/fH+jwCg1krg uchwZKbkVciEQGzB8rBXiUc= =RXLr -----END PGP SIGNATURE----- -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Mar 11 12:15:47 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 10 Mar 2005 20:15:47 -0500 Subject: OpenSSH 4.0 released In-Reply-To: <1110388282.24846.11.camel@hh1pc14.desy.de> References: <200503090954.j299sEXY029145@cvs.openbsd.org> <1110388282.24846.11.camel@hh1pc14.desy.de> Message-ID: <000001c525d7$db5d0530$1402a8c0@netcentric.local> On Wed, Mar 09, 2005 at 06:11:22PM +0100, Rainer Peter Feller wrote: > On Wed, 2005-03-09 at 02:54 -0700, Damien Miller wrote: > > > > Checksums: > > ========== > > > > - MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0 > > - MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3 > whups! I got 7b36f28fc16e1b7f4ba3c1dca191ac92 for openssh-4.0p1.tar.gz ??? > what is wrong? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In short, the MD5 signature for the Portable tarball in the release notes is wrong. The correct signature is: 7b36f28fc16e1b7f4ba3c1dca191ac92 openssh-4.0p1.tar.gz There was a last-minute compile fix which require a re-rolling of the release tarballs. I have confirmed that the signature in the release notes matches the signature for the tarball without that fix, that the the tarball on the FTP site contains the fix and that the only difference between the two is the aforementioned fix. I have also confirmed a good gpg signature from djm. The online version of the release notee has also been corrected and will appear at http://www.openssh.com/txt/release-4.0 shortly. Apologies to all for the confusion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (OpenBSD) iD8DBQFCL1Y4yYKAx4/0+mkRAiAAAJ9J/It/MkUrnjjBHmTV4zed/fH+jwCg1krg uchwZKbkVciEQGzB8rBXiUc= =RXLr -----END PGP SIGNATURE----- -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From gert at greenie.muc.de Fri Mar 11 20:02:10 2005 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 11 Mar 2005 10:02:10 +0100 Subject: Dynamic smartcard support? In-Reply-To: <20050311070939.GB5020@foo.birdnet.se> References: <20050311070939.GB5020@foo.birdnet.se> Message-ID: <20050311090210.GU1110@greenie.muc.de> Hi, On Fri, Mar 11, 2005 at 08:09:39AM +0100, Peter Stuge wrote: > Originating from an OpenSSH package maintainer's desire to keep > dependencies to a minimum, the idea to load OpenSC dynamically > popped up. Now the question is whether this is an approach that > would be favored by the OpenSSH maintainers? I'm not an OpenSSH maintainer, but this sounds to me as "even more dependencies" - portable shared libraries are *hard*, and you'd still need to have all the calls to OpenSC functions in the OpenSSH code base. 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 at net.informatik.tu-muenchen.de From jason at dour.org Sat Mar 12 07:30:09 2005 From: jason at dour.org (Jason A. Dour) Date: Fri, 11 Mar 2005 15:30:09 -0500 Subject: SFTP Logging Patch Webpage Message-ID: <20050311203009.GA904@dour.org> For those in the open-ssh community that have been using my SFTP Logging patches over the years, I've finally posted a webpage where I will keep the patch available to the public. It is current as of 4.0p1. All versions of the patch that I have readily available are at: http://oddgeek.info/code/openssh/ It goes back as far as 2.9, though I obviously wouldn't encourage anyone to continue using older versions of open-ssh. Please feel free to use the patch, and provide any feedback. Cheers, Jason From jason at dour.org Sat Mar 12 07:30:09 2005 From: jason at dour.org (Jason A. Dour) Date: Fri, 11 Mar 2005 15:30:09 -0500 Subject: SFTP Logging Patch Webpage Message-ID: <20050311203009.GA904@dour.org> For those in the open-ssh community that have been using my SFTP Logging patches over the years, I've finally posted a webpage where I will keep the patch available to the public. It is current as of 4.0p1. All versions of the patch that I have readily available are at: http://oddgeek.info/code/openssh/ It goes back as far as 2.9, though I obviously wouldn't encourage anyone to continue using older versions of open-ssh. Please feel free to use the patch, and provide any feedback. Cheers, Jason From dtucker at zip.com.au Sat Mar 12 13:03:34 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 12 Mar 2005 13:03:34 +1100 Subject: Dynamic smartcard support? In-Reply-To: <20050311070939.GB5020@foo.birdnet.se> References: <20050311070939.GB5020@foo.birdnet.se> Message-ID: <42324DF6.7020203@zip.com.au> Peter Stuge wrote: > There's been recent discussion on the OpenSC mailing list about > getting better/updated smartcard support into OpenSSH. > > Originating from an OpenSSH package maintainer's desire to keep > dependencies to a minimum, the idea to load OpenSC dynamically > popped up. That is this thread? http://www.opensc.org/pipermail/opensc-devel/2005-March/005707.html > Now the question is whether this is an approach that > would be favored by the OpenSSH maintainers? This has been suggested once before (dlopen'ing a library for KerberosGetAFSToken) but there was not much support for it. I suspect there would not be much support for this either. > Do all of the portable platforms even support dynamic loading? I don't think Cygwin does. There could well be others. Even on platforms where it is supported it's likely to vary quite a bit. On AIX, libfoo.a can contain shared and static components. On HP-UX, the libraries are libfoo.sl not libfoo.so. dlopen can be hiding in different places on different platforms. And probably many other things... -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From stuge-openssh-unix-dev at cdy.org Sat Mar 12 13:10:24 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 12 Mar 2005 03:10:24 +0100 Subject: Dynamic smartcard support? In-Reply-To: <42324DF6.7020203@zip.com.au> References: <20050311070939.GB5020@foo.birdnet.se> <42324DF6.7020203@zip.com.au> Message-ID: <20050312021024.GA17700@foo.birdnet.se> On Sat, Mar 12, 2005 at 01:03:34PM +1100, Darren Tucker wrote: > Peter Stuge wrote: > >Originating from an OpenSSH package maintainer's desire to keep > >dependencies to a minimum, the idea to load OpenSC dynamically > >popped up. > > That is this thread? > http://www.opensc.org/pipermail/opensc-devel/2005-March/005707.html Right. I found out that Nils Larsch is discussing this with Markus off-lists too. > >Now the question is whether this is an approach that > >would be favored by the OpenSSH maintainers? > > This has been suggested once before (dlopen'ing a library for > KerberosGetAFSToken) but there was not much support for it. I > suspect there would not be much support for this either. > > >Do all of the portable platforms even support dynamic loading? > > I don't think Cygwin does. There could well be others. > > Even on platforms where it is supported it's likely to vary quite a > bit. On AIX, libfoo.a can contain shared and static components. On > HP-UX, the libraries are libfoo.sl not libfoo.so. dlopen can be > hiding in different places on different platforms. And probably > many other things... Right. This is pretty much what I expected. Thanks for the input I got though. //Peter From dtucker at zip.com.au Sat Mar 12 19:55:19 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 12 Mar 2005 19:55:19 +1100 Subject: OpenSSH 4.0p1 segfaults on keyboard-interactive login In-Reply-To: References: <42304661.6050708@zip.com.au> Message-ID: <4232AE77.1040500@zip.com.au> Andreas M. Kirchwitz wrote: > Please don't laugh, but the mere existance of the directory > "/var/empty/sshd/lib" is sufficient to make Fedora Core 2 happy. > (I started with a complete copy of /lib and removed the libraries > step by step to see which one I need. And to my surprise, I could > safely delete everything except the "lib" directory itself.) It's reproducable with a minimal test case, and it's definitely deep in libc. It's been confirmed to be a known problem in glibc, but the fix does not seem to have made it to a released rpm yet. In the mean time, the workaround is to create /var/empty/lib. References: https://bugzilla.redhat.com/beta/show_bug.cgi?id=144303 http://sources.redhat.com/ml/libc-hacker/2005-02/msg00005.html $ cat chroot-dns-test.c #include #include int main(void) { chroot("/tmp"); chdir("/"); gethostbyname("foo"); } $ gcc -g chroot-dns-test.c $ sudo gdb -q ./a.out Using host libthread_db library "/lib/tls/i686/libthread_db.so.1". (gdb) run Starting program: /home/dtucker/a.out Program received signal SIGSEGV, Segmentation fault. open_path (name=0xbff34b30 "libnss_dns.so.2", namelen=16, preloaded=0, sps=0x955ed0, realname=0xffffffff, fbp=0xbff345c4) at dl-load.c:1791 1791 sps->dirs = (void *) -1; (gdb) bt #0 open_path (name=0xbff34b30 "libnss_dns.so.2", namelen=16, preloaded=0, sps=0x955ed0, realname=0xffffffff, fbp=0xbff345c4) at dl-load.c:1791 #1 0x00948630 in _dl_map_object (loader=0x9564e0, name=0xbff34b30 "libnss_dns.so.2", preloaded=0, type=2, trace_mode=0, mode=-1879048191, nsid=0) at dl-load.c:1961 #2 0x00a3b516 in dl_open_worker () from /lib/tls/i686/libc.so.6 #3 0x0094cbd1 in _dl_catch_error (objname=0xbff349a0, errstring=0xbff349a4, operate=0xa3b41c , args=0xbff349a8) at dl-error.c:161 #4 0x00a3c0a9 in _dl_open () from /lib/tls/i686/libc.so.6 #5 0x00a3d3ad in do_dlopen () from /lib/tls/i686/libc.so.6 #6 0x0094cbd1 in _dl_catch_error (objname=0xbff34aec, errstring=0xbff34af0, operate=0xa3d398 , args=0xbff34af4) at dl-error.c:161 #7 0x00a3d461 in __libc_dlopen_mode () from /lib/tls/i686/libc.so.6 #8 0x00a1d611 in __nss_lookup_function () from /lib/tls/i686/libc.so.6 #9 0x00a1d711 in __nss_lookup () from /lib/tls/i686/libc.so.6 #10 0x00a1ed42 in __nss_hosts_lookup () from /lib/tls/i686/libc.so.6 #11 0x00a21788 in gethostbyname_r@@GLIBC_2.1.2 () from /lib/tls/i686/libc.so.6 #12 0x00a21154 in gethostbyname () from /lib/tls/i686/libc.so.6 #13 0x08048421 in main () at chroot-dns-test.c:9 > Do you have any idea what code change from OpenSSH 3.9p1 to 4.0p1 > may have triggered this strange bug in system libraries? Especially > the workaround with "mkdir /var/empty/sshd/lib" is, hmmm, confusing. It's probably just a DNS lookup somplace where there wasn't previously. It could be something as simple as a debug() call. > Hopefully, this isn't a general security risk for applications that > do nameservice lookups within a chroot'ed environment. I don't think it is. The description I got was that the segfault is caused because libc attempts to write to a segment mapped readonly. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Sun Mar 13 20:57:34 2005 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 13 Mar 2005 10:57:34 +0100 Subject: [PATCH] contrib/cygwin/ssh-host-config: Reliability fix Message-ID: <20050313095734.GH7473@cygbert.vinschen.de> Hi, the below patch makes the query for the localized name of the local administrators group more reliable. Can somebody check it in, please? Thanks, Corinna Index: ssh-host-config =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-host-config,v retrieving revision 1.15 diff -p -u -r1.15 ssh-host-config --- ssh-host-config 21 Sep 2004 11:35:56 -0000 1.15 +++ ssh-host-config 13 Mar 2005 09:45:30 -0000 @@ -449,12 +449,10 @@ then echo "Should this script create a new local account 'sshd_server' which has" if request "the required privileges?" then - _admingroup=`awk -F: '{if ( $1 != "root" && $2 == "S-1-5-32-544" ) print $1;}' ${SYSCONFDIR}/group` + _admingroup=`mkgroup -l | awk -F: '{if ( $2 == "S-1-5-32-544" ) print $1;}' ` if [ -z "${_admingroup}" ] then - echo "There's no group with SID S-1-5-32-544 (Local administrators group) in" - echo "your ${SYSCONFDIR}/group file. Please regenerate this entry using 'mkgroup -l'" - echo "and restart this script." + echo "mkgroup -l produces no group with SID S-1-5-32-544 (Local administrators group)." exit 1 fi dos_var_empty=`cygpath -w ${LOCALSTATEDIR}/empty` -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc. From Dale.Roberts at corptech.qld.gov.au Fri Mar 11 16:22:03 2005 From: Dale.Roberts at corptech.qld.gov.au (Dale.Roberts at corptech.qld.gov.au) Date: Fri, 11 Mar 2005 15:22:03 +1000 Subject: OpenSSH for Win2003 Server Message-ID: Couldnt find a solution for dropping out of the session after loggin in using key authentication. But if you start the service as a user instead of system and chown and chmod the /var/log/OpenSSHd.log to give that user appropriate rights it works fine. ************************************************************ Opinions contained in this e-mail do not necessarily reflect the opinions of the Queensland Department of Main Roads, Queensland Transport or Maritime Safety Queensland, or endorsed organisations utilising the same infrastructure. If you have received this electronic mail message in error, please immediately notify the sender and delete the message from your computer. ************************************************************ From peter at slagheap.net Tue Mar 15 10:21:13 2005 From: peter at slagheap.net (Peter Bartoli) Date: Mon, 14 Mar 2005 15:21:13 -0800 Subject: scp problem on OS X Message-ID: <12f0319048be88e32d258b6396362a59@slagheap.net> Anybody seen this? Only happens with scp. hackintosh502% scp -pr submerging_tech phoenix:tmp xfree: NULL pointer given as argument lost connection -peter From dtucker at zip.com.au Tue Mar 15 10:39:48 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Mar 2005 10:39:48 +1100 Subject: scp problem on OS X In-Reply-To: <12f0319048be88e32d258b6396362a59@slagheap.net> References: <12f0319048be88e32d258b6396362a59@slagheap.net> Message-ID: <423620C4.8070200@zip.com.au> Peter Bartoli wrote: > Anybody seen this? Only happens with scp. > > hackintosh502% scp -pr submerging_tech phoenix:tmp > xfree: NULL pointer given as argument > lost connection Yes, unfortunately it's a bug. See: http://bugzilla.mindrot.org/show_bug.cgi?id=996 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From peter at slagheap.net Tue Mar 15 10:48:14 2005 From: peter at slagheap.net (Peter Bartoli) Date: Mon, 14 Mar 2005 15:48:14 -0800 Subject: scp problem on OS X In-Reply-To: <423620C4.8070200@zip.com.au> References: <12f0319048be88e32d258b6396362a59@slagheap.net> <423620C4.8070200@zip.com.au> Message-ID: On Mar 14, 2005, at 3:39 PM, Darren Tucker wrote: > Peter Bartoli wrote: >> Anybody seen this? Only happens with scp. >> hackintosh502% scp -pr submerging_tech phoenix:tmp >> xfree: NULL pointer given as argument >> lost connection > > Yes, unfortunately it's a bug. See: > http://bugzilla.mindrot.org/show_bug.cgi?id=996 Thanks, Darren, and please pardon my ignorance. Will there be a 4.0.1p1 release to fix this or a source patch? -peter From dtucker at zip.com.au Tue Mar 15 10:53:18 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Mar 2005 10:53:18 +1100 Subject: scp problem on OS X In-Reply-To: References: <12f0319048be88e32d258b6396362a59@slagheap.net> <423620C4.8070200@zip.com.au> Message-ID: <423623EE.9060903@zip.com.au> Peter Bartoli wrote: > Thanks, Darren, and please pardon my ignorance. Will there be a 4.0.1p1 > release to fix this or a source patch? There's a source patch attached to the bug (see the attachments section immediately before the start of the comments). Not sure about the next release yet. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From d.khan at ventigo.com Tue Mar 15 21:23:54 2005 From: d.khan at ventigo.com (Daniel Khan) Date: Tue, 15 Mar 2005 11:23:54 +0100 Subject: Segmentation fault on public key authentification Message-ID: <4236B7BA.8050303@ventigo.com> Hello list, after some weeks of operation and updates one server of mine needed a reboot. Now authentification with public key causes a segfault. System information: 2.6.8-gentoo-r4 x86_64 AMD Dual Opteron(tm) Processor 242 AuthenticAMD Debugging information: // ssh fom node2 to node1 # ssh -vvv node1 OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to node1 [192.168.0.100] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Not a RSA1 key file /root/.ssh/identity. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /root/.ssh/identity type 2 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes25 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes25 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-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes25 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes25 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 134/256 debug2: bits set: 518/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host 'node1' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:2 debug2: bits set: 524/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/identity (0x556370) debug2: key: /root/.ssh/id_rsa ((nil)) debug2: key: /root/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,keyboard-interactive debug3: start over, passed a different list publickey,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/identity debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply Connection closed by 192.168.0.100 // SSH Logfile on node1: Mar 15 11:21:14 [sshd] debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7 Mar 15 11:21:14 [sshd] debug1: Forked child 1817. Mar 15 11:21:14 [sshd] debug1: inetd sockets after dupping: 3, 3 Mar 15 11:21:14 [sshd] Connection from 192.168.0.200 port 37281 Mar 15 11:21:14 [sshd] debug1: Client protocol version 2.0; client software version OpenSSH_3.9p1 Mar 15 11:21:14 [sshd] debug1: match: OpenSSH_3.9p1 pat OpenSSH* Mar 15 11:21:14 [sshd] debug1: Enabling compatibility mode for protocol 2.0 Mar 15 11:21:14 [sshd] debug1: Local version string SSH-2.0-OpenSSH_3.9p1 Mar 15 11:21:14 [sshd] debug1: PAM: initializing for "root" Mar 15 11:21:14 [sshd] debug1: PAM: setting PAM_RHOST to "node2" Mar 15 11:21:14 [sshd] debug1: PAM: setting PAM_TTY to "ssh" Mar 15 11:21:14 [sshd] debug1: temporarily_use_uid: 0/0 (e=0/0) Mar 15 11:21:14 [sshd] debug1: trying public key file /root/.ssh/authorized_keys Mar 15 11:21:14 [sshd] debug1: restore_uid: 0/0 Mar 15 11:21:14 [sshd] debug1: temporarily_use_uid: 0/0 (e=0/0) Mar 15 11:21:14 [sshd] debug1: trying public key file /root/.ssh/authorized_keys2 // Messagelog on node1: Mar 15 11:21:14 [sshd] Connection from 192.168.0.200 port 37281 Mar 15 11:21:14 [kernel] sshd[1817]: segfault at 0000000000000003 rip 0000002a9615274d rsp 0000007fbfffc290 error 6 // Public key file: -rw------- 1 root root 2.4K Mar 15 11:02 /root/.ssh/authorized_keys2 Any ideas? Thanks for your help. greetings -- Daniel Khan Technische Leitung Gesch?ftsf?hrender Gesellschafter Ventigo Werbung . IT . Marketing GmbH Kornstrasse 10 4060 Leonding T. +43 (0) 732 37 09 60 | F. +43 (0) 732 37 09 60 10 http://www.ventigo.com | office at ventigo.com From dtucker at zip.com.au Tue Mar 15 22:21:03 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Mar 2005 22:21:03 +1100 Subject: Segmentation fault on public key authentification In-Reply-To: <4236B7BA.8050303@ventigo.com> References: <4236B7BA.8050303@ventigo.com> Message-ID: <4236C51F.6020705@zip.com.au> Daniel Khan wrote: > after some weeks of operation and updates one server of mine needed a > reboot. > Now authentification with public key causes a segfault. One of those updates didn't happen to be an openssl one, did it? Since it's while reading keys that's a good place to start looking. I vaguely recall a problem on amd64 (in the asm?), although it should not be in the current openssl. (Found it in the list archives, it was a SIGFPE not SEGV so it's probably not related. > // Messagelog on node1: > Mar 15 11:21:14 [sshd] Connection from 192.168.0.200 port 37281 > Mar 15 11:21:14 [kernel] sshd[1817]: segfault at 0000000000000003 rip > 0000002a9615274d rsp 0000007fbfffc290 error 6 [...] Your best bet is to get a stack trace of sshd using gdb. To do this, as root (I'm using port 2022 for this example): # gdb /path/to/sshd (gdb) set args -ddd -p 2022 -o useprivilegeseparation=no (gdb) run [now connect and wait for the failure] (gdb) backtrace > // Public key file: > -rw------- 1 root root 2.4K Mar 15 11:02 /root/.ssh/authorized_keys2 That looks to have changed recently, does the problem persist if you remove the recent entries? > Any ideas? 4.0p1 is out, you could try that. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From d.khan at ventigo.com Tue Mar 15 23:22:50 2005 From: d.khan at ventigo.com (Daniel Khan) Date: Tue, 15 Mar 2005 13:22:50 +0100 Subject: Segmentation fault on public key authentification In-Reply-To: <4236C51F.6020705@zip.com.au> References: <4236B7BA.8050303@ventigo.com> <4236C51F.6020705@zip.com.au> Message-ID: <4236D39A.7060906@ventigo.com> Darren Tucker wrote: >> after some weeks of operation and updates one server of mine needed a >> reboot. >> Now authentification with public key causes a segfault. > > One of those updates didn't happen to be an openssl one, did it? > Since it's while reading keys that's a good place to start looking. No - I don't know what I updated but it wasn't OpenSSH. A mirror with pretty the "same" configuration works.. > > Your best bet is to get a stack trace of sshd using gdb. To do this, > as root (I'm using port 2022 for this example): > // Here it comes - but it doesn't look to exiting I think: Starting program: /usr/sbin/sshd -ddd -p 2022 -o useprivilegeseparation=no warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: shared library handler failed to enable breakpoint debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 203 debug2: parse_server_config: config /etc/ssh/sshd_config len 203 debug1: sshd version OpenSSH_3.9p1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2022' debug1: rexec_argv[4]='-o' debug1: rexec_argv[5]='useprivilegeseparation=no' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2022 on 0.0.0.0. Server listening on 0.0.0.0 port 2022. socket: Address family not supported by protocol debug3: fd 4 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 203 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 Program received signal SIGSEGV, Segmentation fault. 0x0000002a9615274d in ?? () (gdb) backtrace #0 0x0000002a9615274d in ?? () #1 0x00000000fbad8000 in ?? () >> // Public key file: >> -rw------- 1 root root 2.4K Mar 15 11:02 /root/.ssh/authorized_keys2 > > That looks to have changed recently, does the problem persist if you > remove the recent entries? No - I was just playing around with this file after the problem occured. >> Any ideas? > > > 4.0p1 is out, you could try that. I just want to find the cause. Maybe anything else is b0rked here na dI don't want to wait till it really bites me.. Thanks a lot. -- Daniel Khan Technische Leitung Gesch?ftsf?hrender Gesellschafter Ventigo Werbung . IT . Marketing GmbH Kornstrasse 10 4060 Leonding T. +43 (0) 732 37 09 60 | F. +43 (0) 732 37 09 60 10 http://www.ventigo.com | office at ventigo.com From dtucker at zip.com.au Tue Mar 15 23:34:06 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 15 Mar 2005 23:34:06 +1100 Subject: Segmentation fault on public key authentification In-Reply-To: <4236D39A.7060906@ventigo.com> References: <4236B7BA.8050303@ventigo.com> <4236C51F.6020705@zip.com.au> <4236D39A.7060906@ventigo.com> Message-ID: <4236D63E.2050501@zip.com.au> Daniel Khan wrote: > Darren Tucker wrote: >> One of those updates didn't happen to be an openssl one, did it? >> Since it's while reading keys that's a good place to start looking. > > No - I don't know what I updated but it wasn't OpenSSH. > A mirror with pretty the "same" configuration works.. No, OpenSSL the library, not OpenSSH. You may want to compare /usr/lib/libcrypto* with your working machine. >> Your best bet is to get a stack trace of sshd using gdb. To do this, >> as root (I'm using port 2022 for this example): >> > // Here it comes - but it doesn't look to exiting I think: > Starting program: /usr/sbin/sshd -ddd -p 2022 -o useprivilegeseparation=no > warning: Unable to find dynamic linker breakpoint function. > GDB will be unable to debug shared library initializers > and track explicitly loaded dynamic code. > warning: shared library handler failed to enable breakpoint [...] > Program received signal SIGSEGV, Segmentation fault. > 0x0000002a9615274d in ?? () > (gdb) backtrace > #0 0x0000002a9615274d in ?? () > #1 0x00000000fbad8000 in ?? () Hmm, that's not very helpful. You can try disabling reexec (add "-r" to the args gdb passes to sshd) but if the problem is because of the breakpoint thing gdb is complaining about then it's possible that won't help either. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From d.khan at ventigo.com Wed Mar 16 00:06:19 2005 From: d.khan at ventigo.com (Daniel Khan) Date: Tue, 15 Mar 2005 14:06:19 +0100 Subject: Segmentation fault on public key authentification In-Reply-To: <4236D63E.2050501@zip.com.au> References: <4236B7BA.8050303@ventigo.com> <4236C51F.6020705@zip.com.au> <4236D39A.7060906@ventigo.com> <4236D63E.2050501@zip.com.au> Message-ID: <4236DDCB.3010800@ventigo.com> Darren Tucker wrote: > No, OpenSSL the library, not OpenSSH. You may want to compare > /usr/lib/libcrypto* with your working machine. It's the same. > [..] > >> >> #1 0x00000000fbad8000 in ?? () > > Hmm, that's not very helpful. You can try disabling reexec (add "-r" > to the args gdb passes to sshd) but if the problem is because of the > breakpoint thing gdb is complaining about then it's possible that > won't help either. Didn't help. BUT I now compiled 4.0 on node1 and the segfault is gone but public key auth still doesn't work anymore. I have the debugging output of such a session and a working session with another host. // NOT WORKING debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/identity debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Trying private key: /root/.ssh/id_rsa debug3: no such identity: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug3: no such identity: /root/.ssh/id_dsa debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password // WORKING debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/identity debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 433 debug2: input_userauth_pk_ok: fp c2:45:5c:00:f4:64:d5:41:46:d3:aa:d0:e5:4b:5c:2d debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. I have some ideas about the cause but I am not really sure. Maybe this gives some kind of hint to you? Thanks for your effords! :-) -- Daniel Khan Technische Leitung Gesch?ftsf?hrender Gesellschafter Ventigo Werbung . IT . Marketing GmbH Kornstrasse 10 4060 Leonding T. +43 (0) 732 37 09 60 | F. +43 (0) 732 37 09 60 10 http://www.ventigo.com | office at ventigo.com From lucio at sulweb.org Wed Mar 16 03:10:02 2005 From: lucio at sulweb.org (Lucio Crusca) Date: Tue, 15 Mar 2005 17:10:02 +0100 Subject: Port 0 forwarding Message-ID: <200503151710.02507.lucio@sulweb.org> Hello all. I posted here a few days ago about the support of dynamic selection of the port to forward (ssh -R 0:host:port), which refers to section 7.1 of http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-24.txt . My posts were from lcml at pixel.it, while this is from lucio at sulweb.org. Nevermind, It's always me. Here is the patch that adds support for that thing. It's in unified diff I believe, but I don't know if I generated the right way. It's based on the latest stable sources (openssh-4.0p1). The patch is tested and seems to work on my system (Debian GNU/Linux Sarge i386), but I have no other resources to do other tests. There is a problem: while the relevant part of the protocol is now implemented, both on the client and the server side, it lacks the user interface, so the only way for the user to realize what port the server has choosen is to nmap the server and guess from the output. The fact is that I really don't know how to provide a useful interface for that, because the information it's of some interest for the server, but not for the client I believe. So, how do we make sshd tell someone what port it has choosen? Setting an env variable is not possible AFAIK, because the forwarding may be established after the interactive session has been started. Executing a configurable script? Maybe, but I'm not sure it's the best solution. Any suggestion is appreciated. Lucio Crusca. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.txt.gz Type: application/x-gzip Size: 1999 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050315/47372d05/attachment.bin From dothoro at gmail.com Wed Mar 16 10:35:13 2005 From: dothoro at gmail.com (Pete Dow) Date: Tue, 15 Mar 2005 15:35:13 -0800 Subject: SFTP append patch Message-ID: Hi, We plan to do automated file transfers with SFTP where an uploaded file is always appended on the server, and I made this patch to support that. The patch 1. adds the "ap" command to the client (syntax just like the put command) 2. adds in both client and server support for the SSH2_FXF_APPEND flag of the "pflags" field of the file open message. Patch is against 4.0p1. Thanks, Pete Dow -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-4.0p1-append-changes.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050315/1a1c6e33/attachment.ksh From nickls at apple.com Wed Mar 16 11:52:45 2005 From: nickls at apple.com (Nick Lane-Smith) Date: Tue, 15 Mar 2005 16:52:45 -0800 Subject: openssh-3.8.1p1, with pthreads enabled, hung in pthread_join. Message-ID: I connect to my OpenSSH 3.8.1p1 server and when the password dialog shoes up I wait a min or so, long enough for the "Timeout before authentication for %s" alarm to trigger. If at that point I enter my password ssh will just sit there: debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: debug3: packet_send2: adding 32 (len 18 padlen 14 extra_pad 64) And the sshd will be in this state: Attaching to program: `/private/tmp/OpenSSH.roots/OpenSSH~obj/sshd', process 26589. Reading symbols for shared libraries ...................... done 0x9002cf88 in semaphore_wait_trap () (gdb) bt #0 0x9002cf88 in semaphore_wait_trap () #1 0x9006153c in pthread_join () #2 0x00028a50 in sshpam_thread_cleanup () at /tmp/OpenSSH.roots/OpenSSH/openssh/auth-pam.c:417 #3 0x00017110 in do_cleanup (authctxt=0x4034e0) at /tmp/OpenSSH.roots/OpenSSH/openssh/session.c:2273 #4 0x00007044 in cleanup_exit (i=255) at /tmp/OpenSSH.roots/OpenSSH/openssh/sshd.c:1923 #5 0x00035bb0 in fatal (fmt=0x547d0 "Timeout before authentication for %s") at /tmp/OpenSSH.roots/OpenSSH/openssh/fatal.c:40 #6 0x00002d40 in grace_alarm_handler (sig=14) at /tmp/OpenSSH.roots/OpenSSH/openssh/sshd.c:320 #7 #8 0x90013bc8 in read () #9 0x0002b5ec in atomicio (f=0x90013bc0 , fd=6, _s=0xbfffef60, n=4) at /tmp/OpenSSH.roots/OpenSSH/openssh/atomicio.c:45 #10 0x00020744 in mm_request_receive (socket=6, m=0xbfffefc0) at /tmp/OpenSSH.roots/OpenSSH/openssh/monitor_wrap.c:110 #11 0x0001c290 in monitor_read (pmonitor=0x403540, ent=0x633c4, pent=0xbffff030) at /tmp/OpenSSH.roots/OpenSSH/openssh/monitor.c:446 #12 0x0001bda8 in monitor_child_preauth (_authctxt=0x4034e0, pmonitor=0x403540) at /tmp/OpenSSH.roots/OpenSSH/openssh/monitor.c:343 #13 0x000039dc in privsep_preauth (authctxt=0x4034e0) at /tmp/OpenSSH.roots/OpenSSH/openssh/sshd.c:607 #14 0x000061c0 in main (ac=3, av=0x400f10) at /tmp/OpenSSH.roots/OpenSSH/openssh/sshd.c:1544 (gdb) info threads 2 process 26589 thread 0x1103 0x90013bcc in read () * 1 process 26589 thread 0x203 0x9002cf88 in semaphore_wait_trap () (gdb) thread 2 [Switching to thread 2 (process 26589 thread 0x1103)] #0 0x90013bcc in read () (gdb) bt #0 0x90013bcc in read () #1 0x0002b5ec in atomicio (f=0x90013bc0 , fd=8, _s=0xf0080ac0, n=4) at /tmp/OpenSSH.roots/OpenSSH/openssh/atomicio.c:45 #2 0x000491fc in ssh_msg_recv (fd=8, m=0xf0080b20) at /tmp/OpenSSH.roots/OpenSSH/openssh/msg.c:63 #3 0x00028514 in sshpam_thread_conv (n=1, msg=0xf0080bb4, resp=0xf0080bb8, data=0x403830) at /tmp/OpenSSH.roots/OpenSSH/openssh/auth-pam.c:272 #4 0x96798918 in _pam_system_log () #5 0x967989f4 in pam_get_pass () #6 0x0018a930 in pam_sm_authenticate () #7 0x967961c4 in pam_fail_delay () #8 0x96796514 in _pam_dispatch () #9 0x96797c40 in pam_authenticate () #10 0x00028880 in sshpam_thread (ctxtp=0x403830) at /tmp/OpenSSH.roots/OpenSSH/openssh/auth-pam.c:354 #11 0x9002c7f4 in _pthread_body () Thread two will just sit there in read while thread one waits for thread two to exit. If i attempt this with privilege separation turned on the lowered privilege process will exit and become a zombie, as the original process never exits. Shouldn't the sshpam/read thread have an alarm set so if the authentication times out it will exit cleanly? -Nick From dtucker at zip.com.au Wed Mar 16 13:55:12 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 16 Mar 2005 13:55:12 +1100 Subject: openssh-3.8.1p1, with pthreads enabled, hung in pthread_join. In-Reply-To: References: Message-ID: <4237A010.1080004@zip.com.au> First, if you're building with USE_POSIX_THREADS then that's an unsupported configuration. Nick Lane-Smith wrote: > I connect to my OpenSSH 3.8.1p1 server and when the password dialog > shoes up I wait a min or so, long enough for the "Timeout before > authentication for %s" alarm to trigger. If at that point I enter my > password ssh will just sit there: > > debug2: input_userauth_info_req > debug2: input_userauth_info_req: num_prompts 1 > Password: > debug3: packet_send2: adding 32 (len 18 padlen 14 extra_pad 64) > > And the sshd will be in this state: > > Attaching to program: `/private/tmp/OpenSSH.roots/OpenSSH~obj/sshd', > process 26589. > Reading symbols for shared libraries ...................... done > 0x9002cf88 in semaphore_wait_trap () > (gdb) bt > #0 0x9002cf88 in semaphore_wait_trap () > #1 0x9006153c in pthread_join () > #2 0x00028a50 in sshpam_thread_cleanup () at > /tmp/OpenSSH.roots/OpenSSH/openssh/auth-pam.c:417 That line is immediately preceded by: pthread_cancel(ctxt->pam_thread); Maybe pthread_cancel doesn't interrupt the read() syscall? I don't know anything about your thread implementation. > Shouldn't the sshpam/read thread have an alarm set so if the > authentication times out it will exit cleanly? It shouldn't be necessary (and it's a potential source of races). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Steven.Vandor at ca.com Thu Mar 17 08:53:02 2005 From: Steven.Vandor at ca.com (Vandor, Steven A) Date: Wed, 16 Mar 2005 16:53:02 -0500 Subject: openssh on Red Hat and Suse Linux with PAM (cf. bug 559, patches 292, 675) Message-ID: <6263B5BBA63290489CB4C87738402CCC07FAED1B@usilms22.ca.com> Do you know if either of the patches referenced above can be applied to the 3.6p1 code shipped by Red Hat (RHEL3) and Suse (SLES8)? It appears they were integrated in the 3.7p1 and 3.9p1 releases, respectively. Steven Vandor Computer Associates 425 825 2799 vandor at ca.com This message may contain confidential, privileged or other legally protected information.? It is intended for the addressee only.? If you aren't the addressee (or someone authorized by the addressee to receive this message), you are prohibited from copying, distributing, or otherwise using it.? Please notify the sender and return it at our cost.? Thank you. From thesource at ldb-jab.org Thu Mar 17 09:08:54 2005 From: thesource at ldb-jab.org (Lawrence Bowie) Date: Wed, 16 Mar 2005 17:08:54 -0500 Subject: openssh on Red Hat and Suse Linux with PAM (cf. bug 559, patches 292, 675) In-Reply-To: <6263B5BBA63290489CB4C87738402CCC07FAED1B@usilms22.ca.com> References: <6263B5BBA63290489CB4C87738402CCC07FAED1B@usilms22.ca.com> Message-ID: <4238AE76.7040402@ldb-jab.org> Do not be deceived by the 3.6p1 by RH? They backport everything and thus 3.6p1 is most likely update with OpenSSH current. Also, recently, RH decided to fork their own SSH from the openSSH code. Someone correct me if I am wrong. I cannot accuraately speak to suse's situation ... LDB Vandor, Steven A wrote: >Do you know if either of the patches referenced above can be applied to the 3.6p1 code shipped by Red Hat (RHEL3) and Suse (SLES8)? It appears they were integrated in the 3.7p1 and 3.9p1 releases, respectively. >Steven Vandor >Computer Associates >425 825 2799 >vandor at ca.com >This message may contain confidential, privileged or other legally protected information. It is intended for the addressee only. If you aren't the addressee (or someone authorized by the addressee to receive this message), you are prohibited from copying, distributing, or otherwise using it. Please notify the sender and return it at our cost. Thank you. > > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > From Peter_Losher at isc.org Thu Mar 17 12:11:08 2005 From: Peter_Losher at isc.org (Peter Losher) Date: Wed, 16 Mar 2005 17:11:08 -0800 Subject: OpenSSH 4.0 released In-Reply-To: <200503090954.j299sDng029163@cvs.openbsd.org> References: <200503090954.j299sDng029163@cvs.openbsd.org> Message-ID: <4238D92C.3080402@isc.org> Damien Miller wrote: > * Improve account and password expiry support in sshd(8). Ther server > will now warn in advance for both account and password expiry. Curious - does this include Krb5/GSSAPI support? I'd like to expire passwords at regular intervals, but SSH was my main roadblock since password would expire with no notice... (I assume it would only warn you, and not let you change expired passwords) Kudos to the OpenSSH folks for 4.0... :) Best Wishes - Peter -- Peter_Losher at isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050316/6c2a7aa4/attachment.bin From dtucker at zip.com.au Thu Mar 17 15:03:13 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 17 Mar 2005 15:03:13 +1100 Subject: OpenSSH 4.0 released In-Reply-To: <4238D92C.3080402@isc.org> References: <200503090954.j299sDng029163@cvs.openbsd.org> <4238D92C.3080402@isc.org> Message-ID: <42390181.8020402@zip.com.au> Peter Losher wrote: > Damien Miller wrote: > >> * Improve account and password expiry support in sshd(8). Ther server >> will now warn in advance for both account and password expiry. > > Curious - does this include Krb5/GSSAPI support? That entry was specific to BSD auth. > I'd like to expire > passwords at regular intervals, but SSH was my main roadblock since > password would expire with no notice... (I assume it would only warn > you, and not let you change expired passwords) For BSD auth, it already forced you to change an expired password, that change was to give advance warning. In Portable, warning and forced change of expired password already worked with many systems (PAM, AIX, platforms with /etc/shadow). If you're using a Kerberos PAM module that is reported to work too (with some limitations when working with public-key authentication). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From senthilkumar_sen at hotpop.com Thu Mar 17 19:49:06 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Thu, 17 Mar 2005 14:19:06 +0530 Subject: openssh-3.8.1p1, with pthreads enabled, hung in pthread_join. References: <4237A010.1080004@zip.com.au> Message-ID: <30c201c52ace$3178d840$220110ac@sekco> Hi All, I am also facing the same situation here but only when Privilegeseparation is disabled. Smith wrote: >If i attempt this with privilege separation turned on the lowered privilege >process will exit and become a zombie, as the original process never exits. This is not happening to me. Darren wrote: >Maybe pthread_cancel doesn't interrupt the read() syscall? I think the problem lies in the target threads cancelability state. This may make the requests pending. Any ideas? Thanks, Senthil kumar. ----- Original Message ----- From: "Darren Tucker" To: "Nick Lane-Smith" Cc: Sent: Wednesday, March 16, 2005 8:25 AM Subject: Re: openssh-3.8.1p1, with pthreads enabled, hung in pthread_join. > First, if you're building with USE_POSIX_THREADS then that's an > unsupported configuration. > > Nick Lane-Smith wrote: >> I connect to my OpenSSH 3.8.1p1 server and when the password dialog shoes >> up I wait a min or so, long enough for the "Timeout before authentication >> for %s" alarm to trigger. If at that point I enter my password ssh will >> just sit there: >> >> debug2: input_userauth_info_req >> debug2: input_userauth_info_req: num_prompts 1 >> Password: >> debug3: packet_send2: adding 32 (len 18 padlen 14 extra_pad 64) >> >> And the sshd will be in this state: >> >> Attaching to program: `/private/tmp/OpenSSH.roots/OpenSSH~obj/sshd', >> process 26589. >> Reading symbols for shared libraries ...................... done >> 0x9002cf88 in semaphore_wait_trap () >> (gdb) bt >> #0 0x9002cf88 in semaphore_wait_trap () >> #1 0x9006153c in pthread_join () >> #2 0x00028a50 in sshpam_thread_cleanup () at >> /tmp/OpenSSH.roots/OpenSSH/openssh/auth-pam.c:417 > > That line is immediately preceded by: > > pthread_cancel(ctxt->pam_thread); > > Maybe pthread_cancel doesn't interrupt the read() syscall? I don't know > anything about your thread implementation. > >> Shouldn't the sshpam/read thread have an alarm set so if the >> authentication times out it will exit cleanly? > > It shouldn't be necessary (and it's a potential source of races). > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From lpeca at csc.com Fri Mar 18 12:05:04 2005 From: lpeca at csc.com (Lou C Peca) Date: Thu, 17 Mar 2005 19:05:04 -0600 Subject: OpenSSH and CVS Message-ID: With the CVS server in a DMZ. Using OpenSSH on the server and the JRcraft client plugin. What ports need to be allowed for proper operation? How do you prevent non- secure pserver access to the cvs server? Thanks Lou ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- From dtucker at zip.com.au Fri Mar 18 14:50:39 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 18 Mar 2005 14:50:39 +1100 Subject: OpenSSH and CVS In-Reply-To: References: Message-ID: <423A500F.9010902@zip.com.au> Lou C Peca wrote: > This is a PRIVATE message. If you are not the intended recipient Please don't send private messages to a public list. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From htodd at twofifty.com Fri Mar 18 16:00:06 2005 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Thu, 17 Mar 2005 21:00:06 -0800 (PST) Subject: OpenSSH and CVS In-Reply-To: <423A500F.9010902@zip.com.au> References: <423A500F.9010902@zip.com.au> Message-ID: On Fri, 18 Mar 2005, Darren Tucker wrote: > Lou C Peca wrote: >> This is a PRIVATE message. If you are not the intended recipient > > Please don't send private messages to a public list. Darren, you should know better. Some of us have jobs where we're required to put those stupid messages on our email. It's not polite to point and laugh at us poor schlubs whose lives are run by lawyers. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte From mstone at mathom.us Fri Mar 18 22:19:18 2005 From: mstone at mathom.us (Michael Stone) Date: Fri, 18 Mar 2005 06:19:18 -0500 Subject: OpenSSH and CVS In-Reply-To: References: <423A500F.9010902@zip.com.au> Message-ID: <20050318111918.GV19692@mathom.us> On Thu, Mar 17, 2005 at 09:00:06PM -0800, you wrote: >Darren, you should know better. Some of us have jobs where we're >required to put those stupid messages on our email. It's not polite to >point and laugh at us poor schlubs whose lives are run by lawyers. Sure it is. Otherwise people might start to think that the nonsensical isn't. If every message sent from your employer's email system is private, maybe you should use gmail or somesuch for mailing list traffic. Mike Stone From anders.liljegren at its.uu.se Sat Mar 19 00:43:31 2005 From: anders.liljegren at its.uu.se (Anders Liljegren) Date: Fri, 18 Mar 2005 14:43:31 +0100 Subject: Setauthdb defined twice in openssh-4.0p1 on AIX 5.3 Message-ID: When compiling openssh-4.0p1 under AIX 5.3 ML01 using gcc 3.4.3 I get the following error: > (cd openbsd-compat && make) > make[1]: Entering directory > `/usr/local/src/openssh-4.0p1/openbsd-compat' > gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I.. -I. > -I./.. -I/usr/local/ssl/include -DHAVE_CONFIG_H -c bsd-arc4random.c > In file included from ../openbsd-compat/openbsd-compat.h:171, > from ../includes.h:199, > from bsd-arc4random.c:17: > ../openbsd-compat/port-aix.h:50: error: conflicting types for > 'setauthdb' > /usr/include/usersec.h:590: error: previous declaration of 'setauthdb' > was here > ../openbsd-compat/port-aix.h:50: error: conflicting types for > 'setauthdb' > /usr/include/usersec.h:590: error: previous declaration of 'setauthdb' > was here > make[1]: *** [bsd-arc4random.o] Error 1 > make[1]: Leaving directory > `/usr/local/src/openssh-4.0p1/openbsd-compat' > make: *** [openbsd-compat/libopenbsd-compat.a] Error 2 When compiling openssh-3.9p1 in exactly the same way I don't get this error. After applying the following simplistic patch I can compile 4.0p1 without a problem: > *** openbsd-compat/port-aix.h.orig Fri Mar 18 14:20:28 2005 > --- openbsd-compat/port-aix.h Fri Mar 18 14:21:16 2005 > *************** > *** 47,53 **** > > /* These should be in the system headers but are not. */ > int usrinfo(int, char *, int); > ! int setauthdb(const char *, char *); > /* these may or may not be in the headers depending on the version */ > #if (HAVE_DECL_AUTHENTICATE == 0) > int authenticate(char *, char *, int *, char **); > --- 47,53 ---- > > /* These should be in the system headers but are not. */ > int usrinfo(int, char *, int); > ! /*int setauthdb(const char *, char *);*/ > /* these may or may not be in the headers depending on the version */ > #if (HAVE_DECL_AUTHENTICATE == 0) > int authenticate(char *, char *, int *, char **); I guess this really should be done in a smarter way using a test. -- Anders Liljegren Mail: IT-st?d, Uppsala universitet Phone: +46 18 4717751 Box 887 mailto:anders.liljegren at its.uu.se SE-751 08 UPPSALA http://www.anst.uu.se/andelilj Sweden From htodd at twofifty.com Sat Mar 19 02:59:09 2005 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 18 Mar 2005 07:59:09 -0800 (PST) Subject: OpenSSH and CVS In-Reply-To: <20050318111918.GV19692@mathom.us> References: <423A500F.9010902@zip.com.au> <20050318111918.GV19692@mathom.us> Message-ID: On Fri, 18 Mar 2005, Michael Stone wrote: > On Thu, Mar 17, 2005 at 09:00:06PM -0800, you wrote: >> Darren, you should know better. Some of us have jobs where we're >> required to put those stupid messages on our email. It's not polite to >> point and laugh at us poor schlubs whose lives are run by lawyers. > > Sure it is. Otherwise people might start to think that the nonsensical > isn't. If every message sent from your employer's email system is > private, maybe you should use gmail or somesuch for mailing list > traffic. I'm at home now, but some workplaces forbid the use of gmail, etc (think Wall Street). And sending the email home once and then to the list just creates more trouble. I don't know why people can't ignore the stupid messages. I sure didn't choose to add it to all my work mail. I'm just REQUIRED to use it. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte From mstone at mathom.us Sat Mar 19 03:28:57 2005 From: mstone at mathom.us (Michael Stone) Date: Fri, 18 Mar 2005 11:28:57 -0500 Subject: OpenSSH and CVS In-Reply-To: References: <423A500F.9010902@zip.com.au> <20050318111918.GV19692@mathom.us> Message-ID: <20050318162856.GW19692@mathom.us> On Fri, Mar 18, 2005 at 07:59:09AM -0800, Hisashi T Fujinaka wrote: >I don't know why people can't ignore the stupid messages. I sure didn't >choose to add it to all my work mail. I'm just REQUIRED to use it. I'm not, of course, a lawyer, but I can't help but think that it would be hard to enforce any conditions of a disclaimer if representatives of the company tell people to ignore it. Mike Stone From htodd at twofifty.com Sat Mar 19 04:30:17 2005 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Fri, 18 Mar 2005 09:30:17 -0800 (PST) Subject: OpenSSH and CVS In-Reply-To: <20050318162856.GW19692@mathom.us> References: <423A500F.9010902@zip.com.au> <20050318111918.GV19692@mathom.us> <20050318162856.GW19692@mathom.us> Message-ID: On Fri, 18 Mar 2005, Michael Stone wrote: > On Fri, Mar 18, 2005 at 07:59:09AM -0800, Hisashi T Fujinaka wrote: >> I don't know why people can't ignore the stupid messages. I sure didn't >> choose to add it to all my work mail. I'm just REQUIRED to use it. > > I'm not, of course, a lawyer, but I can't help but think that it would > be hard to enforce any conditions of a disclaimer if representatives of > the company tell people to ignore it. I want to keep my job, I have to leave it in. It has no legal meaning. I have to leave it in to keep my job. If you would like, I can repeat that last sentence several times so it sinks in. My job sucks, but so does the economy. -- Hisashi T Fujinaka - htodd at twofifty.com BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte From dtucker at zip.com.au Sat Mar 19 09:33:27 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 19 Mar 2005 09:33:27 +1100 Subject: Setauthdb defined twice in openssh-4.0p1 on AIX 5.3 In-Reply-To: References: Message-ID: <423B5737.7090604@zip.com.au> Anders Liljegren wrote: > When compiling openssh-4.0p1 under AIX 5.3 ML01 using gcc 3.4.3 I get > the following error: [setauthdb conflicting definitions] > I guess this really should be done in a smarter way using a test. Yes it should. Please try this patch. You will need to rebuild configure by running "autoreconf" then run ./configure again. If you don't have autoconf handy I have uploaded the rebuilt configure to http://www.zip.com.au/~dtucker/tmp/configure-setauthdb.gz, just download, decompress and rename to "configure". -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-aix-setauthdb.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050319/774bf25d/attachment.ksh From bob at proulx.com Sun Mar 20 06:18:37 2005 From: bob at proulx.com (Bob Proulx) Date: Sat, 19 Mar 2005 12:18:37 -0700 Subject: OpenSSH and CVS In-Reply-To: References: <423A500F.9010902@zip.com.au> <20050318111918.GV19692@mathom.us> Message-ID: <20050319191837.GE7675@dementia.proulx.com> Hisashi T Fujinaka wrote: > I'm at home now, but some workplaces forbid the use of gmail, etc (think > Wall Street). And sending the email home once and then to the list just > creates more trouble. If you employer forbids you to use external email while on the job then you have two choices. 1) Do as your employer demands of you. Do not use external email. But also do not post with an email disclaimer and do not get outside help for your problems. 2) Ignore your employer. Use external email. Interact with the world. Run the risk of being terminated for disregarding employer rules. > I don't know why people can't ignore the stupid messages. I sure didn't > choose to add it to all my work mail. I'm just REQUIRED to use it. I feel sorry for you. But that does not in any way change the fact that you are still sending mail marked with a private message disclaimer. Don't do that or find alternatives. Let's put this another way. Let's say I have a job where my employer requires me to avoid washing. No one can understand it. It makes no sense. It is a stupid rule. I smell with body odor. People around me complain that my smell offends them. I tell them that my employer requires me to avoid washing. And in a later message in the thread: > I want to keep my job, I have to leave it in. It has no legal meaning. I > have to leave it in to keep my job. > > If you would like, I can repeat that last sentence several times so it > sinks in. My job sucks, but so does the economy. But you have an alternative. You are using it now. Interact with the outside world on your own time outside of your job. Your job cannot require you to be a bad citizen in the global community. If you employer does require you to interact with others on the Internet then you now have justification for your employer to use external email on the job. Bob From Jefferson.Ogata at noaa.gov Sun Mar 20 06:55:36 2005 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sat, 19 Mar 2005 14:55:36 -0500 Subject: OpenSSH and CVS In-Reply-To: <20050319191837.GE7675@dementia.proulx.com> References: <423A500F.9010902@zip.com.au> <20050318111918.GV19692@mathom.us> <20050319191837.GE7675@dementia.proulx.com> Message-ID: <423C83B8.1060702@noaa.gov> It's pretty sad when a list stops being about its purported subject and people start pontificating wildly about irrelevant nonsense. Christ, who gives a flying fsck if the guy has a weird disclaimer on his email? In what conceivable way does that affect anyone here? Can't you just pretend it's another one of those "clever" .signatures and ignore it already? No, please don't bother to answer. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From rz1a at nwgsm.ru Sun Mar 20 21:00:39 2005 From: rz1a at nwgsm.ru (rz1a at nwgsm.ru) Date: Sun, 20 Mar 2005 13:00:39 +0300 Subject: OpenSSH and a "handicaped" flavour of UNIX. Message-ID: <411005713.20050320130039@nwgsm.ru> Hello, list! Instead of reading about someone's signatures, may I ask again whether I have any chance to compile OpenSSH package with a toolchain lacking the int64 support (such as Watcom v10.6 on QNX4)? I'd like to be able to compile as many modules as do not depend on int64. (Currently I do not need SFTP that bad, the SSH is enough for me) -- Best regards, Anthony mailto:rz1a at mail.ru From rz1a at nwgsm.ru Sun Mar 20 21:24:46 2005 From: rz1a at nwgsm.ru (rz1a at nwgsm.ru) Date: Sun, 20 Mar 2005 13:24:46 +0300 Subject: OpenSSH and a "handicaped" flavour of UNIX. In-Reply-To: <423D4E7D.1060506@zip.com.au> References: <411005713.20050320130039@nwgsm.ru> <423D4E7D.1060506@zip.com.au> Message-ID: <782172801.20050320132446@nwgsm.ru> Hello Darren, Sunday, March 20, 2005, 1:20:45 PM, you wrote: DT> Don't feel offended about the lack of response; half the team is either DT> away or otherwise occupied so we can't even discuss it yet. :) I was "offended" with that off-topic. PS I was asking to benchmark GMP v4.1.4 against BigNum from OpenSSL - nearly all the tests were ~2~3 times quicker on GMP. Will OpenSSH use GMP ever again? -- Best regards, Anthony mailto:rz1a at nwgsm.ru From nlarsch at gmx.net Sun Mar 20 22:17:37 2005 From: nlarsch at gmx.net (Nils Larsch) Date: Sun, 20 Mar 2005 12:17:37 +0100 Subject: OpenSSH and a "handicaped" flavour of UNIX. In-Reply-To: <782172801.20050320132446@nwgsm.ru> References: <411005713.20050320130039@nwgsm.ru> <423D4E7D.1060506@zip.com.au> <782172801.20050320132446@nwgsm.ru> Message-ID: <423D5BD1.1060303@gmx.net> rz1a at nwgsm.ru wrote: > Hello Darren, > > Sunday, March 20, 2005, 1:20:45 PM, you wrote: > DT> Don't feel offended about the lack of response; half the team is either > DT> away or otherwise occupied so we can't even discuss it yet. > :) > I was "offended" with that off-topic. > > PS > I was asking to benchmark GMP v4.1.4 against BigNum from OpenSSL - > nearly all the tests were ~2~3 times quicker on GMP. > Will OpenSSH use GMP ever again? btw: afaik there's a gmp engine for openssl ;-) Nils From rapier at psc.edu Mon Mar 21 01:59:29 2005 From: rapier at psc.edu (Chris Rapier) Date: Sun, 20 Mar 2005 09:59:29 -0500 Subject: OpenSSH and CVS In-Reply-To: <20050319191837.GE7675@dementia.proulx.com> References: <423A500F.9010902@zip.com.au> <20050318111918.GV19692@mathom.us> <20050319191837.GE7675@dementia.proulx.com> Message-ID: <423D8FD1.4030008@psc.edu> Do ya'll think you can leave the guy alone? This is just a really pointless thing to have a discussion about on a software development list. Bob Proulx wrote: > Hisashi T Fujinaka wrote: > >>I'm at home now, but some workplaces forbid the use of gmail, etc (think >>Wall Street). And sending the email home once and then to the list just >>creates more trouble. > > > If you employer forbids you to use external email while on the job > then you have two choices. 1) Do as your employer demands of you. Do > not use external email. But also do not post with an email disclaimer > and do not get outside help for your problems. 2) Ignore your > employer. Use external email. Interact with the world. Run the risk > of being terminated for disregarding employer rules. > > >>I don't know why people can't ignore the stupid messages. I sure didn't >>choose to add it to all my work mail. I'm just REQUIRED to use it. > > > I feel sorry for you. But that does not in any way change the fact > that you are still sending mail marked with a private message > disclaimer. Don't do that or find alternatives. > > Let's put this another way. Let's say I have a job where my employer > requires me to avoid washing. No one can understand it. It makes no > sense. It is a stupid rule. I smell with body odor. People around > me complain that my smell offends them. I tell them that my employer > requires me to avoid washing. > > And in a later message in the thread: > >>I want to keep my job, I have to leave it in. It has no legal meaning. I >>have to leave it in to keep my job. >> >>If you would like, I can repeat that last sentence several times so it >>sinks in. My job sucks, but so does the economy. > > > But you have an alternative. You are using it now. Interact with the > outside world on your own time outside of your job. Your job cannot > require you to be a bad citizen in the global community. If you > employer does require you to interact with others on the Internet then > you now have justification for your employer to use external email on > the job. > > Bob > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From tim at multitalents.net Mon Mar 21 08:07:05 2005 From: tim at multitalents.net (Tim Rice) Date: Sun, 20 Mar 2005 13:07:05 -0800 (PST) Subject: OpenSSH and a "handicaped" flavour of UNIX. In-Reply-To: <411005713.20050320130039@nwgsm.ru> References: <411005713.20050320130039@nwgsm.ru> Message-ID: On Sun, 20 Mar 2005 rz1a at nwgsm.ru wrote: > Hello, list! > > Instead of reading about someone's signatures, may I ask again > whether I have any chance to compile OpenSSH package with a > toolchain lacking the int64 support (such as Watcom v10.6 on QNX4)? > > I'd like to be able to compile as many modules as do not depend on > int64. (Currently I do not need SFTP that bad, the SSH is enough for > me) If you go back far enough, OpenSSH will compile everything except sftpd on compilers without int64 support. Look at versions that came out prior to Mar 21 2003 -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From lucio at sulweb.org Tue Mar 22 01:31:13 2005 From: lucio at sulweb.org (Lucio Crusca) Date: Mon, 21 Mar 2005 15:31:13 +0100 Subject: Port 0 forwarding In-Reply-To: <200503151710.02507.lucio@sulweb.org> References: <200503151710.02507.lucio@sulweb.org> Message-ID: <200503211531.14011.lucio@sulweb.org> I wrote: > Here is the patch [...] But, how long does it take for a patch to be applied/rejected? I'd like to know if the patch is ok or not, and, if not, what went wrong with it, so that I can fix it and move ahead with the next one (which depends on my first patch being included in CVS). From piotr at hoop.pl Tue Mar 22 01:52:05 2005 From: piotr at hoop.pl (Piotr Kapczuk) Date: Mon, 21 Mar 2005 15:52:05 +0100 Subject: Why not to read environment before do_pwchange() ? Message-ID: <7219972949.20050321155205@hoop.pl> Hi I use OpenSSH 3.8.1p1 on AIX 5.2 ML05. (compiled from source, not IBM's package). On one of my hosts users use it solely for password changes. Default user shell is /usr/bin/passwd. After one logs in, environment is set per user (/etc/security/environ, ~/.ssh/environment) LANG is set to pl_PL passwd is "aware" of the environment and system talks to user in Polish. That's what I want. Problem occurres when password expires. User is forced to change password. From now on passwd talks in system's default $LANG, which is English. I've found the cause of such behavior in session.c Function do_child() invokes do_pwchange() at the beginning, before everything else. (4.0p1 session.c line 1445) Environment is read later by do_setup_env() - when setting $SHELL (line 1496) When /usr/bin/passwd is executed by do_pwchange() it doesn't know environment and uses default from /etc/environment. The solution is to read user environment before forcing password change. Is this appropriate place for asking for a fix ? PS. I know there's IBM's OpenSSH port with NLS patches. Unfortunately it's old :| I'm not subscribed to the list so please CC me when replaying. -- Regards Piotr Kapczuk _________________________________________________________ "Decisions are good, but good decisions are better." From rant at radvision.com Tue Mar 22 03:14:42 2005 From: rant at radvision.com (Ran Tidhar) Date: Mon, 21 Mar 2005 18:14:42 +0200 Subject: openSSH for VxWorks Message-ID: hello. i am interested in porting the openSSH to VxWorks. 1) is there a free port that has been done for this OS ? 2) can you assess what is the effort required to perfrom such a task ? 3) what would be the expected footprint of the code ? best regards Ran Tidhar From rz1a at nwgsm.ru Tue Mar 22 05:26:23 2005 From: rz1a at nwgsm.ru (rz1a at nwgsm.ru) Date: Mon, 21 Mar 2005 21:26:23 +0300 Subject: no-pty option. Message-ID: <1529859962.20050321212623@nwgsm.ru> Hello list! Not sure if this is a proper list to ask and it's not strictly OpenSSH related. I put the "no-pty" option on a key and try to login with it. As it should be - the shell access is denyed. However, I get an unrestricted access if I execute a command like this: $ ssh user at server /bin/sh I get the shell that just has no prompt but works as usual. All this badness happens to me on QNX4 and SSH.com's ssh-1.2.33. Now the question: How does it happen on other UNIXes? What would you suggest - is it a port's fault or a OS's "specifics"? Anthony. From rz1a at nwgsm.ru Tue Mar 22 05:26:33 2005 From: rz1a at nwgsm.ru (rz1a at nwgsm.ru) Date: Mon, 21 Mar 2005 21:26:33 +0300 Subject: ssh-agent: How to use it properly? Message-ID: <7110575730.20050321212633@nwgsm.ru> Hello list, Again not sure if this is a right place to ask. I read the "Snail book" (SSH, The secure shell. The definitive guide. 1st ed.) and try to figure out whether I need a copy of the ssh-agent running on a host through which I try connect further. The Snail book recommends running the ssh-agent on the remote host always if the TTY is allocated (i.e. I not just remote-execute a command there). My feel is that I need an agent only if I'm on /dev/con not on /dev/tty, i.e. logged-in locally. Please comment. -- Best regards, Anthony From deraadt at cvs.openbsd.org Tue Mar 22 05:37:02 2005 From: deraadt at cvs.openbsd.org (Theo de Raadt) Date: Mon, 21 Mar 2005 11:37:02 -0700 Subject: Openssh 3.9p1 query - TOP URGENT. In-Reply-To: Your message of "Mon, 21 Mar 2005 17:10:39 +0530." <1BD922A62552D411B48A00D0B74723752058DA0F@kecmsg04.ad.infosys.com> Message-ID: <200503211837.j2LIb2rr007578@cvs.openbsd.org> I believe the messages are more than self-explanatory. Do not mail openssh at openssh.com for issues like this. > I am upgrading my openSSH 3.7.1p1 to 3.9p1 in solaris 8 > system. During the ./configure step, the output shows the following > WARNING messages. Could you please shed some light on what these > messages are and how it impacts the running environment. > Earliest reply is most appreciated. Thanks in advance, > =20 > SVR4 style packages are supported with "make package"\n > WARNING: you are using the builtin random number collection > service. Please read WARNING.RNG and request that your OS > vendor includes kernel-based random number collection in > future versions of your OS. > =20 > WARNING: the operating system that you are using does not > appear to support either the getpeereid() API nor the > SO_PEERCRED getsockopt() option. These facilities are used to > enforce security checks to prevent unauthorised connections to > ssh-agent. Their absence increases the risk that a malicious > user can connect to your agent. > =20 > Regards > Sankar G. From dtucker at zip.com.au Tue Mar 22 07:00:14 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 22 Mar 2005 07:00:14 +1100 Subject: no-pty option. In-Reply-To: <1529859962.20050321212623@nwgsm.ru> References: <1529859962.20050321212623@nwgsm.ru> Message-ID: <423F27CE.4090105@zip.com.au> rz1a at nwgsm.ru wrote: > Not sure if this is a proper list to ask and it's not strictly > OpenSSH related. > > I put the "no-pty" option on a key and try to login with it. As it > should be - the shell access is denyed. > > However, I get an unrestricted access if I execute a command like > this: > $ ssh user at server /bin/sh > > I get the shell that just has no prompt but works as usual. What you have there is a regular interactive shell without a controlling terminal. Things requiring a controlling terminal won't work but pretty much everything else will. > All this badness happens to me on QNX4 and SSH.com's ssh-1.2.33. > > Now the question: > How does it happen on other UNIXes? Typically the same thing happens. > What would you suggest - is it a port's fault or a OS's "specifics"? If you need to prevent users running certain commands (like /bin/sh) you'll need a restricted shell or similar. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From guyverdh at mchsi.com Tue Mar 22 07:31:50 2005 From: guyverdh at mchsi.com (guyverdh at mchsi.com) Date: Mon, 21 Mar 2005 20:31:50 +0000 Subject: Solaris 10 support Message-ID: <032120052031.22981.423F2F35000B3D59000059C52197913363080B9D0A90979A09@mchsi.com> Couple of things. #1 - ISO Images of Solaris 10 can be downloaded for free from www.sun.com - for x86 and Sparc platforms. No need for a media kit. You're on your own on finding a hard drive. #2 - Out of the box, using the Sun supplied opensource software contained in /usr/sfw for compiling, breaks down during the "make" process. PATH=/usr/sfw/bin:/usr/bin:/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin export CFLAGS="-O3" ./configure --with-pam --disable-suid-ssh --without-rsh --with-default-path=/usr/bin:/bin:/usr/sbin:/sbin:/usr/sfw/bin:/usr/local/bin:/usr/local/sbin returns OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/sfw/bin:/usr/local/bin:/usr/local/sbin (If PATH is set in /etc/default/login it will be used instead. If used, ensure the path to scp is present, otherwise scp will not work.) Manpage format: man PAM support: yes KerberosV support: no Smartcard support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no libedit support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: sparc-sun-solaris2.10 Compiler: gcc Compiler flags: -O3 -Wall -Wpointer-arith -Wno-uninitialized Preprocessor flags: Linker flags: Libraries: -lpam -ldl -lresolv -lcrypto -lrt -lz -lsocket -lnsl SVR4 style packages are supported with "make package" PAM is enabled. You may need to install a PAM control file for sshd, otherwise password authentication may fail. Example PAM control files can be found in the contrib/ subdirectory WARNING: the operating system that you are using does not appear to support either the getpeereid() API nor the SO_PEERCRED getsockopt() option. These facilities are used to enforce security checks to prevent unauthorised connections to ssh-agent. Their absence increases the risk that a malicious user can connect to your agent. $ gmake gets to this point and dies gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lresolv -lcrypto -lrt -lz -lsocket -lnsl Undefined first referenced symbol in file EVP_aes_192_cbc ./libssh.a(cipher.o) EVP_aes_256_cbc ./libssh.a(cipher.o) ld: fatal: Symbol referencing errors. No output written to ssh collect2: ld returned 1 exit status gmake: *** [ssh] Error 1 It's probably a simple library pathing issue, just haven't had time to dig into it at this time. From dtucker at zip.com.au Tue Mar 22 11:17:39 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 22 Mar 2005 11:17:39 +1100 Subject: Solaris 10 support In-Reply-To: <032120052031.22981.423F2F35000B3D59000059C52197913363080B9D0A90979A09@mchsi.com> References: <032120052031.22981.423F2F35000B3D59000059C52197913363080B9D0A90979A09@mchsi.com> Message-ID: <423F6423.9040102@zip.com.au> guyverdh at mchsi.com wrote: > gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o > sshconnect2.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lresolv -lcrypto > -lrt -lz -lsocket -lnsl > Undefined first referenced > symbol in file > EVP_aes_192_cbc ./libssh.a(cipher.o) > EVP_aes_256_cbc ./libssh.a(cipher.o) > ld: fatal: Symbol referencing errors. No output written to ssh > collect2: ld returned 1 exit status > gmake: *** [ssh] Error 1 It looks like the Sun-supplied OpenSSL (which I believe is modified?) does not have the 192-bit and 256-bit AES functions. Does it work with the vanilla OpenSSL distribution? (Possibly you will have to "configure --with-ssl-dir=/usr/local/ssl"). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From carl at bl.echidna.id.au Tue Mar 22 11:38:18 2005 From: carl at bl.echidna.id.au (Carl Brewer) Date: Tue, 22 Mar 2005 11:38:18 +1100 Subject: Solaris 10 support In-Reply-To: <423F6423.9040102@zip.com.au> References: <032120052031.22981.423F2F35000B3D59000059C52197913363080B9D0A90979A09@mchsi.com> <423F6423.9040102@zip.com.au> Message-ID: <423F68FA.4050405@bl.echidna.id.au> Darren Tucker wrote: > guyverdh at mchsi.com wrote: > >> gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o >> sshconnect1.o >> sshconnect2.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lresolv >> -lcrypto >> -lrt -lz -lsocket -lnsl >> Undefined first referenced >> symbol in file >> EVP_aes_192_cbc ./libssh.a(cipher.o) >> EVP_aes_256_cbc ./libssh.a(cipher.o) >> ld: fatal: Symbol referencing errors. No output written to ssh >> collect2: ld returned 1 exit status >> gmake: *** [ssh] Error 1 > > > It looks like the Sun-supplied OpenSSL (which I believe is modified?) > does not have the 192-bit and 256-bit AES functions. Does it work with > the vanilla OpenSSL distribution? (Possibly you will have to "configure > --with-ssl-dir=/usr/local/ssl"). That can bite you when you build apache2 with SSL as well (just for the record :) ) From stuge-openssh-unix-dev at cdy.org Tue Mar 22 13:48:33 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 22 Mar 2005 03:48:33 +0100 Subject: ssh-agent: How to use it properly? In-Reply-To: <7110575730.20050321212633@nwgsm.ru> References: <7110575730.20050321212633@nwgsm.ru> Message-ID: <20050322024833.GA31001@foo.birdnet.se> On Mon, Mar 21, 2005 at 09:26:33PM +0300, rz1a at nwgsm.ru wrote: > The Snail book recommends running the ssh-agent on the remote host > always if the TTY is allocated (i.e. I not just remote-execute a > command there). > > My feel is that I need an agent only if I'm on /dev/con not on > /dev/tty, i.e. logged-in locally. Technicalities such as PTY or console aren't as important as whether you trust the system or not. As you probably know from the book, the agent will be able to use your private key. I suggest that you run the agent on a system that you are comfortable with running it on, keeping that in mind. The agent mechanism has a great benefit over regular key authentication, in that the agent connection can be forwarded over the network if you're always using SSH. A forwarded agent socket will also mean access to use of the private key. Some like to use -c when ssh-add:ing their key to the agent, to confirm each use of the key. That of course requires the agent to run somewhere it can communicate with you.. //Peter From robvdwal at sara.nl Tue Mar 22 22:40:42 2005 From: robvdwal at sara.nl (Rob v.d. Wal) Date: Tue, 22 Mar 2005 12:40:42 +0100 Subject: Segmentation fault in buffer_append_space for AIX 5.3 for openssh-4.0p1 Message-ID: <20050322124042.4fc319a4.robvdwal@sara.nl> For AIX 53 ML01 I'm getting a "Segmentation fault in buffer_append_space at line 85 in file buffer.c" in sshd after typing my password for a new connection to the AIX 5.3 host. Line 85 is "if (buffer->offset == buffer->end) {". Is this caused by an old bug in buffer_append_space? Regards Rob v.d. Wal From rz1a at nwgsm.ru Fri Mar 25 01:03:20 2005 From: rz1a at nwgsm.ru (rz1a at nwgsm.ru) Date: Thu, 24 Mar 2005 17:03:20 +0300 Subject: "ssh user@server /bin/sh" vs "no-pty" option. Message-ID: <36223088.20050324170320@nwgsm.ru> Hello List, Do I get it right that I *MUST* chroot a user first and make /bin/rssh his shell in the /etc/passwd to effectively restrict him? There should be no /bin/ksh (or bash) in his jail? If I do not jail him - no matter what is his passwd shell - he will be able to issue "ssh user at server /bin/sh" still, right? -- Best regards, Anthony mailto:rz1a at nwgsm.ru From dtucker at zip.com.au Wed Mar 23 11:09:43 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 23 Mar 2005 11:09:43 +1100 Subject: Segmentation fault in buffer_append_space for AIX 5.3 for openssh-4.0p1 In-Reply-To: <20050322124042.4fc319a4.robvdwal@sara.nl> References: <20050322124042.4fc319a4.robvdwal@sara.nl> Message-ID: <4240B3C7.9090009@zip.com.au> Rob v.d. Wal wrote: > For AIX 53 ML01 I'm getting a "Segmentation fault in > buffer_append_space at line 85 in file buffer.c" in sshd after typing > my password for a new connection to the AIX 5.3 host. Line 85 is "if > (buffer->offset == buffer->end) {". It's not a known problem, and I've not seen it on any other version of AIX (but I don't have access to 5.3). It's also an odd place for a segfault. What compiler are you using? I've seen weird segfaults from binaries compiled with the gcc-2.9x IBM used to ship on the gnu tools cds. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Wed Mar 23 11:20:03 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 23 Mar 2005 11:20:03 +1100 Subject: Solaris 10 support In-Reply-To: <032220051944.13230.424075B300006A68000033AE2197912995080B9D0A90979A09@mchsi.com> References: <032220051944.13230.424075B300006A68000033AE2197912995080B9D0A90979A09@mchsi.com> Message-ID: <4240B633.3010903@zip.com.au> guyverdh at mchsi.com wrote: > The regression tests fail due to issues with the location of the ssh-rand-helper. > I ran the install then, and it went fine, and the binary works. ssh-rand-helper is only needed because /dev/*random on Solaris are symlinks and OpenSSL opens them with O_NOFOLLOW, which fails. This is a bug in OpenSSL which has already been fixed but which has not yet made it to a release. (There's a bug report and patch somewhere in OpenSSL's bug tracker, and it was mentioned a while back here on openssh-unix-dev too). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rz1a at nwgsm.ru Fri Mar 25 01:07:01 2005 From: rz1a at nwgsm.ru (rz1a at nwgsm.ru) Date: Thu, 24 Mar 2005 17:07:01 +0300 Subject: ssh-agent: How to use it properly? Message-ID: <1092192982.20050324170701@nwgsm.ru> Hello List, The "ssh-add -c" is not in the Snail book. Is it available in the newer OpenSSH versions only? Neither (SSH.com's) ssh-1.2.33 nor ssh-3.2.9.1 sport this switch. -- Best regards, Anthony mailto:rz1a at nwgsm.ru From frederik at a5.repetae.net Thu Mar 24 14:41:39 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Wed, 23 Mar 2005 19:41:39 -0800 Subject: caching In-Reply-To: <20050310031604.GA29384@a5.repetae.net> References: <20050310031604.GA29384@a5.repetae.net> Message-ID: <20050324034139.GA11181@a5.repetae.net> Also, terminal resizing doesn't seem to work through cached connections... More concisely: What is the status of the caching facilities? Is someone working on improving them? Frederik On Wed, Mar 09, 2005 at 07:16:04PM -0800, Frederik Eaton wrote: > I'm trying to use ssh's new connection caching facilities from a > wrapper script so that the caching is transparent to the user, i.e. a > socket for each destination is created in the user's ~/.ssh/ > directory. For the most part it works well, but I've been having some > trouble. > > Firstly, sometimes when I create a slave connection, it hangs when the > connection is created; slightly more often it hangs when I try to log > out. > > Secondly, it seems that X11 port forwarding isn't done for slave > connections. > > Have other people encountered these issues? If they are actual bugs, > are they being worked on? Does somebody have a wrapper script which > accomplishes the task I'm trying to accomplish (or is support for it > planned to be included in ssh - since it seems like the main reason > one would want caching in the first place)? Thanks, > > Frederik > > -- > http://ofb.net/~frederik/ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- http://ofb.net/~frederik/ From markus at openbsd.org Fri Mar 25 20:22:00 2005 From: markus at openbsd.org (Markus Friedl) Date: Fri, 25 Mar 2005 10:22:00 +0100 Subject: ssh-agent: How to use it properly? In-Reply-To: <1092192982.20050324170701@nwgsm.ru> References: <1092192982.20050324170701@nwgsm.ru> Message-ID: <20050325092200.GA11115@folly> All releases after January 2003 should support it (3.6 and later). On Thu, Mar 24, 2005 at 05:07:01PM +0300, rz1a at nwgsm.ru wrote: > > Hello List, > > The "ssh-add -c" is not in the Snail book. > Is it available in the newer OpenSSH versions only? > Neither (SSH.com's) ssh-1.2.33 nor ssh-3.2.9.1 sport this switch. > > -- > Best regards, > Anthony mailto:rz1a at nwgsm.ru > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From stuge-openssh-unix-dev at cdy.org Fri Mar 25 20:24:31 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 25 Mar 2005 10:24:31 +0100 Subject: ssh-agent: How to use it properly? In-Reply-To: <1092192982.20050324170701@nwgsm.ru> References: <1092192982.20050324170701@nwgsm.ru> Message-ID: <20050325092431.GC27116@foo.birdnet.se> Hi, On Thu, Mar 24, 2005 at 05:07:01PM +0300, rz1a at nwgsm.ru wrote: > > Hello List, > > The "ssh-add -c" is not in the Snail book. > Is it available in the newer OpenSSH versions only? > Neither (SSH.com's) ssh-1.2.33 nor ssh-3.2.9.1 sport this switch. That doesn't look like OpenSSH version numbers. This is the OpenSSH list, you know. :) -c was added to ssh-add.c v 1.65 Thu Jan 23 13:50:27 2003, which looks like some time right before OpenSSH 3.6. //Peter From guyverdh at mchsi.com Fri Mar 25 08:17:46 2005 From: guyverdh at mchsi.com (guyverdh at mchsi.com) Date: Thu, 24 Mar 2005 21:17:46 +0000 Subject: Solaris 10 support Message-ID: <032420052117.1620.42432E7A00049AFA000006542197913363080B9D0A90979A09@mchsi.com> Okay. Uninstalled OpenSSL 0.9.7e, re-compiled and installed OpenSSL 0.9.7f. Removed the copy of the ssh-rand-helper from /usr/local/libexec. gmake distclean re-ran config with appropriate params. re-ran gmake re-ran gmake tests - the bug regarding symbolic links appears to be fixed in new openssl release however, had some issues arise later in tests... run test multiplex.sh ... test connection multiplexing: envpass test connection multiplexing: transfer scp: failed copy /bin/ls cmp: cannot open /tech_svc/SSH/openssh-4.0p1/regress/ls.copy scp: corrupted copy of /bin/ls test connection multiplexing: status 0 test connection multiplexing: status 1 test connection multiplexing: status 4 test connection multiplexing: status 5 test connection multiplexing: status 44 Master running (pid=10834) Exit request sent. failed connection multiplexing gmake[1]: *** [t-exec] Error 1 gmake[1]: Leaving directory `/tech_svc/SSH/openssh-4.0p1/regress' gmake: *** [tests] Error 2 Noticed on the console that repeated messages were being sent to console from sshd daemon... copied from the /var/adm/syslog... Mar 24 15:02:43 srvname sshd[4368]: [ID 800047 auth.error] error: setsockopt SO_KEEPALIVE: Socket operation on non-socket Mar 24 15:02:46 srvname sshd[4400]: [ID 800047 auth.error] error: setsockopt SO_KEEPALIVE: Socket operation on non-socket Mar 24 15:02:47 srvname sshd[4402]: [ID 800047 auth.error] error: setsockopt SO_KEEPALIVE: Socket operation on non-socket So, there are still a few issues to resolve. Thanks, Larry From rz1a at nwgsm.ru Fri Mar 25 22:00:29 2005 From: rz1a at nwgsm.ru (rz1a at nwgsm.ru) Date: Fri, 25 Mar 2005 14:00:29 +0300 Subject: ssh-agent: How to use it properly? In-Reply-To: <20050325092431.GC27116@foo.birdnet.se> References: <1092192982.20050324170701@nwgsm.ru> <20050325092431.GC27116@foo.birdnet.se> Message-ID: <944032082.20050325140029@nwgsm.ru> Hello Peter, Friday, March 25, 2005, 12:24:31 PM, you wrote: >> Neither (SSH.com's) ssh-1.2.33 nor ssh-3.2.9.1 sport this switch. PS> That doesn't look like OpenSSH version numbers. This is the OpenSSH PS> list, you know. :) Oh, yes... I know. I was not able to port OpenSSH to my QNX4 yet. PS> -c was added to ssh-add.c v 1.65 Thu Jan 23 13:50:27 2003 Does this feature depend on some cooperation in ssh-agent as well? Will it suffice just to pull "ssh-add.c v 1.65" out of the CVS and merge with my sources? -- Best regards, Anthony From guyverdh at mchsi.com Wed Mar 23 06:44:51 2005 From: guyverdh at mchsi.com (guyverdh at mchsi.com) Date: Tue, 22 Mar 2005 19:44:51 +0000 Subject: Solaris 10 support Message-ID: <032220051944.13230.424075B300006A68000033AE2197912995080B9D0A90979A09@mchsi.com> Thanks for the info. It appears that the bundled openssl is version 0.9.7d. Loaded up openssl-0.9.7e in the standard /usr/local/ssl location. I then added the --with-ssl=/usr/local/ssl parameter to the config run. It built just fine. The regression tests fail due to issues with the location of the ssh-rand-helper. I ran the install then, and it went fine, and the binary works. Once it had loaded the ssh-rand-helper to where it wanted it, I re-ran the make tests command again, successfully. So, the end-result is this. Requirements. PATH=/usr/sfw/bin:/usr/ccs/bin:${PATH} Vanilla openssl-0.9.7e must be installed. configure must be run with the --with-openssl-dir=/usr/local/ssl parameter. Regression tests appear to want to run ssh-rand-helper from the install location, not the build directory for some reason. Otherwise, it makes fine, and installs correctly. Thanks again. Hope this helps someone out. > Darren Tucker wrote: > > guyverdh at mchsi.com wrote: > > > >> gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o > >> sshconnect1.o > >> sshconnect2.o -L. -Lopenbsd-compat/ -lssh -lopenbsd-compat -lresolv > >> -lcrypto > >> -lrt -lz -lsocket -lnsl > >> Undefined first referenced > >> symbol in file > >> EVP_aes_192_cbc ./libssh.a(cipher.o) > >> EVP_aes_256_cbc ./libssh.a(cipher.o) > >> ld: fatal: Symbol referencing errors. No output written to ssh > >> collect2: ld returned 1 exit status > >> gmake: *** [ssh] Error 1 > > > > > > It looks like the Sun-supplied OpenSSL (which I believe is modified?) > > does not have the 192-bit and 256-bit AES functions. Does it work with > > the vanilla OpenSSL distribution? (Possibly you will have to "configure > > --with-ssl-dir=/usr/local/ssl"). > > That can bite you when you build apache2 with SSL as well (just > for the record :) ) > > From stuge-openssh-unix-dev at cdy.org Sat Mar 26 05:15:21 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 25 Mar 2005 19:15:21 +0100 Subject: ssh-agent: How to use it properly? In-Reply-To: <944032082.20050325140029@nwgsm.ru> References: <1092192982.20050324170701@nwgsm.ru> <20050325092431.GC27116@foo.birdnet.se> <944032082.20050325140029@nwgsm.ru> Message-ID: <20050325181521.GC12157@foo.birdnet.se> On Fri, Mar 25, 2005 at 02:00:29PM +0300, rz1a at nwgsm.ru wrote: > > Hello Peter, > > Friday, March 25, 2005, 12:24:31 PM, you wrote: > >> Neither (SSH.com's) ssh-1.2.33 nor ssh-3.2.9.1 sport this switch. > PS> That doesn't look like OpenSSH version numbers. This is the OpenSSH > PS> list, you know. :) > Oh, yes... I know. > I was not able to port OpenSSH to my QNX4 yet. Ahh! > PS> -c was added to ssh-add.c v 1.65 Thu Jan 23 13:50:27 2003 > Does this feature depend on some cooperation in ssh-agent as well? > Will it suffice just to pull "ssh-add.c v 1.65" out of the CVS and > merge with my sources? ssh-agent is the process asking for the confirmation. ssh-add -c tells the agent that it should confirm each use of the key. Depending on whether your agents know how to ask for confirmation already you may only need the ssh-add modifications. I don't know how well IPC with ssh-agent is standardized across SSH implementations. //Peter From rapier at psc.edu Sat Mar 26 07:59:06 2005 From: rapier at psc.edu (chris rapier) Date: Fri, 25 Mar 2005 15:59:06 -0500 Subject: New HPN patch released for 3.9 Message-ID: <919efa71f961f04c49cb72db8baa4b62@psc.edu> We've released a new HPN (High Performance Network) patch for OpenSSH 3.9p1. We've made two major changes - first off we backed out of all the modifications we made to buffer.c. Turns out that it just wasn't necessary once we fixed a nagging bug in channels.c. I also made a minor change to the buffer sizes in the source and sink functions in scp.c Increasing the size of both reduces the number of read/write syscalls 60% for source and 20% for sink. It doesn't give a big performance gain but once this starts moving at GigE speeds most any performance gain is worth exploring. Anyway, the patch can be found at http://www.psc.edu/networking/projects/hpn-ssh We'll have a patch for 4.0 up by Monday at the latest. Any comments, critiques, or suggestions about these patches are welcome and all will be taken seriously and given due consideration. From ed.white at libero.it Sun Mar 27 02:06:37 2005 From: ed.white at libero.it (Ed White) Date: Sat, 26 Mar 2005 16:06:37 +0100 Subject: forwarding data ? Message-ID: <200503261606.37577.ed.white@libero.it> Hi, I'm trying to configure ssh to get this behaviour: ssh binds on "localhost:60110" and when a local application connect to that port, all the data are forwarded to the "server". The particular fact is that I can't use port forwarding because I don't have any pop3 daemon on the "server". In fact I'm using a pop3 script as user's shell! $ ssh ... user at server +OK list +OK . quit +OK Connection to server closed. When I try by hand everything is ok, but it seems I cannot use ssh to bind a port and simply forward the data. Is this a known OpenSSH limitation ? From stuge-openssh-unix-dev at cdy.org Sun Mar 27 02:40:50 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 26 Mar 2005 16:40:50 +0100 Subject: forwarding data ? In-Reply-To: <200503261606.37577.ed.white@libero.it> References: <200503261606.37577.ed.white@libero.it> Message-ID: <20050326154050.GA1842@foo.birdnet.se> On Sat, Mar 26, 2005 at 04:06:37PM +0100, Ed White wrote: > ssh binds on "localhost:60110" and when a local application connect > to that port, all the data are forwarded to the "server". The > particular fact is that I can't use port forwarding because I don't > have any pop3 daemon on the "server". In fact I'm using a pop3 > script as user's shell! > > When I try by hand everything is ok, but it seems I cannot use ssh > to bind a port and simply forward the data. Is this a known OpenSSH > limitation ? I guess you could say that, but I would rather say that you're trying to use a tool for a task that it wasn't designed to perform. You could try running faucet[1] with the script on the server to turn it into a TCP service and then use regular port forwarding to reach it. //Peter [1] http://web.purplefrog.com/~thoth/netpipes/netpipes.html From kees at osdl.org Sat Mar 26 12:12:25 2005 From: kees at osdl.org (Kees Cook) Date: Fri, 25 Mar 2005 17:12:25 -0800 Subject: bug: X11 forwarding silently falls back to ForwardX11Trusted=yes Message-ID: <20050326011225.GF4475@osdl.org> On 2005-01-11 at 6:36:13 Darren Tucker said: > kochera at postfinance.ch wrote: > > We upgraded from 3.7.1p2 to 3.9p1. The behaviour of the X11 forwarding > > changed significantly, it is much slower. See below the truss output > > (server side which runs 3.7.1p2) an check for the timestamp (6 seconds > > delay). Do you have any idea what may causes this behaviour? Platform is > > Solaris 5.9 Generic_117171-05. > > One thing that changed was the use of untrusted xauth cookies. You can > use the previous behaviour by putting "ForwardX11Trusted yes" in > ssh_config. > > The other possibility I can think of is some kind of name resolution or > IPv6 wackiness: you can try "UseDNS no" and "AddressFamily inet" in > sshd_config and/or start sshd with the "-4" option to test those. I actually just tracked this problem down. When "ForwardX11Trusted" is "no", the local ssh client will attempt to requested the new generated cookie with xauth, but times out in the attempt, and falls back to forwarding the trusted cookie. (I think this is a bug: it should emit a failure, since it should never default to a _less_ secure option.) The cause of the failure (for our situations) happens one a double-ssh. For example, we have people ssh'ing into our shell machine from home, and then ssh'ing to their project machines, where they run X11 programs. The code just before the xauth calls (in ssh.c:x11_get_proto) attempts to figure out if the X11 screen is local to the machine or not. It assumes that "localhost:..." means it should rewrite the display to "unix:...". However, this breaks our situation, since the display is "localhost" due to it being forwarded via sshd. Since unix:... doesn't exist, the xauth hangs, and then times out, causing this delay. A "true local" display shouldn't have a host part at all (":0.0", for example). Perhaps that would be a better way to test for local displays? (please Cc any replies, I'm not subscribed) Thanks! -- Kees Cook Core Services x1918 From strbenjr at yahoo.com Sun Mar 27 06:15:17 2005 From: strbenjr at yahoo.com (Ben Hacker Jr) Date: Sat, 26 Mar 2005 15:15:17 -0500 Subject: Convert keys (OpenSSL to OpenSSH) Message-ID: <4245C2D5.4040507@yahoo.com> Hello, I would like to use Public Key authentication with OpenSSH. I am trying to use a public / private key set created using CA.pl. http://www.openssl.org/docs/apps/CA.pl.html I am not sure but I think my OpenSSL keys will not work until some conversion takes place. I was able to get them working between Windows (Putty.EXE) and my SSHD server but PuttyGen.EXE converted the public keys for me. QUESTION: How do I convert the keys myself [using OpenSSL or...] so one unix box can talk/SSH to the other using public key authentication??? (* Thanks in advance!! and also please reply directly to me since I am not a member of this listserver. *) I found this message (listed below) on the OpenSSL archives. The message explains the differences between the two formats that I am seeing but does not help me with converting from one format to the other. In message <41077310.9080102 at zrz.TU-Berlin.DE> on Wed, 28 Jul 2004 11:34:08 +0200, Gerd Schering said: Schering> Then I extracted the public key, Schering> 1. with openssl: Schering> Schering> -----BEGIN PUBLIC KEY----- Schering> MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQC/mID2ohE8oahTW2/v0uXOKe/9 Schering> 8Lxywo8p0D56prYHlMIUoTMkouoY+DfbF65a1gNQaLCp2izqSPQZvHk9RqESpGkT Schering> df8voe9uONz902xZ9f5fJVgi2ASQvKpEzlZOWVuPPXWqTe1eqQLQ39wAaX/TqA6h Schering> raEdYAWxZUUn3iTv1wIBIw== Schering> -----END PUBLIC KEY----- Schering> Schering> 2. with ssh-keygen: Schering> Schering> ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAv5iA9qIRPKGoU1tv79Llzinv/fC8csKPKdA+e \ Schering> qa2B5TCFKEzJKLqGPg32xeuWtYDUGiwqdos6kj0Gbx5PUahEqRpE3X/L6Hvbjjc/dNsWfX+Xy \ Schering> VYItgEkLyqRM5WTllbjz11qk3tXqkC0N/cAGl/06gOoa2hHWAFsWVFJ94k79c= Schering> (there are no newlines) Schering> Schering> Schering> They look different and the ssh key is not in PEM format. Schering> But besides that by which means is this difference produced? Schering> Or s it only the lack of header-, footer-, newlines and the Schering> "ssh-rsa" which produces a different base64 encoding? The difference is in structure. In the PEM form, there are some codes around the RSA numbers that indicate what they are (ASN.1 structure, DER encoding, if that says anything). In the SSH form, the BASE64 stuff includes a repeat of "ssh-rsa", followed by the RSA numbers e and n, with no extra structure information. Schering> B.t.w In PEM format, are the newlines part of the Schering> base64-encoded data, or get the data encoded first? The data is encoded first, the newlines are added on and are basically part of the PEM format. BASE64 can be all in one line if you want. -- Ben Hacker, Jr. Sr. Security Analyst strbenjr at yahoo.com ben_hacker at inter-op.net 703.751.3757 (w) -- -- -- http://www.coeba.org http://www.inter-op.net http://www.hackerweb.net/bthacker From djm at mindrot.org Sun Mar 27 23:32:36 2005 From: djm at mindrot.org (Damien Miller) Date: Sun, 27 Mar 2005 23:32:36 +1000 Subject: caching In-Reply-To: <20050324034139.GA11181@a5.repetae.net> References: <20050310031604.GA29384@a5.repetae.net> <20050324034139.GA11181@a5.repetae.net> Message-ID: <4246B5F4.3060504@mindrot.org> Frederik Eaton wrote: > Also, terminal resizing doesn't seem to work through cached > connections... It works for me. Please file a bug an attach a detailed (-vvv) trace when resizing a slave window doesn't work. It would be good if you could capture one from the server end ("sshd -ddd") too. >>I'm trying to use ssh's new connection caching facilities from a >>wrapper script so that the caching is transparent to the user, i.e. a >>socket for each destination is created in the user's ~/.ssh/ >>directory. For the most part it works well, but I've been having some >>trouble. >> >>Firstly, sometimes when I create a slave connection, it hangs when the >>connection is created; slightly more often it hangs when I try to log >>out. Can you also try to catch this with debugging turned on and attach the trace to a separate bug? >>Secondly, it seems that X11 port forwarding isn't done for slave >>connections. Yes, this is something of a protocol limitation but there may be ways to cheat around it. Please file a bug for this too, so it doesn't get dropped. >>Have other people encountered these issues? If they are actual bugs, >>are they being worked on? Does somebody have a wrapper script which >>accomplishes the task I'm trying to accomplish (or is support for it >>planned to be included in ssh - since it seems like the main reason >>one would want caching in the first place)? Thanks, Automated multiplexing connections are planned and a couple of people are looking at it. I didn't implement it at first because I wanted to make it stable before adding extra features. > More concisely: What is the status of the caching facilities? Is > someone working on improving them? I use them daily and have found it to be very stable. Naturally we will fix any bugs we find and we plan to implement a few more features when we have time (like the automatic setup of the master connection). -d From p_quiring at yahoo.com Mon Mar 28 06:50:23 2005 From: p_quiring at yahoo.com (Peter Quiring) Date: Sun, 27 Mar 2005 12:50:23 -0800 (PST) Subject: gettings started Message-ID: <20050327205023.42710.qmail@web50907.mail.yahoo.com> I would like to use OpenSSH just as I have OpenSSL, but I can't seem to find any API references like there are at openssl.org. Where can I find some good API references for OpenSSH? This is what I want to do : create a C++ class around SSH that will make a client/server connection that deals with the data only. The data could come from a socket, pipe or just memory (up to the developer that uses the class). I've already done this with SSL and it works great (I've used this class to create secure HTTP,FTP,SMTP,etc. servers and clients). Any help to get me started would be great. I've tried to look thru the src code of openssh but it's a little overwhelming. Thanks again. Peter Quiring pquiring at geocities.com From judicator3 at gmail.com Tue Mar 29 15:12:17 2005 From: judicator3 at gmail.com (Richard) Date: Tue, 29 Mar 2005 00:12:17 -0500 Subject: Loading keys in SSH2 Message-ID: Hello, I am going through the source of openssh-3.9p1 and I have a quick question on how the sshd daemon loads the host keys. In the default configuration of SSH2 protocol, the private DSA hostkey is found in the file 'ssh_host_dsa_key' and the public DSA hostkey counterpart in 'ssh_host_dsa_key.pub'. Likewise, the private and public RSA hostkeys are found in 'ssh_host_rsa_key' and 'ssh_host_rsa_key.pub' respectively. Now I am tracing through the sshd.c file and I am interested about how the SSH2 protocol loads the host keys. Below I drew a rough call graph as [fileName]functionName [sshd.c]main() | \/ [authfile.c]key_load_private() | \/ [authfile.c]key_load_private_pem() | \/ [in openssl library]PEM_read_PrivateKey() I am a bit confused about the call to the function PEM_read_PrivateKey() Below is the call to PEM_read_PrivateKey() on line 463 of authfile.c ========================================================= pk = PEM_read_PrivateKey(fp, NULL, NULL, (char *)passphrase); ========================================================= Does the function PEM_read_PrivateKey() returns something that contains data about BOTH the public and private parts of the assymetric DSA or RSA key ? Thanks Richard From rapier at psc.edu Wed Mar 30 02:35:59 2005 From: rapier at psc.edu (chris rapier) Date: Tue, 29 Mar 2005 11:35:59 -0500 Subject: New HPN patch released for 3.9 In-Reply-To: <42493741.6050400@ulyssis.org> References: <919efa71f961f04c49cb72db8baa4b62@psc.edu> <42493741.6050400@ulyssis.org> Message-ID: <3d1efbff02b67c7b1d080a4f8d62627e@psc.edu> I really need to get more sleep before I touch a keyboard. I'll take a look at it. I wouldn't be surprised if I screwed it up because I found a typo in it yesterday. I'll have the 4.0 patch out soon as well. After I have someone who has had more sleep to review it. On Mar 29, 2005, at 6:08 AM, Dries Schellekens wrote: > chris rapier wrote: > >> Anyway, the patch can be found at >> http://www.psc.edu/networking/projects/hpn-ssh > > The patch looks to be reverse. > > > Cheers, > > Dries From rapier at psc.edu Wed Mar 30 03:05:40 2005 From: rapier at psc.edu (chris rapier) Date: Tue, 29 Mar 2005 12:05:40 -0500 Subject: New HPN patch released for 3.9 In-Reply-To: <3d1efbff02b67c7b1d080a4f8d62627e@psc.edu> References: <919efa71f961f04c49cb72db8baa4b62@psc.edu> <42493741.6050400@ulyssis.org> <3d1efbff02b67c7b1d080a4f8d62627e@psc.edu> Message-ID: <80484005d1fca4ea147edd816550ed03@psc.edu> Fixed. However, at the request of some of the other researchers here I'll be adding a new feature later today. Which means a new version of the patch with some added functionality will be available later today or tomorrow. On Mar 29, 2005, at 11:35 AM, chris rapier wrote: > I really need to get more sleep before I touch a keyboard. I'll take a > look at it. I wouldn't be surprised if I screwed it up because I found > a typo in it yesterday. > > I'll have the 4.0 patch out soon as well. After I have someone who has > had more sleep to review it. > > On Mar 29, 2005, at 6:08 AM, Dries Schellekens wrote: > >> chris rapier wrote: >> >>> Anyway, the patch can be found at >>> http://www.psc.edu/networking/projects/hpn-ssh >> >> The patch looks to be reverse. >> >> >> Cheers, >> >> Dries > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From RBal at krafteurope.com Thu Mar 31 06:29:22 2005 From: RBal at krafteurope.com (Bal, Radu) Date: Wed, 30 Mar 2005 22:29:22 +0200 Subject: cc: "/usr/include/setjmp.h", line 53: error 1000: Unexpected symb ol: "int".HP-UX 10.20 Message-ID: <4BE18FF9C599EC4BBEE3A261AA8FEB2704581BB0@kjsatvieshrexc1.eu.pm.com> Hello, I tried to "make install" open ssh 3.9p1 on a HP-UX 10.20. I compiled previously openssl-0.9.7f and zlib-1.2.2 The make install for the open ssh produced the following error: rver\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PID DIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\ "/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh-keyscan.c cc: "/usr/include/setjmp.h", line 53: error 1000: Unexpected symbol: "int". cc: "ssh-keyscan.c", line 57: error 1000: Unexpected symbol: "kexjmp". cc: "openbsd-compat/glob.h", line 46: warning 617: Redeclaration of tag "stat" i gnored. cc: "/usr/include/setjmp.h", line 35: error 1588: "_JBLEN" undefined. Can somebody help? Would you need more information? Kind regards, Radu Bal Kraft Foods Austria Senior Project Manager Information Systems +43 1 60544 255, mobile +43 664 60544 255 rbal at krafteurope.com > The Information contained in this e-mail, and any files transmitted with > it, is confidential and may be legally privileged. It is intended solely > for the addressee. If you are not the intended recipient, please return > the message by replying to it and then delete the message from your > computer. Any disclosure, copying, distribution or action taken in > reliance on its contents is prohibited and may be unlawful. > From maximander at gmail.com Thu Mar 31 10:00:51 2005 From: maximander at gmail.com (maximander) Date: Wed, 30 Mar 2005 16:00:51 -0800 Subject: SSH known host file should store port as well as host Message-ID: <2763cb2d05033016003dbdad37@mail.gmail.com> Hello all, i just discovered that the known hosts file seems to only store the server finger prints for distinct *hostnames/IPs*, not hostnames/IPs and ports, meaning i can't ssh to a multiple boxes on the same host even if they have different ports. Every client other than the one shipped with openSSH seems to work fine, presumably because they store fingerprints by host:port combinations rather than only by host. Would it be possible to modify the openSSH client to also store fingerprints by distinct host *and* port? -- --david ------------------- photograph (n.) A picture painted by the sun without instruction in art. ------------------- phrisco.com | gerpok.com | bamboozled.org ------------------ From dtucker at zip.com.au Thu Mar 31 17:30:20 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 31 Mar 2005 17:30:20 +1000 Subject: SSH known host file should store port as well as host In-Reply-To: <2763cb2d05033016003dbdad37@mail.gmail.com> References: <2763cb2d05033016003dbdad37@mail.gmail.com> Message-ID: <424BA70C.1000502@zip.com.au> maximander wrote: > Hello all, i just discovered that the known hosts file seems to only > store the server finger prints for distinct *hostnames/IPs*, not > hostnames/IPs and ports, meaning i can't ssh to a multiple boxes on > the same host even if they have different ports. Every client other > than the one shipped with openSSH seems to work fine, presumably > because they store fingerprints by host:port combinations rather than > only by host. Would it be possible to modify the openSSH client to > also store fingerprints by distinct host *and* port? See http://bugzilla.mindrot.org/show_bug.cgi?id=454 In the mean time, check out the CheckHostIP and HostKeyAlias options in the ssh_config(5) man page. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Mar 31 21:23:44 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 31 Mar 2005 21:23:44 +1000 Subject: Bug in AIX password expiry code in 4.0p1 Message-ID: <424BDDC0.4060804@zip.com.au> Hi all. There's a bug in sshd in the handling of the password expiry messages returned by AIX's authentication routines, which will cause sshd to segfault after password authentication if the user's password has expired or is about to expire. It was originally reported by Rob v.d. Wal. It doesn't affect any other platforms. I recommend that anyone deploying 4.0p1 on AIX systems apply the patch in the following bug, or wait for the 4.1p1 release (which will be some time in the next couple of weeks). My apologies for any inconvenience caused. http://bugzilla.mindrot.org/show_bug.cgi?id=1006 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From pquiring at geocities.com Thu Mar 31 08:57:56 2005 From: pquiring at geocities.com (Peter Quiring) Date: Wed, 30 Mar 2005 17:57:56 -0500 Subject: name pollution Message-ID: <424B2EF4.90501@geocities.com> I've finally got SSH compiling for me, but there are a few filenames that conflict with other projects out there (zlib, etc.) and I'm unable to create a monolithic library with SSH without renaming some files. Could you prefix "ssh" to the following files in the next release of OpenSSH. Thanks. crc32,buffer,compress,base64(openbsd file). Thanks again.