From djm at mindrot.org Mon Dec 3 09:57:51 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 3 Dec 2012 09:57:51 +1100 (EST) Subject: AuthenticationMethods option. In-Reply-To: References: <20121122101658.GC1419@garage.freebsd.pl> Message-ID: On Fri, 23 Nov 2012, Damien Miller wrote: > On Fri, 23 Nov 2012, Damien Miller wrote: > > > On Thu, 22 Nov 2012, Pawel Jakub Dawidek wrote: > > > > > Hi. > > > > > > I can see that SSH partial success functionality was implemented very > > > recently in the OpenSSH server. That's great news. > > > > > > I just tried it and I don't seem to be able to make it work with both > > > public key authentication and password authentication through PAM. > > > I wonder if this is a bug or something that won't be implemented for now > > > or if this is still WIP and I should be more patient? > > > > Yes, there is a bug in there - the monitor is becoming confused by > > returns from monitor_read() that don't reset auth_method to an > > expected method name. > > > > I'll take a look. > > I think this fixes it: [patch] This is committed and will be in the 20121204 snapshot. -d From jan.pechanec at oracle.com Tue Dec 4 06:27:27 2012 From: jan.pechanec at oracle.com (Jan Pechanec) Date: Mon, 3 Dec 2012 11:27:27 -0800 (PST) Subject: HostKey in hardware? In-Reply-To: References: <20121121184930.GX11406@acooke.org> Message-ID: On Wed, 28 Nov 2012, Damien Miller wrote: >> Here's a (lightly tested) patch for PKCS#11 host keys. At the moment, the >> keys are loaded using a fixed PIN of 0000, but there's probably a better >> way to do it. I don't really want sshd to block at startup time while looking >> for a password, but my PKCS#15-fu isn't good enough to know how to create >> keys that don't require a PIN at all. > >Thinking about it some more, I've come to the conclusion that this patch >is insufficient because it offers no way to select which keys from the >token will end up as SSH hostkeys. An administrator who has gone to the >trouble of setting up some sort of token for the storage of SSH keys may >well want to use it with independent keys for other purposes (e.g. TLS keys). > >So we need some way of selecting keys from the token for use. I don't like >doing it via reader ID / slot, as readers on USB busses can move around - >IMO it's safer to explicitly specify the public key. Perhaps like: > >HostKeyPKCS11 /path/to/pkcs11.so /path/to/hostkey.pub Damien, you could use PKCS#11 URI for that. You may even overload HostKey keyword and test for "pkcs:" prefix to distinguish between a path and a URI. http://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 the URI is already used in GNOME, GnuTLS, and Solaris (ZFS, SSH). J. -- Jan Pechanec http://blogs.oracle.com/janp From loganaden at gmail.com Tue Dec 4 23:05:51 2012 From: loganaden at gmail.com (Loganaden Velvindron) Date: Tue, 4 Dec 2012 16:05:51 +0400 Subject: OpenSSH warnings on FreeBSD Message-ID: on FreeBSD, gcc complains that %d is used for sig_atomic_t Casting to (int) as a solution ? Index: serverloop.c =================================================================== RCS file: /cvs/openssh/serverloop.c,v retrieving revision 1.172 diff -u -p -r1.172 serverloop.c --- serverloop.c 2 Dec 2012 22:50:55 -0000 1.172 +++ serverloop.c 4 Dec 2012 11:46:33 -0000 @@ -708,7 +708,7 @@ server_loop(pid_t pid, int fdin_arg, int &nalloc, max_time_milliseconds); if (received_sigterm) { - logit("Exiting on signal %d", received_sigterm); + logit("Exiting on signal %d", (int)received_sigterm); /* Clean up sessions, utmp, etc. */ cleanup_exit(255); } @@ -858,7 +858,7 @@ server_loop2(Authctxt *authctxt) &nalloc, 0); if (received_sigterm) { - logit("Exiting on signal %d", received_sigterm); + logit("Exiting on signal %d", (int)received_sigterm); /* Clean up sessions, utmp, etc. */ cleanup_exit(255); -- Brightest day, Blackest night, No bug shall escape my sight, And those who worship evil's mind, be wary of my powers, puffy lantern's light ! From amesh at juniper.net Wed Dec 5 05:51:26 2012 From: amesh at juniper.net (Arthur Mesh) Date: Tue, 4 Dec 2012 10:51:26 -0800 Subject: OpenSSH warnings on FreeBSD In-Reply-To: References: Message-ID: <20121204185126.GS35562@juniper.net> On Tue, Dec 04, 2012 at 04:05:51PM +0400, Loganaden Velvindron wrote: > on FreeBSD, gcc complains that %d is used for sig_atomic_t > > Casting to (int) as a solution ? I think casting to intmax_t is a safer approach, together with changing the format to %jd (although I am not sure how portable this is). -- Arthur Mesh Juniper Networks +1 408 936-4968 From lists at eitanadler.com Wed Dec 5 06:00:08 2012 From: lists at eitanadler.com (Eitan Adler) Date: Tue, 4 Dec 2012 14:00:08 -0500 Subject: OpenSSH warnings on FreeBSD In-Reply-To: <20121204185126.GS35562@juniper.net> References: <20121204185126.GS35562@juniper.net> Message-ID: On 4 December 2012 13:51, Arthur Mesh wrote: > On Tue, Dec 04, 2012 at 04:05:51PM +0400, Loganaden Velvindron wrote: >> on FreeBSD, gcc complains that %d is used for sig_atomic_t >> >> Casting to (int) as a solution ? > > I think casting to intmax_t is a safer approach, together with changing > the format to %jd (although I am not sure how portable this is). I think this is the more portable approach among the two. -- Eitan Adler From dtucker at zip.com.au Wed Dec 5 11:19:04 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 5 Dec 2012 11:19:04 +1100 Subject: OpenSSH warnings on FreeBSD In-Reply-To: References: <20121204185126.GS35562@juniper.net> Message-ID: On Wed, Dec 5, 2012 at 6:00 AM, Eitan Adler wrote: > On 4 December 2012 13:51, Arthur Mesh wrote: >> On Tue, Dec 04, 2012 at 04:05:51PM +0400, Loganaden Velvindron wrote: >>> on FreeBSD, gcc complains that %d is used for sig_atomic_t >>> >>> Casting to (int) as a solution ? >> >> I think casting to intmax_t is a safer approach, together with changing >> the format to %jd (although I am not sure how portable this is). Not everything has an intmax_t, and it's not used anywhere else in OpenSSH so in order to use it we'd need to add it to configure. > I think this is the more portable approach among the two. %jd isn't portable either (it's not in SuSv2, for example): http://pubs.opengroup.org/onlinepubs/007908799/xsh/fprintf.html Signal numbers have to fit into 7 bits (since they can be crammed into the shell's return code with the high bit set) so casting to int should be fine. -- 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 gasser at in.tum.de Wed Dec 5 12:58:18 2012 From: gasser at in.tum.de (Oliver Gasser) Date: Wed, 5 Dec 2012 02:58:18 +0100 Subject: [PATCH] Large log output does not print newline Message-ID: Hi, I think I found a minor bug in OpenSSH's log functionality: If a log message which is larger than MSGBUFSIZE=1024 and logged to stderr, then the newline (\r\n) is not printed. This is due to the fact that the newline is added after the log message concatenated with "\r\n" is snprintf'd to another buffer of the same size. If the source buffer (fmtbuf) would already fill the destination buffer (msgbuf), then the additional "\r\n" are of course never written into the destination buffer. See the one-line attached patch. Could it be possible to make the size limit for log messages dynamic, e.g. via ssh_config? Or is the fixed limit of 1024 characters there on purpose? Kind regards, Oliver Gasser From gasser at in.tum.de Wed Dec 5 19:09:08 2012 From: gasser at in.tum.de (Oliver Gasser) Date: Wed, 5 Dec 2012 09:09:08 +0100 Subject: [PATCH] Large log output does not print newline In-Reply-To: <20121205021520.5171.qmail@stuge.se> References: <20121205021520.5171.qmail@stuge.se> Message-ID: Second try for the patch. Otherwise, here is the .patch's content: diff --git a/log.c b/log.c index ad5a10b..de3f451 100644 --- a/log.c +++ b/log.c @@ -413,6 +413,7 @@ do_log(LogLevel level, const char *fmt, va_list args) tmp_handler(level, fmtbuf, log_handler_ctx); log_handler = tmp_handler; } else if (log_on_stderr) { + fmtbuf[sizeof(fmtbuf)-3] = '\0'; snprintf(msgbuf, sizeof msgbuf, "%s\r\n", fmtbuf); write(STDERR_FILENO, msgbuf, strlen(msgbuf)); } else { On Wed, Dec 5, 2012 at 3:15 AM, Peter Stuge wrote: > Oliver Gasser wrote: > > one-line attached patch. > > No patch. Make sure mimetype is text/plain. > > > //Peter > -------------- next part -------------- diff --git a/log.c b/log.c index ad5a10b..de3f451 100644 --- a/log.c +++ b/log.c @@ -413,6 +413,7 @@ do_log(LogLevel level, const char *fmt, va_list args) tmp_handler(level, fmtbuf, log_handler_ctx); log_handler = tmp_handler; } else if (log_on_stderr) { + fmtbuf[sizeof(fmtbuf)-3] = '\0'; snprintf(msgbuf, sizeof msgbuf, "%s\r\n", fmtbuf); write(STDERR_FILENO, msgbuf, strlen(msgbuf)); } else { From ivan at sysprogs.com Mon Dec 10 00:51:46 2012 From: ivan at sysprogs.com (Ivan Shcherbakov) Date: Sun, 9 Dec 2012 14:51:46 +0100 Subject: Another SSH client on Windows Message-ID: <006301cdd614$548cdc60$fda69520$@sysprogs.com> Dear All, I just wanted to announce another free SSH client on Windows capable of working with OpenSSH. The too is called SmarTTY and is available via http://smartty.sysprogs.com/ Could you guys please reference it at the Win32 alternatives page (http://www.openssh.org/windows.html)? Best regards, Ivan Shcherbakov From cal.leeming at simplicitymedialtd.co.uk Mon Dec 10 02:19:45 2012 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Sun, 9 Dec 2012 15:19:45 +0000 Subject: Another SSH client on Windows In-Reply-To: <006301cdd614$548cdc60$fda69520$@sysprogs.com> References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> Message-ID: Hi Ivan, Here is the negative feedback; * No support for pageant keys.. * No support for PPK keys (putty) * "upload a file / download a file etc" does not default to the directory you are currently in on the shell (this would be a *really* neat feature) * Doesn't have as many hidden features as putty (tunnelling etc) * Really thick border around the shell window in non maximized mode is very off-putting (nearly twice as thick as putty) * No 'true' full screen (i.e. full screen that gets rid of the title bar, and puts you into no distractions mode). * "manage public key" does not offer ability to manage multiple keys * Opening too many tabs will result in "LIBSSH2_ERROR_CHANNEL_FAILURE" * Tabs will only connect to the same server.. being able to have tabs across multiple servers is a must. Here is a positive feedback; * The idea of "set up public key auth and do not ask for pw again" is pretty neat, I like this :) * "manage public key" is really quite nice.. * The tabs windows are really nice The thing this is *really* missing (imho) is "drag/drop upload support". For example, you cd into a directory on the shell, you drag a file into the window, and it uploads the file into that directory for you. For years I've been saying how awesome it would be if putty had this feature. Although there is more negative than positive, I *really* quite like this product and I think it's got a lot of potential. Keep up the good work, I look forward to seeing your next release (please do put me on your mailing list for release announcements) Cal On Sun, Dec 9, 2012 at 1:51 PM, Ivan Shcherbakov wrote: > Dear All, > > > > I just wanted to announce another free SSH client on Windows capable of > working with OpenSSH. > > The too is called SmarTTY and is available via > http://smartty.sysprogs.com/ > > > > Could you guys please reference it at the Win32 alternatives page > (http://www.openssh.org/windows.html)? > > > > Best regards, > > Ivan Shcherbakov > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From cal.leeming at simplicitymedialtd.co.uk Mon Dec 10 02:21:28 2012 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Sun, 9 Dec 2012 15:21:28 +0000 Subject: Another SSH client on Windows In-Reply-To: References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> Message-ID: Also, the built-in xming stuff looks pretty awesome - though sadly I can't try it out as I haven't got any servers running X. Cal On Sun, Dec 9, 2012 at 3:19 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming at simplicitymedialtd.co.uk> wrote: > Hi Ivan, > > Here is the negative feedback; > > * No support for pageant keys.. > * No support for PPK keys (putty) > * "upload a file / download a file etc" does not default to the directory > you are currently in on the shell (this would be a *really* neat feature) > * Doesn't have as many hidden features as putty (tunnelling etc) > * Really thick border around the shell window in non maximized mode is > very off-putting (nearly twice as thick as putty) > * No 'true' full screen (i.e. full screen that gets rid of the title bar, > and puts you into no distractions mode). > * "manage public key" does not offer ability to manage multiple keys > * Opening too many tabs will result in "LIBSSH2_ERROR_CHANNEL_FAILURE" > * Tabs will only connect to the same server.. being able to have tabs > across multiple servers is a must. > > Here is a positive feedback; > > * The idea of "set up public key auth and do not ask for pw again" is > pretty neat, I like this :) > * "manage public key" is really quite nice.. > * The tabs windows are really nice > > The thing this is *really* missing (imho) is "drag/drop upload support". > For example, you cd into a directory on the shell, you drag a file into the > window, and it uploads the file into that directory for you. For years I've > been saying how awesome it would be if putty had this feature. > > Although there is more negative than positive, I *really* quite like this > product and I think it's got a lot of potential. > > Keep up the good work, I look forward to seeing your next release (please > do put me on your mailing list for release announcements) > > Cal > > On Sun, Dec 9, 2012 at 1:51 PM, Ivan Shcherbakov wrote: > >> Dear All, >> >> >> >> I just wanted to announce another free SSH client on Windows capable of >> working with OpenSSH. >> >> The too is called SmarTTY and is available via >> http://smartty.sysprogs.com/ >> >> >> >> Could you guys please reference it at the Win32 alternatives page >> (http://www.openssh.org/windows.html)? >> >> >> >> Best regards, >> >> Ivan Shcherbakov >> >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > From seniorgeek at rocketmail.com Mon Dec 10 02:47:45 2012 From: seniorgeek at rocketmail.com (Harry Davidson) Date: Sun, 9 Dec 2012 15:47:45 +0000 (GMT) Subject: AllowTcpForwarding Message-ID: <1355068065.62900.YahooMailNeo@web133017.mail.ir2.yahoo.com> Hello, I have downloaded, built and installed version 6.1p1 on Ubuntu 12.04LTS. I want to use AllowTcpForwarding=remote AllowTcpForwarding=local in sshd_config as described in the sshd_config manual page, but these values cause sshd to fail to start with an error objecting to these values.? I have tired AllowTcpForwarding=yes AllowTcpForwarding=no and they are both accepted and work correctly. I also tried using the local/remote values in a Match section, but that made no difference. As the manual page for sshd_config says OpenBSD at the top, I guess this is a BSD facility.? Is it likely to be implemented in the portable version?? Or has it already, and I am being thick? Kind regards Harry From ivan at sysprogs.com Mon Dec 10 05:10:28 2012 From: ivan at sysprogs.com (Ivan Shcherbakov) Date: Sun, 9 Dec 2012 19:10:28 +0100 Subject: Another SSH client on Windows In-Reply-To: References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> Message-ID: <007b01cdd638$787b1fa0$69715ee0$@sysprogs.com> Hi, Thanks for the feedback. In fact, most of the "hidden" features (e.g. tunneling) are planned for the future versions. Regarding other feedback: 1. Regarding the drag-and-drop upload and the current directory, it is actually supported as long as your shell reports the current directory via the tab caption. 2. Thanks for the full screen/thin border suggestion, I will put it to the feature list. 3. Too many tabs is in fact a limitation of the server side and overcoming it would require having multiple sessions per window, that is currently not supported. 4. The idea behind public keys is having one automatically managed public key per client machine (the users can still manually select explicit key files). As only the public part is stored on the remote servers, this imposes no security risk and makes most use scenarios less complicated. Anyway, thanks again for all feedback and suggestions. You can watch out for future versions via our twitter: https://twitter.com/Sysprogs Best regards, Ivan Shcherbakov From: Cal Leeming [Simplicity Media Ltd] [mailto:cal.leeming at simplicitymedialtd.co.uk] Sent: Sonntag, 9. Dezember 2012 16:21 To: Ivan Shcherbakov Cc: openssh-unix-dev at mindrot.org Subject: Re: Another SSH client on Windows Also, the built-in xming stuff looks pretty awesome - though sadly I can't try it out as I haven't got any servers running X. Cal On Sun, Dec 9, 2012 at 3:19 PM, Cal Leeming [Simplicity Media Ltd] wrote: Hi Ivan, Here is the negative feedback; * No support for pageant keys.. * No support for PPK keys (putty) * "upload a file / download a file etc" does not default to the directory you are currently in on the shell (this would be a *really* neat feature) * Doesn't have as many hidden features as putty (tunnelling etc) * Really thick border around the shell window in non maximized mode is very off-putting (nearly twice as thick as putty) * No 'true' full screen (i.e. full screen that gets rid of the title bar, and puts you into no distractions mode). * "manage public key" does not offer ability to manage multiple keys * Opening too many tabs will result in "LIBSSH2_ERROR_CHANNEL_FAILURE" * Tabs will only connect to the same server.. being able to have tabs across multiple servers is a must. Here is a positive feedback; * The idea of "set up public key auth and do not ask for pw again" is pretty neat, I like this :) * "manage public key" is really quite nice.. * The tabs windows are really nice The thing this is *really* missing (imho) is "drag/drop upload support". For example, you cd into a directory on the shell, you drag a file into the window, and it uploads the file into that directory for you. For years I've been saying how awesome it would be if putty had this feature. Although there is more negative than positive, I *really* quite like this product and I think it's got a lot of potential. Keep up the good work, I look forward to seeing your next release (please do put me on your mailing list for release announcements) Cal On Sun, Dec 9, 2012 at 1:51 PM, Ivan Shcherbakov wrote: Dear All, I just wanted to announce another free SSH client on Windows capable of working with OpenSSH. The too is called SmarTTY and is available via http://smartty.sysprogs.com/ Could you guys please reference it at the Win32 alternatives page (http://www.openssh.org/windows.html)? Best regards, Ivan Shcherbakov _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From ras at anzio.com Mon Dec 10 07:13:27 2012 From: ras at anzio.com (Bob Rasmussen) Date: Sun, 9 Dec 2012 12:13:27 -0800 (PST) Subject: Another SSH client on Windows In-Reply-To: <007b01cdd638$787b1fa0$69715ee0$@sysprogs.com> References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> <007b01cdd638$787b1fa0$69715ee0$@sysprogs.com> Message-ID: On Sun, 9 Dec 2012, Ivan Shcherbakov wrote: > ... > 1. Regarding the drag-and-drop upload and the current directory, it is > actually supported as long as your shell reports the current directory via > the tab caption. What does this mean? I am not aware of any means by which the client can determine the Current Working Directory of the session on the server, particularly if it changes. Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From ivan at sysprogs.com Mon Dec 10 07:17:00 2012 From: ivan at sysprogs.com (Ivan Shcherbakov) Date: Sun, 9 Dec 2012 21:17:00 +0100 Subject: Another SSH client on Windows In-Reply-To: References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> <007b01cdd638$787b1fa0$69715ee0$@sysprogs.com> Message-ID: <009a01cdd64a$25b1b6a0$711523e0$@sysprogs.com> Hi, Normally, bash and mc report the current directory by changing the tab text to : via OSC control sequences. SmarTTY uses it to detect the current directory. Although it is not a perfect way to detect the current directory, it is better than blindly issuing a "pwd\n" sequence assuming that a shell is currently active. -----Original Message----- From: Bob Rasmussen [mailto:ras at anzio.com] Sent: Sonntag, 9. Dezember 2012 21:13 To: Ivan Shcherbakov Cc: 'Cal Leeming [Simplicity Media Ltd]'; openssh-unix-dev at mindrot.org Subject: RE: Another SSH client on Windows On Sun, 9 Dec 2012, Ivan Shcherbakov wrote: > ... > 1. Regarding the drag-and-drop upload and the current directory, it is > actually supported as long as your shell reports the current directory > via the tab caption. What does this mean? I am not aware of any means by which the client can determine the Current Working Directory of the session on the server, particularly if it changes. Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From highc at us.ibm.com Mon Dec 10 08:03:48 2012 From: highc at us.ibm.com (Chris High) Date: Sun, 9 Dec 2012 16:03:48 -0500 Subject: AUTO: Chris High/Endicott/IBM is out of the office until 07/08/2002. (returning 12/10/2012) Message-ID: I am out of the office until 12/10/2012. Out sick through Friday 12/7, Dr's orders. Expect to return Monday 12/10. 11/23 - 24 no cover. 11/26-30 -self - cover - call 720 395 9374 and leave a message. I will return your call w/in one business day. Specific issue coverage: Questions regard AG sudo deployment, including questions about sudo templates? Sudo Deployment AG/Hartford/IBM, SA & D 'ownership of items' items for L2 SA teams can best be directed to: Jeannie Carlson/Chicago/IBM, Issues which cannot wait for my return and do not 'fit' into the above, and Issues requiring immediate management attention may be referred to my manager, Harish Dindigal/Whippany/IBM Note: This is an automated response to your message "openssh-unix-dev Digest, Vol 116, Issue 3" sent on 12/09/2012 13:10:47. This is the only notification you will receive while this person is away. From mloftis at wgops.com Mon Dec 10 08:09:31 2012 From: mloftis at wgops.com (Michael Loftis) Date: Sun, 9 Dec 2012 13:09:31 -0800 Subject: Another SSH client on Windows In-Reply-To: References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> <007b01cdd638$787b1fa0$69715ee0$@sysprogs.com> Message-ID: On Sun, Dec 9, 2012 at 12:13 PM, Bob Rasmussen wrote: > On Sun, 9 Dec 2012, Ivan Shcherbakov wrote: > > > ... > > 1. Regarding the drag-and-drop upload and the current directory, > it is > > actually supported as long as your shell reports the current directory > via > > the tab caption. > > What does this mean? I am not aware of any means by which the client can > determine the Current Working Directory of the session on the server, > particularly if it changes. > XWindows/xterm set title escape sequence I'd imagine. "\033]0;\033\\" or in english.. ESC ] 0;blah ESC \ -- then the title becomes "blah" -- there's a bit of disagreement about what the end sequence should be, xterm IIRC takes both the BEL (^G) and the ESC \ sequence, but screen only takes the ESC \ sequence. There's documentation in the console_codes(4) man page on most Linux distro's. From peter at stuge.se Mon Dec 10 12:49:46 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 10 Dec 2012 02:49:46 +0100 Subject: Another SSH client on Windows In-Reply-To: References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> Message-ID: <20121210014946.15332.qmail@stuge.se> Cal Leeming [Simplicity Media Ltd] wrote: > Here is the negative feedback; > > * No support for pageant keys.. The libssh2 agent API supports pageant already, so this should be an easy addition. > * "upload a file / download a file etc" does not default to the directory > you are currently in on the shell (this would be a *really* neat feature) Come on, think about this for a second, and I'm sure you will realize why this is not possible to do in the general case. > * Opening too many tabs will result in "LIBSSH2_ERROR_CHANNEL_FAILURE" As was mentioned this is the server rejecting your new channel. > The thing this is *really* missing (imho) is "drag/drop upload support". > For example, you cd into a directory on the shell, you drag a file into the > window, and it uploads the file into that directory for you. For years I've > been saying how awesome it would be if putty had this feature. So start looking at, or even thinking about, what is required to do it, and start sending patches. Again, you'll find that a general solution is not possible. //Peter From cal.leeming at simplicitymedialtd.co.uk Mon Dec 10 14:06:10 2012 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Mon, 10 Dec 2012 03:06:10 +0000 Subject: Another SSH client on Windows In-Reply-To: <20121210014946.15332.qmail@stuge.se> References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> <20121210014946.15332.qmail@stuge.se> Message-ID: On Mon, Dec 10, 2012 at 1:49 AM, Peter Stuge wrote: > Cal Leeming [Simplicity Media Ltd] wrote: > > Here is the negative feedback; > > > > * No support for pageant keys.. > > The libssh2 agent API supports pageant already, so this should be an > easy addition. > > > > * "upload a file / download a file etc" does not default to the directory > > you are currently in on the shell (this would be a *really* neat feature) > > Come on, think about this for a second, and I'm sure you will realize > why this is not possible to do in the general case. > See below point. > > > > * Opening too many tabs will result in "LIBSSH2_ERROR_CHANNEL_FAILURE" > > As was mentioned this is the server rejecting your new channel. > This should be nicely hidden by opening another connection then in the event of channels running out. Think outside the box :) > > > > The thing this is *really* missing (imho) is "drag/drop upload support". > > For example, you cd into a directory on the shell, you drag a file into > the > > window, and it uploads the file into that directory for you. For years > I've > > been saying how awesome it would be if putty had this feature. > > So start looking at, or even thinking about, what is required to do > it, and start sending patches. Again, you'll find that a general > solution is not possible. > Actually, it is. One method has already been described by the OP. I am not a C coder (8 years python dev), so I cannot contribute patches. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From peter at stuge.se Mon Dec 10 14:37:10 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 10 Dec 2012 04:37:10 +0100 Subject: Another SSH client on Windows In-Reply-To: References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> <20121210014946.15332.qmail@stuge.se> Message-ID: <20121210033710.24218.qmail@stuge.se> Cal Leeming [Simplicity Media Ltd] wrote: > > > * Opening too many tabs will result in "LIBSSH2_ERROR_CHANNEL_FAILURE" > > > > As was mentioned this is the server rejecting your new channel. > > This should be nicely hidden by opening another connection then in > the event of channels running out. > > Think outside the box :) It's not about any box. Creating a new session automatically is what *you* want, but it may be wildly inappropriate in any number of scenarios, so it is not a reasonable default. > > So start looking at, or even thinking about, what is required to do > > it, and start sending patches. Again, you'll find that a general > > solution is not possible. > > Actually, it is. One method has already been described by the OP. What was described is no general solution. > I am not a C coder (8 years python dev), so I cannot contribute patches. How deep is your operating system knowledge? The problem is on that level, so hopefully you've been using python for lots of OS things, because it would help to model this problem. Every interactive session is a shell process started by sshd. The current working directory is a per-process property. It is inappropriate for an SSH client to make assumptions about any processes on the server which the client does not control. Interactive sessions are by definition not such processes; they are controlled by the user. It was mentioned before on this list, maybe several times, that there is no standardized API for a process (sshd) to find the cwd of one of it's child processes (your shell) - and of course even if OpenSSH did that, it is still no general solution, because other SSH servers may not be able to do it. I suggest that you create a subsystem which enumerates every other channel the invoking user currently has opened in sshd, and looks up their cwd. (SSH subsystems speak a protocol which you define on stdio.) You can make this an @openssh.com subsystem and if implemented within sshd it would work fabulously, but that is *still* no general solution. A general solution needs to work regardless of which sshd is being used. That constraint means that python is just as good a tool as any other for creating the solution. I say a general solution is not possible. You can prove me wrong by sending patches with new python files which do it. //Peter From djm at mindrot.org Mon Dec 10 16:38:14 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Dec 2012 16:38:14 +1100 (EST) Subject: Another SSH client on Windows In-Reply-To: References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> <20121210014946.15332.qmail@stuge.se> Message-ID: On Mon, 10 Dec 2012, Cal Leeming [Simplicity Media Ltd] wrote: > > > * Opening too many tabs will result in "LIBSSH2_ERROR_CHANNEL_FAILURE" > > > > As was mentioned this is the server rejecting your new channel. > > This should be nicely hidden by opening another connection then in the > event of channels running out. > > Think outside the box :) It's great that you are offering feedback to the developers of this application, but could I ask you to refrain from doing it on our mailing list? Their windows client isn't OpenSSH or based on OpenSSH so such discussion is pretty far off-topic. -d From djm at mindrot.org Mon Dec 10 16:41:51 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Dec 2012 16:41:51 +1100 (EST) Subject: AllowTcpForwarding In-Reply-To: <1355068065.62900.YahooMailNeo@web133017.mail.ir2.yahoo.com> References: <1355068065.62900.YahooMailNeo@web133017.mail.ir2.yahoo.com> Message-ID: On Sun, 9 Dec 2012, Harry Davidson wrote: > Hello, > > I have downloaded, built and installed version 6.1p1 on Ubuntu 12.04LTS. > > I want to use > > AllowTcpForwarding=remote > AllowTcpForwarding=local These are only supported in the unreleased snapshot versions. > As the manual page for sshd_config says OpenBSD at the top, I guess > this is a BSD facility. Is it likely to be implemented in the portable > version? Or has it already, and I am being thick? The OpenBSD manpages served on www.openbsd.org are for the current development version. You're welcome to try the snapshots if you need this feature sooner than our next release (early next year, most likely). You can find them via http://www.openssh.com/portable.html#cvs We try to keep the development version stable at all times, but the snapshots are not as heavily tested as the release versions. That being said, Ubuntu 12.04 is one of the platforms I regularly run the regress suite on. -d From cal.leeming at simplicitymedialtd.co.uk Mon Dec 10 22:33:32 2012 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Mon, 10 Dec 2012 11:33:32 +0000 Subject: Another SSH client on Windows In-Reply-To: <20121210033710.24218.qmail@stuge.se> References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> <20121210014946.15332.qmail@stuge.se> <20121210033710.24218.qmail@stuge.se> Message-ID: Peter, can you reply off-list, thanks. Cal On Mon, Dec 10, 2012 at 3:37 AM, Peter Stuge wrote: > Cal Leeming [Simplicity Media Ltd] wrote: > > > > * Opening too many tabs will result in > "LIBSSH2_ERROR_CHANNEL_FAILURE" > > > > > > As was mentioned this is the server rejecting your new channel. > > > > This should be nicely hidden by opening another connection then in > > the event of channels running out. > > > > Think outside the box :) > > It's not about any box. > > Creating a new session automatically is what *you* want, but it may > be wildly inappropriate in any number of scenarios, so it is not a > reasonable default. > Please provide an example of how this would be "wildly inappropriate" > > > > > So start looking at, or even thinking about, what is required to do > > > it, and start sending patches. Again, you'll find that a general > > > solution is not possible. > > > > Actually, it is. One method has already been described by the OP. > > What was described is no general solution. > Duh. > > > > I am not a C coder (8 years python dev), so I cannot contribute patches. > > How deep is your operating system knowledge? The problem is on that > level, so hopefully you've been using python for lots of OS things, > because it would help to model this problem. > > Every interactive session is a shell process started by sshd. > > The current working directory is a per-process property. > > It is inappropriate for an SSH client to make assumptions about > any processes on the server which the client does not control. > > Interactive sessions are by definition not such processes; they are > controlled by the user. > > It was mentioned before on this list, maybe several times, that there > is no standardized API for a process (sshd) to find the cwd of one of > it's child processes (your shell) - and of course even if OpenSSH did > that, it is still no general solution, because other SSH servers may > not be able to do it. > > I suggest that you create a subsystem which enumerates every other > channel the invoking user currently has opened in sshd, and looks > up their cwd. > > (SSH subsystems speak a protocol which you define on stdio.) > > You can make this an @openssh.com subsystem and if implemented > within sshd it would work fabulously, but that is *still* no > general solution. > > A general solution needs to work regardless of which sshd is being > used. That constraint means that python is just as good a tool as any > other for creating the solution. > > I say a general solution is not possible. > > You can prove me wrong by sending patches with new python files which > do it. > Sure, let me just put this on my list of 9834955 todo items to look at sometime in the future ;) > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From cal.leeming at simplicitymedialtd.co.uk Mon Dec 10 22:36:55 2012 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Mon, 10 Dec 2012 11:36:55 +0000 Subject: Another SSH client on Windows In-Reply-To: References: <006301cdd614$548cdc60$fda69520$@sysprogs.com> <20121210014946.15332.qmail@stuge.se> <20121210033710.24218.qmail@stuge.se> Message-ID: On Mon, Dec 10, 2012 at 11:33 AM, Cal Leeming [Simplicity Media Ltd] < cal.leeming at simplicitymedialtd.co.uk> wrote: > Peter, can you reply off-list, thanks. > > Cal > > On Mon, Dec 10, 2012 at 3:37 AM, Peter Stuge wrote: > >> Cal Leeming [Simplicity Media Ltd] wrote: >> > > > * Opening too many tabs will result in >> "LIBSSH2_ERROR_CHANNEL_FAILURE" >> > > >> > > As was mentioned this is the server rejecting your new channel. >> > >> > This should be nicely hidden by opening another connection then in >> > the event of channels running out. >> > >> > Think outside the box :) >> >> It's not about any box. >> >> Creating a new session automatically is what *you* want, but it may >> be wildly inappropriate in any number of scenarios, so it is not a >> reasonable default. >> > > Please provide an example of how this would be "wildly inappropriate" > > >> >> >> > > So start looking at, or even thinking about, what is required to do >> > > it, and start sending patches. Again, you'll find that a general >> > > solution is not possible. >> > >> > Actually, it is. One method has already been described by the OP. >> >> What was described is no general solution. >> > > Duh. > > >> >> >> > I am not a C coder (8 years python dev), so I cannot contribute patches. >> >> How deep is your operating system knowledge? The problem is on that >> level, so hopefully you've been using python for lots of OS things, >> because it would help to model this problem. >> >> Every interactive session is a shell process started by sshd. >> >> The current working directory is a per-process property. >> >> It is inappropriate for an SSH client to make assumptions about >> any processes on the server which the client does not control. >> >> Interactive sessions are by definition not such processes; they are >> controlled by the user. >> >> It was mentioned before on this list, maybe several times, that there >> is no standardized API for a process (sshd) to find the cwd of one of >> it's child processes (your shell) - and of course even if OpenSSH did >> that, it is still no general solution, because other SSH servers may >> not be able to do it. >> >> I suggest that you create a subsystem which enumerates every other >> channel the invoking user currently has opened in sshd, and looks >> up their cwd. >> >> (SSH subsystems speak a protocol which you define on stdio.) >> >> You can make this an @openssh.com subsystem and if implemented >> within sshd it would work fabulously, but that is *still* no >> general solution. >> >> A general solution needs to work regardless of which sshd is being >> used. That constraint means that python is just as good a tool as any >> other for creating the solution. >> >> I say a general solution is not possible. >> >> You can prove me wrong by sending patches with new python files which >> do it. >> > > Sure, let me just put this on my list of 9834955 todo items to look at > sometime in the future ;) > Sorry, I forgot to say thank you for your in-depth breakdown on this, gives some food for thoughts! > > >> >> >> //Peter >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > From tim+ssh at timheckman.net Tue Dec 11 04:50:29 2012 From: tim+ssh at timheckman.net (Tim Heckman) Date: Mon, 10 Dec 2012 12:50:29 -0500 Subject: Retrieve TTL of key from the agent Message-ID: Hello, I'm writing a system to maintain keys within an SSH agent, and all of these keys will only remain in the agent for a short amount of time. This is done to limit access to that key for a short period, as well as to avoid the agent from being cluttered up with a large number of unique SSH keys. This system decrypts the SSH keys on the disk and then loads them in to the agent. I would like to be able to get the key's TTL so I can decide if it's worth decrypting the key again and loading it in to the agent, or if I should just use the key already in the agent. So in short, is there a way to get the TTL for a key in the agent? Thanks! -Tim From keisial at gmail.com Tue Dec 11 06:50:41 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Mon, 10 Dec 2012 20:50:41 +0100 Subject: Retrieve TTL of key from the agent In-Reply-To: References: Message-ID: <50C63D11.9060002@gmail.com> On 10/12/12 18:50, Tim Heckman wrote: > Hello, > > I'm writing a system to maintain keys within an SSH agent, and all of these > keys will only remain in the agent for a short amount of time. This is done > to limit access to that key for a short period, as well as to avoid the > agent from being cluttered up with a large number of unique SSH keys. > > This system decrypts the SSH keys on the disk and then loads them in to the > agent. I would like to be able to get the key's TTL so I can decide if it's > worth decrypting the key again and loading it in to the agent, or if I > should just use the key already in the agent. > > So in short, is there a way to get the TTL for a key in the agent? > > Thanks! Hello Tim, I think there's no message to query the TTL (ie. no). I'm not sure why you need to decide that in advance, though. Can't you just use it if it's in the agent or else load it? From djm at mindrot.org Tue Dec 11 08:29:13 2012 From: djm at mindrot.org (Damien Miller) Date: Tue, 11 Dec 2012 08:29:13 +1100 (EST) Subject: Retrieve TTL of key from the agent In-Reply-To: References: Message-ID: On Mon, 10 Dec 2012, Tim Heckman wrote: > Hello, > > I'm writing a system to maintain keys within an SSH agent, and all of these > keys will only remain in the agent for a short amount of time. This is done > to limit access to that key for a short period, as well as to avoid the > agent from being cluttered up with a large number of unique SSH keys. > > This system decrypts the SSH keys on the disk and then loads them in to the > agent. I would like to be able to get the key's TTL so I can decide if it's > worth decrypting the key again and loading it in to the agent, or if I > should just use the key already in the agent. > > So in short, is there a way to get the TTL for a key in the agent? No - the agent protocol (detailed in PROTOCOL.agent) doesn't offer any way to export this information. -d From tim+ssh at timheckman.net Tue Dec 11 10:10:24 2012 From: tim+ssh at timheckman.net (Tim Heckman) Date: Mon, 10 Dec 2012 18:10:24 -0500 Subject: Retrieve TTL of key from the agent In-Reply-To: References: Message-ID: <3C506F0F098F48CB9FCDFEC8BCED2235@timheckman.net> On Monday, December 10, 2012 at 2:50 PM, ?ngel Gonz?lez wrote: > Hello Tim, > I think there's no message to query the TTL (ie. no). > I'm not sure why you need to decide that in advance, though. Can't you just > use it if it's in the agent or else load it? On Monday, December 10, 2012 at 4:29 PM, Damien Miller wrote: > No - the agent protocol (detailed in PROTOCOL.agent) doesn't offer any way > to export this information. > > -d What I'm working on is to allow users access to a system for a short period of time without them actually having read/write access to where the keys are stored. There will also be a slight delay between my system checking the status of the agent and the user attempting to connect. As such, there is a window (albeit short) where the key could be gone but the user doesn't know about it. I was trying to be slick and not have to decrypt the SSH key on each request if the key already exists in the agent. However, I think the best option would be to just add the key each time. Thank you very much for getting back to me ?ngel and Damien. Hope you two have a great holidays and an awesome 2013. :) -Tim From gasser at in.tum.de Tue Dec 11 23:53:02 2012 From: gasser at in.tum.de (Oliver Gasser) Date: Tue, 11 Dec 2012 13:53:02 +0100 Subject: [PATCH] Large log output does not print newline In-Reply-To: References: <20121205021520.5171.qmail@stuge.se> Message-ID: Hi, can anyone take a look at the bug and the patch for it? Here is my original email message: I think I found a minor bug in OpenSSH's log functionality: If a log message which is larger than MSGBUFSIZE=1024 and logged to stderr, then the newline (\r\n) is not printed. This is due to the fact that the newline is added after the log message concatenated with "\r\n" is snprintf'd to another buffer of the same size. If the source buffer (fmtbuf) would already fill the destination buffer (msgbuf), then the additional "\r\n" are of course never written into the destination buffer. See the one-line attached patch. Patch is attached. Thank you, Oliver On Wed, Dec 5, 2012 at 9:09 AM, Oliver Gasser wrote: > Second try for the patch. Otherwise, here is the .patch's content: > > diff --git a/log.c b/log.c > index ad5a10b..de3f451 100644 > --- a/log.c > +++ b/log.c > @@ -413,6 +413,7 @@ do_log(LogLevel level, const char *fmt, va_list args) > tmp_handler(level, fmtbuf, log_handler_ctx); > log_handler = tmp_handler; > } else if (log_on_stderr) { > + fmtbuf[sizeof(fmtbuf)-3] = '\0'; > snprintf(msgbuf, sizeof msgbuf, "%s\r\n", fmtbuf); > write(STDERR_FILENO, msgbuf, strlen(msgbuf)); > } else { > > > > On Wed, Dec 5, 2012 at 3:15 AM, Peter Stuge wrote: > >> Oliver Gasser wrote: >> > one-line attached patch. >> >> No patch. Make sure mimetype is text/plain. >> >> >> //Peter >> > > -------------- next part -------------- diff --git a/log.c b/log.c index ad5a10b..de3f451 100644 --- a/log.c +++ b/log.c @@ -413,6 +413,7 @@ do_log(LogLevel level, const char *fmt, va_list args) tmp_handler(level, fmtbuf, log_handler_ctx); log_handler = tmp_handler; } else if (log_on_stderr) { + fmtbuf[sizeof(fmtbuf)-3] = '\0'; snprintf(msgbuf, sizeof msgbuf, "%s\r\n", fmtbuf); write(STDERR_FILENO, msgbuf, strlen(msgbuf)); } else { From pjd at FreeBSD.org Wed Dec 12 01:01:41 2012 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue, 11 Dec 2012 15:01:41 +0100 Subject: evp_aes__ctr() vs. EVP_aes__ctr(). Message-ID: <20121211140141.GA1394@garage.freebsd.pl> Hi. OpenSSH currently has its own implementation of AES in counter mode (cipher-ctr.c). This is probably because it wasn't available in OpenSSL. From what I see now, recent OpenSSL does implement EVP_aes_{128,192,256}_ctr() and it would be nice to use it whenever possible. The gain here is that OpenSSH's version uses software AES implementation and OpenSSL's version will use AES-NI if available. Just FYI, unfortunately I cannot prepare nice and clean patch for this right now, but changing all evp_aes_128_ctr to EVP_aes_128_ctr, EVP_aes_192_ctr and EVP_aes_256_ctr respectively in ciphers[] array just works (thanks to the fact that 'c->evptype == evp_aes_128_ctr' is no longer true and IV is taken from cc->evp.iv).. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From aris at 0xbadc0de.be Wed Dec 12 06:07:19 2012 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Tue, 11 Dec 2012 20:07:19 +0100 Subject: evp_aes__ctr() vs. EVP_aes__ctr(). In-Reply-To: <20121211140141.GA1394@garage.freebsd.pl> References: <20121211140141.GA1394@garage.freebsd.pl> Message-ID: <50C78467.3060504@0xbadc0de.be> Hi, FYI OpenSSL used to provide broken AES-CTR in version 0.9.7a, shipped in RHEL 4.8. You can see more info on http://blog.0xbadc0de.be/archives/15 where I learned it the hard way when I got a bug reported to me in libssh. You may want to detect that version and fall back to software implementation. Kr, Aris Le 11/12/12 15:01, Pawel Jakub Dawidek a ?crit : > Hi. > > OpenSSH currently has its own implementation of AES in counter mode > (cipher-ctr.c). This is probably because it wasn't available in OpenSSL. > From what I see now, recent OpenSSL does implement > EVP_aes_{128,192,256}_ctr() and it would be nice to use it whenever > possible. The gain here is that OpenSSH's version uses software AES > implementation and OpenSSL's version will use AES-NI if available. > > Just FYI, unfortunately I cannot prepare nice and clean patch for this > right now, but changing all evp_aes_128_ctr to EVP_aes_128_ctr, > EVP_aes_192_ctr and EVP_aes_256_ctr respectively in ciphers[] array just > works (thanks to the fact that 'c->evptype == evp_aes_128_ctr' is no > longer true and IV is taken from cc->evp.iv).. > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From andrew at acooke.org Wed Dec 12 23:24:33 2012 From: andrew at acooke.org (andrew cooke) Date: Wed, 12 Dec 2012 09:24:33 -0300 Subject: HostKey in hardware? In-Reply-To: References: <20121121184930.GX11406@acooke.org> Message-ID: <20121212122433.GC14730@acooke.org> Hi, I have a client interested in using this patch and would appreciate help + advice on the best way to move forwards. My impression is that you're still thinking about the details (PIN etc) and so this is not in trunk? And even if it were in trunk, it wuld be for the FreeBSD reopo, which would then need porting (client on CentOS)? I imagine that's too far away to guesstimate a timeline? So I guess that the only thing I can offer my client now is to move the patch you provided across to CentOS myself and give them a custom patch / openssh source. Apart from the maintenance issues that would imply (which my client can worry about), what is your opinion of this approach (my client is already reading this thread)? The change seemed fairly simple to me, but I am no expert. Also, if I do any of the above, is there anything that could be fed back to you to help with your development? I guess not as I am effectively snapshotting a random idea... Sorry for all the questions and thanks for any guidance, Andrew On Fri, Nov 23, 2012 at 12:18:14PM +1100, Damien Miller wrote: > On Wed, 21 Nov 2012, andrew cooke wrote: > > > > > Hi, > > > > Is there any way to store HostKey in hardware (and delegate the related > > processing)? > > I've been wanting to do this for a while, but hadn't got around to it. > > Congratulations, you managed to troll me into action :) (see below) > > > The hardware I am using (Spyrus Lynks II) doesn't have PKCS#11 support, so I > > would prefer the OpenSSL route (since I already have an engine), but if > > necessary I would consider writing a minimal PKCS#11 implementation (can > > anyone give a rough idea of the amount of work involved to get HostKey > > working, only?) > > We aren't likely to add support for anything other than PKCS#11 host keys. > > Here's a (lightly tested) patch for PKCS#11 host keys. At the moment, the > keys are loaded using a fixed PIN of 0000, but there's probably a better > way to do it. I don't really want sshd to block at startup time while looking > for a password, but my PKCS#15-fu isn't good enough to know how to create > keys that don't require a PIN at all. > > diff --git servconf.c servconf.c > index 9919778..3670a2f 100644 > --- servconf.c > +++ servconf.c > @@ -67,6 +67,7 @@ initialize_server_options(ServerOptions *options) > options->listen_addrs = NULL; > options->address_family = -1; > options->num_host_key_files = 0; > + options->num_host_key_pkcs11_providers = 0; > options->num_host_cert_files = 0; > options->pid_file = NULL; > options->server_key_bits = -1; > @@ -160,6 +161,7 @@ fill_default_server_options(ServerOptions *options) > _PATH_HOST_ECDSA_KEY_FILE; > } > } > + /* No PKCS#11 providers by default */ > /* No certificates by default */ > if (options->num_ports == 0) > options->ports[options->num_ports++] = SSH_DEFAULT_PORT; > @@ -281,7 +283,8 @@ fill_default_server_options(ServerOptions *options) > /* Keyword tokens. */ > typedef enum { > sBadOption, /* == unknown option */ > - sPort, sHostKeyFile, sServerKeyBits, sLoginGraceTime, sKeyRegenerationTime, > + sPort, sHostKeyFile, sHostKeyPKCS11, sServerKeyBits, > + sLoginGraceTime, sKeyRegenerationTime, > sPermitRootLogin, sLogFacility, sLogLevel, > sRhostsRSAAuthentication, sRSAAuthentication, > sKerberosAuthentication, sKerberosOrLocalPasswd, sKerberosTicketCleanup, > @@ -324,6 +327,7 @@ static struct { > { "port", sPort, SSHCFG_GLOBAL }, > { "hostkey", sHostKeyFile, SSHCFG_GLOBAL }, > { "hostdsakey", sHostKeyFile, SSHCFG_GLOBAL }, /* alias */ > + { "hostkeypkcs11", sHostKeyPKCS11, SSHCFG_GLOBAL }, > { "pidfile", sPidFile, SSHCFG_GLOBAL }, > { "serverkeybits", sServerKeyBits, SSHCFG_GLOBAL }, > { "logingracetime", sLoginGraceTime, SSHCFG_GLOBAL }, > @@ -907,22 +911,33 @@ process_server_config_line(ServerOptions *options, char *line, > fatal("%s line %d: missing file name.", > filename, linenum); > if (*activep && *charptr == NULL) { > - *charptr = derelativise_path(arg); > + if (strcasecmp(arg, "none") == 0) > + *charptr = xstrdup("none"); > + else > + *charptr = derelativise_path(arg); > /* increase optional counter */ > if (intptr != NULL) > *intptr = *intptr + 1; > } > break; > > + case sHostKeyPKCS11: > + intptr = &options->num_host_key_pkcs11_providers; > + if (*intptr >= MAX_HOSTPKCS11) > + fatal("%s line %d: too many host key PKCS#11 providers " > + "specified (max %d).", filename, linenum, > + MAX_HOSTPKCS11); > + charptr = &options->host_key_pkcs11_providers[*intptr]; > + goto parse_filename; > + > case sHostCertificate: > intptr = &options->num_host_cert_files; > - if (*intptr >= MAX_HOSTKEYS) > + if (*intptr >= MAX_HOSTCERTS) > fatal("%s line %d: too many host certificates " > "specified (max %d).", filename, linenum, > MAX_HOSTCERTS); > charptr = &options->host_cert_files[*intptr]; > goto parse_filename; > - break; > > case sPidFile: > charptr = &options->pid_file; > @@ -1918,7 +1933,9 @@ dump_config(ServerOptions *o) > o->authorized_keys_files); > dump_cfg_strarray(sHostKeyFile, o->num_host_key_files, > o->host_key_files); > - dump_cfg_strarray(sHostKeyFile, o->num_host_cert_files, > + dump_cfg_strarray(sHostKeyPKCS11, o->num_host_key_pkcs11_providers, > + o->host_key_pkcs11_providers); > + dump_cfg_strarray(sHostCertificate, o->num_host_cert_files, > o->host_cert_files); > dump_cfg_strarray(sAllowUsers, o->num_allow_users, o->allow_users); > dump_cfg_strarray(sDenyUsers, o->num_deny_users, o->deny_users); > diff --git servconf.h servconf.h > index da2374b..e48b38a 100644 > --- servconf.h > +++ servconf.h > @@ -23,8 +23,9 @@ > #define MAX_ALLOW_GROUPS 256 /* Max # groups on allow list. */ > #define MAX_DENY_GROUPS 256 /* Max # groups on deny list. */ > #define MAX_SUBSYSTEMS 256 /* Max # subsystems. */ > -#define MAX_HOSTKEYS 256 /* Max # hostkeys. */ > -#define MAX_HOSTCERTS 256 /* Max # host certificates. */ > +#define MAX_HOSTKEYS 16 /* Max # hostkeys. */ > +#define MAX_HOSTCERTS 16 /* Max # host certificates. */ > +#define MAX_HOSTPKCS11 16 /* Max # host key PKCS#11 providers. */ > #define MAX_ACCEPT_ENV 256 /* Max # of env vars. */ > #define MAX_MATCH_GROUPS 256 /* Max # of groups for Match. */ > #define MAX_AUTHKEYS_FILES 256 /* Max # of authorized_keys files. */ > @@ -55,10 +56,17 @@ typedef struct { > char *listen_addr; /* Address on which the server listens. */ > struct addrinfo *listen_addrs; /* Addresses on which the server listens. */ > int address_family; /* Address family used by the server. */ > - char *host_key_files[MAX_HOSTKEYS]; /* Files containing host keys. */ > - int num_host_key_files; /* Number of files for host keys. */ > - char *host_cert_files[MAX_HOSTCERTS]; /* Files containing host certs. */ > - int num_host_cert_files; /* Number of files for host certs. */ > + > + /* Host key files */ > + char *host_key_files[MAX_HOSTKEYS]; > + int num_host_key_files; > + /* Host key PKCS#11 providers */ > + char *host_key_pkcs11_providers[MAX_HOSTPKCS11]; > + int num_host_key_pkcs11_providers; > + /* Host certificate files */ > + char *host_cert_files[MAX_HOSTCERTS]; > + int num_host_cert_files; > + > char *pid_file; /* Where to put our pid */ > int server_key_bits;/* Size of the server key. */ > int login_grace_time; /* Disconnect if no auth in this time > diff --git sshd.c sshd.c > index d3f53c0..83eab58 100644 > --- sshd.c > +++ sshd.c > @@ -105,6 +105,13 @@ > #include "ssh-sandbox.h" > #include "version.h" > > +#ifdef ENABLE_PKCS11 > +#include "ssh-pkcs11.h" > +#endif > + > +/* PIN used for PKCS#11 providers */ > +#define SSHD_PKCS11_PIN "0000" /* XXX */ > + > #ifdef LIBWRAP > #include > #include > @@ -188,6 +195,7 @@ Kex *xxx_kex; > struct { > Key *server_key; /* ephemeral server key */ > Key *ssh1_host_key; /* ssh1 host key */ > + int num_host_keys; /* number of private host keys */ > Key **host_keys; /* all private host keys */ > Key **host_certificates; /* all public host certificates */ > int have_ssh1_key; > @@ -534,7 +542,7 @@ destroy_sensitive_data(void) > key_free(sensitive_data.server_key); > sensitive_data.server_key = NULL; > } > - for (i = 0; i < options.num_host_key_files; i++) { > + for (i = 0; i < sensitive_data.num_host_keys; i++) { > if (sensitive_data.host_keys[i]) { > key_free(sensitive_data.host_keys[i]); > sensitive_data.host_keys[i] = NULL; > @@ -561,7 +569,7 @@ demote_sensitive_data(void) > sensitive_data.server_key = tmp; > } > > - for (i = 0; i < options.num_host_key_files; i++) { > + for (i = 0; i < sensitive_data.num_host_keys; i++) { > if (sensitive_data.host_keys[i]) { > tmp = key_demote(sensitive_data.host_keys[i]); > key_free(sensitive_data.host_keys[i]); > @@ -747,7 +755,7 @@ list_hostkey_types(void) > Key *key; > > buffer_init(&b); > - for (i = 0; i < options.num_host_key_files; i++) { > + for (i = 0; i < sensitive_data.num_host_keys; i++) { > key = sensitive_data.host_keys[i]; > if (key == NULL) > continue; > @@ -791,7 +799,7 @@ get_hostkey_by_type(int type, int need_private) > int i; > Key *key; > > - for (i = 0; i < options.num_host_key_files; i++) { > + for (i = 0; i < sensitive_data.num_host_keys; i++) { > switch (type) { > case KEY_RSA_CERT_V00: > case KEY_DSA_CERT_V00: > @@ -826,7 +834,7 @@ get_hostkey_private_by_type(int type) > Key * > get_hostkey_by_index(int ind) > { > - if (ind < 0 || ind >= options.num_host_key_files) > + if (ind < 0 || ind >= sensitive_data.num_host_keys) > return (NULL); > return (sensitive_data.host_keys[ind]); > } > @@ -836,7 +844,7 @@ get_hostkey_index(Key *key) > { > int i; > > - for (i = 0; i < options.num_host_key_files; i++) { > + for (i = 0; i < sensitive_data.num_host_keys; i++) { > if (key_is_cert(key)) { > if (key == sensitive_data.host_certificates[i]) > return (i); > @@ -1296,7 +1304,7 @@ main(int ac, char **av) > { > extern char *optarg; > extern int optind; > - int opt, i, j, on = 1; > + int opt, i, j, nkeys, on = 1; > int sock_in = -1, sock_out = -1, newsock = -1; > const char *remote_ip; > int remote_port; > @@ -1305,7 +1313,7 @@ main(int ac, char **av) > u_int n; > u_int64_t ibytes, obytes; > mode_t new_umask; > - Key *key; > + Key *key, **keys; > Authctxt *authctxt; > struct connection_info *connection_info = get_connection_info(0, 0); > > @@ -1530,20 +1538,54 @@ main(int ac, char **av) > debug("sshd version %.100s", SSH_VERSION); > > /* load private host keys */ > - sensitive_data.host_keys = xcalloc(options.num_host_key_files, > - sizeof(Key *)); > - for (i = 0; i < options.num_host_key_files; i++) > - sensitive_data.host_keys[i] = NULL; > + sensitive_data.host_keys = xcalloc(options.num_host_key_files + > + options.num_host_key_pkcs11_providers, sizeof(Key *)); > + sensitive_data.num_host_keys = 0; > + > +#ifdef ENABLE_PKCS11 > + if (options.num_host_key_pkcs11_providers > 0) { > + if (pkcs11_init(0) != 0) > + fatal("Could not initialise PKCS#11 for host keys"); > + for (i = 0; i < options.num_host_key_pkcs11_providers; i++) { > + nkeys = pkcs11_add_provider( > + options.host_key_pkcs11_providers[i], > + SSHD_PKCS11_PIN, &keys); > + if (nkeys == -1) > + fatal("Failed to add PKCS#11 provider \"%s\"", > + options.host_key_pkcs11_providers[i]); > + if (nkeys == 0) { > + error("PKCS#11 provider \"%s\" yielded no keys", > + options.host_key_pkcs11_providers[i]); > + continue; > + } > + for (j = 0; j < nkeys; j++) { > + sensitive_data.host_keys[ > + sensitive_data.num_host_keys++] = keys[j]; > + } > + free(keys); > + } > + } > +#endif /* ENABLE_PKCS11 */ > > for (i = 0; i < options.num_host_key_files; i++) { > + if (strcasecmp(options.host_key_files[i], "none") == 0) > + continue; > key = key_load_private(options.host_key_files[i], "", NULL); > - sensitive_data.host_keys[i] = key; > + sensitive_data.host_keys[sensitive_data.num_host_keys++] = key; > if (key == NULL) { > error("Could not load host key: %s", > options.host_key_files[i]); > - sensitive_data.host_keys[i] = NULL; > continue; > } > + debug("private host key: #%d type %d %s", > + sensitive_data.num_host_keys - 1, key->type, key_type(key)); > + } > + > + /* Figure out whether we have loaded keys for protocols 1 and 2 */ > + for (i = 0; i < sensitive_data.num_host_keys; i++) { > + key = sensitive_data.host_keys[i]; > + if (key == NULL) > + continue; > switch (key->type) { > case KEY_RSA1: > sensitive_data.ssh1_host_key = key; > @@ -1555,9 +1597,8 @@ main(int ac, char **av) > sensitive_data.have_ssh2_key = 1; > break; > } > - debug("private host key: #%d type %d %s", i, key->type, > - key_type(key)); > } > + > if ((options.protocol & SSH_PROTO_1) && !sensitive_data.have_ssh1_key) { > logit("Disabling protocol version 1. Could not load host key"); > options.protocol &= ~SSH_PROTO_1; > @@ -1575,9 +1616,9 @@ main(int ac, char **av) > * Load certificates. They are stored in an array at identical > * indices to the public keys that they relate to. > */ > - sensitive_data.host_certificates = xcalloc(options.num_host_key_files, > + sensitive_data.host_certificates = xcalloc(sensitive_data.num_host_keys, > sizeof(Key *)); > - for (i = 0; i < options.num_host_key_files; i++) > + for (i = 0; i < sensitive_data.num_host_keys; i++) > sensitive_data.host_certificates[i] = NULL; > > for (i = 0; i < options.num_host_cert_files; i++) { > @@ -1594,14 +1635,14 @@ main(int ac, char **av) > continue; > } > /* Find matching private key */ > - for (j = 0; j < options.num_host_key_files; j++) { > + for (j = 0; j < sensitive_data.num_host_keys; j++) { > if (key_equal_public(key, > sensitive_data.host_keys[j])) { > sensitive_data.host_certificates[j] = key; > break; > } > } > - if (j >= options.num_host_key_files) { > + if (j >= sensitive_data.num_host_keys) { > error("No matching private key for certificate: %s", > options.host_cert_files[i]); > key_free(key); > diff --git sshd_config.5 sshd_config.5 > index 91935d0..5ec06f2 100644 > --- sshd_config.5 > +++ sshd_config.5 > @@ -517,6 +517,10 @@ for protocol version 1, and > and > .Pa /etc/ssh/ssh_host_rsa_key > for protocol version 2. > +It is possible to skip loading of host keys by specifying a path of > +.Pa none > +in cases where keys are supplied via > +.Cm HostKeyPKCS11 . > Note that > .Xr sshd 8 > will refuse to use a file if it is group/world-accessible. > @@ -528,6 +532,15 @@ keys are used for version 1 and > or > .Dq rsa > are used for version 2 of the SSH protocol. > +.It Cm HostKeyPKCS11 > +Specify a PKCS#11 provider for host keys. > +.Nm > +will attempt to load all keys in this device assuming a PIN of > +.Dq 0000 > +and use them as host keys. > +This option may be specified more than once to allow loading of host keys > +from multiple devices. > +The default is not to attempt to load host keys from PKCS#11 devices. > .It Cm IgnoreRhosts > Specifies that > .Pa .rhosts > From djm at mindrot.org Fri Dec 14 16:23:50 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 14 Dec 2012 16:23:50 +1100 (EST) Subject: HostKey in hardware? In-Reply-To: <20121212122433.GC14730@acooke.org> References: <20121121184930.GX11406@acooke.org> <20121212122433.GC14730@acooke.org> Message-ID: On Wed, 12 Dec 2012, andrew cooke wrote: > > Hi, > > I have a client interested in using this patch and would appreciate help + > advice on the best way to move forwards. > > My impression is that you're still thinking about the details (PIN etc) and so > this is not in trunk? And even if it were in trunk, it wuld be for the > FreeBSD reopo, which would then need porting (client on CentOS)? I imagine > that's too far away to guesstimate a timeline? I'm looking into rewriting it to use ssh-agent in sshd for keys rather than loading PKCS#11 providers directly. I'd like to get this done before the 6.2 release due early next year, but I can't promise anything. > So I guess that the only thing I can offer my client now is to move the patch > you provided across to CentOS myself and give them a custom patch / openssh > source. Yes. > Apart from the maintenance issues that would imply (which my client can worry > about), what is your opinion of this approach (my client is already reading > this thread)? The change seemed fairly simple to me, but I am no expert. It's up to you and your client to qualify any change. Personally, I'd be comfortable running that patch if my host had only a single token with a single key attached. -d From flavien-ssh at lebarbe.net Fri Dec 14 22:18:21 2012 From: flavien-ssh at lebarbe.net (Flavien Lebarbe) Date: Fri, 14 Dec 2012 12:18:21 +0100 Subject: SSH 5.8p1 hang in kernel mode / AIX 7.1 Message-ID: <20121214111821.GA861@srv3.flavien.org> Hello, An AIX machine runs a program that forks ssh client in order to launch commands on a remote. I'm first seting up a Master connection with a ControlPath, then using that connection to launch various commands on the remote, and killing the master by issuing a "-O exit" command. SSH client version on that machine is : # ssh -V OpenSSH_5.8p1, OpenSSL 0.9.8r 8 Feb 2011 # uname -nrsv AIX P7_AIX7 1 7 The program runs every 5 minutes for about 10s or so, gathering the information from the remote just fine. Now, I'm looking at the output of "ps" and see some left-over processes : root 5832832 1 69 22 nov - 5424:59 ssh -o BatchMode=yes -o ControlPath=/opt/data/ssh-socket_A-10.10.14.126 -o User=foobar 10.10.14.126 remote_command This instance of ssh client should not be there anymore. Having a deeper look: * kill -9 on that process does not kill it. * The corresponding ControlPath socket does not exist anymore on the system, nor does the ssh master process for this socket. * truss on that process does not show any activity at all: the process is apparently inside a system call. * kernel activity on the machine as reported by topas is 99% * ls -l /proc/5832832/fd only shows 3 FDs : # ls -l /proc/5832832/fd 0 total c--------- 1 root system 2, 2 14 d? 11:22 0 p--------- 0 root system 0 22 nov 06:18 1 c--------- 1 root system 2, 2 14 d? 11:22 2 I have currently 6 of those processes running on this system. Some of them are running for weeks like the above. Others are running for days. This situation looks like a kernel bug to me. Do you have any idea of anything that might be triggering it in the OpenSSH code in this old version of OpenSSH ? Thanks, Flavien. From DAaron at trustwave.com Sat Dec 15 09:10:51 2012 From: DAaron at trustwave.com (David Aaron) Date: Fri, 14 Dec 2012 22:10:51 +0000 Subject: CVE-2006-4925 - Affected OpenSSH Versions Message-ID: <556068DBCD01BF40AB052D4173D3802F079704@SKYMB2.trustwave.com> Comparison of http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/openssh-4.4.tar.gz to http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/openssh-4.5.tar.gz source codes, in conjunction with the changes shown at http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/packet.c.diff?r1=1.144&r2=1.145&f=h, appear to shows that CVE-2006-4925 was fixed with the release of OpenSSH 4.5. However, can a list of OpenSSH versions which are/were affected by this CVE be supplied? I ask as there seems to be little in the way of documentation at http://www.openssh.com regarding CVE-2006-4925. ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. From djm at mindrot.org Mon Dec 17 11:56:10 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Dec 2012 11:56:10 +1100 (EST) Subject: CVE-2006-4925 - Affected OpenSSH Versions In-Reply-To: <556068DBCD01BF40AB052D4173D3802F079704@SKYMB2.trustwave.com> References: <556068DBCD01BF40AB052D4173D3802F079704@SKYMB2.trustwave.com> Message-ID: On Fri, 14 Dec 2012, David Aaron wrote: > Comparison of > http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/openssh-4.4.tar.gz to > http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/openssh-4.5.tar.gz > source codes, in conjunction with the changes shown at > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/packet.c.diff?r1 > =1.144&r2=1.145&f=h, appear to shows that CVE-2006-4925 was fixed with > the release of OpenSSH 4.5. > > However, can a list of OpenSSH versions which are/were affected by > this CVE be supplied? > > I ask as there seems to be little in the way of documentation at > http://www.openssh.com regarding CVE-2006-4925. That's because it isn't a security problem. An "attacker" can cause their own connection to abort and no others. -d From john.m.olsson at ericsson.com Mon Dec 17 22:13:19 2012 From: john.m.olsson at ericsson.com (John Olsson M) Date: Mon, 17 Dec 2012 11:13:19 +0000 Subject: How to control which command is executed with "plain ssh" from remote machine? Message-ID: <56C5269167653F4EB997E85F8CBB32990A05A3@ESESSMB301.ericsson.se> Hi! Is it possible to override in OpenSSH so that the shell specified in the /etc/passwd (or what comes from the LDAP server) is not executed at login? We have na?vely tried to specify this with subsystem but found out that by default the ssh client does not specify any subsystem. So how to override something that is unset from the client? /John -- John Olsson Ericsson AB BSC/BSS System Management -------------------------------------------------- Tel: +46 (0)10 7114 666 Mobile: +46 (0)730 43 53 44 -------------------------------------------------- From DAaron at trustwave.com Tue Dec 18 02:53:18 2012 From: DAaron at trustwave.com (David Aaron) Date: Mon, 17 Dec 2012 15:53:18 +0000 Subject: CVE-2006-4925 - Affected OpenSSH Versions In-Reply-To: Message-ID: <556068DBCD01BF40AB052D4173D3802F079983@SKYMB2.trustwave.com> Thank you for the previous information. However, http://www.securityfocus.com/archive/1/archive/1/447153/100/0/threaded, which is associated with CVE-2006-4925, explains the following: "Previous versions of the openssh package are vulnerable to a remote denial of service attack that cause the server to consume CPU when presented with certain data. They also have a bug (not a vulnerability) that causes the client to crash harmlessly instead of exiting cleanly under some attacks; this is not a vulnerability but is also fixed in this update." As such it would appear that there is a client side issue, as has been suggested, but also that there is a server side DoS issue as well. The server side DoS is the vulnerability of interest here. Is it being suggested that there is no server side DoS which is actually exploitable via CVE-2006-4925 (and that there is just a relitvely harmless client side crashing issue)? If there is a server side DoS vulnerability, then we at Trustwave would still be interested in knowing the versions of OpenSSH affected by CVE-2006-4925. David Aaron Security Researcher Trustwave www.trustwave.com On 12/16/12 6:56 PM, "Damien Miller" wrote: >On Fri, 14 Dec 2012, David Aaron wrote: > >> Comparison of >> http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/openssh-4.4.tar.gz to >> http://mirror.team-cymru.org/pub/OpenBSD/OpenSSH/openssh-4.5.tar.gz >> source codes, in conjunction with the changes shown at >> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/packet.c.diff?r1 >> =1.144&r2=1.145&f=h, appear to shows that CVE-2006-4925 was fixed with >> the release of OpenSSH 4.5. >> >> However, can a list of OpenSSH versions which are/were affected by >> this CVE be supplied? >> >> I ask as there seems to be little in the way of documentation at >> http://www.openssh.com regarding CVE-2006-4925. > >That's because it isn't a security problem. An "attacker" can cause their >own connection to abort and no others. > >-d > ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. From imorgan at nas.nasa.gov Tue Dec 18 05:18:23 2012 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 17 Dec 2012 10:18:23 -0800 Subject: How to control which command is executed with "plain ssh" from remote machine? In-Reply-To: <56C5269167653F4EB997E85F8CBB32990A05A3@ESESSMB301.ericsson.se> References: <56C5269167653F4EB997E85F8CBB32990A05A3@ESESSMB301.ericsson.se> Message-ID: <20121217181823.GA3451@linux124.nas.nasa.gov> On Mon, Dec 17, 2012 at 05:13:19 -0600, John Olsson M wrote: > Hi! > > Is it possible to override in OpenSSH so that the shell specified in the /etc/passwd (or what comes from the LDAP server) is not executed at login? > > We have na?vely tried to specify this with subsystem but found out that by default the ssh client does not specify any subsystem. So how to override something that is unset from the client? > > > /John > OpenSSH does not provide the ability to override the user's shell. At times, I have contemplated submitting a patch to implement a ForceShell option that would do this, but I haven't gotten around to writing any code yet. I hope to take a look at this in the near future. Since you mentioned LDAP, the client software which you are using may provide the ability to override the user's shell. For example, nslcd and recent versions of sssd can do this. However, they may not have the flexibility that you are looking for. -- Iain Morgan From bil_hays at unc.edu Tue Dec 18 07:22:22 2012 From: bil_hays at unc.edu (hays) Date: Mon, 17 Dec 2012 15:22:22 -0500 Subject: reporting... Message-ID: <07F434E5-01AC-45EB-884C-DD5370EC64BA@unc.edu> Got this building portable openssh on os x 10.8.2, reporting as requested. checking for sandbox_init... yes checking sandbox.h usability... no checking sandbox.h presence... yes configure: WARNING: sandbox.h: present but cannot be compiled configure: WARNING: sandbox.h: check for missing prerequisite headers? configure: WARNING: sandbox.h: see the Autoconf documentation configure: WARNING: sandbox.h: section "Present But Cannot Be Compiled" configure: WARNING: sandbox.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## -- ________________________ bil hays Infrastructure Manager Computer Science, UNC CH http://www.cs.unc.edu/~hays/ From dtucker at zip.com.au Tue Dec 18 09:27:12 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Dec 2012 09:27:12 +1100 Subject: reporting... In-Reply-To: <07F434E5-01AC-45EB-884C-DD5370EC64BA@unc.edu> References: <07F434E5-01AC-45EB-884C-DD5370EC64BA@unc.edu> Message-ID: <20121217222712.GA23159@gate.dtucker.net> On Mon, Dec 17, 2012 at 03:22:22PM -0500, hays wrote: > Got this building portable openssh on os x 10.8.2, reporting as requested. > > checking for sandbox_init... yes > checking sandbox.h usability... no > checking sandbox.h presence... yes > configure: WARNING: sandbox.h: present but cannot be compiled could you please take a look in config.log and see what the actual error message is? it'll be a compile error before the error above, but in between that there'll be lots of #defines and configure settings. 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 mindrot.org Tue Dec 18 09:39:31 2012 From: djm at mindrot.org (Damien Miller) Date: Tue, 18 Dec 2012 09:39:31 +1100 (EST) Subject: CVE-2006-4925 - Affected OpenSSH Versions In-Reply-To: <556068DBCD01BF40AB052D4173D3802F079983@SKYMB2.trustwave.com> References: <556068DBCD01BF40AB052D4173D3802F079983@SKYMB2.trustwave.com> Message-ID: On Mon, 17 Dec 2012, David Aaron wrote: > Thank you for the previous information. > > However, > http://www.securityfocus.com/archive/1/archive/1/447153/100/0/threaded, > which is associated with CVE-2006-4925, explains the following: > > "Previous versions of the openssh package are vulnerable to a > remote denial of service attack that cause the server to consume > CPU when presented with certain data. They also have a bug (not > a vulnerability) that causes the client to crash harmlessly > instead of exiting cleanly under some attacks; this is not a > vulnerability but is also fixed in this update." > > As such it would appear that there is a client side issue, as has been > suggested, but also that there is a server side DoS issue as well. The > server side DoS is the vulnerability of interest here. The server DoS is: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2006-4924 This is actually mentioned in the securityfocus discussion you referred to. From peter at stuge.se Tue Dec 18 10:10:41 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 18 Dec 2012 00:10:41 +0100 Subject: How to control which command is executed with "plain ssh" from remote machine? In-Reply-To: <56C5269167653F4EB997E85F8CBB32990A05A3@ESESSMB301.ericsson.se> References: <56C5269167653F4EB997E85F8CBB32990A05A3@ESESSMB301.ericsson.se> Message-ID: <20121217231041.27554.qmail@stuge.se> Hej John, John Olsson M wrote: > found out that by default the ssh client does not specify any > subsystem. Please, *please*, read the SSH protocol RFCs, they are a very quick read and they are an *excellent* way to learn the protocol. Please, *please*, stop wasting time making guesses about things which are really well documented. http://tools.ietf.org/html/rfc4250 SSH Protocol Assigned Numbers http://tools.ietf.org/html/rfc4251 SSH Protocol Architecture http://tools.ietf.org/html/rfc4252 SSH Authentication Protocol http://tools.ietf.org/html/rfc4253 SSH Transport Layer Protocol http://tools.ietf.org/html/rfc4254 SSH Connection Protocol http://tools.ietf.org/html/rfc4256 Generic Message Exchange for SSH Authentication AKA keyboard-interactive //Peter From tim at multitalents.net Wed Dec 19 08:14:56 2012 From: tim at multitalents.net (Tim Rice) Date: Tue, 18 Dec 2012 13:14:56 -0800 (PST) Subject: reporting... In-Reply-To: <20121217222712.GA23159@gate.dtucker.net> References: <07F434E5-01AC-45EB-884C-DD5370EC64BA@unc.edu> <20121217222712.GA23159@gate.dtucker.net> Message-ID: On Tue, 18 Dec 2012, Darren Tucker wrote: > On Mon, Dec 17, 2012 at 03:22:22PM -0500, hays wrote: > > Got this building portable openssh on os x 10.8.2, reporting as requested. > > > > checking for sandbox_init... yes > > checking sandbox.h usability... no > > checking sandbox.h presence... yes > > configure: WARNING: sandbox.h: present but cannot be compiled > > could you please take a look in config.log and see what the actual error > message is? it'll be a compile error before the error above, but in > between that there'll be lots of #defines and configure settings. > > thanks. I had a look at this on my Lion box. ........ In file included from conftest.c:101: /usr/include/sandbox.h:98:29: error: sandbox/private.h: No such file or directory ........ Indeed sandbox/private.h does not exist. The offending code looks like this #ifdef __APPLE_API_PRIVATE #ifndef _SANDBOX_INTERNAL_ #define _SANDBOX_INDIRECT_ #include #undef _SANDBOX_INDIRECT_ #endif #endif Now we're not defining __APPLE_API_PRIVATE anywhere. "gcc -E -dM - < /dev/null" doesn't show __APPLE_API_PRIVATE Digging deeper, I find it is defined in sys/appleapiopts.h that sys/types.h pulls in. The __APPLE_API_PRIVATE (and __APPLE_API_EVOLVING, __APPLE_API_UNSTABLE, and __APPLE_API_OBSOLETE) are guarded with a #ifndef __APPLE_API_STRICT_CONFORMANCE so if we want to quiet down that warning we could define __APPLE_API_STRICT_CONFORMANCE before testing for sandbox.h -- Tim Rice Multitalents tim at multitalents.net From wp02855 at gmail.com Fri Dec 21 06:03:01 2012 From: wp02855 at gmail.com (Bill Parker) Date: Thu, 20 Dec 2012 11:03:01 -0800 Subject: Deprecated calls to bzero() and index() found in OpenSSH 6.1p1 Message-ID: Hello All, In reviewing source code for OpenSSH-6.1p1, I found instances of deprecated library calls still within various source code files. Examples of deprecated calls are: bzero() (replaced with memset() which is ANSI compliant), index() (replaced with strchr() which is also ANSI compliant). In file 'auth2-jpake.c', I've replaced all the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- auth2-jpake.c.orig 2012-12-19 17:01:52.817528171 -0800 +++ auth2-jpake.c 2012-12-19 17:05:59.044554766 -0800 @@ -178,7 +178,7 @@ fatal("%s: not enough bytes for rawsalt (want %u have %u)", __func__, len, digest_len); memcpy(rawsalt, digest, len); - bzero(digest, digest_len); + memset(digest, 0, digest_len); xfree(digest); } @@ -203,10 +203,10 @@ fatal("%s: want %u", __func__, want); derive_rawsalt(user, rawsalt, sizeof(rawsalt)); - bzero(ret, sizeof(ret)); + memset(ret, 0, sizeof(ret)); for (i = 0; i < want; i++) ret[i] = pw_encode64(rawsalt[i]); - bzero(rawsalt, sizeof(rawsalt)); + memset(rawsalt, 0, sizeof(rawsalt)); return ret; } @@ -360,7 +360,7 @@ debug3("%s: scheme = %s", __func__, *hash_scheme); JPAKE_DEBUG_BN((*s, "%s: s = ", __func__)); #endif - bzero(secret, secret_len); + memset(secret, 0, secret_len); xfree(secret); } @@ -401,12 +401,12 @@ packet_send(); packet_write_wait(); - bzero(hash_scheme, strlen(hash_scheme)); - bzero(salt, strlen(salt)); + memset(hash_scheme, 0, strlen(hash_scheme)); + memset(salt, 0, strlen(salt)); xfree(hash_scheme); xfree(salt); - bzero(x3_proof, x3_proof_len); - bzero(x4_proof, x4_proof_len); + memset(x3_proof, 0, x3_proof_len); + memset(x4_proof, 0, x4_proof_len); xfree(x3_proof); xfree(x4_proof); @@ -453,8 +453,8 @@ &pctx->b, &x4_s_proof, &x4_s_proof_len)); - bzero(x1_proof, x1_proof_len); - bzero(x2_proof, x2_proof_len); + memset(x1_proof, 0, x1_proof_len); + mmeset(x2_proof, 0, x2_proof_len); xfree(x1_proof); xfree(x2_proof); @@ -468,7 +468,7 @@ packet_send(); packet_write_wait(); - bzero(x4_s_proof, x4_s_proof_len); + memset(x4_s_proof, 0, x4_s_proof_len); xfree(x4_s_proof); /* Expect step 2 packet from peer */ @@ -509,7 +509,7 @@ &pctx->k, &pctx->h_k_sid_sessid, &pctx->h_k_sid_sessid_len)); - bzero(x2_s_proof, x2_s_proof_len); + memset(x2_s_proof, 0, x2_s_proof_len); xfree(x2_s_proof); if (!use_privsep) In file 'authfd.c', I've replaced the bzero() call with the equivalent memset() call. The patch file is below in (diff -u) format: --- authfd.c.orig 2012-12-19 17:07:08.292534290 -0800 +++ authfd.c 2012-12-19 17:10:48.240556291 -0800 @@ -102,7 +102,7 @@ if (!authsocket) return -1; - bzero(&sunaddr, sizeof(sunaddr)); + memset(&sunaddr, 0, sizeof(sunaddr)); sunaddr.sun_family = AF_UNIX; strlcpy(sunaddr.sun_path, authsocket, sizeof(sunaddr.sun_path)); In file 'authfile.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- authfile.c.orig 2012-12-19 17:11:06.537523347 -0800 +++ authfile.c 2012-12-19 17:12:03.999868720 -0800 @@ -349,17 +349,17 @@ __func__, filename == NULL ? "" : filename, filename == NULL ? "" : " ", strerror(errno)); buffer_clear(blob); - bzero(buf, sizeof(buf)); + memset(buf, 0, sizeof(buf)); return 0; } buffer_append(blob, buf, len); if (buffer_len(blob) > MAX_KEY_FILE_SIZE) { buffer_clear(blob); - bzero(buf, sizeof(buf)); + memset(buf, 0, sizeof(buf)); goto toobig; } } - bzero(buf, sizeof(buf)); + memset(buf, 0, sizeof(buf)); if ((st.st_mode & (S_IFSOCK|S_IFCHR|S_IFIFO)) == 0 && st.st_size != buffer_len(blob)) { debug("%s: key file %.200s%schanged size while reading", In file 'bufaux.c', I've replaced the bzero() call with the equivalent memset() call. The patch file is below in (diff -u) format: --- bufaux.c.orig 2012-12-19 17:12:21.672509848 -0800 +++ bufaux.c 2012-12-19 17:12:44.902553992 -0800 @@ -215,7 +215,7 @@ if (cp == ret + length - 1) error("buffer_get_cstring_ret: string contains \\0"); else { - bzero(ret, length); + memset(ret, 0, length); xfree(ret); return NULL; } In file 'bufec.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- bufec.c.orig 2012-12-19 17:13:00.367528026 -0800 +++ bufec.c 2012-12-19 17:13:26.725554444 -0800 @@ -77,7 +77,7 @@ ret = 0; out: if (buf != NULL) { - bzero(buf, len); + memset(buf, 0, len); xfree(buf); } BN_CTX_free(bnctx); @@ -130,7 +130,7 @@ ret = 0; out: BN_CTX_free(bnctx); - bzero(buf, len); + memset(buf, 0, len); xfree(buf); return ret; } In file 'canohost.c', I've replaced the bzero() call with the equivalent memset() call. The patch file is below in (diff -u) format: --- canohost.c.orig 2012-12-19 17:13:41.958551344 -0800 +++ canohost.c 2012-12-19 17:14:05.773567216 -0800 @@ -199,7 +199,7 @@ memcpy(&inaddr, ((char *)&a6->sin6_addr) + 12, sizeof(inaddr)); port = a6->sin6_port; - bzero(a4, sizeof(*a4)); + memset(a4, 0, sizeof(*a4)); a4->sin_family = AF_INET; *len = sizeof(*a4); In file 'channels.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- channels.c.orig 2012-12-19 17:14:18.911938266 -0800 +++ channels.c 2012-12-19 17:15:04.724553211 -0800 @@ -425,7 +425,7 @@ if (cc->abandon_cb != NULL) cc->abandon_cb(c, cc->ctx); TAILQ_REMOVE(&c->status_confirms, cc, entry); - bzero(cc, sizeof(*cc)); + memset(cc, 0, sizeof(*cc)); xfree(cc); } if (c->filter_cleanup != NULL && c->filter_ctx != NULL) @@ -2667,7 +2667,7 @@ return; cc->cb(type, c, cc->ctx); TAILQ_REMOVE(&c->status_confirms, cc, entry); - bzero(cc, sizeof(*cc)); + memset(cc, 0, sizeof(*cc)); xfree(cc); } @@ -3296,7 +3296,7 @@ xfree(cctx->host); if (cctx->aitop) freeaddrinfo(cctx->aitop); - bzero(cctx, sizeof(*cctx)); + memset(cctx, 0, sizeof(*cctx)); cctx->host = NULL; cctx->ai = cctx->aitop = NULL; } In file 'clientloop.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- clientloop.c.orig 2012-12-19 17:15:16.548673571 -0800 +++ clientloop.c 2012-12-19 17:15:52.244510839 -0800 @@ -551,7 +551,7 @@ gc->cb(type, seq, gc->ctx); if (--gc->ref_count <= 0) { TAILQ_REMOVE(&global_confirms, gc, entry); - bzero(gc, sizeof(*gc)); + memset(gc, 0, sizeof(*gc)); xfree(gc); } @@ -867,7 +867,7 @@ int cancel_port, ok; Forward fwd; - bzero(&fwd, sizeof(fwd)); + memset(&fwd, 0, sizeof(fwd)); fwd.listen_host = fwd.connect_host = NULL; leave_raw_mode(options.request_tty == REQUEST_TTY_FORCE); In file 'hostfile.c', I've replaced the bzero() call with the equivalent memset() call. The patch file is below in (diff -u) format: --- hostfile.c.orig 2012-12-19 17:19:15.393667218 -0800 +++ hostfile.c 2012-12-19 17:19:50.752556571 -0800 @@ -330,7 +330,7 @@ xfree(hostkeys->entries[i].host); xfree(hostkeys->entries[i].file); key_free(hostkeys->entries[i].key); - bzero(hostkeys->entries + i, sizeof(*hostkeys->entries)); + memset(hostkeys->entries + i, 0, sizeof(*hostkeys->entries)); } if (hostkeys->entries != NULL) xfree(hostkeys->entries); In file 'jpake.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- jpake.c.orig 2012-12-19 17:20:06.946529817 -0800 +++ jpake.c 2012-12-19 17:21:32.343510968 -0800 @@ -105,7 +105,7 @@ #define JPAKE_BUF_CLEAR_FREE(v, l) \ do { \ if ((v) != NULL) { \ - bzero((v), (l)); \ + memset((v), 0, (l)); \ xfree(v); \ (v) = NULL; \ (l) = 0; \ @@ -133,7 +133,7 @@ #undef JPAKE_BN_CLEAR_FREE #undef JPAKE_BUF_CLEAR_FREE - bzero(pctx, sizeof(*pctx)); + memset(pctx, 0, sizeof(*pctx)); xfree(pctx); } @@ -444,7 +444,7 @@ else if (timingsafe_bcmp(peer_confirm_hash, expected_confirm_hash, expected_confirm_hash_len) == 0) success = 1; - bzero(expected_confirm_hash, expected_confirm_hash_len); + memset(expected_confirm_hash, 0, expected_confirm_hash_len); xfree(expected_confirm_hash); debug3("%s: success = %d", __func__, success); return success; In file 'monitor.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- monitor.c.orig 2012-12-19 17:22:45.966559767 -0800 +++ monitor.c 2012-12-19 17:26:41.827534855 -0800 @@ -547,7 +547,7 @@ struct pollfd pfd[2]; for (;;) { - bzero(&pfd, sizeof(pfd)); + memset(&pfd, 0, sizeof(pfd)); pfd[0].fd = pmonitor->m_sendfd; pfd[0].events = POLLIN; pfd[1].fd = pmonitor->m_log_recvfd; @@ -2137,8 +2137,8 @@ debug3("%s: sending step1", __func__); mm_request_send(sock, MONITOR_ANS_JPAKE_STEP1, m); - bzero(x3_proof, x3_proof_len); - bzero(x4_proof, x4_proof_len); + memset(x3_proof, 0, x3_proof_len); + memset(x4_proof, 0, x4_proof_len); xfree(x3_proof); xfree(x4_proof); @@ -2167,8 +2167,8 @@ debug3("%s: sending pwdata", __func__); mm_request_send(sock, MONITOR_ANS_JPAKE_GET_PWDATA, m); - bzero(hash_scheme, strlen(hash_scheme)); - bzero(salt, strlen(salt)); + memset(hash_scheme, 0, strlen(hash_scheme)); + memset(salt, 0, strlen(salt)); xfree(hash_scheme); xfree(salt); @@ -2207,8 +2207,8 @@ JPAKE_DEBUG_CTX((pctx, "step2 done in %s", __func__)); - bzero(x1_proof, x1_proof_len); - bzero(x2_proof, x2_proof_len); + memset(x1_proof, 0, x1_proof_len); + memset(x2_proof, 0, x2_proof_len); xfree(x1_proof); xfree(x2_proof); @@ -2220,7 +2220,7 @@ debug3("%s: sending step2", __func__); mm_request_send(sock, MONITOR_ANS_JPAKE_STEP2, m); - bzero(x4_s_proof, x4_s_proof_len); + memset(x4_s_proof, 0, x4_s_proof_len); xfree(x4_s_proof); monitor_permit(mon_dispatch, MONITOR_REQ_JPAKE_KEY_CONFIRM, 1); @@ -2254,7 +2254,7 @@ JPAKE_DEBUG_CTX((pctx, "key_confirm done in %s", __func__)); - bzero(x2_s_proof, x2_s_proof_len); + memset(x2_s_proof, 0, x2_s_proof_len); buffer_clear(m); /* pctx->k is sensitive, not sent */ @@ -2288,7 +2288,7 @@ JPAKE_DEBUG_CTX((pctx, "check_confirm done in %s", __func__)); - bzero(peer_confirm_hash, peer_confirm_hash_len); + memset(peer_confirm_hash, 0, peer_confirm_hash_len); xfree(peer_confirm_hash); buffer_clear(m); In file 'sandbox-systrace.c', I've replaced the bzero() call with the equivalent memset() call. The patch file is below in (diff -u) format: --- sandbox-systrace.c.orig 2012-12-19 17:27:48.258532654 -0800 +++ sandbox-systrace.c 2012-12-19 17:28:12.705825672 -0800 @@ -140,7 +140,7 @@ box->systrace_fd, child_pid, strerror(errno)); /* Allocate and assign policy */ - bzero(&policy, sizeof(policy)); + memset(&policy, 0, sizeof(policy)); policy.strp_op = SYSTR_POLICY_NEW; policy.strp_maxents = SYS_MAXSYSCALL; if (ioctl(box->systrace_fd, STRIOCPOLICY, &policy) == -1) In file 'schnorr.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- schnorr.c.orig 2012-12-19 17:28:24.666675070 -0800 +++ schnorr.c 2012-12-19 17:29:14.920563605 -0800 @@ -101,7 +101,7 @@ SCHNORR_DEBUG_BN((h, "%s: h = ", __func__)); out: buffer_free(&b); - bzero(digest, digest_len); + memset(digest, 0, digest_len); xfree(digest); digest_len = 0; if (success == 0) @@ -477,7 +477,7 @@ success = 0; out: EVP_MD_CTX_cleanup(&evp_md_ctx); - bzero(digest, sizeof(digest)); + memset(digest, 0, sizeof(digest)); digest_len = 0; return success; } @@ -570,7 +570,7 @@ BN_clear_free(grp->p); if (grp->q != NULL) BN_clear_free(grp->q); - bzero(grp, sizeof(*grp)); + memset(grp, 0, sizeof(*grp)); xfree(grp); } In file 'session.c', I've replaced the bzero() call with the equivalent memset() call. The patch file is below in (diff -u) format: --- session.c.orig 2012-12-19 17:29:24.289506673 -0800 +++ session.c 2012-12-19 17:29:50.967542588 -0800 @@ -1840,7 +1840,7 @@ fatal("%s: insane session id %d (max %d nalloc %d)", __func__, id, options.max_sessions, sessions_nalloc); } - bzero(&sessions[id], sizeof(*sessions)); + memset(&sessions[id], 0, sizeof(*sessions)); sessions[id].self = id; sessions[id].used = 0; sessions[id].chanid = -1; In file 'sftp-client.c', I've replaced the bzero() call with the equivalent memset() call. The patch file is below in (diff -u) format: --- sftp-client.c.orig 2012-12-19 17:30:09.345533585 -0800 +++ sftp-client.c 2012-12-19 17:30:34.055766403 -0800 @@ -308,7 +308,7 @@ SSH2_FXP_EXTENDED_REPLY, type); } - bzero(st, sizeof(*st)); + memset(st, 0, sizeof(*st)); st->f_bsize = buffer_get_int64(&msg); st->f_frsize = buffer_get_int64(&msg); st->f_blocks = buffer_get_int64(&msg); In file 'sshconnect2.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- sshconnect2.c.orig 2012-12-19 17:32:38.389551253 -0800 +++ sshconnect2.c 2012-12-19 17:35:55.170602684 -0800 @@ -1010,14 +1010,14 @@ &secret, &secret_len) != 0) fatal("%s: hash_buffer", __func__); - bzero(password, strlen(password)); - bzero(crypted, strlen(crypted)); + memset(password, 0, strlen(password)); + memset(crypted, 0, strlen(crypted)); xfree(password); xfree(crypted); if ((ret = BN_bin2bn(secret, secret_len, NULL)) == NULL) fatal("%s: BN_bin2bn (secret)", __func__); - bzero(secret, secret_len); + memset(secret, 0, secret_len); xfree(secret); return ret; @@ -1054,8 +1054,8 @@ /* Obtain password and derive secret */ pctx->s = jpake_password_to_secret(authctxt, crypt_scheme, salt); - bzero(crypt_scheme, strlen(crypt_scheme)); - bzero(salt, strlen(salt)); + memset(crypt_scheme, 0, strlen(crypt_scheme)); + memset(salt, 0, strlen(salt)); xfree(crypt_scheme); xfree(salt); JPAKE_DEBUG_BN((pctx->s, "%s: s = ", __func__)); @@ -1070,8 +1070,8 @@ &pctx->a, &x2_s_proof, &x2_s_proof_len); - bzero(x3_proof, x3_proof_len); - bzero(x4_proof, x4_proof_len); + memset(x3_proof, 0, x3_proof_len); + memset(x4_proof, 0, x4_proof_len); xfree(x3_proof); xfree(x4_proof); @@ -1083,7 +1083,7 @@ packet_put_string(x2_s_proof, x2_s_proof_len); packet_send(); - bzero(x2_s_proof, x2_s_proof_len); + memset(x2_s_proof, 0, x2_s_proof_len); xfree(x2_s_proof); /* Expect step 2 packet from peer */ @@ -1123,7 +1123,7 @@ &pctx->k, &pctx->h_k_cid_sessid, &pctx->h_k_cid_sessid_len); - bzero(x4_s_proof, x4_s_proof_len); + memset(x4_s_proof, 0, x4_s_proof_len); xfree(x4_s_proof); JPAKE_DEBUG_CTX((pctx, "confirm sending in %s", __func__)); @@ -1787,8 +1787,8 @@ packet_put_string(x2_proof, x2_proof_len); packet_send(); - bzero(x1_proof, x1_proof_len); - bzero(x2_proof, x2_proof_len); + memset(x1_proof, 0, x1_proof_len); + memset(x2_proof, 0, x2_proof_len); xfree(x1_proof); xfree(x2_proof); In file 'ssh.c', I've replaced the bzero() calls with the equivalent memset() calls. The patch file is below in (diff -u) format: --- ssh.c.orig 2012-12-19 17:30:53.992528775 -0800 +++ ssh.c 2012-12-19 17:32:16.421511581 -0800 @@ -1509,8 +1509,8 @@ #endif /* PKCS11 */ n_ids = 0; - bzero(identity_files, sizeof(identity_files)); - bzero(identity_keys, sizeof(identity_keys)); + memset(identity_files, 0, sizeof(identity_files)); + memset(identity_keys, 0, sizeof(identity_keys)); #ifdef ENABLE_PKCS11 if (options.pkcs11_provider != NULL && @@ -1584,9 +1584,9 @@ memcpy(options.identity_files, identity_files, sizeof(identity_files)); memcpy(options.identity_keys, identity_keys, sizeof(identity_keys)); - bzero(pwname, strlen(pwname)); + memset(pwname, 0, strlen(pwname)); xfree(pwname); - bzero(pwdir, strlen(pwdir)); + memset(pwdir, 0, strlen(pwdir)); xfree(pwdir); } In file 'ssh-keygen.c', I've replaced the bzero() call with the equivalent memset() call. The patch file is below in (diff -u) format: --- ssh-keygen.c.orig 2012-12-19 17:21:53.056678875 -0800 +++ ssh-keygen.c 2012-12-19 17:22:21.022556542 -0800 @@ -1660,7 +1660,7 @@ fatal("Invalid certificate time format %s", s); } - bzero(&tm, sizeof(tm)); + memset(&tm, 0, sizeof(tm)); if (strptime(buf, fmt, &tm) == NULL) fatal("Invalid certificate time %s", s); if ((tt = mktime(&tm)) < 0) In directory 'openbsd-compat', file 'ssh-keygen.c', I've replaced the index() call with the equivalent strchr() call. The patch file is below in (diff -u) format: --- port-linux.c.orig 2012-12-19 17:40:53.231529475 -0800 +++ port-linux.c 2012-12-19 17:41:27.573571514 -0800 @@ -191,7 +191,7 @@ logit("%s: getcon failed with %s", __func__, strerror(errno)); return; } - if ((cx = index(oldctx, ':')) == NULL || (cx = index(cx + 1, ':')) == + if ((cx = strchr(oldctx, ':')) == NULL || (cx = strchr(cx + 1, ':')) == NULL) { logit ("%s: unparseable context %s", __func__, oldctx); return; @@ -210,7 +210,7 @@ len = cx - oldctx + 1; memcpy(newctx, oldctx, len); strlcpy(newctx + len, newname, newlen - len); - if ((cx = index(cx + 1, ':'))) + if ((cx = strchr(cx + 1, ':'))) strlcat(newctx, cx, newlen); debug3("%s: setting context from '%s' to '%s'", __func__, oldctx, newctx); A configure with the following parameters below: ./configure --with-pam --with-md5-passwords --with-kerberos5=/usr/kerberos --with-tcp-wrappers and 'make' result in clean configure and make. I am attaching all of the patch files (in diff -u format) to this email/bug report. Please feel free to make any needed changes, etc as needed. Bill Parker (wp02855 at gmail dot com) From keisial at gmail.com Fri Dec 21 06:22:06 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 20 Dec 2012 20:22:06 +0100 Subject: Deprecated calls to bzero() and index() found in OpenSSH 6.1p1 In-Reply-To: References: Message-ID: <50D3655E.1050709@gmail.com> On 20/12/12 20:03, Bill Parker wrote: > I am attaching all of the patch files (in diff -u format) to > this email/bug report. Please feel free to make any needed > changes, etc as needed. > > Bill Parker (wp02855 at gmail dot com) They didn't reach the list (stripped due to wrong mime?). They are available inline in your message, though. I noticed that in several points your change adds one extra space to the indentation. You may want to check it. Regards From peter at stuge.se Fri Dec 21 06:27:14 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 20 Dec 2012 20:27:14 +0100 Subject: Deprecated calls to bzero() and index() found in OpenSSH 6.1p1 In-Reply-To: References: Message-ID: <20121220192714.5543.qmail@stuge.se> Bill Parker wrote: > In file 'auth2-jpake.c', I've replaced all the bzero() calls with > the equivalent memset() calls. The patch file is below in (diff -u) > format: > > --- auth2-jpake.c.orig 2012-12-19 17:01:52.817528171 -0800 > +++ auth2-jpake.c 2012-12-19 17:05:59.044554766 -0800 > @@ -178,7 +178,7 @@ > fatal("%s: not enough bytes for rawsalt (want %u have %u)", > __func__, len, digest_len); > memcpy(rawsalt, digest, len); > - bzero(digest, digest_len); > + memset(digest, 0, digest_len); The whitespace style on all touched lines has been changed. Please don't do that. //Peter From keisial at gmail.com Fri Dec 21 07:14:10 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 20 Dec 2012 21:14:10 +0100 Subject: Deprecated calls to bzero() and index() found in OpenSSH 6.1p1 In-Reply-To: References: <50D3655E.1050709@gmail.com> Message-ID: <50D37192.9040604@gmail.com> On 20/12/12 20:33, Bill Parker wrote: > I have fixed all of the patch files so the extra space before memset() > is eliminated, and corrected a misspelled memset() as well. How would > you like me to get the patch files to the list, can I send the lot of > them to you? > > Bill Parker If they are sent with a mime of text/plain, the list won't strip them. From djm at mindrot.org Fri Dec 21 11:06:18 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Dec 2012 11:06:18 +1100 (EST) Subject: Deprecated calls to bzero() and index() found in OpenSSH 6.1p1 In-Reply-To: References: Message-ID: On Thu, 20 Dec 2012, Bill Parker wrote: > Hello All, > > In reviewing source code for OpenSSH-6.1p1, I found instances > of deprecated library calls still within various source code files. > > Examples of deprecated calls are: bzero() (replaced with memset() > which is ANSI compliant), index() (replaced with strchr() which > is also ANSI compliant). No thanks. I prefer bzero actually. Less to type, less chance to get the arguments wrong. The BSD functions are widely used and not going anywhere. If you're spending time reviewing the OpenSSH source, please look for real bugs or opportunities to switch to improved APIs like xasprintf from alloc+snprintf, etc. -d From dtucker at zip.com.au Fri Dec 21 11:43:26 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Dec 2012 11:43:26 +1100 Subject: more compiler safety flags Message-ID: <20121221004326.GA8205@gate.dtucker.net> Anyone see any reason not to add these extra compiler/linker flags if they're supported? Index: aclocal.m4 =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/aclocal.m4,v retrieving revision 1.8 diff -u -p -r1.8 aclocal.m4 --- aclocal.m4 20 May 2011 01:45:25 -0000 1.8 +++ aclocal.m4 17 Dec 2012 03:56:32 -0000 @@ -21,6 +21,23 @@ AC_DEFUN([OSSH_CHECK_CFLAG_COMPILE], [{ ) }]) +dnl OSSH_CHECK_CFLAG_LINK(check_flag[, define_flag]) +dnl Check that $LD accepts a flag 'check_flag'. If it is supported append +dnl 'define_flag' to $LDFLAGS. If 'define_flag' is not specified, then append +dnl 'check_flag'. +AC_DEFUN([OSSH_CHECK_LDFLAG_LINK], [{ + AC_MSG_CHECKING([if $LD supports $1]) + saved_LDFLAGS="$LDFLAGS" + LDFLAGS="$LDFLAGS $1" + _define_flag="$2" + test "x$_define_flag" = "x" && _define_flag="$1" + AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(void) { return 0; }]])], + [ AC_MSG_RESULT([yes]) + LDFLAGS="$saved_LDFLAGS $_define_flag"], + [ AC_MSG_RESULT([no]) + LDFLAGS="$saved_LDFLAGS" ] + ) +}]) dnl OSSH_CHECK_HEADER_FOR_FIELD(field, header, symbol) dnl Does AC_EGREP_HEADER on 'header' for the string 'field' Index: configure.ac =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/configure.ac,v retrieving revision 1.499 diff -u -p -r1.499 configure.ac --- configure.ac 12 Dec 2012 21:18:56 -0000 1.499 +++ configure.ac 17 Dec 2012 03:57:01 -0000 @@ -164,6 +164,11 @@ if test "$GCC" = "yes" || test "$GCC" = OSSH_CHECK_CFLAG_COMPILE([-Wunused-result], [-Wno-unused-result]) OSSH_CHECK_CFLAG_COMPILE([-fno-strict-aliasing]) OSSH_CHECK_CFLAG_COMPILE([-D_FORTIFY_SOURCE=2]) + OSSH_CHECK_CFLAG_COMPILE([-fPIC]) + OSSH_CHECK_LDFLAG_LINK([-pie]) + OSSH_CHECK_LDFLAG_LINK([-Wa,--noexecstack]) + OSSH_CHECK_LDFLAG_LINK([-Wl,-z,relro]) + OSSH_CHECK_LDFLAG_LINK([-Wl,-z,now]) AC_MSG_CHECKING([gcc version]) GCC_VER=`$CC -v 2>&1 | $AWK '/gcc version /{print $3}'` case $GCC_VER in -- 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 Dec 21 15:42:45 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Dec 2012 15:42:45 +1100 (EST) Subject: more compiler safety flags In-Reply-To: <20121221004326.GA8205@gate.dtucker.net> References: <20121221004326.GA8205@gate.dtucker.net> Message-ID: On Fri, 21 Dec 2012, Darren Tucker wrote: > Anyone see any reason not to add these extra compiler/linker flags if > they're supported? I think the risk is that some of these features need crt0/ld.so assistance to work that might be absent, causing the programs to link but fail to execute. Is this a problem in practice? I have no idea :) I'm not opposed to you committing this diff while we are still in development mode to help find out though. > + OSSH_CHECK_CFLAG_COMPILE([-fPIC]) Isn't fPIE more usual? > + OSSH_CHECK_LDFLAG_LINK([-pie]) > + OSSH_CHECK_LDFLAG_LINK([-Wa,--noexecstack]) > + OSSH_CHECK_LDFLAG_LINK([-Wl,-z,relro]) > + OSSH_CHECK_LDFLAG_LINK([-Wl,-z,now]) From vinschen at redhat.com Fri Dec 21 20:42:41 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 21 Dec 2012 10:42:41 +0100 Subject: more compiler safety flags In-Reply-To: <20121221004326.GA8205@gate.dtucker.net> References: <20121221004326.GA8205@gate.dtucker.net> Message-ID: <20121221094241.GA27661@calimero.vinschen.de> On Dec 21 11:43, Darren Tucker wrote: > Anyone see any reason not to add these extra compiler/linker flags if > they're supported? > > Index: aclocal.m4 > =================================================================== > RCS file: /home/dtucker/openssh/cvs/openssh/aclocal.m4,v > retrieving revision 1.8 > diff -u -p -r1.8 aclocal.m4 > --- aclocal.m4 20 May 2011 01:45:25 -0000 1.8 > +++ aclocal.m4 17 Dec 2012 03:56:32 -0000 > @@ -21,6 +21,23 @@ AC_DEFUN([OSSH_CHECK_CFLAG_COMPILE], [{ > ) > }]) > > +dnl OSSH_CHECK_CFLAG_LINK(check_flag[, define_flag]) > +dnl Check that $LD accepts a flag 'check_flag'. If it is supported append > +dnl 'define_flag' to $LDFLAGS. If 'define_flag' is not specified, then append > +dnl 'check_flag'. > +AC_DEFUN([OSSH_CHECK_LDFLAG_LINK], [{ > + AC_MSG_CHECKING([if $LD supports $1]) > + saved_LDFLAGS="$LDFLAGS" > + LDFLAGS="$LDFLAGS $1" > + _define_flag="$2" > + test "x$_define_flag" = "x" && _define_flag="$1" > + AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(void) { return 0; }]])], > + [ AC_MSG_RESULT([yes]) > + LDFLAGS="$saved_LDFLAGS $_define_flag"], > + [ AC_MSG_RESULT([no]) > + LDFLAGS="$saved_LDFLAGS" ] > + ) > +}]) > > dnl OSSH_CHECK_HEADER_FOR_FIELD(field, header, symbol) > dnl Does AC_EGREP_HEADER on 'header' for the string 'field' > Index: configure.ac > =================================================================== > RCS file: /home/dtucker/openssh/cvs/openssh/configure.ac,v > retrieving revision 1.499 > diff -u -p -r1.499 configure.ac > --- configure.ac 12 Dec 2012 21:18:56 -0000 1.499 > +++ configure.ac 17 Dec 2012 03:57:01 -0000 > @@ -164,6 +164,11 @@ if test "$GCC" = "yes" || test "$GCC" = > OSSH_CHECK_CFLAG_COMPILE([-Wunused-result], [-Wno-unused-result]) > OSSH_CHECK_CFLAG_COMPILE([-fno-strict-aliasing]) > OSSH_CHECK_CFLAG_COMPILE([-D_FORTIFY_SOURCE=2]) > + OSSH_CHECK_CFLAG_COMPILE([-fPIC]) > + OSSH_CHECK_LDFLAG_LINK([-pie]) > + OSSH_CHECK_LDFLAG_LINK([-Wa,--noexecstack]) Shouldn't that be OSSH_CHECK_CFLAG_COMPILE([-Wa,--noexecstack]) ? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From wp02855 at gmail.com Sat Dec 22 06:46:27 2012 From: wp02855 at gmail.com (Bill Parker) Date: Fri, 21 Dec 2012 11:46:27 -0800 Subject: File Attachments for previous bug report Message-ID: I have renamed all of the patch files to .txt, which should be acceptable for the mailer daemon at mindrot, per Angel's suggestion. I am attaching the patch files to the email, with the extra space removed and a minor correction made. Bill Parker (wp02855 at gmail dot com) -------------- next part -------------- --- port-linux.c.orig 2012-12-19 17:40:53.231529475 -0800 +++ port-linux.c 2012-12-19 17:41:27.573571514 -0800 @@ -191,7 +191,7 @@ logit("%s: getcon failed with %s", __func__, strerror(errno)); return; } - if ((cx = index(oldctx, ':')) == NULL || (cx = index(cx + 1, ':')) == + if ((cx = strchr(oldctx, ':')) == NULL || (cx = strchr(cx + 1, ':')) == NULL) { logit ("%s: unparseable context %s", __func__, oldctx); return; @@ -210,7 +210,7 @@ len = cx - oldctx + 1; memcpy(newctx, oldctx, len); strlcpy(newctx + len, newname, newlen - len); - if ((cx = index(cx + 1, ':'))) + if ((cx = strchr(cx + 1, ':'))) strlcat(newctx, cx, newlen); debug3("%s: setting context from '%s' to '%s'", __func__, oldctx, newctx); -------------- next part -------------- --- auth2-jpake.c.orig 2012-12-19 17:01:52.817528171 -0800 +++ auth2-jpake.c 2012-12-19 17:05:59.044554766 -0800 @@ -178,7 +178,7 @@ fatal("%s: not enough bytes for rawsalt (want %u have %u)", __func__, len, digest_len); memcpy(rawsalt, digest, len); - bzero(digest, digest_len); + memset(digest, 0, digest_len); xfree(digest); } @@ -203,10 +203,10 @@ fatal("%s: want %u", __func__, want); derive_rawsalt(user, rawsalt, sizeof(rawsalt)); - bzero(ret, sizeof(ret)); + memset(ret, 0, sizeof(ret)); for (i = 0; i < want; i++) ret[i] = pw_encode64(rawsalt[i]); - bzero(rawsalt, sizeof(rawsalt)); + memset(rawsalt, 0, sizeof(rawsalt)); return ret; } @@ -360,7 +360,7 @@ debug3("%s: scheme = %s", __func__, *hash_scheme); JPAKE_DEBUG_BN((*s, "%s: s = ", __func__)); #endif - bzero(secret, secret_len); + memset(secret, 0, secret_len); xfree(secret); } @@ -401,12 +401,12 @@ packet_send(); packet_write_wait(); - bzero(hash_scheme, strlen(hash_scheme)); - bzero(salt, strlen(salt)); + memset(hash_scheme, 0, strlen(hash_scheme)); + memset(salt, 0, strlen(salt)); xfree(hash_scheme); xfree(salt); - bzero(x3_proof, x3_proof_len); - bzero(x4_proof, x4_proof_len); + memset(x3_proof, 0, x3_proof_len); + memset(x4_proof, 0, x4_proof_len); xfree(x3_proof); xfree(x4_proof); @@ -453,8 +453,8 @@ &pctx->b, &x4_s_proof, &x4_s_proof_len)); - bzero(x1_proof, x1_proof_len); - bzero(x2_proof, x2_proof_len); + memset(x1_proof, 0, x1_proof_len); + memset(x2_proof, 0, x2_proof_len); xfree(x1_proof); xfree(x2_proof); @@ -468,7 +468,7 @@ packet_send(); packet_write_wait(); - bzero(x4_s_proof, x4_s_proof_len); + memset(x4_s_proof, 0, x4_s_proof_len); xfree(x4_s_proof); /* Expect step 2 packet from peer */ @@ -509,7 +509,7 @@ &pctx->k, &pctx->h_k_sid_sessid, &pctx->h_k_sid_sessid_len)); - bzero(x2_s_proof, x2_s_proof_len); + memset(x2_s_proof, 0, x2_s_proof_len); xfree(x2_s_proof); if (!use_privsep) -------------- next part -------------- --- authfd.c.orig 2012-12-19 17:07:08.292534290 -0800 +++ authfd.c 2012-12-19 17:10:48.240556291 -0800 @@ -102,7 +102,7 @@ if (!authsocket) return -1; - bzero(&sunaddr, sizeof(sunaddr)); + memset(&sunaddr, 0, sizeof(sunaddr)); sunaddr.sun_family = AF_UNIX; strlcpy(sunaddr.sun_path, authsocket, sizeof(sunaddr.sun_path)); -------------- next part -------------- --- authfile.c.orig 2012-12-19 17:11:06.537523347 -0800 +++ authfile.c 2012-12-19 17:12:03.999868720 -0800 @@ -349,17 +349,17 @@ __func__, filename == NULL ? "" : filename, filename == NULL ? "" : " ", strerror(errno)); buffer_clear(blob); - bzero(buf, sizeof(buf)); + memset(buf, 0, sizeof(buf)); return 0; } buffer_append(blob, buf, len); if (buffer_len(blob) > MAX_KEY_FILE_SIZE) { buffer_clear(blob); - bzero(buf, sizeof(buf)); + memset(buf, 0, sizeof(buf)); goto toobig; } } - bzero(buf, sizeof(buf)); + memset(buf, 0, sizeof(buf)); if ((st.st_mode & (S_IFSOCK|S_IFCHR|S_IFIFO)) == 0 && st.st_size != buffer_len(blob)) { debug("%s: key file %.200s%schanged size while reading", -------------- next part -------------- --- bufaux.c.orig 2012-12-19 17:12:21.672509848 -0800 +++ bufaux.c 2012-12-19 17:12:44.902553992 -0800 @@ -215,7 +215,7 @@ if (cp == ret + length - 1) error("buffer_get_cstring_ret: string contains \\0"); else { - bzero(ret, length); + memset(ret, 0, length); xfree(ret); return NULL; } -------------- next part -------------- --- bufec.c.orig 2012-12-19 17:13:00.367528026 -0800 +++ bufec.c 2012-12-19 17:13:26.725554444 -0800 @@ -77,7 +77,7 @@ ret = 0; out: if (buf != NULL) { - bzero(buf, len); + memset(buf, 0, len); xfree(buf); } BN_CTX_free(bnctx); @@ -130,7 +130,7 @@ ret = 0; out: BN_CTX_free(bnctx); - bzero(buf, len); + memset(buf, 0, len); xfree(buf); return ret; } -------------- next part -------------- --- canohost.c.orig 2012-12-19 17:13:41.958551344 -0800 +++ canohost.c 2012-12-19 17:14:05.773567216 -0800 @@ -199,7 +199,7 @@ memcpy(&inaddr, ((char *)&a6->sin6_addr) + 12, sizeof(inaddr)); port = a6->sin6_port; - bzero(a4, sizeof(*a4)); + memset(a4, 0, sizeof(*a4)); a4->sin_family = AF_INET; *len = sizeof(*a4); -------------- next part -------------- --- channels.c.orig 2012-12-19 17:14:18.911938266 -0800 +++ channels.c 2012-12-19 17:15:04.724553211 -0800 @@ -425,7 +425,7 @@ if (cc->abandon_cb != NULL) cc->abandon_cb(c, cc->ctx); TAILQ_REMOVE(&c->status_confirms, cc, entry); - bzero(cc, sizeof(*cc)); + memset(cc, 0, sizeof(*cc)); xfree(cc); } if (c->filter_cleanup != NULL && c->filter_ctx != NULL) @@ -2667,7 +2667,7 @@ return; cc->cb(type, c, cc->ctx); TAILQ_REMOVE(&c->status_confirms, cc, entry); - bzero(cc, sizeof(*cc)); + memset(cc, 0, sizeof(*cc)); xfree(cc); } @@ -3296,7 +3296,7 @@ xfree(cctx->host); if (cctx->aitop) freeaddrinfo(cctx->aitop); - bzero(cctx, sizeof(*cctx)); + memset(cctx, 0, sizeof(*cctx)); cctx->host = NULL; cctx->ai = cctx->aitop = NULL; } -------------- next part -------------- --- clientloop.c.orig 2012-12-19 17:15:16.548673571 -0800 +++ clientloop.c 2012-12-19 17:15:52.244510839 -0800 @@ -551,7 +551,7 @@ gc->cb(type, seq, gc->ctx); if (--gc->ref_count <= 0) { TAILQ_REMOVE(&global_confirms, gc, entry); - bzero(gc, sizeof(*gc)); + memset(gc, 0, sizeof(*gc)); xfree(gc); } @@ -867,7 +867,7 @@ int cancel_port, ok; Forward fwd; - bzero(&fwd, sizeof(fwd)); + memset(&fwd, 0, sizeof(fwd)); fwd.listen_host = fwd.connect_host = NULL; leave_raw_mode(options.request_tty == REQUEST_TTY_FORCE); -------------- next part -------------- --- hostfile.c.orig 2012-12-19 17:19:15.393667218 -0800 +++ hostfile.c 2012-12-19 17:19:50.752556571 -0800 @@ -330,7 +330,7 @@ xfree(hostkeys->entries[i].host); xfree(hostkeys->entries[i].file); key_free(hostkeys->entries[i].key); - bzero(hostkeys->entries + i, sizeof(*hostkeys->entries)); + memset(hostkeys->entries + i, 0, sizeof(*hostkeys->entries)); } if (hostkeys->entries != NULL) xfree(hostkeys->entries); -------------- next part -------------- --- jpake.c.orig 2012-12-19 17:20:06.946529817 -0800 +++ jpake.c 2012-12-19 17:21:32.343510968 -0800 @@ -105,7 +105,7 @@ #define JPAKE_BUF_CLEAR_FREE(v, l) \ do { \ if ((v) != NULL) { \ - bzero((v), (l)); \ + memset((v), 0, (l)); \ xfree(v); \ (v) = NULL; \ (l) = 0; \ @@ -133,7 +133,7 @@ #undef JPAKE_BN_CLEAR_FREE #undef JPAKE_BUF_CLEAR_FREE - bzero(pctx, sizeof(*pctx)); + memset(pctx, 0, sizeof(*pctx)); xfree(pctx); } @@ -444,7 +444,7 @@ else if (timingsafe_bcmp(peer_confirm_hash, expected_confirm_hash, expected_confirm_hash_len) == 0) success = 1; - bzero(expected_confirm_hash, expected_confirm_hash_len); + memset(expected_confirm_hash, 0, expected_confirm_hash_len); xfree(expected_confirm_hash); debug3("%s: success = %d", __func__, success); return success; -------------- next part -------------- --- monitor.c.orig 2012-12-19 17:22:45.966559767 -0800 +++ monitor.c 2012-12-19 17:26:41.827534855 -0800 @@ -547,7 +547,7 @@ struct pollfd pfd[2]; for (;;) { - bzero(&pfd, sizeof(pfd)); + memset(&pfd, 0, sizeof(pfd)); pfd[0].fd = pmonitor->m_sendfd; pfd[0].events = POLLIN; pfd[1].fd = pmonitor->m_log_recvfd; @@ -2137,8 +2137,8 @@ debug3("%s: sending step1", __func__); mm_request_send(sock, MONITOR_ANS_JPAKE_STEP1, m); - bzero(x3_proof, x3_proof_len); - bzero(x4_proof, x4_proof_len); + memset(x3_proof, 0, x3_proof_len); + memset(x4_proof, 0, x4_proof_len); xfree(x3_proof); xfree(x4_proof); @@ -2167,8 +2167,8 @@ debug3("%s: sending pwdata", __func__); mm_request_send(sock, MONITOR_ANS_JPAKE_GET_PWDATA, m); - bzero(hash_scheme, strlen(hash_scheme)); - bzero(salt, strlen(salt)); + memset(hash_scheme, 0, strlen(hash_scheme)); + memset(salt, 0, strlen(salt)); xfree(hash_scheme); xfree(salt); @@ -2207,8 +2207,8 @@ JPAKE_DEBUG_CTX((pctx, "step2 done in %s", __func__)); - bzero(x1_proof, x1_proof_len); - bzero(x2_proof, x2_proof_len); + memset(x1_proof, 0, x1_proof_len); + memset(x2_proof, 0, x2_proof_len); xfree(x1_proof); xfree(x2_proof); @@ -2220,7 +2220,7 @@ debug3("%s: sending step2", __func__); mm_request_send(sock, MONITOR_ANS_JPAKE_STEP2, m); - bzero(x4_s_proof, x4_s_proof_len); + memset(x4_s_proof, 0, x4_s_proof_len); xfree(x4_s_proof); monitor_permit(mon_dispatch, MONITOR_REQ_JPAKE_KEY_CONFIRM, 1); @@ -2254,7 +2254,7 @@ JPAKE_DEBUG_CTX((pctx, "key_confirm done in %s", __func__)); - bzero(x2_s_proof, x2_s_proof_len); + memset(x2_s_proof, 0, x2_s_proof_len); buffer_clear(m); /* pctx->k is sensitive, not sent */ @@ -2288,7 +2288,7 @@ JPAKE_DEBUG_CTX((pctx, "check_confirm done in %s", __func__)); - bzero(peer_confirm_hash, peer_confirm_hash_len); + memset(peer_confirm_hash, 0, peer_confirm_hash_len); xfree(peer_confirm_hash); buffer_clear(m); -------------- next part -------------- --- sandbox-systrace.c.orig 2012-12-19 17:27:48.258532654 -0800 +++ sandbox-systrace.c 2012-12-19 17:28:12.705825672 -0800 @@ -140,7 +140,7 @@ box->systrace_fd, child_pid, strerror(errno)); /* Allocate and assign policy */ - bzero(&policy, sizeof(policy)); + memset(&policy, 0, sizeof(policy)); policy.strp_op = SYSTR_POLICY_NEW; policy.strp_maxents = SYS_MAXSYSCALL; if (ioctl(box->systrace_fd, STRIOCPOLICY, &policy) == -1) -------------- next part -------------- --- schnorr.c.orig 2012-12-19 17:28:24.666675070 -0800 +++ schnorr.c 2012-12-19 17:29:14.920563605 -0800 @@ -101,7 +101,7 @@ SCHNORR_DEBUG_BN((h, "%s: h = ", __func__)); out: buffer_free(&b); - bzero(digest, digest_len); + memset(digest, 0, digest_len); xfree(digest); digest_len = 0; if (success == 0) @@ -477,7 +477,7 @@ success = 0; out: EVP_MD_CTX_cleanup(&evp_md_ctx); - bzero(digest, sizeof(digest)); + memset(digest, 0, sizeof(digest)); digest_len = 0; return success; } @@ -570,7 +570,7 @@ BN_clear_free(grp->p); if (grp->q != NULL) BN_clear_free(grp->q); - bzero(grp, sizeof(*grp)); + memset(grp, 0, sizeof(*grp)); xfree(grp); } -------------- next part -------------- --- session.c.orig 2012-12-19 17:29:24.289506673 -0800 +++ session.c 2012-12-19 17:29:50.967542588 -0800 @@ -1840,7 +1840,7 @@ fatal("%s: insane session id %d (max %d nalloc %d)", __func__, id, options.max_sessions, sessions_nalloc); } - bzero(&sessions[id], sizeof(*sessions)); + memset(&sessions[id], 0, sizeof(*sessions)); sessions[id].self = id; sessions[id].used = 0; sessions[id].chanid = -1; -------------- next part -------------- --- sftp-client.c.orig 2012-12-19 17:30:09.345533585 -0800 +++ sftp-client.c 2012-12-19 17:30:34.055766403 -0800 @@ -308,7 +308,7 @@ SSH2_FXP_EXTENDED_REPLY, type); } - bzero(st, sizeof(*st)); + memset(st, 0, sizeof(*st)); st->f_bsize = buffer_get_int64(&msg); st->f_frsize = buffer_get_int64(&msg); st->f_blocks = buffer_get_int64(&msg); -------------- next part -------------- --- sshconnect2.c.orig 2012-12-19 17:32:38.389551253 -0800 +++ sshconnect2.c 2012-12-19 17:35:55.170602684 -0800 @@ -1010,14 +1010,14 @@ &secret, &secret_len) != 0) fatal("%s: hash_buffer", __func__); - bzero(password, strlen(password)); - bzero(crypted, strlen(crypted)); + memset(password, 0, strlen(password)); + memset(crypted, 0, strlen(crypted)); xfree(password); xfree(crypted); if ((ret = BN_bin2bn(secret, secret_len, NULL)) == NULL) fatal("%s: BN_bin2bn (secret)", __func__); - bzero(secret, secret_len); + memset(secret, 0, secret_len); xfree(secret); return ret; @@ -1054,8 +1054,8 @@ /* Obtain password and derive secret */ pctx->s = jpake_password_to_secret(authctxt, crypt_scheme, salt); - bzero(crypt_scheme, strlen(crypt_scheme)); - bzero(salt, strlen(salt)); + memset(crypt_scheme, 0, strlen(crypt_scheme)); + memset(salt, 0, strlen(salt)); xfree(crypt_scheme); xfree(salt); JPAKE_DEBUG_BN((pctx->s, "%s: s = ", __func__)); @@ -1070,8 +1070,8 @@ &pctx->a, &x2_s_proof, &x2_s_proof_len); - bzero(x3_proof, x3_proof_len); - bzero(x4_proof, x4_proof_len); + memset(x3_proof, 0, x3_proof_len); + memset(x4_proof, 0, x4_proof_len); xfree(x3_proof); xfree(x4_proof); @@ -1083,7 +1083,7 @@ packet_put_string(x2_s_proof, x2_s_proof_len); packet_send(); - bzero(x2_s_proof, x2_s_proof_len); + memset(x2_s_proof, 0, x2_s_proof_len); xfree(x2_s_proof); /* Expect step 2 packet from peer */ @@ -1123,7 +1123,7 @@ &pctx->k, &pctx->h_k_cid_sessid, &pctx->h_k_cid_sessid_len); - bzero(x4_s_proof, x4_s_proof_len); + memset(x4_s_proof, 0, x4_s_proof_len); xfree(x4_s_proof); JPAKE_DEBUG_CTX((pctx, "confirm sending in %s", __func__)); @@ -1787,8 +1787,8 @@ packet_put_string(x2_proof, x2_proof_len); packet_send(); - bzero(x1_proof, x1_proof_len); - bzero(x2_proof, x2_proof_len); + memset(x1_proof, 0, x1_proof_len); + memset(x2_proof, 0, x2_proof_len); xfree(x1_proof); xfree(x2_proof); -------------- next part -------------- --- ssh.c.orig 2012-12-19 17:30:53.992528775 -0800 +++ ssh.c 2012-12-19 17:32:16.421511581 -0800 @@ -1509,8 +1509,8 @@ #endif /* PKCS11 */ n_ids = 0; - bzero(identity_files, sizeof(identity_files)); - bzero(identity_keys, sizeof(identity_keys)); + memset(identity_files, 0, sizeof(identity_files)); + memset(identity_keys, 0, sizeof(identity_keys)); #ifdef ENABLE_PKCS11 if (options.pkcs11_provider != NULL && @@ -1584,9 +1584,9 @@ memcpy(options.identity_files, identity_files, sizeof(identity_files)); memcpy(options.identity_keys, identity_keys, sizeof(identity_keys)); - bzero(pwname, strlen(pwname)); + memset(pwname, 0, strlen(pwname)); xfree(pwname); - bzero(pwdir, strlen(pwdir)); + memset(pwdir, 0, strlen(pwdir)); xfree(pwdir); } From os at ohmu.fi Fri Dec 28 02:15:06 2012 From: os at ohmu.fi (Oskari Saarenmaa) Date: Thu, 27 Dec 2012 17:15:06 +0200 Subject: [PATCH] hostfile: list known names (if any) for new hostkeys Message-ID: <20121227151506.GA29988@timantti.taisia.fi> When connecting to a host for which there's no known hostkey, check if the relevant key has been accepted for other hostnames. This is useful when connecting to a host with a dymamic IP address or multiple names. --- auth.c | 4 ++-- hostfile.c | 42 ++++++++++++++++++++++++++++-------------- hostfile.h | 8 ++++++-- sshconnect.c | 39 +++++++++++++++++++++++++++++++++------ sshconnect2.c | 4 ++-- 5 files changed, 71 insertions(+), 26 deletions(-) diff --git a/auth.c b/auth.c index 7bc6f40..1ca07e1 100644 --- a/auth.c +++ b/auth.c @@ -379,7 +379,7 @@ check_key_in_hostfiles(struct passwd *pw, Key *key, const char *host, const struct hostkey_entry *found; hostkeys = init_hostkeys(); - load_hostkeys(hostkeys, host, sysfile); + load_hostkeys(hostkeys, host, NULL, sysfile); if (userfile != NULL) { user_hostfile = tilde_expand_filename(userfile, pw->pw_uid); if (options.strict_modes && @@ -393,7 +393,7 @@ check_key_in_hostfiles(struct passwd *pw, Key *key, const char *host, user_hostfile); } else { temporarily_use_uid(pw); - load_hostkeys(hostkeys, host, user_hostfile); + load_hostkeys(hostkeys, host, NULL, user_hostfile); restore_uid(); } xfree(user_hostfile); diff --git a/hostfile.c b/hostfile.c index b6f924b..e493c91 100644 --- a/hostfile.c +++ b/hostfile.c @@ -58,11 +58,6 @@ #include "log.h" #include "misc.h" -struct hostkeys { - struct hostkey_entry *entries; - u_int num_entries; -}; - static int extract_salt(const char *s, u_int l, char *salt, size_t salt_len) { @@ -236,20 +231,22 @@ init_hostkeys(void) } void -load_hostkeys(struct hostkeys *hostkeys, const char *host, const char *path) +load_hostkeys(struct hostkeys *hostkeys, const char *lookup_host, + const Key *lookup_key, const char *path) { FILE *f; char line[8192]; u_long linenum = 0, num_loaded = 0; char *cp, *cp2, *hashed_host; + const char *current_host; HostkeyMarker marker; Key *key; int kbits; if ((f = fopen(path, "r")) == NULL) return; - debug3("%s: loading entries for host \"%.100s\" from file \"%s\"", - __func__, host, path); + debug3("%s: loading entries for host \"%.100s\"%s from file \"%s\"", + __func__, lookup_host, (lookup_key ? " and key" : ""), path); while (read_keyfile_line(f, path, line, sizeof(line), &linenum) == 0) { cp = line; @@ -269,11 +266,11 @@ load_hostkeys(struct hostkeys *hostkeys, const char *host, const char *path) for (cp2 = cp; *cp2 && *cp2 != ' ' && *cp2 != '\t'; cp2++) ; - /* Check if the host name matches. */ - if (match_hostname(host, cp, (u_int) (cp2 - cp)) != 1) { + /* Check if the host name matches if we're looking for a host. */ + if (lookup_host && match_hostname(lookup_host, cp, (u_int) (cp2 - cp)) != 1) { if (*cp != HASH_DELIM) continue; - hashed_host = host_hash(host, cp, (u_int) (cp2 - cp)); + hashed_host = host_hash(lookup_host, cp, (u_int) (cp2 - cp)); if (hashed_host == NULL) { debug("Invalid hashed host line %lu of %s", linenum, path); @@ -283,7 +280,17 @@ load_hostkeys(struct hostkeys *hostkeys, const char *host, const char *path) continue; } - /* Got a match. Skip host name. */ + /* If we're looking for a key grab the hostname and ignore hashed entries. */ + if (lookup_key) { + if (*cp == HASH_DELIM) + continue; + *cp2++ = 0; + current_host = cp; + } else { + current_host = lookup_host; + } + + /* Move pointer past the hostname. */ cp = cp2; /* @@ -299,7 +306,14 @@ load_hostkeys(struct hostkeys *hostkeys, const char *host, const char *path) continue; } } - if (!hostfile_check_key(kbits, key, host, path, linenum)) + + /* Check if the key matches if we're looking for a key. */ + if (lookup_key) { + if (!key_equal(lookup_key, key)) + continue; + } + + if (!hostfile_check_key(kbits, key, current_host, path, linenum)) continue; debug3("%s: found %skey type %s in file %s:%lu", __func__, @@ -308,7 +322,7 @@ load_hostkeys(struct hostkeys *hostkeys, const char *host, const char *path) key_type(key), path, linenum); hostkeys->entries = xrealloc(hostkeys->entries, hostkeys->num_entries + 1, sizeof(*hostkeys->entries)); - hostkeys->entries[hostkeys->num_entries].host = xstrdup(host); + hostkeys->entries[hostkeys->num_entries].host = xstrdup(current_host); hostkeys->entries[hostkeys->num_entries].file = xstrdup(path); hostkeys->entries[hostkeys->num_entries].line = linenum; hostkeys->entries[hostkeys->num_entries].key = key; diff --git a/hostfile.h b/hostfile.h index d84d422..c2965f9 100644 --- a/hostfile.h +++ b/hostfile.h @@ -29,10 +29,14 @@ struct hostkey_entry { Key *key; HostkeyMarker marker; }; -struct hostkeys; + +struct hostkeys { + struct hostkey_entry *entries; + u_int num_entries; +}; struct hostkeys *init_hostkeys(void); -void load_hostkeys(struct hostkeys *, const char *, const char *); +void load_hostkeys(struct hostkeys *, const char *, const Key *, const char *); void free_hostkeys(struct hostkeys *); HostStatus check_key_in_hostkeys(struct hostkeys *, Key *, diff --git a/sshconnect.c b/sshconnect.c index 07800a6..62306ac 100644 --- a/sshconnect.c +++ b/sshconnect.c @@ -718,13 +718,13 @@ check_host_key(char *hostname, struct sockaddr *hostaddr, u_short port, Key *raw_key = NULL; char *ip = NULL, *host = NULL; char hostline[1000], *hostp, *fp, *ra; - char msg[1024]; + char msg[2048]; const char *type; const struct hostkey_entry *host_found, *ip_found; int len, cancelled_forwarding = 0; int local = sockaddr_is_local(hostaddr); int r, want_cert = key_is_cert(host_key), host_ip_differ = 0; - struct hostkeys *host_hostkeys, *ip_hostkeys; + struct hostkeys *host_hostkeys, *ip_hostkeys, *key_hostkeys = NULL; u_int i; /* @@ -758,17 +758,17 @@ check_host_key(char *hostname, struct sockaddr *hostaddr, u_short port, host_hostkeys = init_hostkeys(); for (i = 0; i < num_user_hostfiles; i++) - load_hostkeys(host_hostkeys, host, user_hostfiles[i]); + load_hostkeys(host_hostkeys, host, NULL, user_hostfiles[i]); for (i = 0; i < num_system_hostfiles; i++) - load_hostkeys(host_hostkeys, host, system_hostfiles[i]); + load_hostkeys(host_hostkeys, host, NULL, system_hostfiles[i]); ip_hostkeys = NULL; if (!want_cert && options.check_host_ip) { ip_hostkeys = init_hostkeys(); for (i = 0; i < num_user_hostfiles; i++) - load_hostkeys(ip_hostkeys, ip, user_hostfiles[i]); + load_hostkeys(ip_hostkeys, ip, NULL, user_hostfiles[i]); for (i = 0; i < num_system_hostfiles; i++) - load_hostkeys(ip_hostkeys, ip, system_hostfiles[i]); + load_hostkeys(ip_hostkeys, ip, NULL, system_hostfiles[i]); } retry: @@ -879,6 +879,29 @@ check_host_key(char *hostname, struct sockaddr *hostaddr, u_short port, "No matching host key fingerprint" " found in DNS.\n"); } + /* Has this key been accepted for other hostnames? */ + key_hostkeys = init_hostkeys(); + for (i = 0; i < num_user_hostfiles; i++) + load_hostkeys(key_hostkeys, NULL, host_key, + user_hostfiles[i]); + for (i = 0; i < num_system_hostfiles; i++) + load_hostkeys(key_hostkeys, NULL, host_key, + system_hostfiles[i]); + if (key_hostkeys->num_entries > 0) { + strlcat(msg2, "You have previously accepted " + "this key for the following hostnames:", + sizeof(msg2)); + for (i = 0; i < key_hostkeys->num_entries; i++) { + strlcat(msg2, "\n\t", sizeof(msg2)); + strlcat(msg2, key_hostkeys->entries[i].host, + sizeof(msg2)); + } + if (strlcat(msg2, "\n", sizeof(msg2)) >= + sizeof(msg2)) { + /* truncate at last newline. */ + *(strrchr(msg2, '\n') + 1) = 0; + } + } snprintf(msg, sizeof(msg), "The authenticity of host '%.200s (%s)' can't be " "established%s\n" @@ -1097,6 +1120,8 @@ check_host_key(char *hostname, struct sockaddr *hostaddr, u_short port, free_hostkeys(host_hostkeys); if (ip_hostkeys != NULL) free_hostkeys(ip_hostkeys); + if (key_hostkeys != NULL) + free_hostkeys(key_hostkeys); return 0; fail: @@ -1120,6 +1145,8 @@ fail: free_hostkeys(host_hostkeys); if (ip_hostkeys != NULL) free_hostkeys(ip_hostkeys); + if (key_hostkeys != NULL) + free_hostkeys(key_hostkeys); return -1; } diff --git a/sshconnect2.c b/sshconnect2.c index 6791ea3..a3ed37a 100644 --- a/sshconnect2.c +++ b/sshconnect2.c @@ -115,9 +115,9 @@ order_hostkeyalgs(char *host, struct sockaddr *hostaddr, u_short port) get_hostfile_hostname_ipaddr(host, hostaddr, port, &hostname, NULL); hostkeys = init_hostkeys(); for (i = 0; i < options.num_user_hostfiles; i++) - load_hostkeys(hostkeys, hostname, options.user_hostfiles[i]); + load_hostkeys(hostkeys, hostname, NULL, options.user_hostfiles[i]); for (i = 0; i < options.num_system_hostfiles; i++) - load_hostkeys(hostkeys, hostname, options.system_hostfiles[i]); + load_hostkeys(hostkeys, hostname, NULL, options.system_hostfiles[i]); oavail = avail = xstrdup(KEX_DEFAULT_PK_ALG); maxlen = strlen(avail) + 1; -- 1.8.0.2 From flavien-ssh at lebarbe.net Fri Dec 28 03:43:48 2012 From: flavien-ssh at lebarbe.net (Flavien Lebarbe) Date: Thu, 27 Dec 2012 17:43:48 +0100 Subject: SSH 5.8p1 hang in kernel mode / AIX 7.1 In-Reply-To: <20121214111821.GA861@srv3.flavien.org> References: <20121214111821.GA861@srv3.flavien.org> Message-ID: <20121227164348.GA17378@srv3.flavien.org> Hello, Replying to self, for the archives. This really looking like an AIX kernel bug that SSH is triggering somehow (once every 5000/6000 runs here on a test machine). We have an open issue with IBM on this. Here's the stack we got from kdb. It's related to CLiC (CryptoLite for C kernel, a kernel extension). Flavien. 0)> f pvthread+01A000 STACK: [F1000000C0339E84].RdTBR+000004 () [F1000000C02F9D64]CLiC__trng+000104 (F1000102135279A8) [F1000000C02FA280]CLiC_rng_seed+0001A0 (F100010213527A80, 0000000000000000, 0000000000000014) [F1000000C02FA448]clic_ctxrng_init+000068 (F100010213527980, 0000000400000004) [F1000000C02FA74C]CLiC_context+00018C (F10001021355B550, 0000000200000002, 0000000400000004, F1000000C03C3A98, F1000000C03C3AB0) [F1000000C036D2E8]P11_CLiC_app_init+000108 (F10001021355B458, F00000002FF45FC8) [F1000000C02C5A9C]p11_init_crypto_ctx+00011C (F10001021355B458, F00000002FF45FC8) [F1000000C02C5F28]p11_acquire_context+000268 (00000000011E00DC, 0000000100000001, F00000002FF45FC8) [F1000000C02C567C]p11_dd_open+0000FC (8000002200000000, 0000000000000001, 000BB003000BB003, 0000000000000000) [00014D70].hkey_legacy_gate+00004C () [005769C0]devcopen+000480 (??, ??, ??, ??, ??) [00576020]rdevopen+000140 (??, ??, ??, ??, ??) [007E2D90]mpx_open+000070 (F10001020FE0D5F0, 0000000100000001, 0000000000000000) [00753E7C]spec_open+0000FC (??, ??, ??, ??, ??) [005A44F8]vnop_open+0004F8 (??, ??, ??, ??, ??) [0063FEAC]openpnp+0006EC (??, ??, ??, ??, ??, ??, ??, ??) [0064056C]openpath+00028C (??, ??, ??, ??, ??, ??, ??, ??) [00640934]copen+000314 (FFFFFFFEFFFFFFFE, 00000000F084A164, 0000000000000000, 0000000800000008, 0000000000000000, F00000002FF47580) [0063F744]kopen+000024 (??, ??, ??) [0000386C]ovlya_addr_sc_flih_main+00014C () [D0119A54]open+0000F4 (F084A164, 00000000, 00000008, 00000001, 11A000C5, 01A000C5, 00000000, F0731A54) [D232F934]C_Initialize+000394 (00000000) [D100DBAC]D100DBAC () [D100BA18]D100BA18 () [D100B9B0]D100B9B0 () [D10109CC]D10109CC () [D1009AEC]D1009AEC () [10060334]ssh_SSLeay_add_all_algorithms+000014 () [100032F0]main+001290 (00000001, 2FF22800) [100001E8]__start+000098 () Flavien Lebarbe wrote : > Hello, > > > > An AIX machine runs a program that forks ssh client in order to > launch commands on a remote. I'm first seting up a Master connection > with a ControlPath, then using that connection to launch various > commands on the remote, and killing the master by issuing a > "-O exit" command. > > SSH client version on that machine is : > # ssh -V > OpenSSH_5.8p1, OpenSSL 0.9.8r 8 Feb 2011 > # uname -nrsv > AIX P7_AIX7 1 7 > > The program runs every 5 minutes for about 10s or so, gathering the > information from the remote just fine. > > Now, I'm looking at the output of "ps" and see some left-over processes : > root 5832832 1 69 22 nov - 5424:59 ssh -o BatchMode=yes -o ControlPath=/opt/data/ssh-socket_A-10.10.14.126 -o User=foobar 10.10.14.126 remote_command > > This instance of ssh client should not be there anymore. > > Having a deeper look: > * kill -9 on that process does not kill it. > * The corresponding ControlPath socket does not exist anymore on the system, > nor does the ssh master process for this socket. > * truss on that process does not show any activity at all: the process is > apparently inside a system call. > * kernel activity on the machine as reported by topas is 99% > * ls -l /proc/5832832/fd only shows 3 FDs : > # ls -l /proc/5832832/fd > 0 total > c--------- 1 root system 2, 2 14 d? 11:22 0 > p--------- 0 root system 0 22 nov 06:18 1 > c--------- 1 root system 2, 2 14 d? 11:22 2 > > I have currently 6 of those processes running on this system. Some of them > are running for weeks like the above. Others are running for days. > > This situation looks like a kernel bug to me. Do you have any idea of > anything that might be triggering it in the OpenSSH code in this old > version of OpenSSH ? > > > Thanks, > Flavien. From BBates at langleyfcu.org Sat Dec 29 00:35:37 2012 From: BBates at langleyfcu.org (Bates, Brent) Date: Fri, 28 Dec 2012 13:35:37 +0000 Subject: Warning/Diagnostic/Error Codes Message-ID: <2BBBDF6BCAC7B14A91188FB61CEAFD640EE6961F@LFCU-MAIL.langleyfcu.org> I'd consider this a bug in documentation as in the lack of documentation. I've looked all over the openssh.org Web site and done a number of Google searches and can not find anything. I'd like to know what error codes, if any, mean. For example, if I do an 'scp', and it fails, will it return a different error code depending on what the error was? Do I get one code if I can't connect to the remote system? A different one if the file or directory I reference doesn't exist? All the manual says is '0' on success and '>0' for any errors. I'd like something more specific, if it exists. I found a couple of references to some error codes on a couple of Web sites, but one sounded like they could be only for their locally modified version. The other didn't look 'official' either. Brent L. Bates - Unix System Administrator Langley Federal Credit Union 1055 W. Mercury Blvd., Box 7463 Hampton, VA 23666 Phone: (757) 848-5443 From peter at stuge.se Sat Dec 29 02:16:38 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 28 Dec 2012 16:16:38 +0100 Subject: Warning/Diagnostic/Error Codes In-Reply-To: <2BBBDF6BCAC7B14A91188FB61CEAFD640EE6961F@LFCU-MAIL.langleyfcu.org> References: <2BBBDF6BCAC7B14A91188FB61CEAFD640EE6961F@LFCU-MAIL.langleyfcu.org> Message-ID: <20121228151638.6845.qmail@stuge.se> Hi Brent, Bates, Brent wrote: > All the manual says is '0' on success and '>0' for any errors. > I'd like something more specific, if it exists. I suggest that you use one of the several existing SSH client libraries and implement your own client, in order to work directly with the SSH protocol. These things become trivial then. //Peter From kevin.brott at gmail.com Sat Dec 29 13:38:23 2012 From: kevin.brott at gmail.com (Kevin Brott) Date: Fri, 28 Dec 2012 18:38:23 -0800 Subject: SSH 5.8p1 hang in kernel mode / AIX 7.1 In-Reply-To: <20121227164348.GA17378@srv3.flavien.org> References: <20121214111821.GA861@srv3.flavien.org> <20121227164348.GA17378@srv3.flavien.org> Message-ID: IBM just released openssh 6.0 for AIX 6.1/7.1 (and lsof 4.85) in the last week or so, upgrading might be an option. OTOH - we've been running 5.8p1 on AIX 7100-01-xx for some time now without issues. On Thu, Dec 27, 2012 at 8:43 AM, Flavien Lebarbe wrote: > Hello, > > > Replying to self, for the archives. > > This really looking like an AIX kernel bug that SSH is triggering > somehow (once every 5000/6000 runs here on a test machine). We have > an open issue with IBM on this. Here's the stack we got from kdb. > It's related to CLiC (CryptoLite for C kernel, a kernel extension). > > > Flavien. > > 0)> f > pvthread+01A000 STACK: > [F1000000C0339E84].RdTBR+000004 () > [F1000000C02F9D64]CLiC__trng+000104 (F1000102135279A8) > [F1000000C02FA280]CLiC_rng_seed+0001A0 (F100010213527A80, 0000000000000000, > 0000000000000014) > [F1000000C02FA448]clic_ctxrng_init+000068 (F100010213527980, > 0000000400000004) > [F1000000C02FA74C]CLiC_context+00018C (F10001021355B550, 0000000200000002, > 0000000400000004, F1000000C03C3A98, F1000000C03C3AB0) > [F1000000C036D2E8]P11_CLiC_app_init+000108 (F10001021355B458, > F00000002FF45FC8) > [F1000000C02C5A9C]p11_init_crypto_ctx+00011C (F10001021355B458, > F00000002FF45FC8) > [F1000000C02C5F28]p11_acquire_context+000268 (00000000011E00DC, > 0000000100000001, > F00000002FF45FC8) > [F1000000C02C567C]p11_dd_open+0000FC (8000002200000000, 0000000000000001, > 000BB003000BB003, 0000000000000000) > [00014D70].hkey_legacy_gate+00004C () > [005769C0]devcopen+000480 (??, ??, ??, ??, ??) > [00576020]rdevopen+000140 (??, ??, ??, ??, ??) > [007E2D90]mpx_open+000070 (F10001020FE0D5F0, 0000000100000001, > 0000000000000000) > [00753E7C]spec_open+0000FC (??, ??, ??, ??, ??) > [005A44F8]vnop_open+0004F8 (??, ??, ??, ??, ??) > [0063FEAC]openpnp+0006EC (??, ??, ??, ??, ??, ??, ??, ??) > [0064056C]openpath+00028C (??, ??, ??, ??, ??, ??, ??, ??) > [00640934]copen+000314 (FFFFFFFEFFFFFFFE, 00000000F084A164, > 0000000000000000, 0000000800000008, 0000000000000000, F00000002FF47580) > [0063F744]kopen+000024 (??, ??, ??) > [0000386C]ovlya_addr_sc_flih_main+00014C () > [D0119A54]open+0000F4 (F084A164, 00000000, 00000008, 00000001, > 11A000C5, 01A000C5, 00000000, F0731A54) > [D232F934]C_Initialize+000394 (00000000) > [D100DBAC]D100DBAC () > [D100BA18]D100BA18 () > [D100B9B0]D100B9B0 () > [D10109CC]D10109CC () > [D1009AEC]D1009AEC () > [10060334]ssh_SSLeay_add_all_algorithms+000014 () > [100032F0]main+001290 (00000001, 2FF22800) > [100001E8]__start+000098 () > > > > Flavien Lebarbe wrote : > > Hello, > > > > > > > > An AIX machine runs a program that forks ssh client in order to > > launch commands on a remote. I'm first seting up a Master connection > > with a ControlPath, then using that connection to launch various > > commands on the remote, and killing the master by issuing a > > "-O exit" command. > > > > SSH client version on that machine is : > > # ssh -V > > OpenSSH_5.8p1, OpenSSL 0.9.8r 8 Feb 2011 > > # uname -nrsv > > AIX P7_AIX7 1 7 > > > > The program runs every 5 minutes for about 10s or so, gathering the > > information from the remote just fine. > > > > Now, I'm looking at the output of "ps" and see some left-over processes : > > root 5832832 1 69 22 nov - 5424:59 ssh -o > BatchMode=yes -o ControlPath=/opt/data/ssh-socket_A-10.10.14.126 -o > User=foobar 10.10.14.126 remote_command > > > > This instance of ssh client should not be there anymore. > > > > Having a deeper look: > > * kill -9 on that process does not kill it. > > * The corresponding ControlPath socket does not exist anymore on the > system, > > nor does the ssh master process for this socket. > > * truss on that process does not show any activity at all: the process is > > apparently inside a system call. > > * kernel activity on the machine as reported by topas is 99% > > * ls -l /proc/5832832/fd only shows 3 FDs : > > # ls -l /proc/5832832/fd > > 0 total > > c--------- 1 root system 2, 2 14 d? 11:22 0 > > p--------- 0 root system 0 22 nov 06:18 1 > > c--------- 1 root system 2, 2 14 d? 11:22 2 > > > > I have currently 6 of those processes running on this system. Some of > them > > are running for weeks like the above. Others are running for days. > > > > This situation looks like a kernel bug to me. Do you have any idea of > > anything that might be triggering it in the OpenSSH code in this old > > version of OpenSSH ? > > > > > > Thanks, > > Flavien. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- # include /* Kevin Brott */