From michael.hebenstreit at intel.com Fri Aug 3 02:07:34 2012 From: michael.hebenstreit at intel.com (Hebenstreit, Michael) Date: Thu, 2 Aug 2012 16:07:34 +0000 Subject: FW: ulimits in ssh/sshd without resorting to PAM? In-Reply-To: References: Message-ID: Is there an (even rudimentary) way to compile/configure/use ulimits in ssh/sshd without resorting to PAM? I've searched docs and archives, but did not find anything Thanks Michael Sorry for posting on this list, but secureshell at securityfocus.com did not distribute my mail :( ------------------------------------------------------------------------ Michael Hebenstreit Senior Cluster Architect Intel Corporation Software and Services Group/HTE 2800 N Center Dr, DP3-307 Tel.: +1 253 371 3144 WA 98327, DuPont UNITED STATES E-mail: michael.hebenstreit at intel.com From djm at mindrot.org Mon Aug 6 08:56:23 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Aug 2012 08:56:23 +1000 (EST) Subject: FW: ulimits in ssh/sshd without resorting to PAM? In-Reply-To: References: Message-ID: On Thu, 2 Aug 2012, Hebenstreit, Michael wrote: > Is there an (even rudimentary) way to compile/configure/use ulimits in > ssh/sshd without resorting to PAM? > > I've searched docs and archives, but did not find anything You might have to use a custom login shell. -d From dtucker at zip.com.au Mon Aug 6 11:08:44 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 6 Aug 2012 11:08:44 +1000 Subject: FW: ulimits in ssh/sshd without resorting to PAM? In-Reply-To: References: Message-ID: On Mon, Aug 6, 2012 at 8:56 AM, Damien Miller wrote: > On Thu, 2 Aug 2012, Hebenstreit, Michael wrote: > >> Is there an (even rudimentary) way to compile/configure/use ulimits in >> ssh/sshd without resorting to PAM? >> >> I've searched docs and archives, but did not find anything > > You might have to use a custom login shell. If you just want to reduce them from whatever the system defaults are you could just put the appropriate ulimit commands in the shell's startup (probably /etc/profile). -- 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 michael.hebenstreit at intel.com Tue Aug 7 01:38:27 2012 From: michael.hebenstreit at intel.com (Hebenstreit, Michael) Date: Mon, 6 Aug 2012 15:38:27 +0000 Subject: FW: ulimits in ssh/sshd without resorting to PAM? In-Reply-To: References: Message-ID: The problem is in a an HPC cluster - under normal circumstances lower limits are enforced, but some jobs need higher limits. We do not want to allow higher limits by default, except when explicitly requested by the users (because as default setting they are to high; a job not aware of correct limits might overload/crash the system). Thanks for the answers; looks like my current method to set the limits in a start script and restart sshd is not so bad after all (even if it's clunky) Happy hacking Michael -----Original Message----- From: dtucker at dtucker.net [mailto:dtucker at dtucker.net] On Behalf Of Darren Tucker Sent: Sunday, August 05, 2012 6:09 PM To: Damien Miller Cc: Hebenstreit, Michael; openssh-unix-dev at mindrot.org Subject: Re: FW: ulimits in ssh/sshd without resorting to PAM? On Mon, Aug 6, 2012 at 8:56 AM, Damien Miller wrote: > On Thu, 2 Aug 2012, Hebenstreit, Michael wrote: > >> Is there an (even rudimentary) way to compile/configure/use ulimits >> in ssh/sshd without resorting to PAM? >> >> I've searched docs and archives, but did not find anything > > You might have to use a custom login shell. If you just want to reduce them from whatever the system defaults are you could just put the appropriate ulimit commands in the shell's startup (probably /etc/profile). -- 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 calestyo at scientia.net Wed Aug 8 07:14:52 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Tue, 07 Aug 2012 23:14:52 +0200 Subject: securely set environment variables per user Message-ID: <1344374092.3392.94.camel@fermat.scientia.net> Hi. Is there a way to securely set environment variables per user on the remote side? What I want is e.g. that I determine on the remote side, that user foo should always have PATH set to "blafasl". ~/.ssh/environment came to my mind for this,... but it needs PermitUserEnvironment which (according to documentation) allows trickery with things like LD_PRELOAD and which I do not want to allow. Thanks, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5450 bytes Desc: not available URL: From nkadel at gmail.com Wed Aug 8 08:37:58 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 7 Aug 2012 18:37:58 -0400 Subject: securely set environment variables per user In-Reply-To: <1344374092.3392.94.camel@fermat.scientia.net> References: <1344374092.3392.94.camel@fermat.scientia.net> Message-ID: On Tue, Aug 7, 2012 at 5:14 PM, Christoph Anton Mitterer wrote: > Hi. > > Is there a way to securely set environment variables per user on the > remote side? That's not an SSH problem. That's a shell environment problem. If the normal user shell reads ordinary, user modifiable configuration files such as "$HOME/.profile", "$HOME/.bashrc", or "$HOME/.cshrc", you are out of luck. this level of environment management requires a restricted shell. > What I want is e.g. that I determine on the remote side, that user foo > should always have PATH set to "blafasl". The normal way to do that is in the shell configuration used by each user. In theory. Why are you trying to do this? From calestyo at scientia.net Wed Aug 8 08:44:40 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 08 Aug 2012 00:44:40 +0200 Subject: securely set environment variables per user In-Reply-To: References: <1344374092.3392.94.camel@fermat.scientia.net> Message-ID: <1344379480.3392.100.camel@fermat.scientia.net> On Tue, 2012-08-07 at 18:37 -0400, Nico Kadel-Garcia wrote: > That's not an SSH problem. That's a shell environment problem. Well in principle I wanted to avoid using any shell... this means just more forking and so on... and I really need to squeeze out the microseconds ;-) > Why are you trying to do this? What exactly do you mean? Setting a path? Well I use the whole thing for Icinga/Nagios remote check commands... The check_plugins are typically not in the standard PATH, but something like /usr/lib/nagios/pluings... And it would be nice if the client side could run the plugins by: ssh host check_foo instead of ssh host /usr/lib/nagios/pluings/check_foo And yes this is actually more than just a cosmetic difference. Cause later on, the whole command string will be used by Icinga/Nagios (well actually by PNP4Nagios) for some matching.... and the prefix "/usr/lib/nagios/pluings/" makes everything more complicated (and resource intensive). Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5450 bytes Desc: not available URL: From nkadel at gmail.com Wed Aug 8 23:53:46 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 8 Aug 2012 09:53:46 -0400 Subject: securely set environment variables per user In-Reply-To: <1344379480.3392.100.camel@fermat.scientia.net> References: <1344374092.3392.94.camel@fermat.scientia.net> <1344379480.3392.100.camel@fermat.scientia.net> Message-ID: On Tue, Aug 7, 2012 at 6:44 PM, Christoph Anton Mitterer wrote: > On Tue, 2012-08-07 at 18:37 -0400, Nico Kadel-Garcia wrote: >> That's not an SSH problem. That's a shell environment problem. > Well in principle I wanted to avoid using any shell... this means just > more forking and so on... and I really need to squeeze out the > microseconds ;-) >> Why are you trying to do this? > What exactly do you mean? Setting a path? > Well I use the whole thing for Icinga/Nagios remote check commands... > The check_plugins are typically not in the standard PATH, but something > like /usr/lib/nagios/pluings... > And it would be nice if the client side could run the plugins by: > ssh host check_foo > instead of > ssh host /usr/lib/nagios/pluings/check_foo > And yes this is actually more than just a cosmetic difference. > Cause later on, the whole command string will be used by Icinga/Nagios > (well actually by PNP4Nagios) for some matching.... and the prefix > "/usr/lib/nagios/pluings/" makes everything more complicated (and > resource intensive). *Oh*. That one. But Christoph, those are typically going through a shell account *anyway*. You should be able to manipulate ~nagios/.bashrc, or ~nagios/.profile, to add the relevant element to the PATH on the clients. If you really want to make the paths consistently accessible, consider using a designated symlink target: "/usr/local/libexec/nagios/plugins" and linking in the components on all your clients. I do this to mix and match system provided and locally built versions of Nagios checks as needed. I do urge you to look at NRPE rather than OpenSSH for this, which also tends to be a bit lighter weight for the Nagios server and Nagios targets than handling thousands of SSH connections every 5 minuts. It also tends to be more secure in configuration: NRPE is normally configured not to allow arbitrary command line arguments, and locking down the permitted SSH commands for Nagios access can be.... a real adventure. I've seen way too many people saying their hosts are *secure* while leaving a passphrase free SSH key for Nagios access lying around, and leaving it availble not only for unfettered shell access but even granting extensive "sudo" access to check the details of system status or to allow traps for handling failures reported by Nagios. > Cheers, > Chris. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From hareesh.dasari at huawei.com Thu Aug 9 14:24:11 2012 From: hareesh.dasari at huawei.com (Hareesh dasari) Date: Thu, 9 Aug 2012 04:24:11 +0000 Subject: Rgd. publick key authentication failure in Win2003 !! Message-ID: Hello OpenSSH team, First of all thanks for your OpenSSH tool which helped us a lot in testing our SSH-SFTP client applications. Your tool is developed as per the standards and we suggested the same to our customers also to use with our client applications. Actually now I am facing some problem when I try to connect to OpenSSH server installed in Win2003 using Public key authentication. But surprisingly password authentication is succeeded always. Can you please let me know if there are any specific steps to be followed while configuring the server in Win2003 w.r.t public key authentication. Currently I am using OpenSSH4.3P2 version. Thanks in advance !! With Thanks and Regards, Hareesh D. Huawei Technologies India Pvt. Ltd. , Bangalore ***************************************************************************************************************************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ************************************************************************************************************************************************************************************ From peter at stuge.se Thu Aug 9 23:06:46 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 9 Aug 2012 15:06:46 +0200 Subject: Rgd. publick key authentication failure in Win2003 !! In-Reply-To: References: Message-ID: <20120809130646.13972.qmail@stuge.se> Hareesh dasari wrote: > Can you please let me know if there are any specific steps to be > followed while configuring the server in Win2003 w.r.t public key > authentication. The way this works is that you show the error messages and get help interpret what the problem in the system is. > Currently I am using OpenSSH4.3P2 version. This version is ancient and may have security problems. It certainly has bugs which have been fixed since then, and which may or may not affect you. You need to study if you can really afford your company to use so old software. > This e-mail and attachments contain confidential information Yet you send the email to a public mailing list. That is confusing. If you want to participate in the public discussion then you must talk to your management about how you can send email which is not mindlessly marked confidential. Many other large companies have mastered to do this successfully already. //Peter From mpatton at inforelay.com Fri Aug 10 12:32:32 2012 From: mpatton at inforelay.com (mpatton at inforelay.com) Date: Thu, 9 Aug 2012 22:32:32 -0400 Subject: AllowUsers "logic" and failure to indicate bad configuration Message-ID: <8c3724260457f4e2b4c251710f865a4c.squirrel@www.inforelay.com> I smacked into this previously reported bug today whereby an invalid keyword in the Match{} stanza did not throw an error on configuration reload. Are there any plans to fix this? Likewise the penchant for some fields to be comma separated and others to be spaces is just asking for mistakes. Why not support both and be done with it? There was no response (that I saw in the archives) to this post http://marc.info/?l=openssh-unix-dev&m=132311628508429&w=2 Like him, I'm using 5.3p1 as packaged in CentOS 6.3. Secondly the Allow/Deny logic is downright tortured. I looked back and again didn't come across any good discussion as to why it was written that way. It should not be necessary for AllowUsers to be the superset of AllowGroups. As Spock would say "it is illogical." If you had to write PF rules like that you'd go crazy. That's why most people use first-match logic. Per the manpage, if the logic is DenyUsers > AllowUsers > DenyGroups > AllowGroups, then there has to be a immediate stop to the logic chain at each stage. if $user ~= %DenyUsers; then ( deny; return ) if $user ~= %AllowUsers; then { allow; return ) if $user member of %DenyGroups; then (deny; return ) if $user member of %AllowGroups; then (allow; return ) if (%AllowUsers != null || %AllowGroups != null); then deny Anything else makes no sense. Can we expect a change in the future? Or if I were to submit a patch to fix this, would it be accepted? The other flaw I see here is the treatment of 'root'. There are already special keywords controlling that UID, so it makes no sense to have to tag 'root' into this logic either. PermitRootLogin is supposed to be sufficient to dictate that particular outcome. From mpatton at inforelay.com Fri Aug 10 13:38:24 2012 From: mpatton at inforelay.com (mpatton at inforelay.com) Date: Thu, 9 Aug 2012 23:38:24 -0400 Subject: AllowUsers "logic" and failure to indicate bad configuration In-Reply-To: <8c3724260457f4e2b4c251710f865a4c.squirrel@www.inforelay.com> References: <8c3724260457f4e2b4c251710f865a4c.squirrel@www.inforelay.com> Message-ID: <0a51b214282f6ad467b4746df4423f2d.squirrel@www.inforelay.com> > way. It should not be necessary for AllowUsers to be the superset of > AllowGroups. Sorry, I meant to say AllowGroups should not have to include at least one GID from each of AllowUsers. I forgot to add that a case could be made for the Allow/Deny directives to be valid within all Match{} stanzas as well. Right now there is only one global rule. However, it makes perfect sense to want to selectively override it. At first blush I thought that maybe the rules specified in Match{} would just be used to "flip" the logic arrived at from the main body; eg. AllowUsers could effectively negate any rejection reached by the main body logic. Then I thought that maybe it would be better to treat it as a complete substitution of the matching global rule directive. To me, this seems to be the most elegant but will have to be clearly spelled out in documentation. The 3rd option would call for ignoring the entire global rule in favor of building a new one based strictly off the directives contained within Match{}. Yes, in most cases they'll be a lot of cut/pasting from the global rule and tweaking them to taste, but the intent of the stanza is unambiguous. If we were to implement option 2, specifying all 4 directives would achieve the same result as option 3. Thoughts? From 1.41421 at gmail.com Tue Aug 14 06:01:26 2012 From: 1.41421 at gmail.com (JCA) Date: Mon, 13 Aug 2012 14:01:26 -0600 Subject: X.509 certificates and OpenSSH Message-ID: I understand that recent versions of OpenSSH have support for X.509 certificates, in the sense that OpenSSH clients can extract the relevant information from such certificates and use it in order to carry out the usual public key-based authentication. Having a quick look into the SSH RFCs, it would seem that this is the only way in which OpenSSH supports X.509-based authentication. That is, it all boils down to the client, not the server. The server just gets a public key, as usual; it never knows whether it has been extracted from an X.509 certificate, or from a run-of-the-mill OpenSSH public key file. Is this correct? From jan.pechanec at oracle.com Tue Aug 14 07:10:25 2012 From: jan.pechanec at oracle.com (Jan Pechanec) Date: Mon, 13 Aug 2012 14:10:25 -0700 (PDT) Subject: X.509 certificates and OpenSSH In-Reply-To: References: Message-ID: On Mon, 13 Aug 2012, JCA wrote: >I understand that recent versions of OpenSSH have support for X.509 >certificates, in the sense that OpenSSH clients can extract the >relevant information from such certificates and use it in order to >carry out the usual public key-based authentication. no, OpenSSH supports its own PKI. X.509 support is available via a publicly available patch though. >Having a quick look into the SSH RFCs, it would seem that this is the >only way in which OpenSSH supports X.509-based authentication. That >is, it all boils down to the client, not the server. The server just >gets a public key, as usual; it never knows whether it has been >extracted from an X.509 certificate, or from a run-of-the-mill OpenSSH >public key file. > >Is this correct? no, it is not. The objective of a certificate is to bind an identity to a public key to avoid the distribution of such keys. If I give you a certificate and you can validate it, me having a private key is a proof that I'm who I claim to be (unless I stole the key). However, if I give an SSH server just a public key, me having a private key proves nothing about me unless the server can find the public key in the authorized_keys file of the user I'm trying to log in as. that means that with X.509 authentication, you send over a certificate, not just a public key, and the peer (client for server authentication, server for user authentication) has to validate it using a trusted anchor (usually a CA cert), map the cert to a username or a hostname, and let the other side prove that it has a private key. That is why X.509 authentication does not need files like known_hosts or authorized_keys (but could fall back to them if the cert cannot be validated). in other words, both sides need to know about X.509, whether for a server or user authentication protocol (or both). the details on X.509 support in SSH are in RFC 6187, not sure how supported that is (it's quite recent). draft-saarenmaa-ssh-x509-00 has been implemented in quite a few SSH apps out there, including the Roumen Petrov's above mentioned patch. J. -- Jan Pechanec http://blogs.oracle.com/janp From 1.41421 at gmail.com Tue Aug 14 13:40:22 2012 From: 1.41421 at gmail.com (JCA) Date: Mon, 13 Aug 2012 21:40:22 -0600 Subject: X.509 certificates and OpenSSH In-Reply-To: References: Message-ID: On Mon, Aug 13, 2012 at 3:10 PM, Jan Pechanec wrote: > On Mon, 13 Aug 2012, JCA wrote: > >>I understand that recent versions of OpenSSH have support for X.509 >>certificates, in the sense that OpenSSH clients can extract the >>relevant information from such certificates and use it in order to >>carry out the usual public key-based authentication. > > no, OpenSSH supports its own PKI. X.509 support is available via > a publicly available patch though. > >>Having a quick look into the SSH RFCs, it would seem that this is the >>only way in which OpenSSH supports X.509-based authentication. That >>is, it all boils down to the client, not the server. The server just >>gets a public key, as usual; it never knows whether it has been >>extracted from an X.509 certificate, or from a run-of-the-mill OpenSSH >>public key file. >> >>Is this correct? > > no, it is not. The objective of a certificate is to bind an > identity to a public key to avoid the distribution of such keys. If I > give you a certificate and you can validate it, me having a private key > is a proof that I'm who I claim to be (unless I stole the key). However, > if I give an SSH server just a public key, me having a private key > proves nothing about me unless the server can find the public key in the > authorized_keys file of the user I'm trying to log in as. > > that means that with X.509 authentication, you send over a > certificate, not just a public key, and the peer (client for server > authentication, server for user authentication) has to validate it using > a trusted anchor (usually a CA cert), map the cert to a username or a > hostname, and let the other side prove that it has a private key. That > is why X.509 authentication does not need files like known_hosts or > authorized_keys (but could fall back to them if the cert cannot be > validated). > > in other words, both sides need to know about X.509, whether for > a server or user authentication protocol (or both). > > the details on X.509 support in SSH are in RFC 6187, not sure > how supported that is (it's quite recent). draft-saarenmaa-ssh-x509-00 > has been implemented in quite a few SSH apps out there, including the > Roumen Petrov's above mentioned patch. Thanks for your answer, which has indeed dissipated quite a few doubts. Since I was unaware of RFC 6187 the Saarenmaa draft, I could not understand how the SSH protocol suite could accommodate for certificate exchange between client and server. From sue at pennine.com Tue Aug 14 20:07:08 2012 From: sue at pennine.com (Sue Spence) Date: Tue, 14 Aug 2012 11:07:08 +0100 Subject: New % substitution for sshd_config Message-ID: I have a system which would benefit from the ability to configure sftp chroot jailing to a directory containing a group name. I have created a simple patch which implements this change and tested it on the openssh 6.0p release. Briefly, %g expands to the user's group name in a ChrootDirectory configuration line. Is it possible that such a change might be rolled into openssh? I would like to be able to use an unpatched version eventually. I will forward the patch in a separate message. Thanks, Sue Spence Pennine Web Works Ltd From sue at pennine.com Tue Aug 14 20:15:31 2012 From: sue at pennine.com (Sue Spence) Date: Tue, 14 Aug 2012 11:15:31 +0100 Subject: Fwd: %g patch for ChrootDirectory References: Message-ID: <6666E968-3512-4310-BDDD-FC1FBD0E4071@pennine.com> Sent from my iPhone Begin forwarded message: > From: Sue Spence > Date: 13 August 2012 08:02:08 GMT+01:00 > To: "susan.spence" > Subject: ssh > > From openssh at roumenpetrov.info Wed Aug 15 07:19:12 2012 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Wed, 15 Aug 2012 00:19:12 +0300 Subject: X.509 certificates and OpenSSH In-Reply-To: References: Message-ID: <502AC0D0.80202@roumenpetrov.info> JCA wrote: > [SNIP] > Thanks for your answer, which has indeed dissipated quite a few > doubts. Since I was unaware of RFC 6187 the Saarenmaa draft, I could > not understand how the SSH protocol suite could accommodate for > certificate exchange between client and server. It is in my todo list but I don't have time to implement new formats. Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From listaddr at gmail.com Wed Aug 15 20:04:43 2012 From: listaddr at gmail.com (Marco) Date: Wed, 15 Aug 2012 12:04:43 +0200 Subject: scp -3 and filenames Message-ID: I really appreciate the recent introduction of the -3 option to scp to perform remote-to-remote copies going through the local machine. I understand this option disables the progress meter (although I don't understand the reason for that, but surely it's just me not knowing the internals well enough). However, would it be terribly complicated to just print the bare names of the files being copied? After all, when using -v the names are printed (in between the other debugging stuff). Thanks. From michael.hebenstreit at intel.com Thu Aug 16 02:42:15 2012 From: michael.hebenstreit at intel.com (Hebenstreit, Michael) Date: Wed, 15 Aug 2012 16:42:15 +0000 Subject: No subject Message-ID: unsubscribe From keisial at gmail.com Sat Aug 18 02:04:23 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 17 Aug 2012 18:04:23 +0200 Subject: Fwd: %g patch for ChrootDirectory In-Reply-To: <6666E968-3512-4310-BDDD-FC1FBD0E4071@pennine.com> References: <6666E968-3512-4310-BDDD-FC1FBD0E4071@pennine.com> Message-ID: <502E6B87.5030300@gmail.com> On 14/08/12 12:15, Sue Spence wrote: > Sent from my iPhone > > Begin forwarded message: > >> From: Sue Spence >> Date: 13 August 2012 08:02:08 GMT+01:00 >> To: "susan.spence" >> Subject: ssh >> >> >> The list ate your patch. Please resend with a content-type of text/plain or similar. Regards From sdaoden at gmail.com Sat Aug 18 04:49:17 2012 From: sdaoden at gmail.com (Steffen "Daode" Nurpmeso) Date: Fri, 17 Aug 2012 20:49:17 +0200 Subject: Question about -b mode of sftp(1) and auto-chdir behaviour Message-ID: <502e922d.poNfTjilsqG4nl7PDOWK+MCA@dietcurd.wild-life.local> Hello, i'm curious to know wether the automatic chdir behaviour of sftp(1) in batch mode is a side-effect of the current implementation, or if it's instead a regular feature. And, if it's indeed the latter, wether there is any compatibility problem if one would actually rely on it? I'll attach a copy+paste diff to document this nice feature in sftp.1, just for the hoped-for case. Thank you! ..and ciao, --steffen -------------- next part -------------- diff --git a/sftp.1 b/sftp.1 --- a/sftp.1 +++ b/sftp.1 @@ -57,7 +57,11 @@ .Oc .Nm sftp .Fl b Ar batchfile -.Oo Ar user Ns @ Oc Ns Ar host +.Oo +.Ar user Ns @ Oc Ns +.Ar host Ns Oo : Ns Ar dir Ns +.Op Ar / +.Oc .Sh DESCRIPTION .Nm is an interactive file transfer program, similar to From sue at pennine.com Sat Aug 18 09:00:35 2012 From: sue at pennine.com (Sue Spence) Date: Sat, 18 Aug 2012 00:00:35 +0100 Subject: %g patch for ChrootDirectory In-Reply-To: <502E6B87.5030300@gmail.com> References: <6666E968-3512-4310-BDDD-FC1FBD0E4071@pennine.com> <502E6B87.5030300@gmail.com> Message-ID: <0088CC14-474F-403B-B980-93B0C619D488@pennine.com> Hi ?ngel, Let's see if mail.app will do the right thing. Best regards, -sue On 17 Aug 2012, at 17:04, ?ngel Gonz?lez wrote: >>> > The list ate your patch. > Please resend with a content-type of text/plain or similar. > > Regards > From djm at mindrot.org Sat Aug 18 09:31:55 2012 From: djm at mindrot.org (Damien Miller) Date: Sat, 18 Aug 2012 09:31:55 +1000 (EST) Subject: %g patch for ChrootDirectory In-Reply-To: <0088CC14-474F-403B-B980-93B0C619D488@pennine.com> References: <6666E968-3512-4310-BDDD-FC1FBD0E4071@pennine.com> <502E6B87.5030300@gmail.com> <0088CC14-474F-403B-B980-93B0C619D488@pennine.com> Message-ID: On Sat, 18 Aug 2012, Sue Spence wrote: > > > Hi ?ngel, > > > Let's see if mail.app will do the right thing. Nope - your best bet is to attach it to a bug on https://bugzilla.mindrot.org/ so it doesn't get eaten by my fascist list software or forgotton about. -d From keisial at gmail.com Sat Aug 18 09:40:51 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 18 Aug 2012 01:40:51 +0200 Subject: %g patch for ChrootDirectory In-Reply-To: <0088CC14-474F-403B-B980-93B0C619D488@pennine.com> References: <6666E968-3512-4310-BDDD-FC1FBD0E4071@pennine.com> <502E6B87.5030300@gmail.com> <0088CC14-474F-403B-B980-93B0C619D488@pennine.com> Message-ID: <502ED683.2000701@gmail.com> On 18/08/12 01:00, Sue Spence wrote: > Let's see if mail.app will do the right thing. > > Best regards, You sent it with Content-Type: application/octet-stream so although I got a copy for being directly addressed, I bet the list didn't. Resending myself. -------------- next part -------------- A non-text attachment was scrubbed... Name: groupparam.patch Type: text/x-patch Size: 961 bytes Desc: not available URL: From sue at pennine.com Sat Aug 18 21:46:33 2012 From: sue at pennine.com (Sue Spence) Date: Sat, 18 Aug 2012 12:46:33 +0100 Subject: %g patch for ChrootDirectory In-Reply-To: <502ED683.2000701@gmail.com> References: <6666E968-3512-4310-BDDD-FC1FBD0E4071@pennine.com> <502E6B87.5030300@gmail.com> <0088CC14-474F-403B-B980-93B0C619D488@pennine.com> <502ED683.2000701@gmail.com> Message-ID: On 18 August 2012 00:40, ?ngel Gonz?lez wrote: > On 18/08/12 01:00, Sue Spence wrote: >> Let's see if mail.app will do the right thing. >> >> Best regards, > You sent it with > > Content-Type: application/octet-stream > so although I got a copy for being directly addressed, > I bet the list didn't. > > Resending myself. > > Fabulous, thank you. I shall prefer to use bugzilla in future. -sue From jainkkapil at gmail.com Sun Aug 19 22:23:17 2012 From: jainkkapil at gmail.com (kapil jain) Date: Sun, 19 Aug 2012 17:53:17 +0530 Subject: Bug Report and patch fix Message-ID: Hi I found this issue in scp in the following blog link http://oldpapyrus.wordpress.com/2012/08/08/scp-a-funny-error/ when the wrong local file name is specified in local to remote transfer mode, scp first tries to establish the connection rather than to check first whether the file is proper or not. However I could not find a reported bug for this. I am attaching the fix as patch for this issue. Thanks Kapil http://jainkkapil.wordpress.com -------------- next part -------------- ? patch.txt Index: scp.c =================================================================== RCS file: /cvs/openssh/scp.c,v retrieving revision 1.189 diff -u -r1.189 scp.c --- scp.c 22 Sep 2011 11:38:01 -0000 1.189 +++ scp.c 19 Aug 2012 12:00:35 -0000 @@ -364,6 +364,7 @@ void tolocal(int, char *[]); void toremote(char *, int, char *[]); void usage(void); +void verifypath(char *); int main(int argc, char **argv) @@ -551,6 +552,18 @@ } void +verifypath(char *file) +{ + if (access(file, F_OK) == -1) + { + errno = ENOENT; + run_err("%s: %s",file,strerror(errno)); + killchild(0); + } +} + + +void toremote(char *targ, int argc, char **argv) { char *bp, *host, *src, *suser, *thost, *tuser, *arg; @@ -656,6 +669,7 @@ if (remin == -1) { xasprintf(&bp, "%s -t %s%s", cmd, *targ == '-' ? "-- " : "", targ); + verifypath(argv[i]);/*added to check for the local existence of file before trying to do anything*/ host = cleanhostname(thost); if (do_cmd(host, tuser, bp, &remin, &remout) < 0) From jainkkapil at gmail.com Mon Aug 20 02:48:21 2012 From: jainkkapil at gmail.com (kapil jain) Date: Sun, 19 Aug 2012 22:18:21 +0530 Subject: Bug Report and patch fix In-Reply-To: References: Message-ID: Hi, I reviewed my previous patch which causes scp to exit if the file does not exist rather than continuing the transfer if there are multiple input files. Here is another patch which differs from previous one in functionality that even if one file does not exist, continue with other input files and if valid, continue to upload them rather then exiting the scp program if an invalid file is found. -- Thanks Kapil K. Jain http://jainkkapil.wordpress.com -------------- next part -------------- ? patch.txt Index: scp.c =================================================================== RCS file: /cvs/openssh/scp.c,v retrieving revision 1.189 diff -u -r1.189 scp.c --- scp.c 22 Sep 2011 11:38:01 -0000 1.189 +++ scp.c 19 Aug 2012 16:43:00 -0000 @@ -653,6 +653,16 @@ if (do_local_cmd(&alist) != 0) errs = 1; } else { /* local to remote */ + /* Before trying to establish connection, + * check whether file exists or not. + * If not then continue with next file + */ + if( access(argv[i],F_OK) == -1 ){ + errno = ENOENT; + run_err("%s: %s",argv[i],strerror(errno)); + continue; + } + if (remin == -1) { xasprintf(&bp, "%s -t %s%s", cmd, *targ == '-' ? "-- " : "", targ); From lists at eitanadler.com Mon Aug 20 09:49:12 2012 From: lists at eitanadler.com (Eitan Adler) Date: Sun, 19 Aug 2012 19:49:12 -0400 Subject: Bug Report and patch fix In-Reply-To: References: Message-ID: On 19 August 2012 12:48, kapil jain wrote: > Hi, > > I reviewed my previous patch which causes scp to exit if the file does not > exist rather than continuing the transfer if there are multiple input files. > Here is another patch which differs from previous one in functionality that > even if one file does not exist, continue with other input files and if > valid, continue to upload them rather then exiting the scp program if an > invalid file is found. just a note: this suffers from a TOCTOU bug, though it is basically harmless (it reverts to the current behavior). -- Eitan Adler From jainkkapil at gmail.com Mon Aug 20 17:11:36 2012 From: jainkkapil at gmail.com (kapil jain) Date: Mon, 20 Aug 2012 12:41:36 +0530 Subject: Bug Report and patch fix In-Reply-To: References: Message-ID: On Mon, Aug 20, 2012 at 5:19 AM, Eitan Adler wrote: > On 19 August 2012 12:48, kapil jain wrote: > > Hi, > > > > I reviewed my previous patch which causes scp to exit if the file does > not > > exist rather than continuing the transfer if there are multiple input > files. > > Here is another patch which differs from previous one in functionality > that > > even if one file does not exist, continue with other input files and if > > valid, continue to upload them rather then exiting the scp program if an > > invalid file is found. > > just a note: this suffers from a TOCTOU bug, though it is basically > harmless (it reverts to the current behavior). > > -- > Eitan Adler > I dont think so as this is being serial execution and no process is forked before that. -- Thanks Kapil K. Jain http://jainkkapil.wordpress.com From carstenmattner at gmail.com Tue Aug 21 01:39:13 2012 From: carstenmattner at gmail.com (Carsten Mattner) Date: Mon, 20 Aug 2012 17:39:13 +0200 Subject: seccomp_filter In-Reply-To: References: Message-ID: On Thu, Jul 26, 2012 at 1:57 PM, Damien Miller wrote: > On Thu, 26 Jul 2012, Carsten Mattner wrote: > >> > HEAD will fallback to the rlimit pseudo-sandbox if seccomp was enabled at >> > compile-time but is not available at runtime. openssh-6.0 will fatal() for >> > these cases. >> >> That sounds good. Is it available in a single commit I could backport >> until the next release? Is it correct that November 2012 is the >> release date for 6.1? > > It will probably be sooner than that. Perhaps late this month even. > > http://hg.mindrot.org/openssh/raw-rev/d8de6b1ebec9 should be all you > need. Any new on the 6.1 release? Also when running ./configure with a sufficient linux kernel and headers will the autoconf script default to the seccomp sandbox? From lists at eitanadler.com Tue Aug 21 02:28:12 2012 From: lists at eitanadler.com (Eitan Adler) Date: Mon, 20 Aug 2012 12:28:12 -0400 Subject: Bug Report and patch fix In-Reply-To: References: Message-ID: On 20 August 2012 03:11, kapil jain wrote: > > > On Mon, Aug 20, 2012 at 5:19 AM, Eitan Adler wrote: >> >> On 19 August 2012 12:48, kapil jain wrote: >> > Hi, >> > >> > I reviewed my previous patch which causes scp to exit if the file does >> > not >> > exist rather than continuing the transfer if there are multiple input >> > files. >> > Here is another patch which differs from previous one in functionality >> > that >> > even if one file does not exist, continue with other input files and if >> > valid, continue to upload them rather then exiting the scp program if an >> > invalid file is found. >> >> just a note: this suffers from a TOCTOU bug, though it is basically >> harmless (it reverts to the current behavior). >> >> -- >> Eitan Adler > > > I dont think so as this is being serial execution and no process is forked > before that. What happens if the file is removed by a different process after scp is started? As I mentioned: this harms nothing, but later code shouldn't rely on the file existing. :) -- Eitan Adler From djm at mindrot.org Tue Aug 21 08:59:25 2012 From: djm at mindrot.org (Damien Miller) Date: Tue, 21 Aug 2012 08:59:25 +1000 (EST) Subject: seccomp_filter In-Reply-To: References: Message-ID: On Mon, 20 Aug 2012, Carsten Mattner wrote: > On Thu, Jul 26, 2012 at 1:57 PM, Damien Miller wrote: > > On Thu, 26 Jul 2012, Carsten Mattner wrote: > > > >> > HEAD will fallback to the rlimit pseudo-sandbox if seccomp was enabled at > >> > compile-time but is not available at runtime. openssh-6.0 will fatal() for > >> > these cases. > >> > >> That sounds good. Is it available in a single commit I could backport > >> until the next release? Is it correct that November 2012 is the > >> release date for 6.1? > > > > It will probably be sooner than that. Perhaps late this month even. > > > > http://hg.mindrot.org/openssh/raw-rev/d8de6b1ebec9 should be all you > > need. > > Any new on the 6.1 release? within days > Also when running ./configure with a sufficient linux kernel and headers > will the autoconf script default to the seccomp sandbox? Yes -d From djm at mindrot.org Tue Aug 21 21:10:37 2012 From: djm at mindrot.org (Damien Miller) Date: Tue, 21 Aug 2012 21:10:37 +1000 (EST) Subject: Call for testing: OpenSSH 6.1 Message-ID: Hi, OpenSSH 6.1 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains a couple of new features and bug fixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via anonymous CVS using the instructions at http://www.openssh.com/portable.html#cvs or via Mercurial at http://hg.mindrot.org/openssh Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: $ ./configure && make tests Live testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Below is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. ------------------------------- Features: * sshd(8): This release turns on pre-auth sandboxing sshd by default for new installs, by setting UsePrivilegeSeparation=sandbox in sshd_config. * ssh-keygen(1): Add options to specify starting line number and number of lines to process when screening moduli candidates, allowing processing of different parts of a candidate moduli file in parallel * sshd(8): The Match directive now supports matching on the local (listen) address and port upon which the incoming connection was received via LocalAddress and LocalPort clauses. * sshd(8): Extend sshd_config Match directive to allow setting AcceptEnv and {Allow,Deny}{Users,Groups} * Add support for RFC6594 SSHFP DNS records for ECDSA key types. bz#1978 * ssh-keygen(1): Allow conversion of RSA1 keys to public PEM and PKCS8 * sshd(8): Allow the sshd_config PermitOpen directive to accept "none" as an argument to refuse all port-forwarding requests. * sshd(8): Support "none" as an argument for AuthorizedPrincipalsFile * ssh-keyscan(1): Look for ECDSA keys by default. bz#1971 * sshd(8): Add "VersionAddendum" to sshd_config to allow server operators to append some arbitrary text to the server SSH protocol banner. Bugfixes: * ssh(1)/sshd(8): Don't spin in accept() in situations of file descriptor exhaustion. Instead back off for a while. * ssh(1)/sshd(8): Remove hmac-sha2-256-96 and hmac-sha2-512-96 MACs as they were removed from the specification. bz#2023, * sshd(8): Handle long comments in config files better. bz#2025 * ssh(1): Delay setting tty_flag so RequestTTY options are correctly picked up. bz#1995 * sshd(8): Fix handling of /etc/nologin incorrectly being applied to root on platforms that use login_cap. Portable OpenSSH: * sshd(8): Allow sshd pre-auth sandboxing to fall-back to the rlimit sandbox from the Linux SECCOMP filter sandbox when the latter is not available in the kernel. * ssh(1): Fix NULL dereference when built with LDNS and using DNSSEC to retrieve a CNAME SSHFP record. * Fix cross-compilation problems related to pkg-config. bz#1996 Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From shk.schneider at gmail.com Fri Aug 24 00:02:59 2012 From: shk.schneider at gmail.com (Alan SCHNEIDER) Date: Thu, 23 Aug 2012 16:02:59 +0200 Subject: Configure report Message-ID: Hi, I got this. configure: WARNING: sys/un.h: present but cannot be compiled configure: WARNING: sys/un.h: check for missing prerequisite headers? configure: WARNING: sys/un.h: see the Autoconf documentation configure: WARNING: sys/un.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/un.h: proceeding with the preprocessor's result configure: WARNING: sys/un.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## Do you need other information? Also on Debian 6.0.5, OpenSSL headers are in /usr/include/openssl and not /usr/local/ssl/include From kevin.brott at gmail.com Fri Aug 24 06:02:36 2012 From: kevin.brott at gmail.com (Kevin Brott) Date: Thu, 23 Aug 2012 13:02:36 -0700 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: References: Message-ID: On Tue, Aug 21, 2012 at 4:10 AM, Damien Miller wrote: > Hi, > > OpenSSH 6.1 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains a > couple of new features and bug fixes. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > ... OS Build_Target CC OpenSSL BUILD TEST ============== =========================== ================ ============ ===== ================= RHEL 2.1 i686-pc-linux-gnu gcc 2.96-129.7.2 0.9.6b OK all tests passed RHL 8.0 i686-pc-linux-gnu gcc 3.2.2-5 0.9.7a OK all tests passed RHEL 3.0 i686-pc-linux-gnu gcc 3.2.3-20 0.9.7a OK all tests passed Fedora Core r2 i686-pc-linux-gnu gcc 3.3.3-7 0.9.7a OK*1 all tests passed RHEL 4.0 nu6 i686-pc-linux-gnu gcc 3.4.6 0.9.7a OK*1 all tests passed RHEL 4.0 nu8 x86_64-unknown-linux-gnu gcc 3.4.6-8 0.9.7a OK*1 all tests passed RHEL 5.4 i686-pc-linux-gnu gcc 4.1.2-46 0.9.8e-fips OK all tests passed RHEL 5.4 x86_64-redhat-linux gcc 4.1.2-46 0.9.8e-fips OK*2 all tests passed RHEL 5.5 i686-pc-linux-gnu gcc 4.1.2-48 0.9.8e-fips OK all tests passed RHEL 5.5 x86_64-redhat-linux gcc 4.1.2-48 0.9.8e-fips OK all tests passed RHEL 5.6 i686-pc-linux-gnu gcc 4.1.2-50 0.9.8e-fips OK all tests passed RHEL 5.6 x86_64-redhat-linux gcc 4.1.2-50 0.9.8e-fips OK*2 all tests passed RHEL 5.7 i686-redhat-linux gcc 4.1.2-51 0.9.8e-fips OK all tests passed RHEL 5.7 x86_64-redhat-linux gcc 4.1.2-51 0.9.8e-fips OK all tests passed RHEL 6.2 i686-redhat-linux gcc 4.4.6-3 1.0.0-fips OK*2 all tests passed RHEL 6.2 x86_64-redhat-linux gcc 4.4.6-3 1.0.0-fips OK all tests passed Ubuntu 8.04.04 i686-pc-linux-gnu gcc 4.2.4-1ubuntu4 0.9.8g OK all tests passed Ubuntu 11.04 x86_64-linux-gnu gcc 4.5.2-8ubuntu4 0.9.8o OK all tests passed AIX 5300-12-02 powerpc-ibm-aix5.3.0.0 gcc 4.0.0 0.9.8m OK all tests passed AIX 5300-12-04 powerpc-ibm-aix5.3.0.0 xlc 8.0.0.16 0.9.8f OK*3 all tests passed AIX 6100-04-06 powerpc-ibm-aix6.1.0.0 gcc 4.2.0 0.9.8k OK all tests passed AIX 6100-04-03 powerpc-ibm-aix6.1.0.0 xlc 10.1.0.8 0.9.8k OK*3 all tests passed AIX 7100-01-05 powerpc-ibm-aix7.1.0.0 xlc 11.1.0.6 0.9.8m OK all tests passed HP-UX 11.23 ia64-hp-hpux11.23 gcc 4.1.1 0.9.8o OK all tests passed HP-UX 11.31 ia64-hp-hpux11.31 gcc 4.6.2 0.9.8n OK all tests passed HP-UX 11.31 ia64-hp-hpux11.31 C/aC++ A.06.20 0.9.8n OK all tests passed Zero problems getting this snapshot to compile that weren't because of missing/old system zlib/openssl headers. -- # include /* Kevin Brott */ From djm at mindrot.org Fri Aug 24 09:56:12 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 Aug 2012 09:56:12 +1000 (EST) Subject: Call for testing: OpenSSH 6.1 In-Reply-To: References: Message-ID: Thanks again for the great testing - it's really appreciated, especially when it all passes :) -d On Thu, 23 Aug 2012, Kevin Brott wrote: > On Tue, Aug 21, 2012 at 4:10 AM, Damien Miller wrote: > Hi, > > OpenSSH 6.1 is almost ready for release, so we would appreciate > testing > on as many platforms and systems as possible. This release > contains a > couple of new features and bug fixes. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > ... > > OS Build_Target CC OpenSSL > BUILD TEST > ============== =========================== ================ ============ > ===== ================= > RHEL 2.1 i686-pc-linux-gnu gcc 2.96-129.7.2 0.9.6b > OK all tests passed > RHL 8.0 i686-pc-linux-gnu gcc 3.2.2-5 0.9.7a > OK all tests passed > RHEL 3.0 i686-pc-linux-gnu gcc 3.2.3-20 0.9.7a > OK all tests passed > Fedora Core r2 i686-pc-linux-gnu gcc 3.3.3-7 0.9.7a > OK*1 all tests passed > RHEL 4.0 nu6 i686-pc-linux-gnu gcc 3.4.6 0.9.7a > OK*1 all tests passed > RHEL 4.0 nu8 x86_64-unknown-linux-gnu gcc 3.4.6-8 0.9.7a > OK*1 all tests passed > RHEL 5.4 i686-pc-linux-gnu gcc 4.1.2-46 0.9.8e-fips > OK all tests passed > RHEL 5.4 x86_64-redhat-linux gcc 4.1.2-46 0.9.8e-fips > OK*2 all tests passed > RHEL 5.5 i686-pc-linux-gnu gcc 4.1.2-48 0.9.8e-fips > OK all tests passed > RHEL 5.5 x86_64-redhat-linux gcc 4.1.2-48 0.9.8e-fips > OK all tests passed > RHEL 5.6 i686-pc-linux-gnu gcc 4.1.2-50 0.9.8e-fips > OK all tests passed > RHEL 5.6 x86_64-redhat-linux gcc 4.1.2-50 0.9.8e-fips > OK*2 all tests passed > RHEL 5.7 i686-redhat-linux gcc 4.1.2-51 0.9.8e-fips > OK all tests passed > RHEL 5.7 x86_64-redhat-linux gcc 4.1.2-51 0.9.8e-fips > OK all tests passed > RHEL 6.2 i686-redhat-linux gcc 4.4.6-3 1.0.0-fips > OK*2 all tests passed > RHEL 6.2 x86_64-redhat-linux gcc 4.4.6-3 1.0.0-fips > OK all tests passed > Ubuntu 8.04.04 i686-pc-linux-gnu gcc 4.2.4-1ubuntu4 0.9.8g > OK all tests passed > Ubuntu 11.04 x86_64-linux-gnu gcc 4.5.2-8ubuntu4 0.9.8o > OK all tests passed > AIX 5300-12-02 powerpc-ibm-aix5.3.0.0 gcc 4.0.0 0.9.8m > OK all tests passed > AIX 5300-12-04 powerpc-ibm-aix5.3.0.0 xlc 8.0.0.16 0.9.8f > OK*3 all tests passed > AIX 6100-04-06 powerpc-ibm-aix6.1.0.0 gcc 4.2.0 0.9.8k > OK all tests passed > AIX 6100-04-03 powerpc-ibm-aix6.1.0.0 xlc 10.1.0.8 0.9.8k > OK*3 all tests passed > AIX 7100-01-05 powerpc-ibm-aix7.1.0.0 xlc 11.1.0.6 0.9.8m > OK all tests passed > HP-UX 11.23 ia64-hp-hpux11.23 gcc 4.1.1 0.9.8o > OK all tests passed > HP-UX 11.31 ia64-hp-hpux11.31 gcc 4.6.2 0.9.8n > OK all tests passed > HP-UX 11.31 ia64-hp-hpux11.31 C/aC++ A.06.20 0.9.8n > OK all tests passed > > Zero problems getting this snapshot to compile that weren't because of > missing/old system zlib/openssl headers. > > -- > # include > /* Kevin Brott */ > > > > From carson at taltos.org Fri Aug 24 11:01:30 2012 From: carson at taltos.org (Carson Gaspar) Date: Thu, 23 Aug 2012 18:01:30 -0700 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: References: Message-ID: <5036D26A.30407@taltos.org> openssh-SNAP-20120824, Solaris 11 - rlimit sandbox fails at configure, as select fails (I think this is expected) - make tests hangs at: ... run test reconfigure.sh ... /export/data/build/openssh-SNAP-20120824/regress/reconfigure.sh: warning: line 18: `...` obsolete, use $(...) /export/data/build/openssh-SNAP-20120824/regress/reconfigure.sh: warning: line 25: `...` obsolete, use $(...) ok simple connect after reconfigure run test dynamic-forward.sh ... /export/data/build/openssh-SNAP-20120824/regress/dynamic-forward.sh: warning: line 6: `...` obsolete, use $(...) /export/data/build/openssh-SNAP-20120824/regress/dynamic-forward.sh: warning: line 27: `...` obsolete, use $(...) /export/data/build/openssh-SNAP-20120824/regress/dynamic-forward.sh: warning: line 53: `...` obsolete, use $(...) nc: read failed (0/8): Broken pipe ssh_exchange_identification: Connection closed by remote host cmp: EOF on /export/data/build/openssh-SNAP-20120824/regress/ls.copy corrupted copy of /bin/ls nc: read failed (0/8): Broken pipe ssh_exchange_identification: Connection closed by remote host cmp: EOF on /export/data/build/openssh-SNAP-20120824/regress/ls.copy corrupted copy of /bin/ls From dtucker at zip.com.au Fri Aug 24 13:41:40 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 24 Aug 2012 13:41:40 +1000 Subject: Configure report In-Reply-To: References: Message-ID: <20120824034140.GA22257@gate.dtucker.net> On Thu, Aug 23, 2012 at 04:02:59PM +0200, Alan SCHNEIDER wrote: > Hi, I got this. > > configure: WARNING: sys/un.h: present but cannot be compiled > configure: WARNING: sys/un.h: check for missing prerequisite headers? > configure: WARNING: sys/un.h: see the Autoconf documentation > configure: WARNING: sys/un.h: section "Present But Cannot Be Compiled" > configure: WARNING: sys/un.h: proceeding with the preprocessor's result > configure: WARNING: sys/un.h: in the future, the compiler will take > precedence > configure: WARNING: ## ------------------------------------------- ## > configure: WARNING: ## Report this to openssh-unix-dev at mindrot.org ## > configure: WARNING: ## ------------------------------------------- ## > > Do you need other information? well the platform and compiler you saw it on would help :-) also, in config.log near the bottom will be the actual compiler error that it saw (most likely a missing typdef of some kind). > Also on Debian 6.0.5, OpenSSL headers are in /usr/include/openssl and not > /usr/local/ssl/include /usr/local/ssl/include is the default for (self installed) openssl. we could potentially go hunting around for it if it's not there, but that could also cause problems (eg library/header mismatches). 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 fredports at mufley.com Fri Aug 24 21:36:13 2012 From: fredports at mufley.com (Frederico Costa (ports)) Date: Fri, 24 Aug 2012 12:36:13 +0100 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: References: Message-ID: <5037672D.7000109@mufley.com> Run ok in FreeBSD 8.3-RELEASE-p4 -- ok expand %h and %n all tests passed -- Fred On 24/08/2012 00:56, Damien Miller wrote: > Thanks again for the great testing - it's really appreciated, especially when > it all passes :) > > -d > > On Thu, 23 Aug 2012, Kevin Brott wrote: > >> On Tue, Aug 21, 2012 at 4:10 AM, Damien Miller wrote: >> Hi, >> >> OpenSSH 6.1 is almost ready for release, so we would appreciate >> testing >> on as many platforms and systems as possible. This release >> contains a >> couple of new features and bug fixes. >> >> Snapshot releases for portable OpenSSH are available from >> http://www.mindrot.org/openssh_snap/ >> >> ... >> >> OS Build_Target CC OpenSSL >> BUILD TEST >> ============== =========================== ================ ============ >> ===== ================= >> RHEL 2.1 i686-pc-linux-gnu gcc 2.96-129.7.2 0.9.6b >> OK all tests passed >> RHL 8.0 i686-pc-linux-gnu gcc 3.2.2-5 0.9.7a >> OK all tests passed >> RHEL 3.0 i686-pc-linux-gnu gcc 3.2.3-20 0.9.7a >> OK all tests passed >> Fedora Core r2 i686-pc-linux-gnu gcc 3.3.3-7 0.9.7a >> OK*1 all tests passed >> RHEL 4.0 nu6 i686-pc-linux-gnu gcc 3.4.6 0.9.7a >> OK*1 all tests passed >> RHEL 4.0 nu8 x86_64-unknown-linux-gnu gcc 3.4.6-8 0.9.7a >> OK*1 all tests passed >> RHEL 5.4 i686-pc-linux-gnu gcc 4.1.2-46 0.9.8e-fips >> OK all tests passed >> RHEL 5.4 x86_64-redhat-linux gcc 4.1.2-46 0.9.8e-fips >> OK*2 all tests passed >> RHEL 5.5 i686-pc-linux-gnu gcc 4.1.2-48 0.9.8e-fips >> OK all tests passed >> RHEL 5.5 x86_64-redhat-linux gcc 4.1.2-48 0.9.8e-fips >> OK all tests passed >> RHEL 5.6 i686-pc-linux-gnu gcc 4.1.2-50 0.9.8e-fips >> OK all tests passed >> RHEL 5.6 x86_64-redhat-linux gcc 4.1.2-50 0.9.8e-fips >> OK*2 all tests passed >> RHEL 5.7 i686-redhat-linux gcc 4.1.2-51 0.9.8e-fips >> OK all tests passed >> RHEL 5.7 x86_64-redhat-linux gcc 4.1.2-51 0.9.8e-fips >> OK all tests passed >> RHEL 6.2 i686-redhat-linux gcc 4.4.6-3 1.0.0-fips >> OK*2 all tests passed >> RHEL 6.2 x86_64-redhat-linux gcc 4.4.6-3 1.0.0-fips >> OK all tests passed >> Ubuntu 8.04.04 i686-pc-linux-gnu gcc 4.2.4-1ubuntu4 0.9.8g >> OK all tests passed >> Ubuntu 11.04 x86_64-linux-gnu gcc 4.5.2-8ubuntu4 0.9.8o >> OK all tests passed >> AIX 5300-12-02 powerpc-ibm-aix5.3.0.0 gcc 4.0.0 0.9.8m >> OK all tests passed >> AIX 5300-12-04 powerpc-ibm-aix5.3.0.0 xlc 8.0.0.16 0.9.8f >> OK*3 all tests passed >> AIX 6100-04-06 powerpc-ibm-aix6.1.0.0 gcc 4.2.0 0.9.8k >> OK all tests passed >> AIX 6100-04-03 powerpc-ibm-aix6.1.0.0 xlc 10.1.0.8 0.9.8k >> OK*3 all tests passed >> AIX 7100-01-05 powerpc-ibm-aix7.1.0.0 xlc 11.1.0.6 0.9.8m >> OK all tests passed >> HP-UX 11.23 ia64-hp-hpux11.23 gcc 4.1.1 0.9.8o >> OK all tests passed >> HP-UX 11.31 ia64-hp-hpux11.31 gcc 4.6.2 0.9.8n >> OK all tests passed >> HP-UX 11.31 ia64-hp-hpux11.31 C/aC++ A.06.20 0.9.8n >> OK all tests passed >> >> Zero problems getting this snapshot to compile that weren't because of >> missing/old system zlib/openssl headers. >> >> -- >> # include >> /* Kevin Brott */ >> >> >> >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Frederico Costa fredports at mufley.com From ffernand.list at gmail.com Sat Aug 25 01:19:00 2012 From: ffernand.list at gmail.com (Filipe Fernandes) Date: Fri, 24 Aug 2012 11:19:00 -0400 Subject: any hope for bug 1663 or similar function? In-Reply-To: References: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> Message-ID: Hello All, I have the same problem with 150+ boxes all running OpenSSH. Although we don't use the patch, and have to write services which modify the authorized_keys file on all boxes. OpenSSH 6.1 looks like it's up for review, but as far as I can tell, there's been no mention of the patch. Is there a timeline for something like this, or is it simply because the patch is not worthy of inclusion? thanks, filipe On Thu, Mar 8, 2012 at 6:36 PM, Damien Miller wrote: > On Tue, 21 Feb 2012, Michael W. Lucas wrote: > >> Hi folks, >> >> Is there any hope for an external source of public keys, such as given >> in bug 1663? >> >> I have dozens of servers, and I have to patch sshd on the vast >> majority of them. OpenSSH is a BSD program, but the BSD boxes are the >> most difficult to manage because of this. > > Yes, I'm aware that this has been on my TODO list for too long. I hope to > come up with some command or agent-based solution (ideally based on one > of the existing patches) soon, but have had some other work queued ahead of > it for a while. I hope I'll be able to do it for 6.1. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From scottmc2 at gmail.com Sat Aug 25 03:15:07 2012 From: scottmc2 at gmail.com (scottmc) Date: Fri, 24 Aug 2012 10:15:07 -0700 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: References: Message-ID: On 8/21/12, Damien Miller wrote: > Hi, > > OpenSSH 6.1 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains a > couple of new features and bug fixes. > We get the following failure(s) on Haiku with snapshot 20120824: run test connect.sh ... ok simple connect run test proxy-connect.sh ... ok proxy connect run test connect-privsep.sh ... Connection closed by UNKNOWN WARNING: ssh privsep/sandbox+proxyconnect protocol 1 failed Connection closed by UNKNOWN WARNING: ssh privsep/sandbox+proxyconnect protocol 2 failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt '' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt '' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'A' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'A' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'F' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'F' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'G' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'G' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'H' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'H' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'J' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'J' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'P' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'P' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'R' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'R' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'S' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'S' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'X' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'X' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'Z' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'Z' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt '<' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt '<' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt '>' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt '>' failed failed proxy connect with privsep make[1]: *** [t-exec] Error 1 make[1]: Leaving directory `/boot/common/develop/haikuports/net-misc/openssh/work/openssh/regress' make: *** [tests] Error 2 All of the tests that are run before the failure(s) passed. -scottmc From wieland at purdue.edu Sat Aug 25 04:55:33 2012 From: wieland at purdue.edu (Jeff Wieland) Date: Fri, 24 Aug 2012 14:55:33 -0400 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: <1667193072.4841.1345549080083.JavaMail.root@mailhub026.itcs.purdue.edu> References: <1667193072.4841.1345549080083.JavaMail.root@mailhub026.itcs.purdue.edu> Message-ID: <5037CE25.8010302@purdue.edu> Ran find on SPARC Solaris 10 using Sun Studio 12. ok expand %h and %n all tests passed Damien Miller wrote: > Hi, > > OpenSSH 6.1 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains a > couple of new features and bug fixes. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > Portable OpenSSH is also available via anonymous CVS using the > instructions at http://www.openssh.com/portable.html#cvs or > via Mercurial at http://hg.mindrot.org/openssh > > Running the regression tests supplied with Portable OpenSSH does not > require installation and is a simply: > > $ ./configure && make tests > > Live testing on suitable non-production systems is also > appreciated. Please send reports of success or failure to > openssh-unix-dev at mindrot.org. > > Below is a summary of changes. More detail may be found in the ChangeLog > in the portable OpenSSH tarballs. > > Thanks to the many people who contributed to this release. > > ------------------------------- > > Features: > > * sshd(8): This release turns on pre-auth sandboxing sshd by default for > new installs, by setting UsePrivilegeSeparation=sandbox in sshd_config. > * ssh-keygen(1): Add options to specify starting line number and number of > lines to process when screening moduli candidates, allowing processing > of different parts of a candidate moduli file in parallel > * sshd(8): The Match directive now supports matching on the local (listen) > address and port upon which the incoming connection was received via > LocalAddress and LocalPort clauses. > * sshd(8): Extend sshd_config Match directive to allow setting AcceptEnv > and {Allow,Deny}{Users,Groups} > * Add support for RFC6594 SSHFP DNS records for ECDSA key types. bz#1978 > * ssh-keygen(1): Allow conversion of RSA1 keys to public PEM and PKCS8 > * sshd(8): Allow the sshd_config PermitOpen directive to accept "none" as > an argument to refuse all port-forwarding requests. > * sshd(8): Support "none" as an argument for AuthorizedPrincipalsFile > * ssh-keyscan(1): Look for ECDSA keys by default. bz#1971 > * sshd(8): Add "VersionAddendum" to sshd_config to allow server operators > to append some arbitrary text to the server SSH protocol banner. > > Bugfixes: > > * ssh(1)/sshd(8): Don't spin in accept() in situations of file > descriptor exhaustion. Instead back off for a while. > * ssh(1)/sshd(8): Remove hmac-sha2-256-96 and hmac-sha2-512-96 MACs as > they were removed from the specification. bz#2023, > * sshd(8): Handle long comments in config files better. bz#2025 > * ssh(1): Delay setting tty_flag so RequestTTY options are correctly > picked up. bz#1995 > * sshd(8): Fix handling of /etc/nologin incorrectly being applied to root > on platforms that use login_cap. > > Portable OpenSSH: > > * sshd(8): Allow sshd pre-auth sandboxing to fall-back to the rlimit > sandbox from the Linux SECCOMP filter sandbox when the latter is > not available in the kernel. > * ssh(1): Fix NULL dereference when built with LDNS and using DNSSEC to > retrieve a CNAME SSHFP record. > * Fix cross-compilation problems related to pkg-config. bz#1996 > > Reporting Bugs: > =============== > > - Please read http://www.openssh.com/report.html > Security bugs should be reported directly to openssh at openssh.com > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, > Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and > Ben Lindstrom. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Jeff Wieland | Purdue University Network Systems Administrator | ITSO UNIX Platforms Voice: (765)496-8234 | 401 S. Grant Street FAX: (765)496-1380 | West Lafayette, IN 47907 From sdaoden at gmail.com Sat Aug 25 22:39:08 2012 From: sdaoden at gmail.com (Steffen Daode Nurpmeso) Date: Sat, 25 Aug 2012 14:39:08 +0200 Subject: Question about -b mode of sftp(1) and auto-chdir behaviour In-Reply-To: <502e922d.poNfTjilsqG4nl7PDOWK+MCA@dietcurd.wild-life.local> References: <502e922d.poNfTjilsqG4nl7PDOWK+MCA@dietcurd.wild-life.local> Message-ID: <5038c76c.rHYD9oNYRWFUaWoj/rWSz/ua@dietcurd.wild-life.local> |Hello, |i'm curious to know wether the automatic chdir behaviour of sftp(1) |in batch mode is a side-effect of the current implementation, or |if it's instead a regular feature. And, if it's indeed the latter, |wether there is any compatibility problem if one would actually |rely on it? |I'll attach a copy+paste diff to document this nice feature in |sftp.1, just for the hoped-for case. |Thank you! ..and ciao, | |--steffen Well, it seems that those are nice but wanted side effects from before start: |?146%2[steffen at sherwood openssh.hg]$ hg s-log -r 5792 || Rev: || 5792:ddc05befc083 || Auth: djm || Date: Tue, 27 Jan 2004 10:22:00 +0000 | |- djm at cvs.openbsd.org 2004/01/27 10:08:10 | [sftp.c] | reorder parsing so user:skey at host:file works (bugzilla #777) | patch from admorten AT umich.edu; ok markus@ | |?0%2[steffen at sherwood openssh.hg]$ hg s-log -r 5877 || Rev: || 5877:6e27a7ce8139 || Auth: djm || Date: Wed, 18 Feb 2004 03:30:55 +0000 | |- djm at cvs.openbsd.org 2004/02/17 11:03:08 | [sftp.c] | sftp.c and sftp-int.c, together at last; ok markus@ Great if that would be documented... Btw. i've recognized that, when ssh is used with -M option, other sessions inherit the PW entry of that session. Happens that i've changed the shell via 'chpass -s' due to debugging and the new login still presented the old shell. grep(1)ping for pw_(chan|expi) in openssh.hg didn't helped so much. Shouldn't this (GNU configure is the one which triggers the most when grep(1)ed) be taken into account even under Control*? I still haven't read the SSH related RFCs, and it seems that a connection is heavily related with PW stuff, on the other hand. Thanks and ciao, --steffen From bruce at untroubled.org Sun Aug 26 14:07:03 2012 From: bruce at untroubled.org (Bruce Guenter) Date: Sat, 25 Aug 2012 22:07:03 -0600 Subject: Capturing sftp logs on stderr Message-ID: <20120826040703.GA12580@untroubled.org> Hi. I am running sshd under supervise, using the -e option to capture the logs on stderr. I am trying to do the same for the sftp subsystem, but I have been unable to do so. Using the same -e option to sftp-server simply sends the debug messages to the client's stderr (instead of sshd's stderr) which doesn't help. Is there any way to do this? I am not averse to doing a local modification to the source to make this happen, if that will be necessary. -- Bruce Guenter http://untroubled.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From dtucker at zip.com.au Sun Aug 26 15:37:21 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 26 Aug 2012 15:37:21 +1000 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: <5036D26A.30407@taltos.org> References: <5036D26A.30407@taltos.org> Message-ID: <20120826053721.GA24056@gate.dtucker.net> On Thu, Aug 23, 2012 at 06:01:30PM -0700, Carson Gaspar wrote: > openssh-SNAP-20120824, Solaris 11 > > - rlimit sandbox fails at configure, as select fails (I think this > is expected) it is: configure tests whether or not select() works with zero available decriptors (as it would be when used for the simple rlimit sandbox). This doesn't work on Solaris, we think because poll (which is what's used under the covers) requires a spare descriptor. > - make tests hangs at: [...] > warning: line 18: `...` obsolete, use $(...) bah, I hate that notation. > nc: read failed (0/8): Broken pipe > ssh_exchange_identification: Connection closed by remote host > cmp: EOF on /export/data/build/openssh-SNAP-20120824/regress/ls.copy > corrupted copy of /bin/ls > nc: read failed (0/8): Broken pipe > ssh_exchange_identification: Connection closed by remote host > cmp: EOF on /export/data/build/openssh-SNAP-20120824/regress/ls.copy I just installed a Solaris 11 x86 VM to test this, and (other than needing to create the privsep user and chroot dir) it worked ok. Which version of "nc" do you have? 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 Mon Aug 27 10:45:34 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 27 Aug 2012 10:45:34 +1000 (EST) Subject: Capturing sftp logs on stderr In-Reply-To: <20120826040703.GA12580@untroubled.org> References: <20120826040703.GA12580@untroubled.org> Message-ID: On Sat, 25 Aug 2012, Bruce Guenter wrote: > Hi. > > I am running sshd under supervise, using the -e option to capture the > logs on stderr. I am trying to do the same for the sftp subsystem, but > I have been unable to do so. Using the same -e option to sftp-server > simply sends the debug messages to the client's stderr (instead of > sshd's stderr) which doesn't help. > > Is there any way to do this? I am not averse to doing a local > modification to the source to make this happen, if that will be > necessary. There isn't any way to do this in sshd/sftp-server. sftp-server is run within a session by sftp and usually has stderr attached to the session when it runs. If you want to hack sshd, then you'd probably need to conditionally disable one of the dup2() calls in session.c:do_exec_no_pty() based on the contents of its command argument. -d From carson at taltos.org Mon Aug 27 17:35:35 2012 From: carson at taltos.org (Carson Gaspar) Date: Mon, 27 Aug 2012 00:35:35 -0700 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: <20120826053721.GA24056@gate.dtucker.net> References: <5036D26A.30407@taltos.org> <20120826053721.GA24056@gate.dtucker.net> Message-ID: <503B2347.9070708@taltos.org> On 8/25/12 10:37 PM, Darren Tucker wrote: > I just installed a Solaris 11 x86 VM to test this, and (other than > needing to create the privsep user and chroot dir) it worked ok. Which > version of "nc" do you have? carson:gandalf 0 $ pkg info pkg:/network/netcat Name: network/netcat Summary: Netcat Command Category: Applications/Internet State: Installed Publisher: solaris Version: 0.5.11 Build Release: 5.11 Branch: 0.175.0.0.0.2.1 Packaging Date: October 19, 2011 06:15:08 AM Size: 140.44 kB FMRI: pkg://solaris/network/netcat at 0.5.11,5.11-0.175.0.0.0.2.1:20111019T061508Z I can try building a different version, if you tell me which of the umpteen forks I should try ;-) -- Carson From bruce at untroubled.org Tue Aug 28 00:31:00 2012 From: bruce at untroubled.org (Bruce Guenter) Date: Mon, 27 Aug 2012 08:31:00 -0600 Subject: Capturing sftp logs on stderr In-Reply-To: References: <20120826040703.GA12580@untroubled.org> Message-ID: <20120827143100.GA11109@untroubled.org> On Mon, Aug 27, 2012 at 10:45:34AM +1000, Damien Miller wrote: > There isn't any way to do this in sshd/sftp-server. sftp-server is run > within a session by sftp and usually has stderr attached to the session > when it runs. That's what I had discovered. Only "usually has stderr attached"? Are there conditions it wouldn't? > If you want to hack sshd, then you'd probably need to conditionally > disable one of the dup2() calls in session.c:do_exec_no_pty() based on > the contents of its command argument. Thanks. Do I also need to change the calls to session_set_fds, or will the err fd parameter be harmless if it's not actually in use? -- Bruce Guenter http://untroubled.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From vinschen at redhat.com Tue Aug 28 18:51:33 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 28 Aug 2012 10:51:33 +0200 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: References: Message-ID: <20120828085133.GA13993@calimero.vinschen.de> Hi Damien, On Aug 21 21:10, Damien Miller wrote: > Hi, > > OpenSSH 6.1 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains a > couple of new features and bug fixes. Builds fine on Cygwin, all tests pass. However, we're just about to change the w32api headers from the Mingw.org based ones to the Mingw-w64 based ones. With the new set of Windows headers, there's a collision with definitions from the wincrypt.h header. It would be nice if we could get rid of the problem even before the new headers are available. The patch is simple: Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.14 diff -u -p -r1.14 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 30 Mar 2012 03:07:07 -0000 1.14 +++ openbsd-compat/bsd-cygwin_util.h 28 Aug 2012 08:38:35 -0000 @@ -36,6 +36,8 @@ #undef ERROR +#define WIN32_LEAN_AND_MEAN + #include #include #include This is also compatible with the older Mingw.org header files. Is it still ok to put this into 6.1? Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Tue Aug 28 20:01:12 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 28 Aug 2012 20:01:12 +1000 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: <20120828085133.GA13993@calimero.vinschen.de> References: <20120828085133.GA13993@calimero.vinschen.de> Message-ID: <20120828100112.GA28615@gate.dtucker.net> On Tue, Aug 28, 2012 at 10:51:33AM +0200, Corinna Vinschen wrote: [...] > Builds fine on Cygwin, all tests pass. Thanks. > However, we're just about to change the w32api headers from the > Mingw.org based ones to the Mingw-w64 based ones. With the new set of > Windows headers, there's a collision with definitions from the > wincrypt.h header. It would be nice if we could get rid of the problem > even before the new headers are available. The patch is simple: [...] > +#define WIN32_LEAN_AND_MEAN What a coincidence: lean and mean are our favourite type of headers. Applied, it will be in 6.1p1. 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 dtucker at zip.com.au Tue Aug 28 20:11:52 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 28 Aug 2012 20:11:52 +1000 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: <503B2347.9070708@taltos.org> References: <5036D26A.30407@taltos.org> <20120826053721.GA24056@gate.dtucker.net> <503B2347.9070708@taltos.org> Message-ID: <20120828101152.GA28702@gate.dtucker.net> On Mon, Aug 27, 2012 at 12:35:35AM -0700, Carson Gaspar wrote: > On 8/25/12 10:37 PM, Darren Tucker wrote: > > >I just installed a Solaris 11 x86 VM to test this, and (other than > >needing to create the privsep user and chroot dir) it worked ok. Which > >version of "nc" do you have? > > carson:gandalf 0 $ pkg info pkg:/network/netcat [...] > FMRI: pkg://solaris/network/netcat at 0.5.11,5.11-0.175.0.0.0.2.1:20111019T061508Z > > I can try building a different version, if you tell me which of the > umpteen forks I should try ;-) Hm, that's what I have and it works for me. Any version that has -x and -X as proxy and proxy protocol respectively should work. You don't have the original avian.org nc somewhere else in the path? Unfortunately debugging test failures is a pain. I usually put a "set -x" at the start of test-exec.sh and an "exit 0" in the fail() function, then you can repeat the last failing command with more -v's. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Aug 28 20:43:18 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 28 Aug 2012 20:43:18 +1000 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: References: Message-ID: <20120828104318.GA29456@gate.dtucker.net> On Fri, Aug 24, 2012 at 10:15:07AM -0700, scottmc wrote: > On 8/21/12, Damien Miller wrote: > > Hi, > > > > OpenSSH 6.1 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This release contains a > > couple of new features and bug fixes. > > > > > We get the following failure(s) on Haiku with snapshot 20120824: [...] > run test connect-privsep.sh ... > Connection closed by UNKNOWN > WARNING: ssh privsep/sandbox+proxyconnect protocol 1 failed > Connection closed by UNKNOWN > WARNING: ssh privsep/sandbox+proxyconnect protocol 2 failed > Connection closed by UNKNOWN > ssh privsep/sandbox+proxyconnect protocol 1 mopt '' failed > Connection closed by UNKNOWN OK, I think this is because privsep doesn't work (without SUDO, anyway), so when it tests with the malloc options it'll fail rather than just warn like the original sandbox test. The trivial workaround is to replace the last "fail" in connect-privsep.sh with "warn". I'm not sure what the proper thing to do is (at some point we're really going to care about sandbox failures). 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 dtucker at zip.com.au Tue Aug 28 22:22:42 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 28 Aug 2012 22:22:42 +1000 Subject: Call for testing: OpenSSH 6.1 In-Reply-To: <20120828104318.GA29456@gate.dtucker.net> References: <20120828104318.GA29456@gate.dtucker.net> Message-ID: <20120828122242.GA31609@gate.dtucker.net> On Tue, Aug 28, 2012 at 08:43:18PM +1000, Darren Tucker wrote: [...] > OK, I think this is because privsep doesn't work (without SUDO, anyway), > so when it tests with the malloc options it'll fail rather than just > warn like the original sandbox test. > > The trivial workaround is to replace the last "fail" in > connect-privsep.sh with "warn". I'm not sure what the proper thing to > do is (at some point we're really going to care about sandbox failures). OK, I tried it on a VM. Firstly I couldn't build without disabling utmpx (should configure do that itself?), next I made the sandbox failures non-fatal on haiku (also fixed some spacing). With these changes it at least makes it past the sandbox tests... Index: configure.ac =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/configure.ac,v retrieving revision 1.496 diff -u -p -r1.496 configure.ac --- configure.ac 6 Jul 2012 01:49:29 -0000 1.496 +++ configure.ac 28 Aug 2012 12:03:57 -0000 @@ -561,12 +561,14 @@ main() { if (NSVersionOfRunTimeLibrary(" *-*-dragonfly*) SSHDLIBS="$SSHDLIBS -lcrypt" ;; -*-*-haiku*) - LIBS="$LIBS -lbsd " - AC_CHECK_LIB([network], [socket]) - AC_DEFINE([HAVE_U_INT64_T]) - MANTYPE=man - ;; +*-*-haiku*) + LIBS="$LIBS -lbsd" + AC_CHECK_LIB([network], [socket]) + AC_DEFINE([HAVE_U_INT64_T]) + AC_DEFINE([DISABLE_UTMPX]) + AC_DEFINE([BROKEN_SANDBOX], [1], [Sandbox does not work on haiku]) + MANTYPE=man + ;; *-*-hpux*) # first we define all of the options common to all HP-UX releases CPPFLAGS="$CPPFLAGS -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1" Index: regress/connect-privsep.sh =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/regress/connect-privsep.sh,v retrieving revision 1.5 diff -u -p -r1.5 connect-privsep.sh --- regress/connect-privsep.sh 2 Jul 2012 14:53:18 -0000 1.5 +++ regress/connect-privsep.sh 28 Aug 2012 12:05:12 -0000 @@ -13,6 +13,12 @@ for p in 1 2; do fi done +if config_defined BROKEN_SANDBOX; then + FAIL=warn +else + FAIL=fail +fi + cp $OBJ/sshd_proxy.orig $OBJ/sshd_proxy echo 'UsePrivilegeSeparation sandbox' >> $OBJ/sshd_proxy @@ -20,7 +26,7 @@ for p in 1 2; do ${SSH} -$p -F $OBJ/ssh_proxy 999.999.999.999 true if [ $? -ne 0 ]; then # XXX replace this with fail once sandbox has stabilised - warn "ssh privsep/sandbox+proxyconnect protocol $p failed" + $FAIL "ssh privsep/sandbox+proxyconnect protocol $p failed" fi done @@ -30,7 +36,7 @@ for m in '' A F G H J P R S X Z '<' '>'; for p in 1 2; do env MALLOC_OPTIONS="$m" ${SSH} -$p -F $OBJ/ssh_proxy 999.999.999.999 true if [ $? -ne 0 ]; then - fail "ssh privsep/sandbox+proxyconnect protocol $p mopt '$m' failed" + $FAIL "ssh privsep/sandbox+proxyconnect protocol $p mopt '$m' failed" fi done done -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at cvs.openbsd.org Wed Aug 29 12:16:22 2012 From: djm at cvs.openbsd.org (Damien Miller) Date: Tue, 28 Aug 2012 20:16:22 -0600 (MDT) Subject: Announce: OpenSSH 6.1 released Message-ID: <201208290216.q7T2GMIC023811@cvs.openbsd.org> OpenSSH 6.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Changes since OpenSSH 6.0 ========================= This is primarily a bugfix release. Features: * sshd(8): This release turns on pre-auth sandboxing sshd by default for new installs, by setting UsePrivilegeSeparation=sandbox in sshd_config. * ssh-keygen(1): Add options to specify starting line number and number of lines to process when screening moduli candidates, allowing processing of different parts of a candidate moduli file in parallel * sshd(8): The Match directive now supports matching on the local (listen) address and port upon which the incoming connection was received via LocalAddress and LocalPort clauses. * sshd(8): Extend sshd_config Match directive to allow setting AcceptEnv and {Allow,Deny}{Users,Groups} * Add support for RFC6594 SSHFP DNS records for ECDSA key types. bz#1978 * ssh-keygen(1): Allow conversion of RSA1 keys to public PEM and PKCS8 * sshd(8): Allow the sshd_config PermitOpen directive to accept "none" as an argument to refuse all port-forwarding requests. * sshd(8): Support "none" as an argument for AuthorizedPrincipalsFile * ssh-keyscan(1): Look for ECDSA keys by default. bz#1971 * sshd(8): Add "VersionAddendum" to sshd_config to allow server operators to append some arbitrary text to the server SSH protocol banner. Bugfixes: * ssh(1)/sshd(8): Don't spin in accept() in situations of file descriptor exhaustion. Instead back off for a while. * ssh(1)/sshd(8): Remove hmac-sha2-256-96 and hmac-sha2-512-96 MACs as they were removed from the specification. bz#2023, * sshd(8): Handle long comments in config files better. bz#2025 * ssh(1): Delay setting tty_flag so RequestTTY options are correctly picked up. bz#1995 * sshd(8): Fix handling of /etc/nologin incorrectly being applied to root on platforms that use login_cap. Portable OpenSSH: * sshd(8): Allow sshd pre-auth sandboxing to fall-back to the rlimit sandbox from the Linux SECCOMP filter sandbox when the latter is not available in the kernel. * ssh(1): Fix NULL dereference when built with LDNS and using DNSSEC to retrieve a CNAME SSHFP record. * Fix cross-compilation problems related to pkg-config. bz#1996 Checksums: ========== - SHA1 (openssh-6.1.tar.gz) = 7ed5b491cfebcaee2273d1f872314107273c2167 - SHA1 (openssh-6.1p1.tar.gz) = 751c92c912310c3aa9cadc113e14458f843fc7b3 Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From mag at netherworld.org Thu Aug 30 05:52:40 2012 From: mag at netherworld.org (John E. Krokes) Date: Wed, 29 Aug 2012 15:52:40 -0400 (EDT) Subject: second FIPS patch for openssh 6.0p1, fix pubkey Message-ID: <201208291952.q7TJqeLc021077@cthulhu.netherworld.org> The patch to enable FIPS mode for openssh 6.0p1 missed two instances of the ssh client trying to use MD5. It causes pubkey-based authentication to fail in FIPS mode. I have copied the missing changes from auth2-pubkey.c into sshconnect2.c. Here is a patch: diff -cr openssh-6.0p1/sshconnect2.c openssh-6.0p1-patched/sshconnect2.c *** openssh-6.0p1/sshconnect2.c Sun May 29 07:42:34 2011 --- openssh-6.0p1-patched/sshconnect2.c Wed Aug 29 14:59:19 2012 *************** *** 77,82 **** --- 77,88 ---- #include "ssh-gss.h" #endif + #include + #ifdef OPENSSL_FIPS + #include + #endif + + /* import */ extern char *client_version_string; extern char *server_version_string; *************** *** 591,597 **** key->type, pktype); goto done; } ! fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); debug2("input_userauth_pk_ok: fp %s", fp); xfree(fp); --- 604,611 ---- key->type, pktype); goto done; } ! fp = key_fingerprint(key, FIPS_mode() ? SSH_FP_SHA1 : SSH_FP_MD5, ! SSH_FP_HEX); debug2("input_userauth_pk_ok: fp %s", fp); xfree(fp); *************** *** 1204,1210 **** int have_sig = 1; char *fp; ! fp = key_fingerprint(id->key, SSH_FP_MD5, SSH_FP_HEX); debug3("sign_and_send_pubkey: %s %s", key_type(id->key), fp); xfree(fp); --- 1218,1225 ---- int have_sig = 1; char *fp; ! fp = key_fingerprint(id->key, FIPS_mode() ? SSH_FP_SHA1 : SSH_FP_MD5, ! SSH_FP_HEX); debug3("sign_and_send_pubkey: %s %s", key_type(id->key), fp); xfree(fp); -Mag From bruce at untroubled.org Thu Aug 30 08:10:31 2012 From: bruce at untroubled.org (Bruce Guenter) Date: Wed, 29 Aug 2012 16:10:31 -0600 Subject: PATCH: Log the PID of executed commands Message-ID: <20120829221031.GA30280@untroubled.org> sshd logs the PID of the network child and the user child sshd processes. This patch adds logging the PID of invoked commands for completeness. diff --git a/session.c b/session.c index f3baea2..dd1d0e8 100644 --- a/session.c +++ b/session.c @@ -579,6 +579,7 @@ do_exec_no_pty(Session *s, const char *command) do_child(s, command); /* NOTREACHED */ default: + verbose("command is on pid %ld", (long)pid); break; } @@ -729,6 +730,7 @@ do_exec_pty(Session *s, const char *command) do_child(s, command); /* NOTREACHED */ default: + verbose("command is on pid %ld", (long)pid); break; } -- Bruce Guenter http://untroubled.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From jonathan.P.schaaf at ge.com Fri Aug 31 01:23:48 2012 From: jonathan.P.schaaf at ge.com (Schaaf, Jonathan P (GE Healthcare)) Date: Thu, 30 Aug 2012 15:23:48 +0000 Subject: second FIPS patch for openssh 6.0p1, fix pubkey In-Reply-To: <201208291952.q7TJqeLc021077@cthulhu.netherworld.org> References: <201208291952.q7TJqeLc021077@cthulhu.netherworld.org> Message-ID: > The patch to enable FIPS mode for openssh 6.0p1 missed two instances of the ssh client trying to use MD5. I assume you're talking about the patch I posted. My patch had another mistake... there's a third place with the same issue, in ssh-agent.c I've updated the patch and reposted it at the same location: http://jpschaaf.com/stuff/openssh-6.0p1-fips.diff Comments are always appreciated... Particularly if anyone knows what the "right way" is to handle the case where cipher is NULL in authfile.c Jonathan From m-ou.se at m-ou.se Fri Aug 31 08:26:28 2012 From: m-ou.se at m-ou.se (Maurice Bos) Date: Fri, 31 Aug 2012 00:26:28 +0200 Subject: Patch to allow glob patterns as authorized keys file names Message-ID: Hello, The patch below allows one to configure not only files like "%h/.ssh/authorized_keys" to be used, but also patterns like "%h/.ssh/authorized_keys.d/*". This can be quite useful if somebody or something has to manage an above average number of keys, like when running a git server that determines the user based on the ssh key. (Like what they do at github.com, and what Gitolite does.) Kind regards, -Maurice Bos- Author: Maurice Bos Date: Thu Aug 30 15:14:49 2012 +0200 Allow glob patterns in authorized keys file names. diff --git a/auth2-pubkey.c b/auth2-pubkey.c --- a/auth2-pubkey.c +++ b/auth2-pubkey.c @@ -454,9 +454,16 @@ user_key_allowed(struct passwd *pw, Key *key) return success; for (i = 0; !success && i < options.num_authkeys_files; i++) { + int j; + glob_t glob_result; file = expand_authorized_keys( options.authorized_keys_files[i], pw); - success = user_key_allowed2(pw, key, file); + glob(file, GLOB_NOCHECK, NULL, &glob_result); + for (j = 0; !success && j < glob_result.gl_pathc; j++) { + char *f = glob_result.gl_pathv[j]; + success = user_key_allowed2(pw, key, f); + } + globfree(&glob_result); xfree(file); } From eric at fergusonhome.net Fri Aug 31 08:45:28 2012 From: eric at fergusonhome.net (Eric Ferguson) Date: Thu, 30 Aug 2012 15:45:28 -0700 Subject: Shell access to SSH KDF Message-ID: <20120830154528.ec202ca2b26352bf496332a09d60cd13.7093a25808.wbe@email15.secureserver.net> Hi everyone. I'm currently running through FIPS validation, and this year CAVP requires KDF tests for SSH. I'm running OpenSSH v5.6p1 and I see that the 6 keys that I need are derived in kex_derived_keys in kex.c. However, I don't yet see any way for me to access this function from an existing command line tool, being able to pass in K, H, and the session_id from the test vector. Is my only option to build a custom executable, linking in key derivation function I need, or am I missing something? Thank you. Eric From djm at mindrot.org Fri Aug 31 09:49:44 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 31 Aug 2012 09:49:44 +1000 (EST) Subject: Shell access to SSH KDF In-Reply-To: <20120830154528.ec202ca2b26352bf496332a09d60cd13.7093a25808.wbe@email15.secureserver.net> References: <20120830154528.ec202ca2b26352bf496332a09d60cd13.7093a25808.wbe@email15.secureserver.net> Message-ID: On Thu, 30 Aug 2012, Eric Ferguson wrote: > Hi everyone. > I'm currently running through FIPS validation, and this year CAVP > requires KDF tests for SSH. I'm running OpenSSH v5.6p1 and I see that > the 6 keys that I need are derived in kex_derived_keys in kex.c. > However, I don't yet see any way for me to access this function from an > existing command line tool, being able to pass in K, H, and the > session_id from the test vector. Is my only option to build a custom > executable, linking in key derivation function I need, or am I missing > something? No, there is definitely no way to invoke the KEX KDF from the shell. You'll have to make you own executable. In the future, we hope to make bits like this available in a more friendly library form but I don't think we will ever expose them via a command interface directly. If there are specific tests that need to be done then I'd certainly consider adding them as unit tests though. -d From eric at fergusonhome.net Fri Aug 31 21:01:38 2012 From: eric at fergusonhome.net (Eric Ferguson) Date: Fri, 31 Aug 2012 04:01:38 -0700 Subject: Shell access to SSH KDF Message-ID: <20120831040138.ec202ca2b26352bf496332a09d60cd13.17c706f758.wbe@email15.secureserver.net> >> Hi everyone. >> I'm currently running through FIPS validation, and this year CAVP >> requires KDF tests for SSH. I'm running OpenSSH v5.6p1 and I see that >> the 6 keys that I need are derived in kex_derived_keys in kex.c. >> However, I don't yet see any way for me to access this function from an >> existing command line tool, being able to pass in K, H, and the >> session_id from the test vector. Is my only option to build a custom >> executable, linking in key derivation function I need, or am I missing >> something? > >No, there is definitely no way to invoke the KEX KDF from the shell. You'll >have to make you own executable. > >In the future, we hope to make bits like this available in a more friendly >library form but I don't think we will ever expose them via a command >interface directly. If there are specific tests that need to be done then >I'd certainly consider adding them as unit tests though. > >-d Thank you for your prompt reply. Will do. Assuming the KDF certifications are here to stay for future FIPS validations, a small test harness for CAVP test vectors is likely something several others may benefit from. Thanks again. Eric From n3rd at Safe-mail.net Fri Aug 31 22:40:55 2012 From: n3rd at Safe-mail.net (n3rd at Safe-mail.net) Date: Fri, 31 Aug 2012 17:40:55 +0500 Subject: How to detect if key ssh-add'ed with '-c' or without? Message-ID: Hi all. Some background: I'm using my own wrapper script for ssh that deals with multitude of IP addresses, user accounts, keys and other ssh parameters for bunch of managed hosts. On X session start i (actually, my script) load all my private keys with 'ssh-add -c', to get confirmation on every key usage. This works bad with autossh, so i would like to add some logic: if I specify to run autossh with some host/user/key, the scipt will reload the private key without -c option (asking me for password). And maybe at the end of autossh session, reload the key back with 'ssh-add -c'. So, how can i detect if key loaded with -c option or without? 'ssh-add -l' lacks such information. My last guess is such: before actually start autossh it's possible to set some small script at SSH_ASKPASS, try to use the key, and if that script is launched, it means i need to reload the key without '-c'. Ugly. PS: BTW there is also no way to get key expiration time (if set with 'ssh-add -t'). From djm at mindrot.org Fri Aug 31 22:49:32 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 31 Aug 2012 22:49:32 +1000 (EST) Subject: How to detect if key ssh-add'ed with '-c' or without? In-Reply-To: References: Message-ID: On Fri, 31 Aug 2012, n3rd at Safe-mail.net wrote: > Hi all. Some background: I'm using my own wrapper script for ssh that > deals with multitude of IP addresses, user accounts, keys and other > ssh parameters for bunch of managed hosts. > > On X session start i (actually, my script) load all my private keys > with 'ssh-add -c', to get confirmation on every key usage. > > This works bad with autossh, so i would like to add some logic: if I > specify to run autossh with some host/user/key, the scipt will reload > the private key without -c option (asking me for password). And maybe > at the end of autossh session, reload the key back with 'ssh-add -c'. > > So, how can i detect if key loaded with -c option or without? You can't, and you won't without a protocol extension to ssh-agent. At the moment the key query message and responses don't have fields to indicate whether any constraints were set. See PROTOCOL.agent in the OpenSSH source for details. It probably wouldn't be something that one would want to advertise to an attacker anyway, as stumbing over keys that require confirmation is the sort of thing that gives them away... > My last guess is such: before actually start autossh it's possible to > set some small script at SSH_ASKPASS, try to use the key, and if that > script is launched, it means i need to reload the key without '-c'. > Ugly. Worse, it won't work - SSH_ASKPASS needs to be set for ssh-agent, not ssh-add. So you can't reset it easily like this. > PS: BTW there is also no way to get key expiration time (if set > with 'ssh-add -t'). Same problem - expiration times are key constrains like confirm-required. -d From n3rd at Safe-mail.net Fri Aug 31 23:18:37 2012 From: n3rd at Safe-mail.net (n3rd at Safe-mail.net) Date: Fri, 31 Aug 2012 18:18:37 +0500 Subject: How to detect if key ssh-add'ed with '-c' or without? Message-ID: Damien, thank you for fast response! Ok, i will just keep list of keys loaded with '-c' in some /tmp/file, and will correct it in process. -------- Original Message -------- From: Damien Miller To: n3rd at Safe-mail.net Cc: openssh-unix-dev at mindrot.org Subject: Re: How to detect if key ssh-add'ed with '-c' or without? Date: Fri, 31 Aug 2012 22:49:32 +1000 (EST) > On Fri, 31 Aug 2012, n3rd at Safe-mail.net wrote: > > > Hi all. Some background: I'm using my own wrapper script for ssh that > > deals with multitude of IP addresses, user accounts, keys and other > > ssh parameters for bunch of managed hosts. > > > > On X session start i (actually, my script) load all my private keys > > with 'ssh-add -c', to get confirmation on every key usage. > > > > This works bad with autossh, so i would like to add some logic: if I > > specify to run autossh with some host/user/key, the scipt will reload > > the private key without -c option (asking me for password). And maybe > > at the end of autossh session, reload the key back with 'ssh-add -c'. > > > > So, how can i detect if key loaded with -c option or without? > > You can't, and you won't without a protocol extension to ssh-agent. > At the moment the key query message and responses don't have fields > to indicate whether any constraints were set. See PROTOCOL.agent > in the OpenSSH source for details. > > It probably wouldn't be something that one would want to advertise to > an attacker anyway, as stumbing over keys that require confirmation > is the sort of thing that gives them away... > > > My last guess is such: before actually start autossh it's possible to > > set some small script at SSH_ASKPASS, try to use the key, and if that > > script is launched, it means i need to reload the key without '-c'. > > Ugly. > > Worse, it won't work - SSH_ASKPASS needs to be set for ssh-agent, not > ssh-add. So you can't reset it easily like this. > > > PS: BTW there is also no way to get key expiration time (if set > > with 'ssh-add -t'). > > Same problem - expiration times are key constrains like confirm-required. > > -d