From dkg-openssh.com at fifthhorseman.net Fri Aug 1 07:49:53 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 31 Jul 2008 17:49:53 -0400 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <878wx0zkpb.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri\, 20 Jun 2008 02\:25\:52 -0400") References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> Message-ID: <87r699raf2.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080731/3315e753/attachment.bin From dkg-openssh.com at fifthhorseman.net Fri Aug 1 23:44:33 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 Aug 2008 09:44:33 -0400 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> (Alon Bar-Lev's message of "Fri\, 1 Aug 2008 08\:32\:36 +0300") References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> Message-ID: <87hca4c0ji.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080801/52ec55be/attachment-0001.bin From alon.barlev at gmail.com Sat Aug 2 01:16:01 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 1 Aug 2008 18:16:01 +0300 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <87hca4c0ji.fsf@squeak.fifthhorseman.net> References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> Message-ID: <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> On 8/1/08, Daniel Kahn Gillmor wrote: > Well, for PKCS#11, you clearly are *interested* in the X.509 > certificate, right? In that case, it wouldn't make sense to care > about a bare public key (unless you had some external mechanism to > retrieve the relevant certificate), so you're doing the right thing in > that patch. But for regular OpenSSH purposes, where X.509 is *not* > relevant, the bare public key is the thing that matters. No... You you interested in making ssh work... The PKCS#11 spec does not enforce the types of objects stored, so in order to save space many vendors choose not to store the public key object. So the minimal configuration is having private key (from which you can extract public key) as a protected object and X.509 certificate (from which you can extract public key) as public object. I am hoping to push the PKCS#11 implementation forward, and then there is no reason to keep the OpenSC specific one. > Help me understand: for a user whose smartcard: > > * allows storage of two private keys, but > > * is not capable of storing two full X.509 certificates (due to space > constraints), but > > * is capable of storing one X.509 cert and one additional raw public > key (i'm in this situation right now), > > how do you propose for OpenSSH to be able to make use of both keys? Oh... you truly got a problem.... I understand why you discuss this now... I would recommend choosing a different smartcard. Alon. From alon.barlev at gmail.com Fri Aug 1 15:32:36 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 1 Aug 2008 08:32:36 +0300 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <87r699raf2.fsf@squeak.fifthhorseman.net> References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> Message-ID: <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> This is incorrect. The public key object is not always available on smartcards. Basic configuration is having private key + X.509 certificate on card. This is why the PKCS#11 patch [1] also don't assume public key existence. Alon. [1] http://alon.barlev.googlepages.com/openssh-pkcs11 On 8/1/08, Daniel Kahn Gillmor wrote: > > The OpenSC smartcard framework supports access to both raw public > > keys and X.509 certificates on crypto tokens. When OpenSSH is > > compiled --with-opensc, it currently looks for X.509 certificates on > > any smartcard it uses. But OpenSSH itself uses raw public keys (and > > not X.509), so requiring the presence of an X.509 cert on the > > smartcard is unnecessary and potentially problematic. > > Any word on the patch i offered to fix this problem? The original > message can be found here: > > http://marc.info/?l=openssh-unix-dev&m=121394687518903&w=2 > > I've now opened it as a bug in the mindrot bugzilla as well: > > https://bugzilla.mindrot.org/show_bug.cgi?id=1498 > > The patch is a narrow one, and affects only those folks who compile > --with-opensc. Is there anything i can do to encourage adoption of > it? > > Thanks for all the great work. I'm excited about 5.1! > > > --dkg > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From stuge-openssh-unix-dev at cdy.org Sat Aug 2 07:18:11 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 1 Aug 2008 23:18:11 +0200 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> Message-ID: <20080801211811.16871.qmail@cdy.org> On Fri, Aug 01, 2008 at 06:16:01PM +0300, Alon Bar-Lev wrote: > > how do you propose for OpenSSH to be able to make use of both keys? > > Oh... you truly got a problem.... I understand why you discuss this > now... I would recommend choosing a different smartcard. The problem is that this is a reality even for Cryptoflex eGate users. Since it used to be the gold standard OpenSC card I would appreciate a good solution for it. Granted, it has been unavailable for a while, but I expect many to still have them in use. //Peter From dkg-openssh.com at fifthhorseman.net Sat Aug 2 09:04:45 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 Aug 2008 19:04:45 -0400 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> (Alon Bar-Lev's message of "Fri\, 1 Aug 2008 18\:16\:01 +0300") References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> Message-ID: <871w188hgy.fsf@squeak.fifthhorseman.net> On Fri 2008-08-01 11:16:01 -0400, Alon Bar-Lev wrote: > No... You you interested in making ssh work... ?? i'm afraid i don't understand this sentence. > The PKCS#11 spec does not enforce the types of objects stored, so in > order to save space many vendors choose not to store the public key > object. Perhaps i'm confused about the PKCS#11 specification: it is my understanding that an X.509 certificate is actually a superset of the public key object itself [0]. Therefore, if you're storing the X.509 certificate, you're already storing the public key. (and in fact, the public key itself is already stored in the private key object, as well. For RSA, it is usually represented as the first two components of the 5-tuple key). Why would being able to produce the public key consume *more* space -- wouldn't the public key already be present? > So the minimal configuration is having private key (from which you > can extract public key) as a protected object and X.509 certificate > (from which you can extract public key) as public object. I'm afraid i don't see this reasoning either. The minimal configuration for an RSA smartcard, it would seem, is an RSA private key. Since the private key is a superset of the public key, the public key itself would be already present. X.509 certificates are (sort of) nice, but they're just gravy if your goal is just a hardware implementation/offload of RSA. (the same is true of other certificate formats, fwiw, such as those specified by RFC 4880 [1]. I don't want this discussion to turn into a debate on the merits of the X.509 certificate format itself; the point is that *any* certificate is superfluous if you're interested in using a hardware token as a raw RSA engine. Certificates can be stored and distributed in many other ways.) > I am hoping to push the PKCS#11 implementation forward, and then there > is no reason to keep the OpenSC specific one. If your PKCS#11 implementation excludes the ability to use raw RSA keys on hardware tokens, then i certainly hope OpenSSH doesn't remove the OpenSC-specific one. > Oh... you truly got a problem.... I understand why you discuss this > now... I would recommend choosing a different smartcard. I've provided an example of a relatively recent, widely-deployed card (still currently available at retail, fwiw [2]) that behaves reasonably under all circumstances we've discussed (at least with my patch applied). But the card doesn't have enough on-board memory to store the data associated with an extra X.509 certificate. I really don't think that "you need to get new hardware" is an appropriate response. I asked earlier for an example of a card that can store (and emit) X.509 certificates, but is incapable of producing a public key. Could you provide a concrete example? If i can find (or get remote access to) such a card, i'd be happy to adjust my patch to be able to pull From both the X.509 certificates and the raw public keys on the card. Would that seem reasonable to you? Can you identify such a card? Regards, --dkg [0] http://tools.ietf.org/html/rfc5280#section-4.1.2.7 [1] http://tools.ietf.org/html/rfc4880#page-20 [2] http://www.usasmartcard.com/component/page,shop.product_details/flypage,shop.flypage/product_id,19/category_id,22/manufacturer_id,0/option,com_virtuemart/Itemid,26/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080801/25a7c507/attachment.bin From stuge-openssh-unix-dev at cdy.org Sat Aug 2 10:09:07 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 2 Aug 2008 02:09:07 +0200 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <871w188hgy.fsf@squeak.fifthhorseman.net> References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> <871w188hgy.fsf@squeak.fifthhorseman.net> Message-ID: <20080802000907.28724.qmail@cdy.org> On Fri, Aug 01, 2008 at 07:04:45PM -0400, Daniel Kahn Gillmor wrote: > Since the private key is a superset of the public key, the public > key itself would be already present. Of course, but I don't think (m)any card OS will create a virtual file EF for the public key that actually fetches from the private key. That would have to be done in higher level software, but that code is not allowed to read the private key. (For good reason.) //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080802/657f2d75/attachment.bin From dkg-openssh.com at fifthhorseman.net Sat Aug 2 10:39:01 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 01 Aug 2008 20:39:01 -0400 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <20080802000907.28724.qmail@cdy.org> (Peter Stuge's message of "Sat\, 2 Aug 2008 02\:09\:07 +0200") References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> <871w188hgy.fsf@squeak.fifthhorseman.net> <20080802000907.28724.qmail@cdy.org> Message-ID: <87abfw45ei.fsf@squeak.fifthhorseman.net> On Fri 2008-08-01 20:09:07 -0400, Peter Stuge wrote: > On Fri, Aug 01, 2008 at 07:04:45PM -0400, Daniel Kahn Gillmor wrote: > >> Since the private key is a superset of the public key, the public >> key itself would be already present. > > Of course, but I don't think (m)any card OS will create a virtual > file EF for the public key that actually fetches from the private > key. That would have to be done in higher level software, but that > code is not allowed to read the private key. (For good reason.) I understand why the code accessing the card itself shouldn't be allowed to read the private components of the secret key. But surely storing the parameters separately and providing access to the public ones would be reasonable? I'm aware that i don't know much about the on-card formats for these devices, though, so i'm probably wishing for things that seem reasonable from a higher level but might run up against implementation limitations. I appreciate your pointing out some of the more nuanced concerns. At any rate, i think my point still stands for any stored certificates: Is there any reason that the card itself (or the drivers accessing the card) couldn't extract the public key information from a stored certificate? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080801/9ad4f6e1/attachment.bin From stuge-openssh-unix-dev at cdy.org Sat Aug 2 11:04:35 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 2 Aug 2008 03:04:35 +0200 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <87abfw45ei.fsf@squeak.fifthhorseman.net> References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> <871w188hgy.fsf@squeak.fifthhorseman.net> <20080802000907.28724.qmail@cdy.org> <87abfw45ei.fsf@squeak.fifthhorseman.net> Message-ID: <20080802010435.9297.qmail@cdy.org> On Fri, Aug 01, 2008 at 08:39:01PM -0400, Daniel Kahn Gillmor wrote: > I understand why the code accessing the card itself shouldn't be > allowed to read the private components of the secret key. But > surely storing the parameters separately and providing access to > the public ones would be reasonable? It's an idea, but no cards I've seen work like that. > I'm aware that i don't know much about the on-card formats for > these devices, though, so i'm probably wishing for things that seem > reasonable from a higher level but might run up against > implementation limitations. I appreciate your pointing out some of > the more nuanced concerns. Sorry - I thought you were more familiar with on-card storage. ISO 7816-4 card OSes implement a quite simple file system with directories (DF) and files (EF), which can be navigated and accessed depending on the various security features implemented by the card OS. (every card does this differently) > At any rate, i think my point still stands for any stored > certificates: Is there any reason that the card itself (or the > drivers accessing the card) couldn't extract the public key > information from a stored certificate? No reason in theory, but in practice cards can't parse certificates. As for drivers - yes, if the public key components are actually available in the certificate then of course they could be extracted. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080802/e42ee69f/attachment-0001.bin From alon.barlev at gmail.com Sat Aug 2 15:10:02 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 2 Aug 2008 08:10:02 +0300 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <20080802000907.28724.qmail@cdy.org> References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> <871w188hgy.fsf@squeak.fifthhorseman.net> <20080802000907.28724.qmail@cdy.org> Message-ID: <9e0cf0bf0808012210p4e5d096cn67e3fc2ab581077@mail.gmail.com> On 8/2/08, Peter Stuge wrote: > On Fri, Aug 01, 2008 at 07:04:45PM -0400, Daniel Kahn Gillmor wrote: > > Since the private key is a superset of the public key, the public > > key itself would be already present. > > > Of course, but I don't think (m)any card OS will create a virtual > file EF for the public key that actually fetches from the private > key. That would have to be done in higher level software, but that > code is not allowed to read the private key. (For good reason.) For achieving sane user experience there is a need to access a public object holding the public key. This allows to enumerate keys without login each time the smartcard is inserted. Alon. From alon.barlev at gmail.com Sat Aug 2 15:13:54 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 2 Aug 2008 08:13:54 +0300 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <20080801211811.16871.qmail@cdy.org> References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> <20080801211811.16871.qmail@cdy.org> Message-ID: <9e0cf0bf0808012213u4c171d9dwf45eda68b1e65ec3@mail.gmail.com> On 8/2/08, Peter Stuge wrote: > On Fri, Aug 01, 2008 at 06:16:01PM +0300, Alon Bar-Lev wrote: > > > how do you propose for OpenSSH to be able to make use of both keys? > > > > Oh... you truly got a problem.... I understand why you discuss this > > now... I would recommend choosing a different smartcard. > > > The problem is that this is a reality even for Cryptoflex eGate > users. Since it used to be the gold standard OpenSC card I would > appreciate a good solution for it. Granted, it has been unavailable > for a while, but I expect many to still have them in use. Maybe a better solution is to implement on disk storage for public objects which will be available as if they were on token? This will allow the users to use their token with other applications... We discuss here OpenSSH, but please keep in mind that it is only one application with not-so-good smartcard support built-in. Users would like to use Firefox, OpenVPN, PSI and other software. All require a certificate on token. Alon. From yaniv at aknin.name Sat Aug 2 20:34:29 2008 From: yaniv at aknin.name (Yaniv Aknin) Date: Sat, 2 Aug 2008 13:34:29 +0300 Subject: Port forwarding feature suggestion: bind to port 0 Message-ID: Hi, Sometimes it's desirable to bind a port forward to port 0: especially when scripting port forwarding, and more especially so with the '-f -N' options. The version of OpenSSH bundled with OSX (4.7p1) accepts '-L 0:192.168.1.1:22', but only if ran as root (I guess this was more an accident than a feature). I saw that the current version (5.1p1) will decline such an options, saying 'Bad local forwarding specification'. I think that's a shame and would like to suggest a feature that would further ease port forwarding; namely, not only allow port 0 forwarding, but also have ssh automagically get the chosen port number from the kernel with getsockname and print it out. It's debatable whether it's worthwhile to add a new option that will make the printout easily machine parseable (say, '-P', and then the only output would be the string representation of the socket, with no further text). The exact same should be done with remote port forwarding. I guess this would be a trivial change for anyone with any OpenSSH hacking, but if the list would accept this feature and no one would like to jot it while munching morning cereals or something, I'll be happy to code it and submit a diff. - Yaniv A bit off topic, but I have to say this: I'm an avid fan (and a humble recurring donator...) of OpenSSH for years now, I think when combining all the metrices of good software, it's one of the best on the planet. Thank you to all submitters wherever you are. From djm at mindrot.org Sat Aug 2 21:18:26 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 2 Aug 2008 21:18:26 +1000 (EST) Subject: Port forwarding feature suggestion: bind to port 0 In-Reply-To: References: Message-ID: On Sat, 2 Aug 2008, Yaniv Aknin wrote: > Hi, > > Sometimes it's desirable to bind a port forward to port 0: especially > when scripting port forwarding, and more especially so with the '-f > -N' options. > > The version of OpenSSH bundled with OSX (4.7p1) accepts '-L > 0:192.168.1.1:22', but only if ran as root (I guess this was more an > accident than a feature). I saw that the current version (5.1p1) will > decline such an options, saying 'Bad local forwarding specification'. > > I think that's a shame and would like to suggest a feature that > would further ease port forwarding; namely, not only allow port 0 > forwarding, but also have ssh automagically get the chosen port number > from the kernel with getsockname and print it out. If it worked before it was by accident. We do not properly implement port-0 forwarding, as the peer is supposed to send back a message indicating the port that was actually bound (see RFC 4254 section 7.1). https://bugzilla.mindrot.org/show_bug.cgi?id=1003 had a patch to implement it, but it contained some problems the last time I checked it. Since then I have implemented some infrastructure (expected response queues) that will make it much easier to implement. I'm also not sure how the bound port will be reported back to the client. It would be easy to logit(), but that doesn't make it particularly accessible to scripts. If you have any ideas, add yourself to the bug and mention them there. I'll put it on the list for 5.2, but it will more likely to be 5.3 as 5.2 is looking more and more like a bugfix-only release. > A bit off topic, but I have to say this: I'm an avid fan (and a humble > recurring donator...) of OpenSSH for years now, I think when combining > all the metrices of good software, it's one of the best on the planet. > Thank you to all submitters wherever you are. Thanks! -d From dkg-openssh.com at fifthhorseman.net Sun Aug 3 01:39:38 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 02 Aug 2008 11:39:38 -0400 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <9e0cf0bf0808012210p4e5d096cn67e3fc2ab581077@mail.gmail.com> (Alon Bar-Lev's message of "Sat\, 2 Aug 2008 08\:10\:02 +0300") References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> <871w188hgy.fsf@squeak.fifthhorseman.net> <20080802000907.28724.qmail@cdy.org> <9e0cf0bf0808012210p4e5d096cn67e3fc2ab581077@mail.gmail.com> Message-ID: <87vdyjwhmt.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080802/64163ea0/attachment.bin From wieland at purdue.edu Tue Aug 5 04:34:23 2008 From: wieland at purdue.edu (Jeff Wieland) Date: Mon, 04 Aug 2008 14:34:23 -0400 Subject: Hanging ssh sessions with openssh-5.1p1 and Solaris 8 & 10 Message-ID: <48974BAF.1020402@purdue.edu> Since we upgraded OpenSSH from 5.0p1 to 5.1p1 on our Solaris 8 boxes (I know, I know, we should upgrade or retire them...), we've started experiencing problems with slogin'ing into these boxes, running vi, and pasting text into the vi session. As long as we are pasting in less that 1024 characters it's fine. With >= 1024 characters, the session hangs. If you run "/usr/ucb/lptest 72 23 | cat -n" in one window, and then cut paste up to the "V" on line 13, things work as expected. If you include the "W" on the line 13, the vi session will hang with none of characters that are being pasted showing up. We've been building OpenSSH with Sun Studio 11 -- I tried building it with GNU-CC 3.4.4 with the same results. We also link against a locally built zlib, since Solaris 8 doesn't have zlib 1.2.3. And we've used OpenSSL 0.9.8g and 0.9.8h with the same results. We also tried building OpenSSH 5.1p1 on our Solaris 10 boxes using Sun Studio 12, and we also get the hangs there. The client doesn't seem to matter -- we've seen it OpenSSH 5.1p1 from both Solaris and Slackware Linux, and also from SecureCRT. I have not been able to get anything useful from running sshd in debug mode (at least, not that I recognize as useful :-) ). -- Jeff Wieland | Purdue University Network Systems Administrator | ITN&S Data Networks Voice: (765)496-8234 | 501 Harrison Street FAX: (765)494-6620 | West Lafayette, IN 47907-2025 From dbeecher at dmsgs.com Tue Aug 5 05:42:32 2008 From: dbeecher at dmsgs.com (David Beecher) Date: Mon, 04 Aug 2008 15:42:32 -0400 Subject: remove In-Reply-To: <20080722022113.D3ECA69CE7@natsu.mindrot.org> References: <20080722022113.D3ECA69CE7@natsu.mindrot.org> Message-ID: <48975BA8.1020401@dmsgs.com> remove unsubscribe -- bugzilla-daemon at bugzilla.mindrot.org wrote: > https://bugzilla.mindrot.org/show_bug.cgi?id=1439 > > > Damien Miller changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |CLOSED > > > > > --- Comment #3 from Damien Miller 2008-07-22 12:21:06 --- > Mass update RESOLVED->CLOSED after release of openssh-5.1 > > -- David Beecher, Executive Vice President and Chief Technical Officer Digital Messaging Solutions, Inc. 678.446.3050 voice 866.881.7081 fax http://www.dmsgs.com We appreciate your business! This e-mail may contain data that is confidential, proprietary or "non-public personal information," as that term is defined in the Gramm-Leach-Bliley Act (collectively, "Confidential Information"). The Confidential Information is disclosed conditioned upon your agreement that you will treat it confidentially and in accordance with applicable law, ensure that such data isn't used or disclosed except for the limited purpose for which it's being provided and will notify and cooperate with us regarding any requested or unauthorized disclosure or use of any Confidential Information. By accepting and reviewing the Confidential Information you agree to indemnify us against any losses or expenses, including attorney's fees that we may incur as a result of any unauthorized use or disclosure of this data due to your acts or omissions. If a party other than the intended recipient receives this e-mail, you are requested to instantly notify us of the erroneous delivery and return to us all data so delivered. From dtucker at zip.com.au Tue Aug 5 11:19:02 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 5 Aug 2008 11:19:02 +1000 Subject: Hanging ssh sessions with openssh-5.1p1 and Solaris 8 & 10 In-Reply-To: <48974BAF.1020402@purdue.edu> References: <48974BAF.1020402@purdue.edu> Message-ID: <20080805011902.GA19142@gate.dtucker.net> On Mon, Aug 04, 2008 at 02:34:23PM -0400, Jeff Wieland wrote: > Since we upgraded OpenSSH from 5.0p1 to 5.1p1 on our Solaris 8 boxes > (I know, I know, we should upgrade or retire them...), we've started > experiencing problems with slogin'ing into these boxes, running vi, > and pasting text into the vi session. > > As long as we are pasting in less that 1024 characters it's fine. > With >= 1024 characters, the session hangs. Do you know if the problem occurs on the client or server side? ie if you use an older client with a newer server (and vice versa) does the problem occur? > If you run "/usr/ucb/lptest 72 23 | cat -n" in one window, and > then cut paste up to the "V" on line 13, things work as expected. > If you include the "W" on the line 13, the vi session will hang > with none of characters that are being pasted showing up. > > We've been building OpenSSH with Sun Studio 11 -- I tried building > it with GNU-CC 3.4.4 with the same results. We also link against > a locally built zlib, since Solaris 8 doesn't have zlib 1.2.3. > And we've used OpenSSL 0.9.8g and 0.9.8h with the same results. > > We also tried building OpenSSH 5.1p1 on our Solaris 10 boxes using > Sun Studio 12, and we also get the hangs there. The client doesn't > seem to matter -- we've seen it OpenSSH 5.1p1 from both Solaris > and Slackware Linux, and also from SecureCRT. > > I have not been able to get anything useful from running sshd in > debug mode (at least, not that I recognize as useful :-) ). Well you could post it, someone else might recognise someting :-) Some versions of AIX have bugs in the tty drivers that prevent largish writes from working correctly. Pehaps Solaris has something similar (although I can't imagine why it's only started recently). You could try the patch below to test this theory. Index: channels.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/channels.c,v retrieving revision 1.273 diff -u -p -r1.273 channels.c --- channels.c 16 Jul 2008 12:42:06 -0000 1.273 +++ channels.c 5 Aug 2008 01:08:22 -0000 @@ -1578,11 +1578,10 @@ channel_handle_wfd(Channel *c, fd_set *r } return 1; } -#ifdef _AIX + /* XXX: Later AIX versions can't push as much data to tty */ if (compat20 && c->wfd_isatty) - dlen = MIN(dlen, 8*1024); -#endif + dlen = MIN(dlen, 1024); len = write(c->wfd, buf, dlen); if (len < 0 && -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From wieland at purdue.edu Tue Aug 5 13:17:47 2008 From: wieland at purdue.edu (Jeff Wieland) Date: Mon, 04 Aug 2008 23:17:47 -0400 Subject: Hanging ssh sessions with openssh-5.1p1 and Solaris 8 & 10 In-Reply-To: <20080805011902.GA19142@gate.dtucker.net> References: <48974BAF.1020402@purdue.edu> <20080805011902.GA19142@gate.dtucker.net> Message-ID: <4897C65B.9030605@purdue.edu> Darren Tucker wrote: > On Mon, Aug 04, 2008 at 02:34:23PM -0400, Jeff Wieland wrote: >> Since we upgraded OpenSSH from 5.0p1 to 5.1p1 on our Solaris 8 boxes >> (I know, I know, we should upgrade or retire them...), we've started >> experiencing problems with slogin'ing into these boxes, running vi, >> and pasting text into the vi session. >> >> As long as we are pasting in less that 1024 characters it's fine. >> With >= 1024 characters, the session hangs. > > Do you know if the problem occurs on the client or server side? ie if > you use an older client with a newer server (and vice versa) does the > problem occur? It's the server side. It still happens if you use the 5.0p1 client, and it also happens with the SecureCRT client. >> If you run "/usr/ucb/lptest 72 23 | cat -n" in one window, and >> then cut paste up to the "V" on line 13, things work as expected. >> If you include the "W" on the line 13, the vi session will hang >> with none of characters that are being pasted showing up. >> >> We've been building OpenSSH with Sun Studio 11 -- I tried building >> it with GNU-CC 3.4.4 with the same results. We also link against >> a locally built zlib, since Solaris 8 doesn't have zlib 1.2.3. >> And we've used OpenSSL 0.9.8g and 0.9.8h with the same results. >> >> We also tried building OpenSSH 5.1p1 on our Solaris 10 boxes using >> Sun Studio 12, and we also get the hangs there. The client doesn't >> seem to matter -- we've seen it OpenSSH 5.1p1 from both Solaris >> and Slackware Linux, and also from SecureCRT. >> >> I have not been able to get anything useful from running sshd in >> debug mode (at least, not that I recognize as useful :-) ). > > Well you could post it, someone else might recognise someting :-) I'll see if I can get this done tomorrow. It's a crazy couple of weeks right now... > Some versions of AIX have bugs in the tty drivers that prevent largish > writes from working correctly. Pehaps Solaris has something similar > (although I can't imagine why it's only started recently). > > You could try the patch below to test this theory. > > Index: channels.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/channels.c,v > retrieving revision 1.273 > diff -u -p -r1.273 channels.c > --- channels.c 16 Jul 2008 12:42:06 -0000 1.273 > +++ channels.c 5 Aug 2008 01:08:22 -0000 > @@ -1578,11 +1578,10 @@ channel_handle_wfd(Channel *c, fd_set *r > } > return 1; > } > -#ifdef _AIX > + > /* XXX: Later AIX versions can't push as much data to tty */ > if (compat20 && c->wfd_isatty) > - dlen = MIN(dlen, 8*1024); > -#endif > + dlen = MIN(dlen, 1024); > > len = write(c->wfd, buf, dlen); > if (len < 0 && > OK -- I can try this too. But it isn't necessary with the 5.0p1 sshd, so I'm thinking that something changed w.r.t. OpenSSH. -- Jeff Wieland | Purdue University Network Systems Administrator | ITN&S Data Networks Voice: (765)496-8234 | 501 Harrison Street FAX: (765)494-6620 | West Lafayette, IN 47907-2025 From aledin at evpatoria.com.ua Tue Aug 5 18:18:59 2008 From: aledin at evpatoria.com.ua (Alexander) Date: Tue, 5 Aug 2008 11:18:59 +0300 (EEST) Subject: rsync problem after ssh upgrade Message-ID: Hello. In my setup I collected logs from many hosts using ssh + rsync. It worked fine untill I upgraded OpenSSH from version 5.0p1 to 5.1p1 on those hosts running Slackware Linux. After upgrade nothing works as before. When I try to get logs connection breaks with the following message in syslog on the server side: Aug 4 15:34:44 srvhost sshd[8130]: Accepted publickey for user from 192.168.1.30 port 48421 ssh2 Aug 4 15:34:44 srvhost rsyncd[8136]: rsyncd version 2.6.9 starting, listening on port 873 Aug 4 15:34:44 srvhost rsyncd[8136]: bind() failed: Permission denied (address-family 2) Aug 4 15:34:44 srvhost rsyncd[8136]: socket(10,1,6) failed: Address family not supported by protocol Aug 4 15:34:44 srvhost rsyncd[8136]: unable to bind any inbound sockets on port 873 Aug 4 15:34:44 srvhost rsyncd[8136]: rsync error: error in socket IO (code 10) at socket.c(477) [receiver=2.6.9] I see that port 873 is privileged and rsyncd can't bind to it. But it could before upgrade! I tried to bind rsyncd to unprivileged port. It works but not as expected. rsyncd starts in background, connection to it through ssh doesn't occur and it continues to run in the background even when I close ssh connection. What the reason of such changed behaviour? How can I restore to what I have before? authorized_keys on server: command="rsync --daemon --config=/home/user/.ssh/rsyncd.conf",no-pty ssh-rsa AAAAB3Nz....... rsyncd.conf on server: [logs] path = /home/user/log use chroot = false read only = true Server sshd_config: Port 12345 AddressFamily inet Protocol 2 DenyUsers baduser UseDNS no Subsystem sftp /usr/libexec/sftp-server On client side a script uses this line to get logs: rsync -v -e "ssh -q -T -p 12345 -l user -i ./key_logs_collector -o 'BatchMode yes' -o 'ConnectTimeout 30' -o 'StrictHostKeyChecking no' -o 'CheckHostIP no'" -zqt --max-size=100M srvhost::logs/* logs/ --- Alexander Pravdin aledin at evpatoria.com.ua From apb at cequrux.com Tue Aug 5 20:35:03 2008 From: apb at cequrux.com (Alan Barrett) Date: Tue, 5 Aug 2008 12:35:03 +0200 Subject: rsync problem after ssh upgrade In-Reply-To: References: Message-ID: <20080805103503.GJ7842@apb-laptoy.apb.alt.za> On Tue, 05 Aug 2008, Alexander wrote: > Aug 4 15:34:44 srvhost sshd[8130]: Accepted publickey for user from 192.168.1.30 port 48421 ssh2 > Aug 4 15:34:44 srvhost rsyncd[8136]: rsyncd version 2.6.9 starting, listening on port 873 > Aug 4 15:34:44 srvhost rsyncd[8136]: bind() failed: Permission denied (address-family 2) [...] > authorized_keys on server: > > command="rsync --daemon --config=/home/user/.ssh/rsyncd.conf",no-pty ssh-rsa AAAAB3Nz....... "rsync --daemon" is documented as having a different behaviour depending on whether or not stdin is a socket. I guess that, with the old sshd, rsync received a socket as stdin, but with the new sshd it receives somethign else (perhaps a pipe or a tty). I suggest that you read the part of the rsync man page under "USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION", and then change the way you attempt to invoke rsync, so that you do not rely on something so fragile as whether or not sshd used a socket for rsync's stdin. Alternatively, you could patch rsync to have a new command line option that makes it behave the way you want regardless of whether or not its input is a socket. --apb (Alan Barrett) From markus.r.friedl at arcor.de Tue Aug 5 20:54:36 2008 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Tue, 5 Aug 2008 12:54:36 +0200 Subject: rsync problem after ssh upgrade In-Reply-To: <20080805103503.GJ7842@apb-laptoy.apb.alt.za> References: <20080805103503.GJ7842@apb-laptoy.apb.alt.za> Message-ID: <20080805105436.GA28310@folly> On Tue, Aug 05, 2008 at 12:35:03PM +0200, Alan Barrett wrote: > > command="rsync --daemon --config=/home/user/.ssh/rsyncd.conf",no-pty ssh-rsa AAAAB3Nz....... > > "rsync --daemon" is documented as having a different behaviour depending > on whether or not stdin is a socket. I guess that, with the old sshd, > rsync received a socket as stdin, but with the new sshd it receives > somethign else (perhaps a pipe or a tty). yes, used to be a socketpair, not it's a pipe (like in the early days). From the_deuce at yahoo.com Tue Aug 5 23:59:03 2008 From: the_deuce at yahoo.com (Deuce) Date: Tue, 5 Aug 2008 06:59:03 -0700 (PDT) Subject: [Patch] contrib/redhat/openssh.spec update Message-ID: <596336.55721.qm@web57611.mail.re1.yahoo.com> The attached patch fixes an RPM build failure on redhat. RFC.nroff was removed, so rpmbuild fails when the file is not found. A similar change was made to the suse .spec file. contrib/cygwin/Makefile may need a similar change. Thanks, Jason Andryuk --- contrib/redhat/openssh.spec.orig 2008-08-05 09:44:46.746915226 -0400 +++ contrib/redhat/openssh.spec 2008-08-05 09:27:59.590525991 -0400 @@ -333,7 +333,7 @@ %files %defattr(-,root,root) -%doc CREDITS ChangeLog INSTALL LICENCE OVERVIEW README* RFC* TODO WARNING* +%doc CREDITS ChangeLog INSTALL LICENCE OVERVIEW README* TODO WARNING* %attr(0755,root,root) %{_bindir}/scp %attr(0644,root,root) %{_mandir}/man1/scp.1* %attr(0755,root,root) %dir %{_sysconfdir}/ssh -------------- next part -------------- A non-text attachment was scrubbed... Name: redhat-openssh.spec.patch Type: text/x-patch Size: 472 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080805/d564006b/attachment.bin From djm at mindrot.org Wed Aug 6 10:33:09 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 6 Aug 2008 10:33:09 +1000 (EST) Subject: Portable OpenSSH needs a new server Message-ID: Hi, The server that hosts Portable OpenSSH's bugzilla, anoncvs and mailing lists is reaching the end of its life and is in need of replacement. Anyone who uses our bugzilla frequently can attest to how annoyingly slow it is. So I am soliciting donations towards a replacement server with a target of AUD$3750. If there are any leftover funds they will be used to defray colo costs that I normally pay myself. The easiest way to donate is via Paypal to my email address (djm at mindrot.org), but if this is inconvenient then please contact me directly. Any support that you can offer will be greatly appreciated. Thanks, Damien Miller From dkg-openssh.com at fifthhorseman.net Thu Aug 7 04:32:35 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 Aug 2008 14:32:35 -0400 Subject: extended test mode for ssh client (by analogy with sshd -T)? Message-ID: <87y73aata4.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080806/18dd4095/attachment.bin From lukasz.stelmach at telmark.waw.pl Thu Aug 7 19:19:47 2008 From: lukasz.stelmach at telmark.waw.pl (Lukasz Stelmach) Date: Thu, 7 Aug 2008 11:19:47 +0200 Subject: choose the right sshfp Message-ID: <20080807091947.GF13736@vlana.p.telmark.waw.pl> Greetings. I've set up several sshfp records some time ago. Everything works great except the way openssh chooses the sshfp record. Now it looks liek the client asks for the name supplied on the command line. It might be a bit trouble some since there are at least three ways to set up some aliases and at leas one of them is secure. I propose an alternative way which even seems more robust as far as multihoming is concerned. 1. Get the name from the command line. 2. Connect the host. 3. Ask the socket for the address of the remote host (important for multihoming) 4. Make revDNS query to get the "real name". 5. Look for an SSHFP for the "real name". Of course this procedure might (I have not analysed it carefully) pose some security risks so it should be optional. Or even more, it should be allowed only for some hosts based on both IP and name (eg. *.example.com and 192.0.2.128/26). PS. Please CC the answers, I haven't subscribed the list. -- Best regards, >?ukasz< From deengert at anl.gov Sat Aug 9 02:33:55 2008 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 08 Aug 2008 11:33:55 -0500 Subject: OpenSC smartcard access should use raw public keys, not X.509 certificates In-Reply-To: <871w188hgy.fsf@squeak.fifthhorseman.net> References: <878wx0zkpb.fsf@squeak.fifthhorseman.net> <87r699raf2.fsf@squeak.fifthhorseman.net> <9e0cf0bf0807312232m3215dd17ne918d852534e32dd@mail.gmail.com> <87hca4c0ji.fsf@squeak.fifthhorseman.net> <9e0cf0bf0808010816m12dc4f7agf2b426ecf8ab0c8f@mail.gmail.com> <871w188hgy.fsf@squeak.fifthhorseman.net> Message-ID: <489C7573.1040409@anl.gov> [Sorry for jumping in late on this.] Daniel Kahn Gillmor wrote: > On Fri 2008-08-01 11:16:01 -0400, Alon Bar-Lev wrote: > >> No... You you interested in making ssh work... > > ?? i'm afraid i don't understand this sentence. > >> The PKCS#11 spec does not enforce the types of objects stored, so in >> order to save space many vendors choose not to store the public key >> object. > > Perhaps i'm confused about the PKCS#11 specification: it is my > understanding that an X.509 certificate is actually a superset of the > public key object itself [0]. Therefore, if you're storing the X.509 > certificate, you're already storing the public key. (and in fact, the > public key itself is already stored in the private key object, as > well. For RSA, it is usually represented as the first two components > of the 5-tuple key). Why would being able to produce the public key > consume *more* space -- wouldn't the public key already be present? > Yes, but on the card there may be a pubkey object as well as a cert object, (which should match), but stored separately thus taking up more space. >> So the minimal configuration is having private key (from which you >> can extract public key) as a protected object and X.509 certificate >> (from which you can extract public key) as public object. > > I'm afraid i don't see this reasoning either. The minimal > configuration for an RSA smartcard, it would seem, is an RSA private > key. Yes. But there needs to be some way to associate the private key with the the pubkey. The minimal would be the user has to entry in some assoication manually. In practice, a certificate is usually stored on a card. > Since the private key is a superset of the public key, the > public key itself would be already present. Yes, but the card may not allow you to read modulus and exponent. > X.509 certificates are > (sort of) nice, but they're just gravy if your goal is just a hardware > implementation/offload of RSA. > > (the same is true of other certificate formats, fwiw, such as those > specified by RFC 4880 [1]. I don't want this discussion to turn into > a debate on the merits of the X.509 certificate format itself; the > point is that *any* certificate is superfluous if you're interested in > using a hardware token as a raw RSA engine. Certificates can be > stored and distributed in many other ways.) > >> I am hoping to push the PKCS#11 implementation forward, and then there >> is no reason to keep the OpenSC specific one. > > If your PKCS#11 implementation excludes the ability to use raw RSA > keys on hardware tokens, then i certainly hope OpenSSH doesn't remove > the OpenSC-specific one. > >> Oh... you truly got a problem.... I understand why you discuss this >> now... I would recommend choosing a different smartcard. > > I've provided an example of a relatively recent, widely-deployed card > (still currently available at retail, fwiw [2]) that behaves > reasonably under all circumstances we've discussed (at least with my > patch applied). But the card doesn't have enough on-board memory to > store the data associated with an extra X.509 certificate. I really > don't think that "you need to get new hardware" is an appropriate > response. > > I asked earlier for an example of a card that can store (and emit) > X.509 certificates, but is incapable of producing a public key. Could > you provide a concrete example? If i can find (or get remote access > to) such a card, i'd be happy to adjust my patch to be able to pull > From both the X.509 certificates and the raw public keys on the card. > Would that seem reasonable to you? Can you identify such a card? But you are mixing up what is on the card and what OpenSC (or some other middleware) can do for you. An example of a card which does not store the pubkey seperatly on the card is the PIV card. It stores objects, including cert objects and private keys. But pkcs15-piv.c uses the OpenSC pkcs15 emulation code sc_pkcs15emu_* to simulate a a pubkey object. It does this be reading the cert, and extracting the pubkey. So from PKCS#11 or PKCS#15 it appears the card does have a pubkey object. With other cards, it is up to the author of the libopensc/card-.C and pkcs15-.c modules to implement this if needed for their card. Your patch would be better if it tried for a cert, and if not available, then try for a pubkey. > > Regards, > > --dkg > > [0] http://tools.ietf.org/html/rfc5280#section-4.1.2.7 > [1] http://tools.ietf.org/html/rfc4880#page-20 > [2] http://www.usasmartcard.com/component/page,shop.product_details/flypage,shop.flypage/product_id,19/category_id,22/manufacturer_id,0/option,com_virtuemart/Itemid,26/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From djm at mindrot.org Sat Aug 9 12:14:52 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 9 Aug 2008 12:14:52 +1000 (EST) Subject: Portable OpenSSH needs a new server In-Reply-To: References: Message-ID: On Wed, 6 Aug 2008, Damien Miller wrote: > Hi, > > The server that hosts Portable OpenSSH's bugzilla, anoncvs and mailing > lists is reaching the end of its life and is in need of replacement. > Anyone who uses our bugzilla frequently can attest to how annoyingly > slow it is. > > So I am soliciting donations towards a replacement server with a target > of AUD$3750. If there are any leftover funds they will be used to defray > colo costs that I normally pay myself. Thanks almost entirely to individual donations, some of which were particularly generous, we are now 1/2 way to reaching this target. This would be a great opportunity for companies who incorporate OpenSSH into their (operating systems, management hardware, network appliances) to contribute something back. Thanks to everyone who has contributed so far! Thanks, Damien Miller From scott_n at xypro.com Tue Aug 12 07:29:16 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 11 Aug 2008 14:29:16 -0700 Subject: dynamic allocation in bsd-poll.c? Message-ID: <78DD71C304F38B41885A242996B96F73019512FD@xyservd.XYPRO-23.LOCAL> I'm wondering about the rationale behind the allocation of the fd_set for the select() call in bsd-poll.c. Is there a reason we're dynamically allocating the fd_sets using nmemb, rather than simply putting three fd_set variables on the stack, followed by FD_ZERO calls? This seems to make life more difficult, as evidenced by the "goto out" statement, needed to free the memory. ---- Scott Neugroschl XYPRO Technologies scott_n at xypro.com 805-583-2874 x121 From djm at mindrot.org Tue Aug 12 09:40:45 2008 From: djm at mindrot.org (Damien Miller) Date: Tue, 12 Aug 2008 09:40:45 +1000 (EST) Subject: dynamic allocation in bsd-poll.c? In-Reply-To: <78DD71C304F38B41885A242996B96F73019512FD@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F73019512FD@xyservd.XYPRO-23.LOCAL> Message-ID: On Mon, 11 Aug 2008, Scott Neugroschl wrote: > I'm wondering about the rationale behind the allocation of the fd_set > for the select() call in bsd-poll.c. Coping with num_fds > FD_SETSIZE. -d From djm at mindrot.org Tue Aug 12 15:57:16 2008 From: djm at mindrot.org (Damien Miller) Date: Tue, 12 Aug 2008 15:57:16 +1000 (EST) Subject: Portable OpenSSH needs a new server In-Reply-To: References: Message-ID: On Sat, 9 Aug 2008, Damien Miller wrote: > On Wed, 6 Aug 2008, Damien Miller wrote: > > > Hi, > > > > The server that hosts Portable OpenSSH's bugzilla, anoncvs and mailing > > lists is reaching the end of its life and is in need of replacement. > > Anyone who uses our bugzilla frequently can attest to how annoyingly > > slow it is. > > > > So I am soliciting donations towards a replacement server with a target > > of AUD$3750. If there are any leftover funds they will be used to defray > > colo costs that I normally pay myself. Hi, Enough money has been donated to buy the server and I will place the order later this week. Thanks very much to everyone who contributed! Damien From des at des.no Wed Aug 13 05:40:53 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 12 Aug 2008 21:40:53 +0200 Subject: IPPORT_RESERVED Message-ID: <86od3y58e2.fsf@ds4.des.no> FreeBSD doesn't have a fixed range of reserved ports, although it still has IPPORT_RESERVED for compatibility; instead, the last reserved port number is indicated by the net.inet.ip.portrange.reservedhigh sysctl, which defaults to IPPORT_RESERVED - 1. The attached patch modifies add_local_forward() to use this sysctl instead of IPPORT_RESERVED on FreeBSD. DES -- Dag-Erling Sm?rgrav - des at des.no -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-ipport-reserved.diff Type: text/x-patch Size: 1090 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080812/c6c905ed/attachment.bin From robert.sicoie at gmail.com Thu Aug 14 00:54:02 2008 From: robert.sicoie at gmail.com (robert) Date: Wed, 13 Aug 2008 17:54:02 +0300 Subject: Encoding SSH RSA public key Message-ID: <1218639242.10624.29.camel@robert> Hello, I'm trying to build a valid public ssh v2 RSA key from a java application but I have some problems understanding how the two numbers (e and n) are base64 encoded into ~/.ssh/id_rsa.pub or ~/.ssh/authorized_keys2 file. My question is what exactly is encoded into the base64 string? For example for this public key: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6p76zG+8aOkFZT1y4O+Y7n +n0jWo6eW3DDPWVMddrR6z37uUsCZXPm1a6Inogp4NOt6UNaa1IrEtRkCWKF/kWoAzpVeJsJCXNc7EGzSBG9Q0JZ43F07X9mQHneUi+SKwDl/dp5O2Mnyi/az2OatyW1XNnpf94yJC1dhPnJSgXNAmp2R5Bq5qktzo0GMUfw11rdZzVNBMwgxZVp6mvuvgQFQ3xJVRIGE54IpW6iTXLOgxCSwL8Xj37fI22wOg7mYlNMIzyy3vUqyx73e00VnxxVp0DcaM347bFvyrRSm3hnBVDmdbTjP/ryHobNpSbPrP6vzNVww5Y61OFyTa60OPjQ== robert at robert There must be options (optional), bits, e, n and comments (optional), but how are these represented before encoding? Are each of these data encoded to base64 separately and then concatenated? What exactly is encoded? Could anyone describe me the algorithm for obtaining the base64 string? I couldn't find it anywhere. Thanks, -- Robert From dkg-openssh.com at fifthhorseman.net Thu Aug 14 07:28:32 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 Aug 2008 17:28:32 -0400 Subject: Encoding SSH RSA public key In-Reply-To: <1218639242.10624.29.camel@robert> (robert's message of "Wed\, 13 Aug 2008 17\:54\:02 +0300") References: <1218639242.10624.29.camel@robert> Message-ID: <87vdy4a9kv.fsf@squeak.fifthhorseman.net> On Wed 2008-08-13 10:54:02 -0400, robert wrote: > There must be options (optional), bits, e, n and comments (optional), > but how are these represented before encoding? Are each of these data > encoded to base64 separately and then concatenated? What exactly is > encoded? > > Could anyone describe me the algorithm for obtaining the base64 string? > I couldn't find it anywhere. The format for the base64-encded data (the unreadable stuff in the middle of the line) appears to be: A series of length-prefixed bitstrings, where the length for each bitstring is encoded as a network-order, 32-bit unsigned integer representing the number of bytes in the following bitstring. The first bitstring indicates the type of the key. This can be used to determine the nature of the bitstrings which follow. The type is represented by a 7-byte string ("ssh-rsa" or "ssh-dss"), so the first 4 bytes are 0x00,0x00,0x00,0x07 (this indicates the length of the type string). For RSA keys, the exponent follows next as a multi-precision integer (MPI), and then the modulus (also an MPI). So for example, for a 2048-bit key, you can unpack it this way: [0 dkg at squeak ~]$ < ./.example/id_rsa.pub cut -f2 -d\ | base64 -d | hd | head -n2 00000000 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 03 01 |....ssh-rsa.....| 00000010 00 01 00 00 01 01 00 c4 68 99 07 36 4f d4 7a 35 |........h..6O.z5| [0 dkg at squeak ~]$ the example above uses a 3-byte exponent of 0x10001 (65537), followed by a 257(==0x101)-byte modulus, which is the rest of the key. Be careful that your MPIs all have the first bit set to 0, though! OpenSSH appears to treat the MPIs as a two's-complement signed representation, so if your first bit is a 1, ssh will think you're trying to provide a negative value. If your calculations produce a number with the high bit set to 1, just increase the length by another byte and pad the beginning with 0x00 to keep it positive. (this is why the modulus above is 257 bytes starting with 0x00,0xc4 instead of 256 starting with 0xc4,0x68). Hope this is helpful, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080813/a28882bf/attachment-0001.bin From larsand at gmail.com Wed Aug 13 23:09:05 2008 From: larsand at gmail.com (Lars Andersson) Date: Wed, 13 Aug 2008 23:09:05 +1000 Subject: ProxyCommand and ExitOnForwardFailure = leftover process Message-ID: <8acca4520808130609q28671e13s7f3d43ba38943945@mail.gmail.com> Hi, I'm having a small problem when using ProxyCommand and ExitOnForwardFailure in combination with OpenSSH 5.1 under Ubuntu 8.04. In order to enable multihop scp and port forwarding, I have enabled automatic public key authenticated tunneling from hostA to hostC via hostB using ProxyCommand in my private .ssh/config file on hostA. : host hostB user X hostC ProxyCommand ssh hostB nc hostC 22 Now, on hostA, I want to forward local port 3333 to port 5433 on hostC from a script using: ssh -x -N -L 3333:hostC:5433 -o BatchMode=yes -o ExitOnForwardFailure=yes X at hostC That works fine, and I now have two processes: 31292 ssh -x -N -L 3333:hostC:5433 -o BatchMode=yes -o ExitOnForwardFailure=yes X at hostC 31293 ssh hostB nc hostC 22 I assume the second is started by the first to forward the tunnel via hostB. I can use the local port 3333 to connect to the server running on port 5433 on hostC. So far so good. If I kill process 31292 it will also terminate 31293 and the TCP connections will eventually shut down fine. if I instead leave the first ssh tunnel running and issue the tunnel command, ssh -x -N -L 3333:hostC:5433 -o BatchMode=yes -o ExitOnForwardFailure=yes X at hostC a second time, I get the following messages (ssh pid=31923): bind: Address already in use channel_setup_fwd_listener: cannot listen to port: 3333 Could not request local forwarding. ssh (pid 31923) exits as can be expected since I specified the ExitOnForwardFailure=yes option. However, this time, ssh doesn't kill the ssh sub process doing the forwarding via hostB, and I'm left with a leftover ssh process: 31924 ssh hostB nc hostC 22 I guess this is not a huge issue, and I'm sure I can come up with some workaround, but it currently creates a few problems in my scripts. Is this a bug, or is this behavior normal? Thanks, Lars From gusgl2001 at yahoo.com Sat Aug 16 08:02:58 2008 From: gusgl2001 at yahoo.com (GB) Date: Fri, 15 Aug 2008 15:02:58 -0700 (PDT) Subject: SSH Command Line Password Support Message-ID: <781297.30010.qm@web30704.mail.mud.yahoo.com> Hello, I am interested in an ssh that is not interactive in requesting the password, i.e, whereas I can specify the password in the command line when calling SSH. I have wondered how such a feature has not been included in such a good client, as it seems there are many (and I have searched for this) people require this capability for their scripts/automation. I understand the possibility of avoiding passwords altogether by generating keys, but such an implementation of password on the command line should not be too difficult. sshconnect2.c, for example, prompts for this on line 273. sshconnect1.c also does something similar in the function try_password_authentication(char *prompt) Would it be possible for you to include this? I would do it myself, however I've had problems compiling openssh. If you are willing to help me compile open ssh, I am willing to work on this issue, which I see required for many people. Thank you for all your work. From des at des.no Sun Aug 17 00:04:35 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat, 16 Aug 2008 16:04:35 +0200 Subject: SSH Command Line Password Support In-Reply-To: <781297.30010.qm@web30704.mail.mud.yahoo.com> (GB's message of "Fri, 15 Aug 2008 15:02:58 -0700 (PDT)") References: <781297.30010.qm@web30704.mail.mud.yahoo.com> Message-ID: <86y72x6op8.fsf@ds4.des.no> GB writes: > I am interested in an ssh that is not interactive in requesting the > password, i.e, whereas I can specify the password in the command line > when calling SSH. ps -fe Just use a passphrase-less keypair. DES -- Dag-Erling Sm?rgrav - des at des.no From gusgl2001 at yahoo.com Sun Aug 17 14:50:48 2008 From: gusgl2001 at yahoo.com (GB) Date: Sat, 16 Aug 2008 21:50:48 -0700 (PDT) Subject: SSH Command Line Password Support In-Reply-To: <86y72x6op8.fsf@ds4.des.no> Message-ID: <294724.1432.qm@web30706.mail.mud.yahoo.com> While trying to compile openssh (I succeeded in compiling openssl) I get the following after using make: gcc -g -O2 -Wall -I/opt/openssl-0.9.8h//include -DETCDIR=\"/etc/ssh\" -DSSH_PROGRAM=\"/usr/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/usr/libexec/ssh/ssh-askpass\" -DHAVE_CONFIG_H?? -c -o sshconnect1.o sshconnect1.c In file included from sshconnect1.c:21: ssh.h:464: warning: conflicting types for built-in function ?log? sshconnect1.c: In function ?respond_to_rsa_challenge?: sshconnect1.c:149: error: ?MD5_CTX? undeclared (first use in this function) sshconnect1.c:149: error: (Each undeclared identifier is reported only once sshconnect1.c:149: error: for each function it appears in.) sshconnect1.c:149: error: expected ?;? before ?md? sshconnect1.c:164: warning: implicit declaration of function ?MD5_Init? sshconnect1.c:164: error: ?md? undeclared (first use in this function) sshconnect1.c:165: warning: implicit declaration of function ?MD5_Update? sshconnect1.c:167: warning: implicit declaration of function ?MD5_Final? make: *** [sshconnect1.o] Error 1 Can anyone help me resolve this issue? Thank you --- On Sat, 8/16/08, Dag-Erling Sm?rgrav wrote: From: Dag-Erling Sm?rgrav Subject: Re: SSH Command Line Password Support To: gusgl2001 at yahoo.com Cc: openssh-unix-dev at mindrot.org Date: Saturday, August 16, 2008, 10:04 AM GB writes: > I am interested in an ssh that is not interactive in requesting the > password, i.e, whereas I can specify the password in the command line > when calling SSH. ps -fe Just use a passphrase-less keypair. DES -- Dag-Erling Sm?rgrav - des at des.no From djm at mindrot.org Sun Aug 17 19:18:44 2008 From: djm at mindrot.org (Damien Miller) Date: Sun, 17 Aug 2008 19:18:44 +1000 (EST) Subject: SSH Command Line Password Support In-Reply-To: <294724.1432.qm@web30706.mail.mud.yahoo.com> References: <294724.1432.qm@web30706.mail.mud.yahoo.com> Message-ID: On Sat, 16 Aug 2008, GB wrote: > While trying to compile openssh (I succeeded in compiling openssl) I > get the following after using make: You aren't making it easy to help. What version of OpenSSH is this? It doesn't appear to be 5.1. What operating system? Does your platform lack OpenSSL? What configure options did you use? -d From michael.barabanov at gmail.com Tue Aug 19 14:40:21 2008 From: michael.barabanov at gmail.com (Michael Barabanov) Date: Mon, 18 Aug 2008 21:40:21 -0700 Subject: [patch] fix to ForceCommand to support additional arguments to internal-sftp Message-ID: <8a8781f20808182140i79d242bpd4a3d7a20c18069a@mail.gmail.com> Hi, This patch makes things like ForceCommand internal-sftp -l INFO work (current code in 5.1 would just end the session). Please consider for inclusion into mainline. Michael. --- /var/tmp/session.c 2008-08-18 21:07:10.000000000 -0700 +++ session.c 2008-08-18 21:12:51.000000000 -0700 @@ -781,7 +781,7 @@ if (options.adm_forced_command) { original_command = command; command = options.adm_forced_command; - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) + if (strncmp(INTERNAL_SFTP_NAME, command, strlen(INTERNAL_SFTP_NAME)) == 0 && isspace(command[strlen( INTERNAL_SFTP_NAME)])) s->is_subsystem = SUBSYSTEM_INT_SFTP; else if (s->is_subsystem) s->is_subsystem = SUBSYSTEM_EXT; @@ -789,7 +789,7 @@ } else if (forced_command) { original_command = command; command = forced_command; - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) + if (strncmp(INTERNAL_SFTP_NAME, command, strlen(INTERNAL_SFTP_NAME)) == 0 && isspace(command[strlen(INTERNAL_SFTP_NAME)])) s->is_subsystem = SUBSYSTEM_INT_SFTP; else if (s->is_subsystem) s->is_subsystem = SUBSYSTEM_EXT; From robert.sicoie at gmail.com Tue Aug 19 17:52:11 2008 From: robert.sicoie at gmail.com (robert) Date: Tue, 19 Aug 2008 10:52:11 +0300 Subject: Encoding SSH RSA public key In-Reply-To: <87vdy4a9kv.fsf@squeak.fifthhorseman.net> References: <1218639242.10624.29.camel@robert> <87vdy4a9kv.fsf@squeak.fifthhorseman.net> Message-ID: <1219132331.24542.4.camel@robert> Thanks, Daniel. You were right. On Wed, 2008-08-13 at 17:28 -0400, Daniel Kahn Gillmor wrote: > On Wed 2008-08-13 10:54:02 -0400, robert wrote: > > > There must be options (optional), bits, e, n and comments (optional), > > but how are these represented before encoding? Are each of these data > > encoded to base64 separately and then concatenated? What exactly is > > encoded? > > > > Could anyone describe me the algorithm for obtaining the base64 string? > > I couldn't find it anywhere. > > The format for the base64-encded data (the unreadable stuff in the > middle of the line) appears to be: > > A series of length-prefixed bitstrings, where the length for each > bitstring is encoded as a network-order, 32-bit unsigned integer > representing the number of bytes in the following bitstring. > > The first bitstring indicates the type of the key. This can be used > to determine the nature of the bitstrings which follow. The type is > represented by a 7-byte string ("ssh-rsa" or "ssh-dss"), so the first > 4 bytes are 0x00,0x00,0x00,0x07 (this indicates the length of the > type string). > > For RSA keys, the exponent follows next as a multi-precision integer > (MPI), and then the modulus (also an MPI). > > So for example, for a 2048-bit key, you can unpack it this way: > > [0 dkg at squeak ~]$ < ./.example/id_rsa.pub cut -f2 -d\ | base64 -d | hd | head -n2 > 00000000 00 00 00 07 73 73 68 2d 72 73 61 00 00 00 03 01 |....ssh-rsa.....| > 00000010 00 01 00 00 01 01 00 c4 68 99 07 36 4f d4 7a 35 |........h..6O.z5| > [0 dkg at squeak ~]$ > > the example above uses a 3-byte exponent of 0x10001 (65537), followed > by a 257(==0x101)-byte modulus, which is the rest of the key. > > Be careful that your MPIs all have the first bit set to 0, though! > OpenSSH appears to treat the MPIs as a two's-complement signed > representation, so if your first bit is a 1, ssh will think you're > trying to provide a negative value. If your calculations produce a > number with the high bit set to 1, just increase the length by another > byte and pad the beginning with 0x00 to keep it positive. (this is > why the modulus above is 257 bytes starting with 0x00,0xc4 instead of > 256 starting with 0xc4,0x68). > > Hope this is helpful, > > --dkg > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From michael.barabanov at gmail.com Wed Aug 20 04:37:47 2008 From: michael.barabanov at gmail.com (Michael Barabanov) Date: Tue, 19 Aug 2008 11:37:47 -0700 Subject: fixed: [patch] fix to ForceCommand to support additional arguments to internal-sftp Message-ID: <8a8781f20808191137g121134felc5cbd15805d778a1@mail.gmail.com> The previous version broke the case of internal-sftp without arguments. This is a fixed version. --- /var/tmp/session.c 2008-08-18 21:07:10.000000000 -0700 +++ session.c 2008-08-19 11:28:29.000000000 -0700 @@ -781,7 +781,7 @@ if (options.adm_forced_command) { original_command = command; command = options.adm_forced_command; - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) + if (strcmp(INTERNAL_SFTP_NAME, command) == 0 || strncmp(INTERNAL_SFTP_NAME, command, strlen(INTERNAL_SFTP_NAME)) == 0 && isspace(command[strlen(INTERNAL_SFTP_NAME)])) s->is_subsystem = SUBSYSTEM_INT_SFTP; else if (s->is_subsystem) s->is_subsystem = SUBSYSTEM_EXT; @@ -789,7 +789,7 @@ } else if (forced_command) { original_command = command; command = forced_command; - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) + if (strcmp(INTERNAL_SFTP_NAME, command) == 0 || strncmp(INTERNAL_SFTP_NAME, command, strlen(INTERNAL_SFTP_NAME)) == 0 && isspace(command[strlen(INTERNAL_SFTP_NAME)])) s->is_subsystem = SUBSYSTEM_INT_SFTP; else if (s->is_subsystem) s->is_subsystem = SUBSYSTEM_EXT; From michael.barabanov at gmail.com Tue Aug 19 14:28:14 2008 From: michael.barabanov at gmail.com (Michael Barabanov) Date: Mon, 18 Aug 2008 21:28:14 -0700 Subject: [patch] fix to ForceCommand to support additional arguments to internal-sftp Message-ID: <8a8781f20808182128v2710e94ao9125e2560aa20c5c@mail.gmail.com> Hi, This patch makes things like ForceCommand internal-sftp -l INFO work (current code in 5.1 would just end the session). Please consider for inclusion into mainline. Michael. --- /var/tmp/session.c 2008-08-18 21:07:10.000000000 -0700 +++ session.c 2008-08-18 21:12:51.000000000 -0700 @@ -781,7 +781,7 @@ if (options.adm_forced_command) { original_command = command; command = options.adm_forced_command; - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) + if (strncmp(INTERNAL_SFTP_NAME, command, strlen(INTERNAL_SFTP_NAME)) == 0 && isspace(command[strlen(INTERNAL_SFTP_NAME)])) s->is_subsystem = SUBSYSTEM_INT_SFTP; else if (s->is_subsystem) s->is_subsystem = SUBSYSTEM_EXT; @@ -789,7 +789,7 @@ } else if (forced_command) { original_command = command; command = forced_command; - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) + if (strncmp(INTERNAL_SFTP_NAME, command, strlen(INTERNAL_SFTP_NAME)) == 0 && isspace(command[strlen(INTERNAL_SFTP_NAME)])) s->is_subsystem = SUBSYSTEM_INT_SFTP; else if (s->is_subsystem) s->is_subsystem = SUBSYSTEM_EXT; From djm at mindrot.org Wed Aug 20 10:32:52 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 20 Aug 2008 10:32:52 +1000 (EST) Subject: fixed: [patch] fix to ForceCommand to support additional arguments to internal-sftp In-Reply-To: <8a8781f20808191137g121134felc5cbd15805d778a1@mail.gmail.com> References: <8a8781f20808191137g121134felc5cbd15805d778a1@mail.gmail.com> Message-ID: On Tue, 19 Aug 2008, Michael Barabanov wrote: > The previous version broke the case of internal-sftp without arguments. This > is a fixed version. How about this: Index: session.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/session.c,v retrieving revision 1.241 diff -u -p -r1.241 session.c --- session.c 16 Jun 2008 13:22:53 -0000 1.241 +++ session.c 20 Aug 2008 00:32:11 -0000 @@ -87,6 +87,12 @@ #include #endif +#define IS_INTERNAL_SFTP(c) \ + (!strncmp(c, INTERNAL_SFTP_NAME, sizeof(INTERNAL_SFTP_NAME) - 1) && \ + (c[sizeof(INTERNAL_SFTP_NAME) - 1] == '\0' || \ + c[sizeof(INTERNAL_SFTP_NAME) - 1] == ' ' || \ + c[sizeof(INTERNAL_SFTP_NAME) - 1] == '\t')) + /* func */ Session *session_new(void); @@ -701,7 +707,7 @@ do_exec(Session *s, const char *command) if (options.adm_forced_command) { original_command = command; command = options.adm_forced_command; - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) + if (IS_INTERNAL_SFTP(command)) s->is_subsystem = SUBSYSTEM_INT_SFTP; else if (s->is_subsystem) s->is_subsystem = SUBSYSTEM_EXT; @@ -709,7 +715,7 @@ do_exec(Session *s, const char *command) } else if (forced_command) { original_command = command; command = forced_command; - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) + if (IS_INTERNAL_SFTP(command)) s->is_subsystem = SUBSYSTEM_INT_SFTP; else if (s->is_subsystem) s->is_subsystem = SUBSYSTEM_EXT; From michael.barabanov at gmail.com Wed Aug 20 10:43:22 2008 From: michael.barabanov at gmail.com (Michael Barabanov) Date: Tue, 19 Aug 2008 17:43:22 -0700 Subject: fixed: [patch] fix to ForceCommand to support additional arguments to internal-sftp In-Reply-To: References: <8a8781f20808191137g121134felc5cbd15805d778a1@mail.gmail.com> Message-ID: <8a8781f20808191743u5201d0fdgb785d521b270e791@mail.gmail.com> This should work as well. On Tue, Aug 19, 2008 at 5:32 PM, Damien Miller wrote: > On Tue, 19 Aug 2008, Michael Barabanov wrote: > > > The previous version broke the case of internal-sftp without arguments. > This > > is a fixed version. > > How about this: > > Index: session.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/session.c,v > retrieving revision 1.241 > diff -u -p -r1.241 session.c > --- session.c 16 Jun 2008 13:22:53 -0000 1.241 > +++ session.c 20 Aug 2008 00:32:11 -0000 > @@ -87,6 +87,12 @@ > #include > #endif > > +#define IS_INTERNAL_SFTP(c) \ > + (!strncmp(c, INTERNAL_SFTP_NAME, sizeof(INTERNAL_SFTP_NAME) - 1) && > \ > + (c[sizeof(INTERNAL_SFTP_NAME) - 1] == '\0' || \ > + c[sizeof(INTERNAL_SFTP_NAME) - 1] == ' ' || \ > + c[sizeof(INTERNAL_SFTP_NAME) - 1] == '\t')) > + > /* func */ > > Session *session_new(void); > @@ -701,7 +707,7 @@ do_exec(Session *s, const char *command) > if (options.adm_forced_command) { > original_command = command; > command = options.adm_forced_command; > - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) > + if (IS_INTERNAL_SFTP(command)) > s->is_subsystem = SUBSYSTEM_INT_SFTP; > else if (s->is_subsystem) > s->is_subsystem = SUBSYSTEM_EXT; > @@ -709,7 +715,7 @@ do_exec(Session *s, const char *command) > } else if (forced_command) { > original_command = command; > command = forced_command; > - if (strcmp(INTERNAL_SFTP_NAME, command) == 0) > + if (IS_INTERNAL_SFTP(command)) > s->is_subsystem = SUBSYSTEM_INT_SFTP; > else if (s->is_subsystem) > s->is_subsystem = SUBSYSTEM_EXT; > From dkg-openssh.com at fifthhorseman.net Thu Aug 21 08:08:00 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 20 Aug 2008 18:08:00 -0400 Subject: using ssh-add unattended on dubious files -- how can i avoid a hang? Message-ID: <87od3nnxvj.fsf@squeak.fifthhorseman.net> I need ssh-add to fail cleanly if it tries and fails to read a key, rather than prompting the user. I can't seem to figure out how to do that. This is on a Linux 2.6.26 system, running OpenSSH 5.1p1 (as built on debian lenny/sid) First, the things i've tried: * i've unset the DISPLAY and SSH_ASKPASS environment variables, so no X11-style prompting should happen. * i've redirected stdin from /dev/null (stdout and stderr too, just for good measure). * i've tried running ssh-add under /usr/bin/nohup However, even with all that, if i feed ssh-add a garbage key as a subprocess of anything that as a controlling terminal, it opens /dev/tty and prompts for a passphrase for the key directly there. You can see what it's doing here: [0 dkg at squeak]$ umask 077 [0 dkg at squeak]$ rm -f x [0 dkg at squeak]$ touch x [0 dkg at squeak]$ unset DISPLAY [0 dkg at squeak]$ unset SSH_ASKPASS [0 dkg at squeak]$ ssh-add x /dev/null 2>/dev/null Enter passphrase for x: ... and at that point it hangs until a carriage return is typed into that terminal. In the meantime, i can look at the process and see that it's opened /dev/tty directly: [0 dkg at squeak]$ ps $(pidof ssh-add) PID TTY STAT TIME COMMAND 3013 pts/19 S+ 0:00 ssh-add x [0 dkg at squeak]$ lsof -p $(pidof ssh-add) | tail -n5 ssh-add 3013 dkg 0r CHR 1,3 627 /dev/null ssh-add 3013 dkg 1w CHR 1,3 627 /dev/null ssh-add 3013 dkg 2w CHR 1,3 627 /dev/null ssh-add 3013 dkg 3u unix 0xd5df5580 105092 socket ssh-add 3013 dkg 4u CHR 5,0 1165 /dev/tty [0 dkg at squeak]$ This seems to be because the ssh-add process is still attached to a pseudoterminal, so read_passphrase (from readpass.c) opens up /dev/tty directly. I'm not sure how to detach the process full from /dev/tty (or if that would do what i need, even). What would it take to get it to just fail with a non-zero return code (the way it does when confronted with a too-permissive key file)? Is this a bug, or am i doing something wrong? Pointers appreciated, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080820/d4ad71f1/attachment.bin From jmknoble at pobox.com Thu Aug 21 08:27:59 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Wed, 20 Aug 2008 18:27:59 -0400 Subject: using ssh-add unattended on dubious files -- how can i avoid a hang? In-Reply-To: <87od3nnxvj.fsf@squeak.fifthhorseman.net> References: <87od3nnxvj.fsf@squeak.fifthhorseman.net> Message-ID: <20080820222759.GC27389@crawfish.ais.com> Circa 2008-08-20 18:08 dixit Daniel Kahn Gillmor: : I need ssh-add to fail cleanly if it tries and fails to read a key, : rather than prompting the user. I can't seem to figure out how to do : that. [...] : However, even with all that, if i feed ssh-add a garbage key as a : subprocess of anything that as a controlling terminal, it opens : /dev/tty and prompts for a passphrase for the key directly there. Have you tried running ssh-add via setsid(1)? According to setsid(2) (used by setsid(1)): setsid() creates a new session if the calling process is not a process group leader. The calling process is the leader of the new session, the process group leader of the new process group, and has no controlling tty. [...] --jim -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From dkg-openssh.com at fifthhorseman.net Thu Aug 21 09:46:22 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 20 Aug 2008 19:46:22 -0400 Subject: using ssh-add unattended on dubious files -- how can i avoid a hang? In-Reply-To: <20080820222759.GC27389@crawfish.ais.com> (Jim Knoble's message of "Wed\, 20 Aug 2008 18\:27\:59 -0400") References: <87od3nnxvj.fsf@squeak.fifthhorseman.net> <20080820222759.GC27389@crawfish.ais.com> Message-ID: <877iabntbl.fsf@squeak.fifthhorseman.net> On Wed 2008-08-20 18:27:59 -0400, Jim Knoble wrote: > Have you tried running ssh-add via setsid(1)? Thanks, Jim! I didn't know about setsid, and it appears to be what i'm looking for. The only remaining irritation is that ssh-add returns a status code of 0 rather than the expected non-zero value from a failed attempted add under setsid. (it also emits the prompt on stderr, even when there is no terminal to read from, which seems useless but not as difficult to work around as the zero-valued return code) In the example below, the number at the beginning of the shell prompt is the return code of the process just completed (i hit ctrl+D (EOF) after the first passphrase prompt, but all other interaction is visible): [0 dkg at squeak test]$ umask 077 [0 dkg at squeak test]$ rm -f x [0 dkg at squeak test]$ touch x [0 dkg at squeak test]$ ssh-add x I will be out of the office starting Sun 08/17/2008 and will not return until Mon 08/25/2008. I am at a customer facility with access to email and voicemail only in the evenings. If this is an urgent issue, please page me at 800-961-5776. Otherwise, email will be reviewed nightly. Alternate contacts: For EC08 issues, please contact Matt Kinard at x6947 or kinard at raytheon.com. For High Speed Guard business issues/requests, please contact Kevin Cariker at kcarike at raytheon.com For ISE Lab issues, please contact Jeff Sherer at jsherer at raytheon.com Thanks! Jason From david-bronder at uiowa.edu Thu Aug 21 10:00:46 2008 From: david-bronder at uiowa.edu (David Bronder) Date: Wed, 20 Aug 2008 19:00:46 -0500 (CDT) Subject: [openssh-unix-dev] Re: using ssh-add unattended on dubious files -- how can i avoid a In-Reply-To: <877iabntbl.fsf@squeak.fifthhorseman.net> from "Daniel Kahn Gillmor" at Aug 20, 2008 07:46:22 PM Message-ID: <200808210000.m7L00kCF042156@fire.its.uiowa.edu> Daniel Kahn Gillmor wrote: > > On Wed 2008-08-20 18:27:59 -0400, Jim Knoble wrote: > > > Have you tried running ssh-add via setsid(1)? > > Thanks, Jim! I didn't know about setsid, and it appears to be what > i'm looking for. > > The only remaining irritation is that ssh-add returns a status code of > 0 rather than the expected non-zero value from a failed attempted add > under setsid. Actually, that isn't really working, either. The ssh-add is still running and grabbing /dev/tty even though you get your prompt back (check ps from another shell). It will eat terminal input until the next newline even though you don't see the prompt. The 0 exit code is coming from setsid, which had no errors. Instead, try setting SSH_ASKPASS to /bin/false or DISPLAY to a bogus value, and redirect/close stdin/stdout/stderr. That will make ssh-add try to use SSH_ASKPASS which will fail (one way or another). $ SSH_ASKPASS=/bin/false ssh-add foo /dev/null 2>&1 $ DISPLAY=bar ssh-add foo /dev/null 2>&1 =Dave -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. david-bronder at uiowa.edu From dkg-openssh.com at fifthhorseman.net Thu Aug 21 14:05:57 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 21 Aug 2008 00:05:57 -0400 Subject: [openssh-unix-dev] Re: using ssh-add unattended on dubious files -- how can i avoid a In-Reply-To: <200808210000.m7L00kCF042156@fire.its.uiowa.edu> (David Bronder's message of "Wed\, 20 Aug 2008 19\:00\:46 -0500 \(CDT\)") References: <200808210000.m7L00kCF042156@fire.its.uiowa.edu> Message-ID: <87ej4jhv16.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080821/a9a7b7af/attachment.bin From scott_n at xypro.com Fri Aug 22 05:33:50 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 21 Aug 2008 12:33:50 -0700 Subject: IP options Message-ID: <78DD71C304F38B41885A242996B96F7301951A0B@xyservd.XYPRO-23.LOCAL> I'm seeing something similar to bug 1179 (https://bugzilla.mindrot.org/show_bug.cgi?id=1179), even with the reordered IP options check. For some reason, getsockopt is returning an IP options of length 2, value 00 00. Would Mark Weindling's original patch (https://bugzilla.mindrot.org/attachment.cgi?id=1105) break anything if I incorporated it? Platform: HP NonStop S7000 series (G-series RVU). ---- Scott Neugroschl XYPRO Technologies scott_n at xypro.com 805-583-2874 x121 From scott_n at xypro.com Fri Aug 22 06:11:32 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 21 Aug 2008 13:11:32 -0700 Subject: IP options Message-ID: <78DD71C304F38B41885A242996B96F7301951A10@xyservd.XYPRO-23.LOCAL> In addition, there's an error in canohost.c/getremotehostname(), that the fix for 1179 introduced (to wit, the variable ntop is uninitialized at the point of call to check_ip_options). I've got to run off to a meeting, but I'll try to post a patch later today. From: Scott Neugroschl Sent: Thursday, August 21, 2008 12:34 PM To: openssh-unix-dev at mindrot.org Subject: IP options I'm seeing something similar to bug 1179 (https://bugzilla.mindrot.org/show_bug.cgi?id=1179), even with the reordered IP options check. For some reason, getsockopt is returning an IP options of length 2, value 00 00. Would Mark Weindling's original patch (https://bugzilla.mindrot.org/attachment.cgi?id=1105) break anything if I incorporated it? Platform: HP NonStop S7000 series (G-series RVU). ---- Scott Neugroschl XYPRO Technologies scott_n at xypro.com 805-583-2874 x121 From bruce.korb at gmail.com Fri Aug 22 05:15:55 2008 From: bruce.korb at gmail.com (Bruce Korb) Date: Thu, 21 Aug 2008 12:15:55 -0700 Subject: I've got joy now -- X protocols working *BUT* Message-ID: <48ADBEEB.8020004@gmail.com> *BUT* for reasons that I find unfathomable, I have to have my xterm open for an hour or so before X applications work. When I first started a particular terminal session, I got this: > $ labconsole 043 > xterm -T "S043-1 via telnet bignts17 5010" -e telnet bignts17 5010 > xterm -T "S043-2 via telnet bignts17 5011" -e telnet bignts17 5011 > xterm -T "S043-3 via telnet bignts17 5012" -e telnet bignts17 5012 > X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) > Major opcode of failed request: 55 (X_CreateGC) > Resource id in failed request: 0x1a6 > Serial number of failed request: 1 > Current serial number in output stream: 3 <<>> ============== An hour later on the same session: > $ labconsole 043 > xterm -T "S043-1 via telnet bignts17 5010" -e telnet bignts17 5010 > xterm -T "S043-2 via telnet bignts17 5011" -e telnet bignts17 5011 > xterm -T "S043-3 via telnet bignts17 5012" -e telnet bignts17 5012 > xterm -T "S043-4 via telnet bignts17 5013" -e telnet bignts17 5013 > xterm -T "S043-5 via telnet bignts17 5014" -e telnet bignts17 5014 > $ OK. Whatever. I'll just have to be patient. Sure seems weird to me. Thank you. Regards, Bruce From djm at mindrot.org Fri Aug 22 02:37:22 2008 From: djm at mindrot.org (Damien Miller) Date: Fri, 22 Aug 2008 02:37:22 +1000 (EST) Subject: fixed: [patch] fix to ForceCommand to support additional arguments to internal-sftp In-Reply-To: <8a8781f20808191743u5201d0fdgb785d521b270e791@mail.gmail.com> References: <8a8781f20808191137g121134felc5cbd15805d778a1@mail.gmail.com> <8a8781f20808191743u5201d0fdgb785d521b270e791@mail.gmail.com> Message-ID: On Tue, 19 Aug 2008, Michael Barabanov wrote: > This should work as well. Applied - thanks. It will be in 5.2. -d From scott_n at xypro.com Fri Aug 22 09:51:03 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 21 Aug 2008 16:51:03 -0700 Subject: IP options Message-ID: <78DD71C304F38B41885A242996B96F7301951A40@xyservd.XYPRO-23.LOCAL> >From: Scott Neugroschl > >In addition, there's an error in canohost.c/getremotehostname(), that the fix >for 1179 introduced (to wit, the variable ntop is uninitialized at the point >of call to check_ip_options). I've got to run off to a meeting, but I'll >try to post a patch later today. Here's the proposed patch: Index: canohost.c =================================================================== RCS file: /cvs/openssh/canohost.c,v retrieving revision 1.73 diff -u -r1.73 canohost.c --- canohost.c 12 Jun 2008 18:46:45 -0000 1.73 +++ canohost.c 21 Aug 2008 23:45:32 -0000 @@ -58,8 +58,13 @@ cleanup_exit(255); } - if (from.ss_family == AF_INET) + if (from.ss_family == AF_INET) { + if (getnameinfo((struct sockaddr *)&from, fromlen, ntop, sizeof(ntop), + NULL, 0, NI_NUMERICHOST) != 0) + fatal("get_remote_hostname: getnameinfo NI_NUMERICHOST failed"); + check_ip_options(sock, ntop); + } ipv64_normalise_mapped(&from, &fromlen); From courtin at gmx.de Fri Aug 22 19:22:34 2008 From: courtin at gmx.de (Bert Courtin) Date: Fri, 22 Aug 2008 11:22:34 +0200 Subject: CIDR address/masklen matching support for permitopen="host:port" restrictions? Message-ID: <20080822092234.15400@gmx.net> Dear openssh-unix-dev list, in OpenSSH 5.1 you introduced CIDR address/masklen matching for "Match address" blocks in sshd_config as well as supporting CIDR matching in ~/.ssh/authorized_keys from="..." restrictions in sshd. I wonder whether CIDR address/masklen matching will be implemented for permitopen="host:port" restrictions in sshd as well, that would be quite beneficially (at least for me, maybe others,too;-)? Thank you - kind regards, Bert. -- GMX Kostenlose Spiele: Einfach online spielen und Spa? haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 From scott_n at xypro.com Sat Aug 23 01:46:46 2008 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 22 Aug 2008 08:46:46 -0700 Subject: REPOST: IP options Message-ID: <78DD71C304F38B41885A242996B96F7301951A5E@xyservd.XYPRO-23.LOCAL> [reposted because original was sent in HTML by mistake] I'm seeing something similar to bug 1179 (https://bugzilla.mindrot.org/show_bug.cgi?id=1179), even with the reordered IP options check. For some reason, getsockopt is returning an IP options of length 2, value 00 00. Would Mark Weindling's original patch (https://bugzilla.mindrot.org/attachment.cgi?id=1105) break anything if I incorporated it? Platform: HP NonStop S7000 series (G-series RVU). ---- Scott Neugroschl XYPRO Technologies scott_n at xypro.com 805-583-2874 x121 From ralph at inputplus.co.uk Sat Aug 23 04:26:43 2008 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 22 Aug 2008 19:26:43 +0100 Subject: Enhance Match Blocks to Test Server Port. Message-ID: <20080822182643.C14AA4836@blake.inputplus.co.uk> Hi, We'd like sshd to listen on port 22 with PasswordAuthentication = no and port 2222 with PasswordAuthentication = yes. At the moment, it seems the only way to do this is to run two sshds, one per port. Since Match blocks already allow PasswordAuthentication to be set, if the Match keyword itself allowed testing of the server port to which the incoming connection was made then we could do PasswordAuthentication no ... Match ServerPort 2222 PasswordAuthentication yes Does this sound plausible? Would you consider it as an enhancement? Should I open a bug accordingly for the work to be done against? Cheers, Ralph. [I'm not subscribed, so please CC me.] From senthilprabu.s at nsn.com Tue Aug 26 02:21:28 2008 From: senthilprabu.s at nsn.com (S, Senthilprabu (NSN - IN/Bangalore)) Date: Mon, 25 Aug 2008 21:51:28 +0530 Subject: Performance of scp with OpenSSH - 5.1p1 Message-ID: <41446CF276F2B8419141678E8117C7C601EB95C9@inbhexc001.nsn-intra.net> Hello All, As the release notes of SSH-4.7 version says that a new MAC algorithm (UMAC-64 - RFC4418) was introduced with OpenSSH-4.7 which gives much better performance, I was tempted to check out the enhanced speed provided with new version. So I downloaded OpenSSH-5.1p1 and build it on Solaris 10 with Sun Compiler CC. My test setup:- 1. Two Sunfire 440 with 2 CPU (1281 MHz) and 4GB RAM. 2. Network interface supports 1 Gbit/s (duplex) I tried transferring 1GB file between Node A and Node B connected using 1GB interface using SCP. Node A can connect to Node B without password using public key authentication. With OpenSSH-5.1p1:- ------------------------ Protocol Time taken rate MB/s Std. scp 53.7 19.3 scp -c arcfour 40.1 26.3 scp -c blowfish 55.5 18.6 scp -C 123.6 16.3 With OpenSSH-4.5p1:- ------------------------- Protocol Time taken rate MB/s Std. scp 59.9 17.9 scp -c arcfour 45 22.3 scp -c blowfish 59.6 17.1 scp -C 131 14.1 I do not see any higher throughput (20%) with the 5.1p1 (with UMAC-64) than 4.5p1. The above results clearly says it is not increasing the performance by 20%. Did I something here?. Also does UMAC-64 have a impact on scp also or my understanding is wrong?. Thanks inadvance Senthil Prabu.S -- Senthil Prabu.S From djm at mindrot.org Tue Aug 26 03:03:39 2008 From: djm at mindrot.org (Damien Miller) Date: Tue, 26 Aug 2008 03:03:39 +1000 (EST) Subject: Performance of scp with OpenSSH - 5.1p1 In-Reply-To: <41446CF276F2B8419141678E8117C7C601EB95C9@inbhexc001.nsn-intra.net> References: <41446CF276F2B8419141678E8117C7C601EB95C9@inbhexc001.nsn-intra.net> Message-ID: On Mon, 25 Aug 2008, S, Senthilprabu (NSN - IN/Bangalore) wrote: > I do not see any higher throughput (20%) with the 5.1p1 (with UMAC-64) > than 4.5p1. The above results clearly says it is not increasing the > performance by 20%. Did I something here?. Did you enable UMAC 64? scp -oCiphers=arcfour256 -oMACs=umac-64 at openssh.com ... I measured a 20% performance improvement on my system on localhost->localhost transfers. BTW, it is good that your results show a 10% improvement *without* the use of UMAC 64. -d From senthilprabu.s at nsn.com Tue Aug 26 11:52:27 2008 From: senthilprabu.s at nsn.com (S, Senthilprabu (NSN - IN/Bangalore)) Date: Tue, 26 Aug 2008 07:22:27 +0530 Subject: Performance of scp with OpenSSH - 5.1p1 In-Reply-To: References: <41446CF276F2B8419141678E8117C7C601EB95C9@inbhexc001.nsn-intra.net> Message-ID: <41446CF276F2B8419141678E8117C7C601EB95E7@inbhexc001.nsn-intra.net> Hello Damien, Thanks a lot for the reply!!! > Did you enable UMAC 64? I did not do any specific setting wrt UMAC-64 explicitly when I used the scp command. But do read on net that some kind of configuration can be done in ssh/sshd config file. Is it true? > scp -oCiphers=arcfour256 -oMACs=umac-64 at openssh.com ... U mean the scp command usage should be like "scp -oCiphers=arcfour256 -oMACs=umac-64 at openssh.com user at server:$PATH_IN_REMOTE -- Senthil Prabu.S From djm at mindrot.org Tue Aug 26 16:45:38 2008 From: djm at mindrot.org (Damien Miller) Date: Tue, 26 Aug 2008 16:45:38 +1000 (EST) Subject: Performance of scp with OpenSSH - 5.1p1 In-Reply-To: <41446CF276F2B8419141678E8117C7C601EB95E7@inbhexc001.nsn-intra.net> References: <41446CF276F2B8419141678E8117C7C601EB95C9@inbhexc001.nsn-intra.net> <41446CF276F2B8419141678E8117C7C601EB95E7@inbhexc001.nsn-intra.net> Message-ID: On Tue, 26 Aug 2008, S, Senthilprabu (NSN - IN/Bangalore) wrote: > Hello Damien, > > Thanks a lot for the reply!!! > > > Did you enable UMAC 64? > > I did not do any specific setting wrt UMAC-64 explicitly when I used the > scp command. But do read on net that some kind of configuration can be > done in ssh/sshd config file. Is it true? MAC algorithms, like ciphers, are selected at runtime. The following command is an example, but there is no substitute for reading the documentation: > > scp -oCiphers=arcfour256 -oMACs=umac-64 at openssh.com ... From stuge-openssh-unix-dev at cdy.org Wed Aug 27 01:43:39 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 26 Aug 2008 17:43:39 +0200 Subject: CIDR address/masklen matching support for permitopen="host:port" restrictions? In-Reply-To: <20080822092234.15400@gmx.net> References: <20080822092234.15400@gmx.net> Message-ID: <20080826154339.17108.qmail@cdy.org> On Fri, Aug 22, 2008 at 11:22:34AM +0200, Bert Courtin wrote: > I wonder whether CIDR address/masklen matching will be implemented > for permitopen="host:port" restrictions in sshd as well, that would > be quite beneficially (at least for me, maybe others,too;-)? Maybe you can look into it yourself? I expect that there are some generically useful functions for CIDR in the code. //Peter From gusgl2001 at yahoo.com Wed Aug 27 06:12:18 2008 From: gusgl2001 at yahoo.com (GB) Date: Tue, 26 Aug 2008 13:12:18 -0700 (PDT) Subject: SSH Command Line Password Support In-Reply-To: Message-ID: <876324.11513.qm@web30706.mail.mud.yahoo.com> Dear Developers, I have successfully implemented the password in the argument line for both ssh and scp. I would be more than willing to share my code so that it will become an official part of ssh and scp to satisfy the needs of users out there using scripts and the like. I don't consider the code to be the most secure possible, but it took 10 minutes to implement in ssh and 20 on scp, so modifications by you to make it compliant would be minimal. Thank you --- On Sun, 8/17/08, Damien Miller wrote: From: Damien Miller Subject: Re: SSH Command Line Password Support To: "GB" Cc: "Dag-Erling Sm?rgrav" , openssh-unix-dev at mindrot.org Date: Sunday, August 17, 2008, 5:18 AM On Sat, 16 Aug 2008, GB wrote: > While trying to compile openssh (I succeeded in compiling openssl) I > get the following after using make: You aren't making it easy to help. What version of OpenSSH is this? It doesn't appear to be 5.1. What operating system? Does your platform lack OpenSSL? What configure options did you use? -d From dkg-openssh.com at fifthhorseman.net Wed Aug 27 07:06:06 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 26 Aug 2008 17:06:06 -0400 Subject: SSH Command Line Password Support In-Reply-To: <86y72x6op8.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Sat\, 16 Aug 2008 16\:04\:35 +0200") References: <781297.30010.qm@web30704.mail.mud.yahoo.com> <86y72x6op8.fsf@ds4.des.no> Message-ID: <87tzd75vwh.fsf@squeak.fifthhorseman.net> On Sat 2008-08-16 10:04:35 -0400, Dag-Erling Sm?rgrav wrote: > GB writes: >> I am interested in an ssh that is not interactive in requesting the >> password, i.e, whereas I can specify the password in the command line >> when calling SSH. > > ps -fe > > Just use a passphrase-less keypair. On Tue 2008-08-26 16:12:18 -0400, GB wrote: > I have successfully implemented the password in the argument line > for both ssh and scp. > > I would be more than willing to share my code so that it will become > an official part of ssh and scp to satisfy the needs of users out > there using scripts and the like. > > I don't consider the code to be the most secure possible, but it > took 10 minutes to implement in ssh and 20 on scp, so modifications > by you to make it compliant would be minimal. What Dag-Erling was pointing out above is that the command line arguments of any process are visible to all users on most UNIX-style systems simply by using the "ps" command. This means that anything you put on the command line is not secure, and it would be a mistake to for OpenSSH to encourage this behavior in its users. Dag-Erling also offered you another technique to achieve your stated goal of "the needs of users out there using scripts", which is to use a passphrase-less keypair for scripted connections. You might want to read Brian Hatch's "SSH User Identities" [0], and Matt Taggart's "Good practices for using SSH" [1]. I'm afraid it would be ill-advised for OpenSSH to adopt your proposed patch, since better, more secure options already exist. Regards, --dkg [0] http://www.securityfocus.com/infocus/1810 [1] http://lackof.org/taggart/hacking/ssh/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080826/efa6f7ad/attachment.bin From carson at taltos.org Wed Aug 27 08:03:02 2008 From: carson at taltos.org (Carson Gaspar) Date: Tue, 26 Aug 2008 15:03:02 -0700 Subject: SSH Command Line Password Support In-Reply-To: <87tzd75vwh.fsf@squeak.fifthhorseman.net> References: <781297.30010.qm@web30704.mail.mud.yahoo.com> <86y72x6op8.fsf@ds4.des.no> <87tzd75vwh.fsf@squeak.fifthhorseman.net> Message-ID: <48B47D96.20702@taltos.org> Daniel Kahn Gillmor wrote: [ why passwords on command lines are evil ] > Dag-Erling also offered you another technique to achieve your stated > goal of "the needs of users out there using scripts", which is to use > a passphrase-less keypair for scripted connections. You might want to > read Brian Hatch's "SSH User Identities" [0], and Matt Taggart's "Good > practices for using SSH" [1]. Or, if you must use a password, use the ssh-askpass interface that already exists. Why write a different and insecure one? -- Carson From des at des.no Wed Aug 27 19:09:49 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed, 27 Aug 2008 11:09:49 +0200 Subject: SSH Command Line Password Support In-Reply-To: <876324.11513.qm@web30706.mail.mud.yahoo.com> (GB's message of "Tue, 26 Aug 2008 13:12:18 -0700 (PDT)") References: <876324.11513.qm@web30706.mail.mud.yahoo.com> Message-ID: <867ia2963m.fsf@ds4.des.no> GB writes: > I have successfully implemented the password in the argument line for > both ssh and scp. Firstly, it's not a -portable issue. The patch should go upstream (to OpenBSD), if anywhere. Secondly, I can tell you already that they will not accept it. It's a very, very bad idea. Just use passphrase-less keys. DES -- Dag-Erling Sm?rgrav - des at des.no From djm at mindrot.org Wed Aug 27 14:05:52 2008 From: djm at mindrot.org (djm at mindrot.org) Date: Wed, 27 Aug 2008 14:05:52 +1000 (EST) Subject: SSH Command Line Password Support In-Reply-To: <867ia2963m.fsf@ds4.des.no> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> Message-ID: On Wed, 27 Aug 2008, Dag-Erling Sm?rgrav wrote: > GB writes: > I have successfully implemented the > password in the argument line for > both ssh and scp. > > Firstly, it's not a -portable issue. The patch should go upstream (to > OpenBSD), if anywhere. > > Secondly, I can tell you already that they will not accept it. It's a > very, very bad idea. Just use passphrase-less keys. The upstream developers mostly read this list, so anything posted here will be considered for both versions (likewise bugzilla, which has the added advantage of remembering patches more clearly). That being said, there is no way we will add an option like this. OpenSSH already has a perfectly good way of "handsfree" authentication in the form of public keys. Furthermore, passwords-on-commandlines are trivially observable by other users on a shared system and have been rightly considered insecure since forever. If you are thinking that such a hack is okay for your system because it is not shared with other users, then consider that any attacker who breaks into a low privilege account now has a perfect opportunity to steal a password to a different host. -d From djm at mindrot.org Wed Aug 27 14:07:14 2008 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Aug 2008 14:07:14 +1000 (EST) Subject: CIDR address/masklen matching support for permitopen="host:port" restrictions? In-Reply-To: <20080826154339.17108.qmail@cdy.org> References: <20080822092234.15400@gmx.net> <20080826154339.17108.qmail@cdy.org> Message-ID: On Tue, 26 Aug 2008, Peter Stuge wrote: > On Fri, Aug 22, 2008 at 11:22:34AM +0200, Bert Courtin wrote: > > I wonder whether CIDR address/masklen matching will be implemented > > for permitopen="host:port" restrictions in sshd as well, that would > > be quite beneficially (at least for me, maybe others,too;-)? > > Maybe you can look into it yourself? I expect that there are some > generically useful functions for CIDR in the code. Also, feel free to file an enhancement request at bugzilla.mindrot.org so it doesn't get lost. -d From courtin at gmx.de Wed Aug 27 21:55:33 2008 From: courtin at gmx.de (Bert Courtin) Date: Wed, 27 Aug 2008 13:55:33 +0200 Subject: CIDR address/masklen matching support for permitopen="host:port" Message-ID: <20080827115533.242000@gmx.net> On Wed, 27 Aug 2008, Damien Miller wrote: > On Tue, 26 Aug 2008, Peter Stuge wrote: > > On Fri, Aug 22, 2008 at 11:22:34AM +0200, Bert Courtin wrote: > > > I wonder whether CIDR address/masklen matching will be implemented > > > for permitopen="host:port" restrictions in sshd as well, that would > > > be quite beneficially (at least for me, maybe others,too;-)? > > > > Maybe you can look into it yourself? I expect that there are some > > generically useful functions for CIDR in the code. > > Also, feel free to file an enhancement request at bugzilla.mindrot.org > so it doesn't get lost. Thank you for your answers. I've done that (filed an enhancement request) - you suggested to look into it by myself (and perhaps contribute a patch...) - I definitively would do that if I'd only speak C... Regards, b. -- GMX Kostenlose Spiele: Einfach online spielen und Spa? haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 From rebel at atrey.karlin.mff.cuni.cz Wed Aug 27 22:21:04 2008 From: rebel at atrey.karlin.mff.cuni.cz (Michal Svec) Date: Wed, 27 Aug 2008 14:21:04 +0200 (CEST) Subject: [PATCH] Re: SSH_RSA_MINIMUM_MODULUS_SIZE In-Reply-To: References: Message-ID: Hello, trying again, with a patch now (only for the client). Currently it's not possible to change this without recompiling so any way to prevent that would do and command line seems to be the easiest. Would something like this be acceptable? Thanks. Michal On Tue, 8 Jul 2008, Michal Svec wrote: > > Hi, > > is there any chance to make SSH_RSA_MINIMUM_MODULUS_SIZE configurable? > I keep receiving these messages: > > ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits > key_verify failed for server_host_key > > And it's quite a hassle to recompile each time I need to use it (there > are still devices where you can't fix it easily). > > Thanks > Michal > -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_rsa_minimum_modulus_size-5.1p1.patch Type: text/x-diff Size: 2801 bytes Desc: Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080827/99a97b65/attachment.bin From janfrode at tanso.net Wed Aug 27 22:16:57 2008 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 27 Aug 2008 14:16:57 +0200 Subject: SSH Command Line Password Support References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> Message-ID: On 2008-08-27, djm at mindrot.org wrote: > > That being said, there is no way we will add an option like this. > OpenSSH already has a perfectly good way of "handsfree" authentication > in the form of public keys. Furthermore, passwords-on-commandlines are > trivially observable by other users on a shared system and have been > rightly considered insecure since forever. Unfortunately not every client can dictate how he's allowed to authenticate towards an external server. We need to push some data from non-shared system, to a windows (free-sshd?) sftp server daily, and the admins there for some reason only allow password-based authentication. What would your answer be if you were in this situation ? Say "no, this is impossible", or hack around it with expect? > If you are thinking that such a hack is okay for your system because > it is not shared with other users, then consider that any attacker who > breaks into a low privilege account now has a perfect opportunity to > steal a password to a different host. I'd love to use rsa-keys if they would let me. Now they woun't, and the lack of client side --password option force me to use an ugly expect script, which is not very easy to have handle error conditions. -jf From stuge-openssh-unix-dev at cdy.org Thu Aug 28 00:10:50 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 27 Aug 2008 16:10:50 +0200 Subject: SSH Command Line Password Support In-Reply-To: References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> Message-ID: <20080827141050.15733.qmail@cdy.org> Jan-Frode Myklebust wrote: > the admins there for some reason only allow password-based > authentication. > > What would your answer be if you were in this situation ? > Say "no, this is impossible", or hack around it with expect? expect works. The SSH_ASKPASS environment variable is another, perhaps more reliable, alternative. //Peter From dkg-openssh.com at fifthhorseman.net Thu Aug 28 01:17:40 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 Aug 2008 11:17:40 -0400 Subject: SSH Command Line Password Support In-Reply-To: (Jan-Frode Myklebust's message of "Wed\, 27 Aug 2008 14\:16\:57 +0200") References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> Message-ID: <87y72itrl7.fsf@squeak.fifthhorseman.net> On Wed 2008-08-27 08:16:57 -0400, Jan-Frode Myklebust wrote: > Unfortunately not every client can dictate how he's allowed > to authenticate towards an external server. We need to push > some data from non-shared system, to a windows (free-sshd?) > sftp server daily, and the admins there for some reason only > allow password-based authentication. > > What would your answer be if you were in this situation ? > Say "no, this is impossible", or hack around it with expect? As Carson Gaspar pointed out elsewhere in this thread, the ssh-askpass functionality is already present, and could be scripted. For a shell with a builtin echo, you could do something like the following (untested, may need tweaking) in a script, and it should not leak into the process table: authdir=$(mktemp -d) mkfifo $authdir/pw echo 'this is my not-so-secret-passphrase' > $authdir/pw DISPLAY=nosuchdisplay SSH_ASKPASS="cat $authdir/pw" ssh foo at bar rm -rf $authdir Note that you want to make sure that ssh is not connected to a tty in this case, or else it will try to ask for the password from the tty anyway. For scripts run from cronjobs, that shouldn't be a problem, but testing them from your own shell might be confusing. Jim Knoble pointed out the possible use of setsid(1) for this very purpose a few days ago on this list. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080827/bd9ba952/attachment.bin From dan3857 at yahoo.com Thu Aug 28 01:49:47 2008 From: dan3857 at yahoo.com (Dan) Date: Wed, 27 Aug 2008 08:49:47 -0700 (PDT) Subject: 5.1p1 doesn't work, 5.0p1 works fine Message-ID: <910545.49667.qm@web34303.mail.mud.yahoo.com> 5.1p1 disconnects after the password prompt when connecting to my router and UPS. 5.1p1 connects fine to other unix hosts, and my Windows client connects fine to 5.1p1 servers. 5.0p1 works fine everywhere. I've tried ssh -T, ssh -t, permutations with ssh -o Compression=no -o TCPKeepAlive=no, etc, to no avail. I've used the default ssh_config file, and it still fails. Can anyone suggest any other command line options to try that might have changed? Here is a -vvv log from 5.1p1 and 5.0p1 connecting to my router: ssh -vvv -p 1024 admin at router 5.1p1: OpenSSH_5.1p1, OpenSSL 0.9.8h 28 May 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug3: cipher ok: aes256-cbc [aes256-cbc,3des-cbc] debug3: cipher ok: 3des-cbc [aes256-cbc,3des-cbc] debug3: ciphers ok: [aes256-cbc,3des-cbc] debug2: mac_setup: found hmac-sha1 debug3: mac ok: hmac-sha1 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: mac_setup: found hmac-md5 debug3: mac ok: hmac-md5 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: mac_setup: found hmac-ripemd160 debug3: mac ok: hmac-ripemd160 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: mac_setup: found hmac-sha1-96 debug3: mac ok: hmac-sha1-96 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: mac_setup: found hmac-md5-96 debug3: mac ok: hmac-md5-96 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug3: macs ok: [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: ssh_connect: needpriv 0 debug1: Connecting to router [10.1.1.1] port 1024. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version NetScreen debug1: no match: NetScreen debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes256-cbc,3des-cbc debug2: kex_parse_kexinit: aes256-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: 3des-cbc debug2: kex_parse_kexinit: 3des-cbc debug2: kex_parse_kexinit: hmac-sha1 debug2: kex_parse_kexinit: hmac-sha1 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1 debug1: kex: server->client 3des-cbc hmac-sha1 none debug2: mac_setup: found hmac-sha1 debug1: kex: client->server 3des-cbc hmac-sha1 none debug2: dh_gen_key: priv key bits set: 182/384 debug2: bits set: 516/1024 debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug3: put_host_port: [10.1.1.1]:1024 debug3: put_host_port: [router]:1024 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 74 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 74 debug1: Host '[router]:1024' is known and matches the DSA host key. debug1: Found key in /root/.ssh/known_hosts:74 debug2: bits set: 481/1024 debug1: ssh_dss_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa ((nil)) debug2: key: /root/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: password debug3: start over, passed a different list password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup password debug3: remaining preferred: ,keyboard-interactive,password debug3: authmethod_is_enabled password debug1: Next authentication method: password admin at router's password: ^ The password prompt works fine and blocks wrong passwords properly. This is a failed connection -> debug3: packet_send2: adding 56 (len 61 padlen 11 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug2: fd 5 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug2: channel 0: request shell confirm 1 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 2048 rmax 1024 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r42 i0/0 o0/0 fd 4/5 cfd -1) debug3: channel 0: close_fds r 4 w 5 e 6 c -1 debug1: fd 1 clearing O_NONBLOCK debug3: fd 2 is not O_NONBLOCK Connection to router closed by remote host. Connection to router closed. Transferred: sent 1224, received 920 bytes, in 0.0 seconds Bytes per second: sent 98557.8, received 74079.4 debug1: Exit status -1 5.0p1: OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug3: cipher ok: aes256-cbc [aes256-cbc,3des-cbc] debug3: cipher ok: 3des-cbc [aes256-cbc,3des-cbc] debug3: ciphers ok: [aes256-cbc,3des-cbc] debug2: mac_setup: found hmac-sha1 debug3: mac ok: hmac-sha1 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: mac_setup: found hmac-md5 debug3: mac ok: hmac-md5 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: mac_setup: found hmac-ripemd160 debug3: mac ok: hmac-ripemd160 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: mac_setup: found hmac-sha1-96 debug3: mac ok: hmac-sha1-96 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: mac_setup: found hmac-md5-96 debug3: mac ok: hmac-md5-96 [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug3: macs ok: [hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96] debug2: ssh_connect: needpriv 0 debug1: Connecting to router [10.1.1.1] port 1024. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version NetScreen debug1: no match: NetScreen debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.0 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes256-cbc,3des-cbc debug2: kex_parse_kexinit: aes256-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: 3des-cbc debug2: kex_parse_kexinit: 3des-cbc debug2: kex_parse_kexinit: hmac-sha1 debug2: kex_parse_kexinit: hmac-sha1 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1 debug1: kex: server->client 3des-cbc hmac-sha1 none debug2: mac_setup: found hmac-sha1 debug1: kex: client->server 3des-cbc hmac-sha1 none debug2: dh_gen_key: priv key bits set: 181/384 debug2: bits set: 562/1024 debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug3: put_host_port: [10.1.1.1]:1024 debug3: put_host_port: [router]:1024 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 74 debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 74 debug1: Host '[router]:1024' is known and matches the DSA host key. debug1: Found key in /root/.ssh/known_hosts:74 debug2: bits set: 511/1024 debug1: ssh_dss_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa ((nil)) debug2: key: /root/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: password debug3: start over, passed a different list password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup password debug3: remaining preferred: ,keyboard-interactive,password debug3: authmethod_is_enabled password debug1: Next authentication method: password admin at router's password: ^ The password prompt works fine and blocks wrong passwords properly. This is a successfull connection -> debug3: packet_send2: adding 56 (len 61 padlen 11 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug2: fd 5 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 0 debug3: tty_make_modes: 7 0 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 0 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 0 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 2048 rmax 1024 Remote Management Console router-> exitdebug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r43 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 6 c -1 debug1: fd 1 clearing O_NONBLOCK debug3: fd 2 is not O_NONBLOCK Connection to router closed. debug1: Transferred: stdin 0, stdout 0, stderr 27 bytes in 1.3 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 20.1 debug1: Exit status -1 From gert at greenie.muc.de Thu Aug 28 04:55:07 2008 From: gert at greenie.muc.de (Gert Doering) Date: Wed, 27 Aug 2008 20:55:07 +0200 Subject: SSH Command Line Password Support In-Reply-To: <87y72itrl7.fsf@squeak.fifthhorseman.net> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> Message-ID: <20080827185507.GD233@greenie.muc.de> Hi, On Wed, Aug 27, 2008 at 11:17:40AM -0400, Daniel Kahn Gillmor wrote: > Note that you want to make sure that ssh is not connected to a tty in > this case, or else it will try to ask for the password from the tty > anyway. For scripts run from cronjobs, that shouldn't be a problem, > but testing them from your own shell might be confusing. Jim Knoble > pointed out the possible use of setsid(1) for this very purpose a few > days ago on this list. Now *that* is actually something I would find extremely useful - tell SSH "do not prompt for anything, use SSH_ASKPASS or fail silently" without having to mess around with process groups and controlling ttys, which is very very very much non-portable. I need to do stuff on AIX, Solaris, BSD, and Linux, and there is no single way that works on all those to get rid of your controlling tty... :-( gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From janfrode at tanso.net Thu Aug 28 07:27:59 2008 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 27 Aug 2008 23:27:59 +0200 Subject: SSH Command Line Password Support References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> Message-ID: On 2008-08-27, Daniel Kahn Gillmor wrote: > As Carson Gaspar pointed out elsewhere in this thread, the ssh-askpass > functionality is already present, and could be scripted. SSH_ASKPASS doesn't work together with "sftp -b batchfile", so expect seems to be the only way to do automated password-based sftp.. -jf From dkg-openssh.com at fifthhorseman.net Thu Aug 28 07:33:15 2008 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 Aug 2008 17:33:15 -0400 Subject: SSH Command Line Password Support In-Reply-To: <20080827185507.GD233@greenie.muc.de> (Gert Doering's message of "Wed\, 27 Aug 2008 20\:55\:07 +0200") References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> Message-ID: <87iqtmkusk.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080827/98411ca6/attachment.bin From djm at mindrot.org Thu Aug 28 01:38:02 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Aug 2008 01:38:02 +1000 (EST) Subject: [PATCH] Re: SSH_RSA_MINIMUM_MODULUS_SIZE In-Reply-To: References: Message-ID: On Wed, 27 Aug 2008, Michal Svec wrote: > > Hello, > > trying again, with a patch now (only for the client). > > Currently it's not possible to change this without recompiling so any way to > prevent that would do and command line seems to be the easiest. > > Would something like this be acceptable? No, we don't want a proliferation of config options. -d From djm at mindrot.org Thu Aug 28 01:54:58 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Aug 2008 01:54:58 +1000 (EST) Subject: 5.1p1 doesn't work, 5.0p1 works fine In-Reply-To: <910545.49667.qm@web34303.mail.mud.yahoo.com> References: <910545.49667.qm@web34303.mail.mud.yahoo.com> Message-ID: On Wed, 27 Aug 2008, Dan wrote: > 5.1p1 disconnects after the password prompt when connecting to my > router and UPS. 5.1p1 connects fine to other unix hosts, and my > Windows client connects fine to 5.1p1 servers. 5.0p1 works fine > everywhere. > > I've tried ssh -T, ssh -t, permutations with ssh -o Compression=no -o > TCPKeepAlive=no, etc, to no avail. I've used the default ssh_config > file, and it still fails. > > Can anyone suggest any other command line options to try that might > have changed? Maybe your router is choking on the no-more-sessions at openssh.com request. Try commenting out this block in ssh.c:ssh_session2() > /* If we don't expect to open a new session, then disallow it */ > if (options.control_master == SSHCTL_MASTER_NO) { > debug("Requesting no-more-sessions at openssh.com"); > packet_start(SSH2_MSG_GLOBAL_REQUEST); > packet_put_cstring("no-more-sessions at openssh.com"); > packet_put_char(0); > packet_send(); > } Otherwise, you might have to compile a ssh client with -DPACKET_DEBUG to see what packet is making your router freak out. Note that you should not send full PACKET_DEBUG output to the mailing list as it will include hex-encoded passwords - make sure you only send packets after authentication has completed. -d From djm at mindrot.org Thu Aug 28 01:55:55 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Aug 2008 01:55:55 +1000 (EST) Subject: SSH Command Line Password Support In-Reply-To: <87iqtmkusk.fsf@squeak.fifthhorseman.net> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> Message-ID: On Wed, 27 Aug 2008, Daniel Kahn Gillmor wrote: > I agree that this would be a useful feature. It seems that it was > proposed back in January of 2007, but nothing came of it: > > http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2 > > and years before that, it's bugzilla #69: > > https://bugzilla.mindrot.org/show_bug.cgi?id=69 > > which actually contains a couple of patches, but is still in the NEW > state. > > Any takers on bringing one of those patches up-to-date with 5.1p1? > Any objections to the idea itself? I think we should do something like this, but I remember having some issues with the user-interface. -d From stuge-openssh-unix-dev at cdy.org Thu Aug 28 09:04:38 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 28 Aug 2008 01:04:38 +0200 Subject: SSH Command Line Password Support In-Reply-To: <87iqtmkusk.fsf@squeak.fifthhorseman.net> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> Message-ID: <20080827230438.21637.qmail@cdy.org> Daniel Kahn Gillmor wrote: > Any objections to the idea itself? I like it. //Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080828/b628a060/attachment.bin From dan3857 at yahoo.com Thu Aug 28 10:45:20 2008 From: dan3857 at yahoo.com (Dan) Date: Wed, 27 Aug 2008 17:45:20 -0700 (PDT) Subject: 5.1p1 doesn't work, 5.0p1 works fine In-Reply-To: Message-ID: <656808.32541.qm@web34301.mail.mud.yahoo.com> > Maybe your router is choking on the > no-more-sessions at openssh.com request. > Try commenting out this block in ssh.c:ssh_session2() > > > /* If we don't expect to open a new > session, then disallow it */ > > if (options.control_master == SSHCTL_MASTER_NO) > { > > debug("Requesting > no-more-sessions at openssh.com"); > > packet_start(SSH2_MSG_GLOBAL_REQUEST); > > > packet_put_cstring("no-more-sessions at openssh.com"); > > packet_put_char(0); > > packet_send(); > > } This is the cause of the problem! I can connect fine to my APC UPS now this is commented out. With the router, right after the password is entered, there's this error message: PTY allocation request failed on channel 0 Then I get the router prompt, and everything is fine from then on. I suspect this issue will come up more often as more people use 5.1p1 with vendor-supplied sshd servers in various pieces of hardware. -Dan From djm at mindrot.org Thu Aug 28 06:45:20 2008 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Aug 2008 06:45:20 +1000 (EST) Subject: 5.1p1 doesn't work, 5.0p1 works fine In-Reply-To: <656808.32541.qm@web34301.mail.mud.yahoo.com> References: <656808.32541.qm@web34301.mail.mud.yahoo.com> Message-ID: On Wed, 27 Aug 2008, Dan wrote: > This is the cause of the problem! I can connect fine to my APC UPS now > this is commented out. With the router, right after the password is > entered, there's this error message: > > PTY allocation request failed on channel 0 > > Then I get the router prompt, and everything is fine from then on. > > I suspect this issue will come up more often as more people use 5.1p1 > with vendor-supplied sshd servers in various pieces of hardware. You should complain to your vendor, they are violating the specification. >From rfc4254, section 4 "Global requests": > If the recipient does not recognize or support the request, it simply > responds with SSH_MSG_REQUEST_FAILURE. What server identification does your UPS report? Look for a line like the following in your "ssh -v" output: debug1: Remote protocol version 1.99, remote software version OpenSSH_5.1 -d From dan3857 at yahoo.com Thu Aug 28 13:33:35 2008 From: dan3857 at yahoo.com (Dan) Date: Wed, 27 Aug 2008 20:33:35 -0700 (PDT) Subject: 5.1p1 doesn't work, 5.0p1 works fine In-Reply-To: Message-ID: <841719.267.qm@web34303.mail.mud.yahoo.com> > You should complain to your vendor, they are violating the > specification. > From rfc4254, section 4 "Global requests": > > > If the recipient does not recognize or support the > request, it simply > > responds with SSH_MSG_REQUEST_FAILURE. > > What server identification does your UPS report? Look for a > line like > the following in your "ssh -v" output: My UPS says this: debug1: Remote protocol version 2.0, remote software version cryptlib My router says this: debug1: Remote protocol version 2.0, remote software version NetScreen -Dan From gert at greenie.muc.de Thu Aug 28 16:44:17 2008 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 28 Aug 2008 08:44:17 +0200 Subject: 5.1p1 doesn't work, 5.0p1 works fine In-Reply-To: <841719.267.qm@web34303.mail.mud.yahoo.com> References: <841719.267.qm@web34303.mail.mud.yahoo.com> Message-ID: <20080828064417.GE233@greenie.muc.de> Hi, On Wed, Aug 27, 2008 at 08:33:35PM -0700, Dan wrote: > My router says this: > debug1: Remote protocol version 2.0, remote software version NetScreen Oh yes. Both NetScreen and Cisco are known for very much sub-standard SSH implementations :-( gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From rebel at atrey.karlin.mff.cuni.cz Thu Aug 28 18:22:07 2008 From: rebel at atrey.karlin.mff.cuni.cz (Michal Svec) Date: Thu, 28 Aug 2008 10:22:07 +0200 (CEST) Subject: [PATCH] Re: SSH_RSA_MINIMUM_MODULUS_SIZE In-Reply-To: References: Message-ID: On Thu, 28 Aug 2008, Damien Miller wrote: >> trying again, with a patch now (only for the client). >> >> Currently it's not possible to change this without recompiling so any way to >> prevent that would do and command line seems to be the easiest. >> >> Would something like this be acceptable? > > No, we don't want a proliferation of config options. Hmm, other ways how to do this are an option in the config file or environment variable. Would either of those would be better? I don't see any other way, currently one has to patch&recompile openssh each time he wants to update to a new version, that's far from optimal. Michal From apb at cequrux.com Thu Aug 28 18:38:20 2008 From: apb at cequrux.com (Alan Barrett) Date: Thu, 28 Aug 2008 10:38:20 +0200 Subject: SSH Command Line Password Support In-Reply-To: References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> Message-ID: <20080828083820.GC2874@apb-laptoy.apb.alt.za> On Thu, 28 Aug 2008, Damien Miller wrote: > [old SSH_ASKPASS proposals:] > > http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2 > > https://bugzilla.mindrot.org/show_bug.cgi?id=69 > > I think we should do something like this, but I remember having some > issues with the user-interface. I don't like having new environment variables like WHEN_TO_USE_SSH_ASKPASS="always" or ALWAYS_USE_SSH_ASKPASS="yes" or any other variations on this theme. I'd prefer to see ssh simply use SSH_ASKPASS all the time regardless of whether or not there's a DISPLAY or a tty. If the user wants conditional behaviour, they can set SSH_ASKPASS to point to a script that does whatever tests they like when it is invoked, or they can use a script to conditionally set SSH_ASKPASS to different values before they invoke ssh. Alternatively, you could put all the complex policy like "use SSH_ASKPASS if foo and not bar" into the configuration file, and let SSH_ASKPASS continue to be the only environment variable related to this issue. The main thing is that I want no more than one environment variable for this. --apb (Alan Barrett) From jmknoble at pobox.com Fri Aug 29 05:08:18 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 28 Aug 2008 15:08:18 -0400 Subject: SSH Command Line Password Support In-Reply-To: <20080828083820.GC2874@apb-laptoy.apb.alt.za> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> <20080828083820.GC2874@apb-laptoy.apb.alt.za> Message-ID: <20080828190818.GB13711@crawfish.ais.com> Circa 2008-08-28 04:38 dixit Alan Barrett: : On Thu, 28 Aug 2008, Damien Miller wrote: : > [old SSH_ASKPASS proposals:] : > > http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2 : > > https://bugzilla.mindrot.org/show_bug.cgi?id=69 : > : > I think we should do something like this, but I remember having some : > issues with the user-interface. : : I don't like having new environment variables like : WHEN_TO_USE_SSH_ASKPASS="always" or ALWAYS_USE_SSH_ASKPASS="yes" or : any other variations on this theme. I'd prefer to see ssh simply use : SSH_ASKPASS all the time regardless of whether or not there's a DISPLAY : or a tty. If the user wants conditional behaviour, they can set : SSH_ASKPASS to point to a script that does whatever tests they like when : it is invoked, or they can use a script to conditionally set SSH_ASKPASS : to different values before they invoke ssh. : : Alternatively, you could put all the complex policy like "use : SSH_ASKPASS if foo and not bar" into the configuration file, and let : SSH_ASKPASS continue to be the only environment variable related to : this issue. The main thing is that I want no more than one environment : variable for this. Disclaimer: I'm the creator of x11-ssh-askpass . I believe the best way to handle this is with an ssh_config file option (which can then also be used on the command line). ssh-add(1) and ssh-agent(1) also use SSH_ASKPASS and should use a command-line option, since they don't read ssh_config files. This allows for the greatest combination of flexibility and backward compatibility. For example: ssh -oUseSshAskpass=auto ssh -oUseSshAskpass=yes ssh -oUseSshAskpass=no "auto": the current method, and the default. "yes": ignore the presence or absence of a controlling terminal and a DISPLAY variable, and just use SSH_ASKPASS if it's set. "no": ignore SSH_ASKPASS; always prompt the terminal for a passphrase or confirmation (if no terminal, fail?). "ssh-agent" => UseSshAskpass=auto "ssh-agent -p" => UseSshAskpass=yes "ssh-agent -P" => UseSshAskpass=no "ssh-add" => UseSshAskpass=auto "ssh-add -p" => UseSshAskpass=yes "ssh-add -P" => UseSshAskpass=no Folks who expect the current way of doing things don't have to change anything. Folks who want something different can use the command-line or ssh_config options. Folks who want something fancy can use "UseSshAskpass=yes", create wrapper scripts for ssh-add(1) and ssh-agent(1), and set SSH_ASKPASS to a script which determines what to do, as Alan Barrett suggests. Comments? --jim -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From openssh at roumenpetrov.info Fri Aug 29 04:37:20 2008 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 28 Aug 2008 21:37:20 +0300 Subject: SSH Command Line Password Support In-Reply-To: <20080828083820.GC2874@apb-laptoy.apb.alt.za> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> <20080828083820.GC2874@apb-laptoy.apb.alt.za> Message-ID: <48B6F060.2090308@roumenpetrov.info> Alan Barrett wrote: > On Thu, 28 Aug 2008, Damien Miller wrote: >> [old SSH_ASKPASS proposals:] >>> http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2 >>> https://bugzilla.mindrot.org/show_bug.cgi?id=69 >> I think we should do something like this, but I remember having some >> issues with the user-interface. > > I don't like having new environment variables like > WHEN_TO_USE_SSH_ASKPASS="always" or ALWAYS_USE_SSH_ASKPASS="yes" or > any other variations on this theme. I'd prefer to see ssh simply use > SSH_ASKPASS all the time regardless of whether or not there's a DISPLAY > or a tty. If the user wants conditional behaviour, they can set > SSH_ASKPASS to point to a script that does whatever tests they like when > it is invoked, or they can use a script to conditionally set SSH_ASKPASS > to different values before they invoke ssh. > > Alternatively, you could put all the complex policy like "use > SSH_ASKPASS if foo and not bar" into the configuration file, and let > SSH_ASKPASS continue to be the only environment variable related to > this issue. The main thing is that I want no more than one environment > variable for this. > > --apb (Alan Barrett) Sounds good if environment variable SSH_ASKPASS is emply or a value like default, tty, internal, none to be used password prompt from ssh otherwise client(ssh) to try to get password from specified program. Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From mouring at eviladmin.org Fri Aug 29 06:24:22 2008 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 28 Aug 2008 15:24:22 -0500 (CDT) Subject: SSH Command Line Password Support In-Reply-To: <20080828190818.GB13711@crawfish.ais.com> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> <20080828083820.GC2874@apb-laptoy.apb.alt.za> <20080828190818.GB13711@crawfish.ais.com> Message-ID: On Thu, 28 Aug 2008, Jim Knoble wrote: > Circa 2008-08-28 04:38 dixit Alan Barrett: > > : On Thu, 28 Aug 2008, Damien Miller wrote: > : > [old SSH_ASKPASS proposals:] > : > > http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2 > : > > https://bugzilla.mindrot.org/show_bug.cgi?id=69 > : > > : > I think we should do something like this, but I remember having some > : > issues with the user-interface. > : > : I don't like having new environment variables like > : WHEN_TO_USE_SSH_ASKPASS="always" or ALWAYS_USE_SSH_ASKPASS="yes" or > : any other variations on this theme. I'd prefer to see ssh simply use > : SSH_ASKPASS all the time regardless of whether or not there's a DISPLAY > : or a tty. If the user wants conditional behaviour, they can set > : SSH_ASKPASS to point to a script that does whatever tests they like when > : it is invoked, or they can use a script to conditionally set SSH_ASKPASS > : to different values before they invoke ssh. > : > : Alternatively, you could put all the complex policy like "use > : SSH_ASKPASS if foo and not bar" into the configuration file, and let > : SSH_ASKPASS continue to be the only environment variable related to > : this issue. The main thing is that I want no more than one environment > : variable for this. > > Disclaimer: I'm the creator of x11-ssh-askpass > . > > I believe the best way to handle this is with an ssh_config file option > (which can then also be used on the command line). ssh-add(1) and > ssh-agent(1) also use SSH_ASKPASS and should use a command-line option, > since they don't read ssh_config files. > > This allows for the greatest combination of flexibility and backward > compatibility. For example: > > ssh -oUseSshAskpass=auto > ssh -oUseSshAskpass=yes > ssh -oUseSshAskpass=no > > "auto": the current method, and the default. > > "yes": ignore the presence or absence of a controlling terminal > and a DISPLAY variable, and just use SSH_ASKPASS if it's set. > > "no": ignore SSH_ASKPASS; always prompt the terminal for a > passphrase or confirmation (if no terminal, fail?). > To me the above makes no sense at a glance. I'd rather see "UseSshAskpassWithoutX11 {Yes/No}" or something that clearly defines that when using SSH_ASKPASS what the behavior one is to expect from it. Only advantage yours provides is if someone wants to disable it period regardless of DISPLAY= and SSH_ASKPASS= being set (which Problem is I can't come up with something that makes good sense at a glance. "AUTO" to me makes no sense. Why would "AUTO" and "YES" (without reading a manpage) be different. I guess I could see the syntax being "UseAskpass {X11,Yes,No}" .. I hate pinning stuff to X because that may not be the case for Windows or Mac. However, seeing our use of it all over the ssh_config it make it consistant. Besides that the rest of the proposal is fine to me. BTW.. Thinking through this.. Had we been discussing implementing this today a new feature I'd be arguing that it would be SSH_ASKPASS program's job to care if DISPLAY= was set, but legacy issue trump this choice these days. - Ben From lists-ssh at jay.fm Fri Aug 29 06:34:11 2008 From: lists-ssh at jay.fm (Jay Levitt) Date: Thu, 28 Aug 2008 16:34:11 -0400 Subject: HostName not quite working as expected? Message-ID: <48B70BC3.3060607@jay.fm> Setting up a few hosts in a small domain, I thought I'd save keystrokes by defining ssh_config aliases for their non-canonicalized names. For example: Host myhost HostName myhost.example.com Host *.example.com Port 23 ... I would have expected that "ssh myhost" would then start a session on port 23 (instead of 22). And I've seen blog/list posts that suggest the same (which, of course, I can't find now), as a workaround for "Host" entries not canonicalizing via DNS. But that's not what happens. "ssh myhost" correctly connects to myhost.example.com, but doesn't pick up any of the *.example.com host configuration. Likewise adding: Host myhost.example.com Port 23 it still connects on port 22. Is this the intended behavior? It seems like a bug to me, but it's still present in the 20080829 5.1 snapshot, and nobody's ever mentioned it before. Maybe it's just something that could be documented better? Jay Levitt From djm at mindrot.org Fri Aug 29 00:40:57 2008 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Aug 2008 00:40:57 +1000 (EST) Subject: [PATCH] Re: SSH_RSA_MINIMUM_MODULUS_SIZE In-Reply-To: References: Message-ID: On Thu, 28 Aug 2008, Michal Svec wrote: > Hmm, other ways how to do this are an option in the config file or > environment variable. Would either of those would be better? > > I don't see any other way, currently one has to patch&recompile openssh > each time he wants to update to a new version, that's far from optimal. Your needs are special - the vast majority of OpenSSH users will never need to change this setting. Therefore a compile-time option is appropriate. -d From djm at mindrot.org Fri Aug 29 00:47:53 2008 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Aug 2008 00:47:53 +1000 (EST) Subject: HostName not quite working as expected? In-Reply-To: <48B70BC3.3060607@jay.fm> References: <48B70BC3.3060607@jay.fm> Message-ID: On Thu, 28 Aug 2008, Jay Levitt wrote: > I would have expected that "ssh myhost" would then start a session on > port 23 (instead of 22). And I've seen blog/list posts that suggest the > same (which, of course, I can't find now), as a workaround for "Host" > entries not canonicalizing via DNS. ... > Is this the intended behavior? It seems like a bug to me, but it's > still present in the 20080829 5.1 snapshot, and nobody's ever mentioned > it before. Maybe it's just something that could be documented better? The behaviour is intended and documented. From ssh_config(5): > Host Restricts the following declarations (up to the next Host key- > word) to be only for those hosts that match one of the patterns > given after the keyword. If more than one pattern is provided, > they should be separated by whitespace. A single `*' as a pat- > tern can be used to provide global defaults for all hosts. The > host is the hostname argument given on the command line (i.e. the > name is not converted to a canonicalized host name before match- > ing). -d From djm at mindrot.org Fri Aug 29 03:55:11 2008 From: djm at mindrot.org (Damien Miller) Date: Fri, 29 Aug 2008 03:55:11 +1000 (EST) Subject: SSH Command Line Password Support In-Reply-To: <20080828190818.GB13711@crawfish.ais.com> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> <20080828083820.GC2874@apb-laptoy.apb.alt.za> <20080828190818.GB13711@crawfish.ais.com> Message-ID: On Thu, 28 Aug 2008, Jim Knoble wrote: > Disclaimer: I'm the creator of x11-ssh-askpass > . > > I believe the best way to handle this is with an ssh_config file option > (which can then also be used on the command line). ssh-add(1) and > ssh-agent(1) also use SSH_ASKPASS and should use a command-line option, > since they don't read ssh_config files. > > This allows for the greatest combination of flexibility and backward > compatibility. For example: > > ssh -oUseSshAskpass=auto > ssh -oUseSshAskpass=yes > ssh -oUseSshAskpass=no > > "auto": the current method, and the default. > > "yes": ignore the presence or absence of a controlling terminal > and a DISPLAY variable, and just use SSH_ASKPASS if it's set. > > "no": ignore SSH_ASKPASS; always prompt the terminal for a > passphrase or confirmation (if no terminal, fail?). > > "ssh-agent" => UseSshAskpass=auto > "ssh-agent -p" => UseSshAskpass=yes > "ssh-agent -P" => UseSshAskpass=no > > "ssh-add" => UseSshAskpass=auto > "ssh-add -p" => UseSshAskpass=yes > "ssh-add -P" => UseSshAskpass=no > > Folks who expect the current way of doing things don't have to change > anything. Folks who want something different can use the command-line > or ssh_config options. Folks who want something fancy can use > "UseSshAskpass=yes", create wrapper scripts for ssh-add(1) and > ssh-agent(1), and set SSH_ASKPASS to a script which determines what to > do, as Alan Barrett suggests. Could you please attach this to https://bugzilla.mindrot.org/b/generalised-askpass ? I think it might need a little more specification of what each option does under various circumstances (tty/no-tty, DISPLAY/no-DISPLAY, etc.), but it is already a lot more likeable that the suggestions already there. Thanks, Damien From stuge-openssh-unix-dev at cdy.org Fri Aug 29 23:53:50 2008 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 29 Aug 2008 15:53:50 +0200 Subject: HostName not quite working as expected? In-Reply-To: <48B70BC3.3060607@jay.fm> References: <48B70BC3.3060607@jay.fm> Message-ID: <20080829135350.5842.qmail@cdy.org> Jay Levitt wrote: > as a workaround for "Host" entries not canonicalizing via DNS. By setting up DNS you could save keystrokes in all other apps too. //Peter From apb at cequrux.com Sat Aug 30 00:22:39 2008 From: apb at cequrux.com (Alan Barrett) Date: Fri, 29 Aug 2008 16:22:39 +0200 Subject: SSH Command Line Password Support In-Reply-To: <20080828190818.GB13711@crawfish.ais.com> References: <876324.11513.qm@web30706.mail.mud.yahoo.com> <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> <20080828083820.GC2874@apb-laptoy.apb.alt.za> <20080828190818.GB13711@crawfish.ais.com> Message-ID: <20080829142239.GA13113@apb-laptoy.apb.alt.za> On Thu, 28 Aug 2008, Jim Knoble wrote: > : > [old SSH_ASKPASS proposals:] > : > > http://marc.info/?l=openssh-unix-dev&m=116921620227593&w=2 > : > > https://bugzilla.mindrot.org/show_bug.cgi?id=69 > > I believe the best way to handle this is with an ssh_config file option > (which can then also be used on the command line). ssh-add(1) and > ssh-agent(1) also use SSH_ASKPASS and should use a command-line option, > since they don't read ssh_config files. Having to use command line options for ssh-add and ssh-agent may be inconvenient in some environments. It occurs to me that the policy on when to use SSH_ASKPASS could also be embedded in the variable itself, like this: SSH_ASKPASS="/path/to/script" # like today SSH_ASKPASS="always:/path/to/script" # use it regardless of DISPLAY or tty --apb (Alan Barrett) From jmknoble at pobox.com Sat Aug 30 05:11:14 2008 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 29 Aug 2008 15:11:14 -0400 Subject: SSH Command Line Password Support In-Reply-To: <20080829142239.GA13113@apb-laptoy.apb.alt.za> References: <867ia2963m.fsf@ds4.des.no> <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> <20080828083820.GC2874@apb-laptoy.apb.alt.za> <20080828190818.GB13711@crawfish.ais.com> <20080829142239.GA13113@apb-laptoy.apb.alt.za> Message-ID: <20080829191114.GD13711@crawfish.ais.com> [This comment also appears as https://bugzilla.mindrot.org/show_bug.cgi?id=69#c13 .] Circa 2008-08-29 10:22 dixit Alan Barrett: : Having to use command line options for ssh-add and ssh-agent may be : inconvenient in some environments. : : It occurs to me that the policy on when to use SSH_ASKPASS : could also be embedded in the variable itself, like this: : : SSH_ASKPASS="/path/to/script" # like today : SSH_ASKPASS="always:/path/to/script" # use it regardless of DISPLAY or tty Alan's propoasl is a much more elegant solution than the one i proposed. In case it's not obvious, there are 3 possible states: (1) Current behavior (depends on whether DISPLAY is set and there is a controlling tty): SSH_ASKPASS="/path/to/file" (2) Always use SSH_ASKPASS, ignoring whether DISPLAY is set and whether a controlling tty exists: SSH_ASKPASS="always:/path/to/file" (3) Always prompt on the tty, unless there isn't one, in which case, fail if a passphrase or confirmation is required: SSH_ASKPASS="", or (SSH_ASKPASS is unset, i.e., not present in environment) The third state is not explicit in Alan's comment. States (1) and (3) are both current behavior, thus they are completely backward compatible with current implementations. State (2) requires command-line options for ssh-add or ssh-agent. Nice work, Alan. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From gert at greenie.muc.de Sat Aug 30 05:41:26 2008 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 29 Aug 2008 21:41:26 +0200 Subject: SSH Command Line Password Support In-Reply-To: <20080829191114.GD13711@crawfish.ais.com> References: <87y72itrl7.fsf@squeak.fifthhorseman.net> <20080827185507.GD233@greenie.muc.de> <87iqtmkusk.fsf@squeak.fifthhorseman.net> <20080828083820.GC2874@apb-laptoy.apb.alt.za> <20080828190818.GB13711@crawfish.ais.com> <20080829142239.GA13113@apb-laptoy.apb.alt.za> <20080829191114.GD13711@crawfish.ais.com> Message-ID: <20080829194126.GW233@greenie.muc.de> Hi, On Fri, Aug 29, 2008 at 03:11:14PM -0400, Jim Knoble wrote: > (2) Always use SSH_ASKPASS, ignoring whether DISPLAY is set and whether > a controlling tty exists: > > SSH_ASKPASS="always:/path/to/file" Seconded. I find this elegant and would love to see it :-) (As of now, I'm travelling too much at unpractical night times to be able to code much - if nobody else volunteers before mid September, I might give it a go. Shouldn't be so hard, actually). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From imorgan at nas.nasa.gov Sat Aug 30 10:32:09 2008 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 29 Aug 2008 17:32:09 -0700 Subject: Exiting ssh when MaxSessions=0 Message-ID: <20080830003209.GA6447@linux55.nas.nasa.gov> Hi, I've been experimenting with MaxSessions=0 in the sshd_config and have encountered one unfortunate problem. Once the client authenticates to the server, it ceases to respond to keyboard input. At first glance, it looks like the client is in a hung state and does not time out. If port forwarding was requested on the command-line and the server accepts the request, that continues to work. But the tilde escapes (and ^C) do not work. Apparently, you have to kill the session from another terminal. Once the session is killed, any buffered input is handled by the shell. In cases where you know the server will have MaxSessions=0, this is not a huge issue; you just have to remember to use the -f option. It is a bit unfortunate if you forget to use -f. It would be nice if ~. worked in this situation. I suppose ~C would also be nice in order to add port forwardings after the fact. I'm not sure if it would be problematic to add such support. -- Iain Morgan From djm at mindrot.org Sat Aug 30 05:30:11 2008 From: djm at mindrot.org (Damien Miller) Date: Sat, 30 Aug 2008 05:30:11 +1000 (EST) Subject: Exiting ssh when MaxSessions=0 In-Reply-To: <20080830003209.GA6447@linux55.nas.nasa.gov> References: <20080830003209.GA6447@linux55.nas.nasa.gov> Message-ID: On Fri, 29 Aug 2008, Iain Morgan wrote: > Hi, > > I've been experimenting with MaxSessions=0 in the sshd_config and have > encountered one unfortunate problem. Once the client authenticates to > the server, it ceases to respond to keyboard input. > > At first glance, it looks like the client is in a hung state and does > not time out. If port forwarding was requested on the command-line and > the server accepts the request, that continues to work. But the tilde > escapes (and ^C) do not work. Apparently, you have to kill the session > from another terminal. > > Once the session is killed, any buffered input is handled by the shell. > > In cases where you know the server will have MaxSessions=0, this is not > a huge issue; you just have to remember to use the -f option. It is a > bit unfortunate if you forget to use -f. > > It would be nice if ~. worked in this situation. I suppose ~C would also > be nice in order to add port forwardings after the fact. I'm not sure if > it would be problematic to add such support. Yes, this is a bug. I think this patch fixes it, but I need to think though the consequences more: Index: channels.c =================================================================== RCS file: /var/cvs/openssh/channels.c,v retrieving revision 1.273 diff -u -p -r1.273 channels.c --- channels.c 16 Jul 2008 12:42:06 -0000 1.273 +++ channels.c 29 Aug 2008 19:25:04 -0000 @@ -2311,8 +2311,8 @@ channel_input_open_failure(int type, u_i xfree(lang); } packet_check_eom(); - /* Free the channel. This will also close the socket. */ - channel_free(c); + /* Schedule the channel for cleanup/deletion. */ + chan_mark_dead(c); } /* ARGSUSED */ The difference if you are curious, is that chan_mark_dead() will schedule the channel for asynchronous cleanup, via channel_garbage_collect(). That path runs the channel->detach_user callback which is what we rely on to determine that our main session channel has exited. channel_free() doesn't run any callbacks, so we never noticed that the session channel went away. -d From dtucker at zip.com.au Sat Aug 30 13:03:16 2008 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 30 Aug 2008 13:03:16 +1000 Subject: Exiting ssh when MaxSessions=0 In-Reply-To: References: <20080830003209.GA6447@linux55.nas.nasa.gov> Message-ID: <48B8B874.4070907@zip.com.au> Damien Miller wrote: > On Fri, 29 Aug 2008, Iain Morgan wrote: > >> Hi, >> >> I've been experimenting with MaxSessions=0 in the sshd_config and have >> encountered one unfortunate problem. Once the client authenticates to >> the server, it ceases to respond to keyboard input. >> >> At first glance, it looks like the client is in a hung state and does >> not time out. If port forwarding was requested on the command-line and >> the server accepts the request, that continues to work. But the tilde >> escapes (and ^C) do not work. Apparently, you have to kill the session >> from another terminal. >> >> Once the session is killed, any buffered input is handled by the shell. >> >> In cases where you know the server will have MaxSessions=0, this is not >> a huge issue; you just have to remember to use the -f option. It is a >> bit unfortunate if you forget to use -f. As a workaround if you need this behaviour: you can set "ForceCommand /bin/true" instead of "MaxSessions 0". This will allow the channel requests to succeed without letting the user actually do anything. >> It would be nice if ~. worked in this situation. I suppose ~C would also >> be nice in order to add port forwardings after the fact. I'm not sure if >> it would be problematic to add such support. > > Yes, this is a bug. I think this patch fixes it, but I need to think > though the consequences more: > > Index: channels.c > =================================================================== > RCS file: /var/cvs/openssh/channels.c,v > retrieving revision 1.273 > diff -u -p -r1.273 channels.c > --- channels.c 16 Jul 2008 12:42:06 -0000 1.273 > +++ channels.c 29 Aug 2008 19:25:04 -0000 > @@ -2311,8 +2311,8 @@ channel_input_open_failure(int type, u_i > xfree(lang); > } > packet_check_eom(); > - /* Free the channel. This will also close the socket. */ > - channel_free(c); > + /* Schedule the channel for cleanup/deletion. */ > + chan_mark_dead(c); > } > > /* ARGSUSED */ > > The difference if you are curious, is that chan_mark_dead() will schedule > the channel for asynchronous cleanup, via channel_garbage_collect(). > That path runs the channel->detach_user callback which is what we rely > on to determine that our main session channel has exited. > > channel_free() doesn't run any callbacks, so we never noticed that the > session channel went away. -- 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.