From scott_n at xypro.com Tue Mar 1 10:59:56 2011 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 28 Feb 2011 15:59:56 -0800 Subject: Anyone else at der.hans's talk at SCALE? Message-ID: <78DD71C304F38B41885A242996B96F730291CD4C@xyservd.XYPRO-23.LOCAL> Just curious. ---- Scott Neugroschl XYPRO Technology Corporation scott_n at xypro.com 805-583-2874 From ludek.h at gmail.com Thu Mar 3 10:57:19 2011 From: ludek.h at gmail.com (Ludek Hlavacek) Date: Thu, 03 Mar 2011 00:57:19 +0100 Subject: sshd doesn't accept -c option Message-ID: <4D6ED95F.80400@gmail.com> Hi, I was testing host key signing when I came across problem with adding certificates using command line. Running /usr/sbin/sshd -c certfile returns sshd: illegal option -- c OpenSSH_5.8p1-hpn13v10, OpenSSL 1.0.0d 8 Feb 2011 usage: sshd [-46DdeiqTt] [-b bits] [-C connection_spec] [-c host_cert_file] [-f config_file] [-g login_grace_time] [-h host_key_file] [-k key_gen_time] [-o option] [-p port] [-u len] In cvs log I found, that certificate support was introduced to sshd.c in revision 1.373 but the optstring argument of getopt function was not changed accordingly. -- L.H. From cjwatson at debian.org Fri Mar 4 01:31:58 2011 From: cjwatson at debian.org (Colin Watson) Date: Thu, 3 Mar 2011 14:31:58 +0000 (GMT) Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110223163821.GA11143@orenhe-laptop> Message-ID: <20110303143158.DF8F73E4F12@sarantium.pelham.vpn.ucam.org> On Wed, Feb 23, 2011 at 04:40:00PM +0000, Oren Held wrote: >I've researched it a bit deeper. Surprisingly it's not a matter of which cipher to >choose, but of *how long the list of ciphers is*. I'll explain: >Doesn't work: >-c 'aes128-ctr' and 94 commas (i.e. -c 'aes128-ctr,,,,,,,,,,,,,,,,,,' etc), >Does work: >-c 'aes128-ctr' and 95 commas > >Now the number above varies. On my home computer it was 105 commas vs. 104 >commas. So eventually I bet it has to do with SSH packet size. For instance in >my place, according to Wireshark, SSH "Client: Key Exchange Init" packet length >is 1044+10(padding) in the bad case, 1036+4 in the good case. What are the MTU values on the relevant network interfaces on the client and the server? -- Colin Watson [cjwatson at debian.org] From oren at held.org.il Fri Mar 4 03:18:42 2011 From: oren at held.org.il (Oren Held) Date: Thu, 3 Mar 2011 18:18:42 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110303143158.DF8F73E4F12@sarantium.pelham.vpn.ucam.org> References: <20110223163821.GA11143@orenhe-laptop> <20110303143158.DF8F73E4F12@sarantium.pelham.vpn.ucam.org> Message-ID: <20110303161840.GA12289@orenhe-laptop> On Thu, Mar 03, 2011 at 02:31:58PM +0000, Colin Watson wrote: > On Wed, Feb 23, 2011 at 04:40:00PM +0000, Oren Held wrote: > >I've researched it a bit deeper. Surprisingly it's not a matter of which cipher to > >choose, but of *how long the list of ciphers is*. I'll explain: > >Doesn't work: > >-c 'aes128-ctr' and 94 commas (i.e. -c 'aes128-ctr,,,,,,,,,,,,,,,,,,' etc), > >Does work: > >-c 'aes128-ctr' and 95 commas > > > >Now the number above varies. On my home computer it was 105 commas vs. 104 > >commas. So eventually I bet it has to do with SSH packet size. For instance in > >my place, according to Wireshark, SSH "Client: Key Exchange Init" packet length > >is 1044+10(padding) in the bad case, 1036+4 in the good case. > > What are the MTU values on the relevant network interfaces on the client > and the server? MTU is 1500 on both client and server, in my case. From vdanen at redhat.com Sat Mar 5 03:05:32 2011 From: vdanen at redhat.com (Vincent Danen) Date: Fri, 4 Mar 2011 09:05:32 -0700 Subject: remote DoS in sftp via crafted glob expressions (CVE-2010-4755) Message-ID: <20110304160532.GB2002@redhat.com> Hi folks. We were made aware of a MITRE CVE assignment on OpenSSH for a remote DoS in sftp, described as: The (1) remote_glob function in sftp-glob.c and the (2) process_put function in sftp.c in OpenSSH 5.8 and earlier, as used in FreeBSD 7.3 and 8.1, NetBSD 5.0.2, OpenBSD 4.7, and other products, allow remote authenticated users to cause a denial of service (CPU and memory consumption) via crafted glob expressions that do not match any pathnames, as demonstrated by glob expressions in SSH_FXP_STAT requests to an sftp daemon, a different vulnerability than CVE-2010-2632. This looks to have been corrected in NetBSD, but I don't know how portable their fix is. Here are some references: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4755 http://securityreason.com/achievement_securityalert/89 http://cxib.net/stuff/glob-0day.c http://securityreason.com/exploitalert/9223 http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp-glob.c#rev1.13.12.1 http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp.c#rev1.21.6.1 http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2010-008.txt.asc https://bugzilla.redhat.com/show_bug.cgi?id=681698 I did try on a Red Hat Enterprise Linux 6 system and did see that sftp-server and sshd were consistently consuming about 20% and 25% CPU respectively for the one crafted ls command: sftp> ls {..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*cx It did not prevent other sftp/ssh logins while this was running, but I imagine a few of these commands running in parallel would tie up quite a bit of CPU. I'm bringing this up because I've not seen any mention of this on the list, so I'm not sure as to whether or not upstream is aware of this. It certainly isn't something critical, but I would think it deserves a fix. Note that the only reason why I would even consider this moderately security-relevant is that you can restrict access to a system to sftp-only using forced commands; if this was not possible and the user had ssh/shell access guaranteed, then they could "DoS" the system just as easily a hundred other ways. Thanks. -- Vincent Danen / Red Hat Security Response Team From djm at mindrot.org Sun Mar 6 09:00:47 2011 From: djm at mindrot.org (Damien Miller) Date: Sun, 6 Mar 2011 09:00:47 +1100 (EST) Subject: remote DoS in sftp via crafted glob expressions (CVE-2010-4755) In-Reply-To: <20110304160532.GB2002@redhat.com> References: <20110304160532.GB2002@redhat.com> Message-ID: The attack is on the client by a malicious server - a client can't DoS a server with this bug. We generally don't put much effort into making the client resilient to DoS from a hostile server. -d On Fri, 4 Mar 2011, Vincent Danen wrote: > Hi folks. > > We were made aware of a MITRE CVE assignment on OpenSSH for a remote DoS > in sftp, described as: > > The (1) remote_glob function in sftp-glob.c and the (2) process_put > function in sftp.c in OpenSSH 5.8 and earlier, as used in FreeBSD 7.3 > and 8.1, NetBSD 5.0.2, OpenBSD 4.7, and other products, allow remote > authenticated users to cause a denial of service (CPU and memory > consumption) via crafted glob expressions that do not match any > pathnames, as demonstrated by glob expressions in SSH_FXP_STAT > requests to an sftp daemon, a different vulnerability than > CVE-2010-2632. > > > This looks to have been corrected in NetBSD, but I don't know how > portable their fix is. Here are some references: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4755 > http://securityreason.com/achievement_securityalert/89 > http://cxib.net/stuff/glob-0day.c > http://securityreason.com/exploitalert/9223 > http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp-glob.c#rev1.13.12.1 > http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp.c#rev1.21.6.1 > http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2010-008.txt.asc > https://bugzilla.redhat.com/show_bug.cgi?id=681698 > > I did try on a Red Hat Enterprise Linux 6 system and did see that > sftp-server and sshd were consistently consuming about 20% and 25% CPU > respectively for the one crafted ls command: > > sftp> ls > {..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*cx > > It did not prevent other sftp/ssh logins while this was running, but I > imagine a few of these commands running in parallel would tie up quite a > bit of CPU. > > I'm bringing this up because I've not seen any mention of this on the > list, so I'm not sure as to whether or not upstream is aware of this. > > It certainly isn't something critical, but I would think it deserves a > fix. > > Note that the only reason why I would even consider this moderately > security-relevant is that you can restrict access to a system to > sftp-only using forced commands; if this was not possible and the user > had ssh/shell access guaranteed, then they could "DoS" the system just > as easily a hundred other ways. > > Thanks. > > -- > Vincent Danen / Red Hat Security Response Team > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Sun Mar 6 09:04:43 2011 From: djm at mindrot.org (Damien Miller) Date: Sun, 6 Mar 2011 09:04:43 +1100 (EST) Subject: remote DoS in sftp via crafted glob expressions (CVE-2010-4755) In-Reply-To: <20110304160532.GB2002@redhat.com> References: <20110304160532.GB2002@redhat.com> Message-ID: On Fri, 4 Mar 2011, Vincent Danen wrote: > Hi folks. > > We were made aware of a MITRE CVE assignment on OpenSSH for a remote DoS > in sftp, described as: > > The (1) remote_glob function in sftp-glob.c and the (2) process_put > function in sftp.c in OpenSSH 5.8 and earlier, as used in FreeBSD 7.3 > and 8.1, NetBSD 5.0.2, OpenBSD 4.7, and other products, allow remote > authenticated users to cause a denial of service (CPU and memory > consumption) via crafted glob expressions that do not match any > pathnames, as demonstrated by glob expressions in SSH_FXP_STAT > requests to an sftp daemon, a different vulnerability than > CVE-2010-2632. actually, the CVE description is nonsensical. sftp-server doesn't process globs in requests at all. All glob expansion is done by the client. So a user entering a malicious glob is DoSing their own end of the connection. -d From vdanen at redhat.com Tue Mar 8 05:20:14 2011 From: vdanen at redhat.com (Vincent Danen) Date: Mon, 7 Mar 2011 11:20:14 -0700 Subject: remote DoS in sftp via crafted glob expressions (CVE-2010-4755) In-Reply-To: References: <20110304160532.GB2002@redhat.com> Message-ID: <20110307182014.GD1875@redhat.com> * [2011-03-06 09:00:47 +1100] Damien Miller wrote: >The attack is on the client by a malicious server - a client can't DoS >a server with this bug. We generally don't put much effort into making >the client resilient to DoS from a hostile server. I'm confused. Why would this be an attack on the client? The client is the one putting the glob (the server isn't pushing this as far as I can see). I do see a CPU spike (and blocking on the ability to execute any subsequent commands) on the client, but I also see (excessive?) CPU usage on the host. Interestingly, subsequent sftp connections to the host, doing the same thing do not increase CPU usage significantly. Is this something you would be interested in disputing with MITRE over the CVE assignment? I see you also said: >actually, the CVE description is nonsensical. sftp-server doesn't >process globs in requests at all. All glob expansion is done by >the client. > >So a user entering a malicious glob is DoSing their own end of the >connection. Doing further testing, I'm inclined to agree with you. At best this is a client DoS, but they are doing it to themselves (but you implied malicious server above, so I'm not sure whether this should be considered a flaw from a malicious server and the description needs to be revised, or if this should be rejected outright since self-inflicted issues shouldn't really be considered security flaws). Thanks for the response, Damien. If you could clarify the malicious server bit you mentioned above, then I can engage with MITRE one way or the other. >On Fri, 4 Mar 2011, Vincent Danen wrote: > >> Hi folks. >> >> We were made aware of a MITRE CVE assignment on OpenSSH for a remote DoS >> in sftp, described as: >> >> The (1) remote_glob function in sftp-glob.c and the (2) process_put >> function in sftp.c in OpenSSH 5.8 and earlier, as used in FreeBSD 7.3 >> and 8.1, NetBSD 5.0.2, OpenBSD 4.7, and other products, allow remote >> authenticated users to cause a denial of service (CPU and memory >> consumption) via crafted glob expressions that do not match any >> pathnames, as demonstrated by glob expressions in SSH_FXP_STAT >> requests to an sftp daemon, a different vulnerability than >> CVE-2010-2632. >> >> >> This looks to have been corrected in NetBSD, but I don't know how >> portable their fix is. Here are some references: >> >> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4755 >> http://securityreason.com/achievement_securityalert/89 >> http://cxib.net/stuff/glob-0day.c >> http://securityreason.com/exploitalert/9223 >> http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp-glob.c#rev1.13.12.1 >> http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/src/crypto/dist/ssh/Attic/sftp.c#rev1.21.6.1 >> http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2010-008.txt.asc >> https://bugzilla.redhat.com/show_bug.cgi?id=681698 >> >> I did try on a Red Hat Enterprise Linux 6 system and did see that >> sftp-server and sshd were consistently consuming about 20% and 25% CPU >> respectively for the one crafted ls command: >> >> sftp> ls >> {..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*/{..,..,..}/*cx >> >> It did not prevent other sftp/ssh logins while this was running, but I >> imagine a few of these commands running in parallel would tie up quite a >> bit of CPU. >> >> I'm bringing this up because I've not seen any mention of this on the >> list, so I'm not sure as to whether or not upstream is aware of this. >> >> It certainly isn't something critical, but I would think it deserves a >> fix. >> >> Note that the only reason why I would even consider this moderately >> security-relevant is that you can restrict access to a system to >> sftp-only using forced commands; if this was not possible and the user >> had ssh/shell access guaranteed, then they could "DoS" the system just >> as easily a hundred other ways. >> >> Thanks. >> >> -- >> Vincent Danen / Red Hat Security Response Team >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Vincent Danen / Red Hat Security Response Team From dkg at fifthhorseman.net Tue Mar 8 06:08:43 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Mar 2011 14:08:43 -0500 Subject: Indicating context when asking the ssh-agent to use a key Message-ID: <4D752D3B.9050709@fifthhorseman.net> This e-mail is about thinking through some possible extensions to the ssh-agent communications protocol. When the ssh-agent receives a request to use one of the keys it holds, it gets no context information from the requesting system about what the key operation is to be used for. My own typical workflow (as a user who actively monitors and confirms the use of my keys by the ssh-agent) is to just correlate things by time. e.g. "i just did action X, so i expect key Y to be used right around now, so i'll say OK". If there was a way to communicate the context of the use to the agent, so that the agent could relay that to the user in whatever notification or confirmation it provides, it would seem like a Good Thing. If there was a way to do that with some measures of cryptographic reliability (e.g. so that a malicious client couldn't say "please make this signature for X" when it was actually intending to be used for Y), it would be even better. I'm not sure i understand how that could happen, though i'd be happy to consider proposals/suggestions. I suspect this would require at least an extension to the ssh-agent protocol, but i'm not sure where or how that would be done. Any thoughts on this? i just opened a bug report about this here, if anyone wants to contribute proposed patches/protocol suggestions: https://bugzilla.mindrot.org/show_bug.cgi?id=agent-context I'm happy to have a bigger-picture discussion here on the list, though. Is this a bad idea? a nice idea but unimplementable for some reason? is this already possible somehow? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From vinschen at redhat.com Tue Mar 8 06:29:30 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 7 Mar 2011 20:29:30 +0100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <4D5D1443.6050101@zip.com.au> References: <20110216102735.GB12486@orenhe-laptop> <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> Message-ID: <20110307192930.GB12138@calimero.vinschen.de> Hi Darren, On Feb 17 23:27, Darren Tucker wrote: > On 17/02/2011 10:34 PM, Corinna Vinschen wrote: > >As an additional datapoint, we had a couple of similar bug reports after > >I upgraded openssh in the Cygwin distro to 5.7p1 and then 5.8p1. One of > >them even comes with a set of debug output of working (5.6p1) and > >non-working (5.8p1) connection attempts: > [...] > >However, I tried with various older versions of SSH running on Cygwin, > >Linux and Solaris to connect from 5.8p1 myself, and I'm unable to > >reproduce this problem. > > Thanks for the extra info. I haven't been able to reproduce either. > I've tried building 5.5p1 and 4.3p1 against (locally built) OpenSSL > 0.9.6b and 0.9.8d. There seems to be some piece of the puzzle > missing... > > I diffed the working and non working clients, and one difference is: > debug1: sending SSH2_MSG_KEX_ECDH_INIT > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > > although I'm not sure that's significant since Oren's output had > SSH2_MSG_KEX_DH_GEX_GROUP. You could try forcing it with "ssh -vvv > -o KexAlgorithms=diffie-hellman-group-exchange-sha1 server" > > (aside: I now want to add OpenSSL's version output to the server > debug output) is there any progress in that matter? Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From djm at mindrot.org Tue Mar 8 07:59:43 2011 From: djm at mindrot.org (Damien Miller) Date: Tue, 8 Mar 2011 07:59:43 +1100 (EST) Subject: remote DoS in sftp via crafted glob expressions (CVE-2010-4755) In-Reply-To: <20110307182014.GD1875@redhat.com> References: <20110304160532.GB2002@redhat.com> <20110307182014.GD1875@redhat.com> Message-ID: On Mon, 7 Mar 2011, Vincent Danen wrote: > * [2011-03-06 09:00:47 +1100] Damien Miller wrote: > > > The attack is on the client by a malicious server - a client can't DoS > > a server with this bug. We generally don't put much effort into making > > the client resilient to DoS from a hostile server. > > I'm confused. Why would this be an attack on the client? The client is > the one putting the glob (the server isn't pushing this as far as I can > see). I do see a CPU spike (and blocking on the ability to execute any > subsequent commands) on the client, but I also see (excessive?) CPU > usage on the host. Sorry, I was incorrect above - the attack is purely client end. If there is additional CPU usage on the server then it is just from the client issuing more requests. > Interestingly, subsequent sftp connections to the host, doing the same > thing do not increase CPU usage significantly. > > Is this something you would be interested in disputing with MITRE over > the CVE assignment? Feel free to forward this email conversation. I don't understand why they don't contact the vendor to verify CVEs to begin with. > I see you also said: > > > actually, the CVE description is nonsensical. sftp-server doesn't > > process globs in requests at all. All glob expansion is done by > > the client. > > > > So a user entering a malicious glob is DoSing their own end of the > > connection. > > Doing further testing, I'm inclined to agree with you. At best this is > a client DoS, but they are doing it to themselves (but you implied > malicious server above, so I'm not sure whether this should be > considered a flaw from a malicious server and the description needs to > be revised, or if this should be rejected outright since self-inflicted > issues shouldn't really be considered security flaws). Here's a simple proof: [djm at mothra openssh]$ grep -l 'glob[(]' *.c sftp-glob.c sftp.c There are no glob calls in the server, so it can't be vulnerable to malicious glob patterns. -d From vdanen at redhat.com Tue Mar 8 08:07:59 2011 From: vdanen at redhat.com (Vincent Danen) Date: Mon, 7 Mar 2011 14:07:59 -0700 Subject: remote DoS in sftp via crafted glob expressions (CVE-2010-4755) In-Reply-To: References: <20110304160532.GB2002@redhat.com> <20110307182014.GD1875@redhat.com> Message-ID: <20110307210759.GJ1875@redhat.com> * [2011-03-08 07:59:43 +1100] Damien Miller wrote: >On Mon, 7 Mar 2011, Vincent Danen wrote: > >> * [2011-03-06 09:00:47 +1100] Damien Miller wrote: >> >> > The attack is on the client by a malicious server - a client can't DoS >> > a server with this bug. We generally don't put much effort into making >> > the client resilient to DoS from a hostile server. >> >> I'm confused. Why would this be an attack on the client? The client is >> the one putting the glob (the server isn't pushing this as far as I can >> see). I do see a CPU spike (and blocking on the ability to execute any >> subsequent commands) on the client, but I also see (excessive?) CPU >> usage on the host. > >Sorry, I was incorrect above - the attack is purely client end. If there >is additional CPU usage on the server then it is just from the client >issuing more requests. That makes sense. Thanks. >> Interestingly, subsequent sftp connections to the host, doing the same >> thing do not increase CPU usage significantly. >> >> Is this something you would be interested in disputing with MITRE over >> the CVE assignment? > >Feel free to forward this email conversation. I don't understand why they >don't contact the vendor to verify CVEs to begin with. I think it simply has to do with volume (I suspect it isn't feasible to try to initiate contact with all upstream vendors considering how much they have to deal with). >> I see you also said: >> >> > actually, the CVE description is nonsensical. sftp-server doesn't >> > process globs in requests at all. All glob expansion is done by >> > the client. >> > >> > So a user entering a malicious glob is DoSing their own end of the >> > connection. >> >> Doing further testing, I'm inclined to agree with you. At best this is >> a client DoS, but they are doing it to themselves (but you implied >> malicious server above, so I'm not sure whether this should be >> considered a flaw from a malicious server and the description needs to >> be revised, or if this should be rejected outright since self-inflicted >> issues shouldn't really be considered security flaws). > >Here's a simple proof: > >[djm at mothra openssh]$ grep -l 'glob[(]' *.c >sftp-glob.c >sftp.c > >There are no glob calls in the server, so it can't be vulnerable to >malicious glob patterns. Perfect. Thanks, Damien. I'm going to summarize this in our bug and then point it to MITRE (as well as this thread) so that it can be disputed. -- Vincent Danen / Red Hat Security Response Team From dyle at dyle.org Tue Mar 8 20:21:04 2011 From: dyle at dyle.org (dyle) Date: Tue, 08 Mar 2011 10:21:04 +0100 Subject: ssh 'connection reset by peer' problem since 5.8p1 Message-ID: #!/bin/hi Sorry to interfere, but finally I find someone talking about my problem. I encountered the very same problem with a mix of Gentoo/Ubuntu/Debian machines whereas I could not connect from my Gentoo Box (5.8p1) to any machine behind the firewall in the wild (Debian; 5.1p1). But connecting to a Ubuntu box right next to me within the very same subnet and then SSH from this very machine to a machine outside worked. I also could connect to any machine inside the subnet from my Gentoo/5.8p1. Then reducing the number of cypher-options on the client side by stating in /etc/ssh/ssh_config: --- 8< snip --- ... # Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc # MACs hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160 MACs hmac-md5,hmac-sha1,hmac-ripemd160 ... --- >8 snap --- worked like charm. I finally can SSH again to my machines behind the firewall. Thanks for this workaround. KR, Oliver From fburleigh at gmail.com Thu Mar 10 00:16:34 2011 From: fburleigh at gmail.com (Frank Burleigh) Date: Wed, 9 Mar 2011 08:16:34 -0500 Subject: OpenSSH upgrade 4.1p to 5.1p brings ssh_exchange_identification trouble Message-ID: I hurt myself in an upgrade. All was working well until a new requirement made sshd.config's MATCH ADDRESS clause essential. I'm hoping someone will recognize how these facts correlate with changes made in the openssh software. Facts: * SUSE Linux ES 10 SP2 x64 * Old openssh was 4.1p (from 2005)] * New openssh is 5.1p, installed using SLES's software management tools * No other software updated * Firewall allows port 22 from the client * hosts.allow had never been used -- it had no sshd rules Behavior changes: * Key exchange log in "ssh name at host" now fails (from OS X client) with ssh_exchange_identification complaint, other servers ok * On sshd 5.1p restart, server log shows - sshd listening on :: on port 22 (old version always said this) - sshd listening on 0.0.0.0 on port 22 (old version never said this) * Connect attempts produce DEBUG3 log activity, text not available to me right now -- I recall what looks like a process being forked. Troubleshooting I've tried: * Set logging to VERBOSE or DEBUG3 in sshd.config * Disabled firewall * sshd -t produces no complaints * Check ps aux -- I see maybe one sshd process * Enable PasswordAuthentication (try to eliminate the machine's host key as an issue) * Tried "sshd : ALL" and "sshd : ALL : ALLOW" in hosts.allow. - It's my impression hosts.allow changes take effect without needing a restart of anything. - hosts.deny has one active line, and says nothing about sshd. The sshd log shows *some* activity on connect attempts but nothing about *my account or key* -- looks like process and networking stuff. I can't tell if that activity is pre- or post-tcp_wrapper interrogation. I'm trying to learn *where* sshd gives up on my connect attempts. I'm obviously dead in the water without a direction. Any nudges toward a better path would be appreciated. From mbox at miguel.ramos.name Thu Mar 10 01:03:52 2011 From: mbox at miguel.ramos.name (Miguel Lopes Santos Ramos) Date: Wed, 09 Mar 2011 14:03:52 +0000 Subject: Match and ChallengeResponseAuthentication Message-ID: <1299679432.15766.23.camel@w500.local> Hi, I'd like to allow PAM authentication only from the local network, and from the Internet only allow public key authentication. A similar-enough problem has been discussed on this list previously: http://www.gossamer-threads.com/lists/openssh/dev/47179?search_string=match%20challengeresponseauthentication;#47179 More specifically, I would like to allow PAM authentication from the Internet only for users which I know use OPIE (that's because pam_opieaccess isn't flexible enough for this). That would be something like this: ChallengeResponseAuthentication no Match Address 10.0.0.0/8 ChallengeResponseAuthentication yes Match User miguel ChallengeResponseAuthentication yes However, ChallengeResponseAuthentication can't be used within Match, as was previously pointed out. Now, about the solutions in the other thread: - Damien Miller suggested patching sshd. That would be ok for me, but only if that's what makes the most sens: that is, my policy is too specific and useless or unadvisable to others. - Damien Miller also suggested turning off KbdInteractiveAuthentication inside match, and, - Darren Tucker suggested turning it off outside and on inside, But, I tried these options: a) ChallengeResponseAuthentication yes #KbdInteractiveAuthentication yes Match Address !10.0.0.0/8 KbdInteractiveAuthentication no - keyboard interactive auth from the Internet isn't prevented. b) ChallengeResponseAuthentication no KbdInteractiveAuthentication no Match Address 10.0.0.0/8 KbdInteractiveAuthentication yes Match User miguel KbdInteractiveAuthentication yes - from the Internet, the desired effect is obtained, when trying ssh -o PubkeyAuthentication=no user at example.com, I get: Permission denied (publickey) - from the local net, when trying ssh -o PubkeyAuthentication=no user at example.com, I get: Permission denied (publickey,keyboard-interactive) That's funny, keyboard-interactive is allowed, but I'm not asked for a password, obviously that must be because ChallengeResponseAuthentication is no, globally. c) ChallengeResponseAuthentication yes KbdInteractiveAuthentication no Match Address 10.0.0.0/8 KbdInteractiveAuthentication yes Match User miguel KbdInteractiveAuthentication yes - keyboard interactive auth from the Internet isn't prevented. So, I guess I'm left with patching sshd?? In everything else my sshd_config is set to defaults. Also, I'm on FreeBSD (8.2-PRERELEASE #2 with OpenSSH_5.4p1). Thanks for any pointers (including telling me that I shouldn't have that policy). -- Miguel Ramos PGP A006A14C From Klaus at Ethgen.de Tue Mar 15 02:15:40 2011 From: Klaus at Ethgen.de (Klaus Ethgen) Date: Mon, 14 Mar 2011 16:15:40 +0100 Subject: Problemes with ControlPersist Message-ID: <20110314151538.GA4962@ikki.ethgen.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, There seems to be just a bit to do with the latest openssh (5.8p1) and ControlPersist. I encountered two problems: 1. When I use ControlPersist in combination with ProxyCommand to reach a other host over that proxy I get the following message: Bad packet length 1397966893. Disconnecting: Paket corrupt When I fist ssh to the proxy, close the connection (that persists in background) and ssh to the target everything works well. 2. When I use cvs over ssh and use ControlPersist and ProxyCommand every ssh command will block at the end for exact the time I specify in ControlPersist. (Note that I have to start the proxy first like I described in the first issue.) For the later problem I think that maybe putting the persistent ssh in a separate process group would help. For the first problem I have no idea. But maybe the problems are the same. Regards Klaus Ethgen Ps. Please set me to Cc as I don't read the list. - -- Klaus Ethgen http://www.ethgen.ch/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEUAwUBTX4xGp+OKpjRpO3lAQqVYQf4zdD83MsXVugIXz0swidhbWZvM5R5zVGt b/nwl0DF0EWnu3NN8zeiq6Z+Wr3kr6X8aQ6FWqZ5ajuiTDAo1IrbIzePayRc1936 MmKdzYov2u0nT/RXgedNWB8BsU786mW+GSGSpASwAjLLsghZXXLxkCWKWBvJVNi/ UHxjg5QBcvwt0I3amzj3OZtrACHF9TNUdaX4nwFEeO1cA/MuvHTXP4kqvkYDR3W1 vBiA+RY1g6MT4d+OpE53FkRyGxGMGOf/8G7EGy6azJIxvCtfNiAi9EYNNLOw0qqY 2zN2MN+w7uf3B2J9EIpPvZ/pBuBx8ZGKdNlg7RBhE3CvuWTjhgXQ =zB+a -----END PGP SIGNATURE----- From scott_n at xypro.com Tue Mar 15 04:42:05 2011 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 14 Mar 2011 10:42:05 -0700 Subject: Problemes with ControlPersist In-Reply-To: <20110314151538.GA4962@ikki.ethgen.ch> References: <20110314151538.GA4962@ikki.ethgen.ch> Message-ID: <78DD71C304F38B41885A242996B96F730297F4A5@xyservd.XYPRO-23.LOCAL> Quoth Klaus Ethgen on Monday, March 14, 2011 8:16 AM > > There seems to be just a bit to do with the latest openssh (5.8p1) and > ControlPersist. I encountered two problems: > > 1. When I use ControlPersist in combination with ProxyCommand to reach > a > other host over that proxy I get the following message: > Bad packet length 1397966893. > Disconnecting: Paket corrupt > I'm not sure what's causing that error, but that packet length translates to 0x5353482D or "SSH-" From joachim at joachimschipper.nl Tue Mar 15 06:34:51 2011 From: joachim at joachimschipper.nl (Joachim Schipper) Date: Mon, 14 Mar 2011 20:34:51 +0100 Subject: Problemes with ControlPersist In-Reply-To: <20110314151538.GA4962@ikki.ethgen.ch> References: <20110314151538.GA4962@ikki.ethgen.ch> Message-ID: <20110314193450.GA4981@polymnia.joachimschipper.nl> On Mon, Mar 14, 2011 at 04:15:40PM +0100, Klaus Ethgen wrote: > There seems to be just a bit to do with the latest openssh (5.8p1) and > ControlPersist. I encountered two problems: > > 1. When I use ControlPersist in combination with ProxyCommand to reach a > other host over that proxy I get the following message: > Bad packet length 1397966893. > Disconnecting: Paket corrupt > > When I fist ssh to the proxy, close the connection (that persists in > background) and ssh to the target everything works well. I use this in .ssh/config, and it works for me (and has been working for a long time): Host * CheckHostIP yes ControlMaster auto ControlPath ~/.ssh/mux-%r@%h:%p ControlPersist 3m HashKnownHosts yes NoHostAuthenticationForLocalhost yes Protocol 2 Host ssh.cwi.nl ProxyCommand none StrictHostKeyChecking yes Host *.cwi.nl User schipper ProxyCommand ssh ssh.cwi.nl netcat %h %p This is on OpenBSD-current (OpenSSH_5.8, OpenSSL 1.0.0a 1 Jun 2010). What are you connecting to what, and does it really say _Paket_ corrupt? > 2. When I use cvs over ssh and use ControlPersist and ProxyCommand every > ssh command will block at the end for exact the time I specify in > ControlPersist. (Note that I have to start the proxy first like I > described in the first issue.) That's a known issue with certain programs (including e.g. Subversion, IIRC), but I don't recall how to fix it. Sorry. Joachim From Klaus at Ethgen.de Tue Mar 15 07:01:36 2011 From: Klaus at Ethgen.de (Klaus Ethgen) Date: Mon, 14 Mar 2011 21:01:36 +0100 Subject: Problemes with ControlPersist In-Reply-To: <20110314193450.GA4981@polymnia.joachimschipper.nl> References: <20110314151538.GA4962@ikki.ethgen.ch> <20110314193450.GA4981@polymnia.joachimschipper.nl> Message-ID: <20110314200135.GF4462@ikki.ethgen.ch> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Am Mo den 14. M?r 2011 um 20:34 schrieb Joachim Schipper: > > 1. When I use ControlPersist in combination with ProxyCommand to reach a > > other host over that proxy I get the following message: > > Bad packet length 1397966893. > > Disconnecting: Paket corrupt > > > > When I fist ssh to the proxy, close the connection (that persists in > > background) and ssh to the target everything works well. > > I use this in .ssh/config, and it works for me (and has been working for > a long time): > > Host * > CheckHostIP yes > ControlMaster auto > ControlPath ~/.ssh/mux-%r@%h:%p > ControlPersist 3m > HashKnownHosts yes > NoHostAuthenticationForLocalhost yes > Protocol 2 > > Host ssh.cwi.nl > ProxyCommand none > StrictHostKeyChecking yes > > Host *.cwi.nl > User schipper > ProxyCommand ssh ssh.cwi.nl netcat %h %p 've like the same. Just the newer syntax for ProxyCommand: Host *.sourceforge.net User XXX ForwardAgent no Host tschil-* ProxyCommand ssh -q -W %h:%p tschil Host XXXXX.XXX.ch ForwardAgent no ForwardX11 no BatchMode yes ProxyCommand ssh -q -W %h:%p XXXXXXXXX Host Manyhosts ProxyCommand ssh -q -W %h:%p XXXXX.XXX.ch Host Otherhosts ProxyCommand ssh -q -W %h:%p XXXXXXXXX Host * Protocol 2 CheckHostIP no Cipher blowfish Ciphers blowfish-cbc VisualHostKey yes HashKnownHosts no ControlPath /home/klaus/.ssh/%r@%h:%p.sock ControlMaster auto ControlPersist 300 ForwardX11 yes ForwardAgent yes All works well when I comment out the ControlPersist line. And all worked well since long time. But The ControlPersist breaks it as I told above. Even the double proxy worked well and do without the ControlPersist line. > This is on OpenBSD-current (OpenSSH_5.8, OpenSSL 1.0.0a 1 Jun 2010). > What are you connecting to what, and does it really say _Paket_ corrupt? Sure. It was cut and paste. > > 2. When I use cvs over ssh and use ControlPersist and ProxyCommand every > > ssh command will block at the end for exact the time I specify in > > ControlPersist. (Note that I have to start the proxy first like I > > described in the first issue.) > > That's a known issue with certain programs (including e.g. Subversion, > IIRC), but I don't recall how to fix it. Sorry. I think the problems have something common. Maybe its the same. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTX50H5+OKpjRpO3lAQpVJwf/dYZ1/5CiKJcCkwLiMuhEzLRc2/32wAIu 24C/jXrahFwMAKJXMk9lYXwtSI56Apj+cUqCO6zz4bomX3IONGLJoT5AGI842vfe gRU4vfub4HbTtyJYQpDLYdYv7mbkZ2n84xH+w88BujX2NzCbjjm2jICjQOggzztw AlFu41teC98T//xLM3PvWP1Je9hvJx3mGACzit0jqV+6DsMMU7l2QgGw8rPso4rS IivccxU/9j/HChSkP8alwtcxqgoc9oWabC4GRYOLJVelHx2D7qFDSe+MDcYdaXuO Koi8QMjIjhBfzxcjvrW/YgbWu2689yjsc5NhGJECK2AcRKgYHMriLA== =Q+Bi -----END PGP SIGNATURE----- From joachim at joachimschipper.nl Tue Mar 15 08:46:06 2011 From: joachim at joachimschipper.nl (Joachim Schipper) Date: Mon, 14 Mar 2011 22:46:06 +0100 Subject: ssh -W/ControlPersist bug (was: Problemes with ControlPersist) In-Reply-To: <20110314200135.GF4462@ikki.ethgen.ch> References: <20110314151538.GA4962@ikki.ethgen.ch> <20110314193450.GA4981@polymnia.joachimschipper.nl> <20110314200135.GF4462@ikki.ethgen.ch> Message-ID: <20110314214604.GA18370@polymnia.joachimschipper.nl> On Mon, Mar 14, 2011 at 09:01:36PM +0100, Klaus Ethgen wrote: > Am Mo den 14. M?r 2011 um 20:34 schrieb Joachim Schipper: > > > 1. When I use ControlPersist in combination with ProxyCommand to reach a > > > other host over that proxy I get the following message: > > > Bad packet length 1397966893. > > > Disconnecting: Paket corrupt > > > > > > When I first ssh to the proxy, close the connection (that > > > persists in background) and ssh to the target everything works > > > well. > > > > I use this in .ssh/config, and it works for me (and has been working for > > a long time): > All works well when I comment out the ControlPersist line. (...) It works for me, too, if I disable ControlPersist. ssh.cwi.nl is running a really old and grotty "OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005", but the following (minimal, nonsensical) configuration (on my OpenBSD-current box) gets me the same error message: Host * ControlMaster auto ControlPath ~/.ssh/mux-%r@%h:%p ControlPersist 3m HashKnownHosts yes Host ssh.cwi.nl ProxyCommand ssh -W %h:%p localhost StrictHostKeyChecking yes I tried 'ssh ssh.cwi.nl'. The logs are a bit too large to attach, sadly; see http://www.joachimschipper.nl/posts/20110314/ssh-log and http://www.joachimschipper.nl/posts/20110314/sshd-log. > > > 2. When I use cvs over ssh and use ControlPersist and ProxyCommand every > > > ssh command will block at the end for exact the time I specify in > > > ControlPersist. (Note that I have to start the proxy first like I > > > described in the first issue.) > > > > That's a known issue with certain programs (including e.g. Subversion, > > IIRC), but I don't recall how to fix it. Sorry. > > I think the problems have something common. Maybe its the same. Yes, in either case the software waits for the ssh process to stop, instead of just closing the file descriptor. Not really an SSH bug, and it certainly has nothing to do with the above. I'm sure someone has solved it before, no? Joachim From raghu.prabhu13 at gmail.com Tue Mar 15 06:41:19 2011 From: raghu.prabhu13 at gmail.com (Raghavendra D Prabhu) Date: Tue, 15 Mar 2011 01:11:19 +0530 Subject: Regarding sshfs and multiplexed connections Message-ID: <20110314194119.GA7770@Xye> Hi, I have sshfs and ssh to my host setup to use the same socket with ControlMaster setting. Now when I try to scp a file to/from my host I see poor transfer speed. Also, a cp-ing a file to the mounted filesystem results in poor throughput. On the other hand, if I don't use the multiplexing, I get very good throughput. Now, my question is, when I multiplex, does the IPQoS get set wrongly for a scp transfer resulting in poor throughput ? Also, is there a way to specify options for subsystems like sftp, scp (like Host based filtering) in ~/.ssh/config so that I don't have to specify to scp to not use ControlMaster on the command line. Thanks, -------------------------- Raghavendra Prabhu GPG ID:D72BE977 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From chris.quenelle at oracle.com Fri Mar 18 10:17:47 2011 From: chris.quenelle at oracle.com (Chris Quenelle) Date: Thu, 17 Mar 2011 16:17:47 -0700 Subject: exit status of ssh? Message-ID: <4D82969B.4010105@oracle.com> The man page for ssh says that the exit status of ssh should be the exit status of the program that it runs. The session terminates when the command or shell on the remote machine exits and all X11 and TCP/IP connections have been closed. The exit sta? tus of the remote program is returned as the exit status of ssh. ... ssh exits with the exit status of the remote command or with 255 if an error occurred. But it doesn't seem to work. % bash -c '"/bin/ls /foo"' ; echo $? bash: /bin/ls /foo: No such file or directory 127 % ssh cryo bash -c '"/bin/ls /foo"' ; echo $? /bin/ls: /foo: No such file or directory 0 What's up? I see the same thing on a Linux system and a Solaris system: % ssh -V OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 % ssh -V Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x0090811f Output of -v is: % ssh -v cryo bash -c '"/bin/ls /foo"' OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /home/quenelle/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to cryo [10.133.144.28] port 22. debug1: Connection established. debug1: identity file /home/quenelle/.ssh/identity type -1 debug1: identity file /home/quenelle/.ssh/id_rsa type 1 debug1: identity file /home/quenelle/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 debug1: match: OpenSSH_4.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'cryo' is known and matches the RSA host key. debug1: Found key in /home/quenelle/.ssh/known_hosts:33 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/quenelle/.ssh/identity debug1: Offering public key: /home/quenelle/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 149 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug1: Sending command: bash -c "/bin/ls /foo" /bin/ls: /foo: No such file or directory debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 2 Since the expected exit status is "127", and the status that the shell sees with $? is "0", I'm not sure how the "status 2" on the last line fits in. From chris.quenelle at oracle.com Sat Mar 19 03:52:51 2011 From: chris.quenelle at oracle.com (Chris Quenelle) Date: Fri, 18 Mar 2011 09:52:51 -0700 Subject: exit status of ssh? In-Reply-To: References: <4D82969B.4010105@oracle.com> Message-ID: <4D838DE3.8020402@oracle.com> On Friday March 18 9:41AM, Michael Loftis wrote: > On Thu, Mar 17, 2011 at 5:17 PM, Chris Quenelle > wrote: >> The man page for ssh says that the exit status of ssh should >> be the exit status of the program that it runs. >> >> The session terminates when the command or shell on the remote machine >> exits and all X11 and TCP/IP connections have been closed. The exit sta? >> tus of the remote program is returned as the exit status of ssh. >> ... >> ssh exits with the exit status of the remote command or with 255 if an >> error occurred. >> >> >> But it doesn't seem to work. >> >> >> % bash -c '"/bin/ls /foo"' ; echo $? >> bash: /bin/ls /foo: No such file or directory >> 127 >> >> % ssh cryo bash -c '"/bin/ls /foo"' ; echo $? >> /bin/ls: /foo: No such file or directory >> 0 >> >> What's up? > You're seeing the exit status from the bash command, which is doing > something different possibly due to configuration (.bashrc and > related). Skip invoking bash and try ssh cryo /bin/ls /foo and see > what your exit code is then. Good point. But the results are the same. Here's the new data without bash in the mix. This assumes that sshd doesn't spawn a shell of some kind to execute the command. % /bin/ls /foo; echo $? /foo: No such file or directory 2 % ssh -v buba /bin/ls /foo; echo $? Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x0090811f debug1: Reading configuration data /home/quenelle/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to buba [10.133.144.239] port 22. debug1: Connection established. debug1: ssh_kmf_check_uri: /home/quenelle/.ssh/identity debug1: Identity file/URI '/home/quenelle/.ssh/identity' pubkey type UNKNOWN debug1: ssh_kmf_check_uri: /home/quenelle/.ssh/id_rsa debug1: ssh_kmf_key_from_blob: blob length is 149. debug1: Identity file/URI '/home/quenelle/.ssh/id_rsa' pubkey type ssh-rsa debug1: ssh_kmf_check_uri: /home/quenelle/.ssh/id_dsa debug1: ssh_kmf_key_from_blob: blob length is 433. debug1: Identity file/URI '/home/quenelle/.ssh/id_dsa' pubkey type ssh-dss debug1: Logging to host: buba debug1: Local user: quenelle Remote user: quenelle debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1 debug1: match: Sun_SSH_1.1 pat Sun_SSH_1.1* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-Sun_SSH_1.5 debug1: use_engine is 'yes' debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers debug1: pkcs11 engine initialization complete debug1: Creating a global KMF session. debug1: My KEX proposal before adding the GSS KEX algorithm: debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible ) debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: My KEX proposal I sent to the peer: debug1: KEX proposal I received from the peer: debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: Host key algorithm 'ssh-rsa' chosen for the KEX. debug1: Peer sent proposed langtags, ctos: en-CA,en-US,es,es-MX,fr,fr-CA,i-default debug1: Peer sent proposed langtags, stoc: en-CA,en-US,es,es-MX,fr,fr-CA,i-default debug1: We proposed langtags, ctos: en-US debug1: We proposed langtags, stoc: en-US debug1: Negotiated lang: en-US debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: Remote: Negotiated main locale: en_US.UTF-8 debug1: Remote: Negotiated messages locale: en_US.UTF-8 debug1: dh_gen_key: priv key bits set: 136/256 debug1: bits set: 1622/3191 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: ssh_kmf_key_from_blob: blob length is 149. debug1: ssh_kmf_key_from_blob: blob length is 149. debug1: ssh_kmf_key_from_blob: blob length is 149. debug1: Host 'buba' is known and matches the RSA host key. debug1: Found key in /home/quenelle/.ssh/known_hosts:42 debug1: bits set: 1588/3191 debug1: ssh_rsa_verify: signature correct debug1: set_newkeys: setting new keys for 'out' mode debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: set_newkeys: setting new keys for 'in' mode debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive debug1: Next authentication method: gssapi-keyex debug1: Next authentication method: gssapi-with-mic debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible ) debug1: Next authentication method: publickey debug1: Trying private key: /home/quenelle/.ssh/identity debug1: ssh_kmf_check_uri: /home/quenelle/.ssh/identity debug1: Trying public key: /home/quenelle/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 80ab010 hint 1 debug1: ssh_kmf_key_from_blob: blob length is 149. debug1: ssh_kmf_check_uri: /home/quenelle/.ssh/id_rsa debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey) debug1: channel 0: new [client-session] debug1: send channel open 0 debug1: Entering interactive session. debug1: ssh_session2_setup: id 0 debug1: channel request 0: env debug1: Sending command: /bin/ls /foo debug1: channel request 0: exec debug1: channel 0: open confirm rwindow 0 rmax 32768 debug1: Remote: Channel 0 set: LANG=en_US.UTF-8 debug1: channel 0: rcvd eof debug1: channel 0: output open -> drain debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: rcvd close debug1: channel 0: close_read debug1: channel 0: input open -> closed /foo: No such file or directory debug1: channel 0: obuf empty debug1: channel 0: close_write debug1: channel 0: output drain -> closed debug1: channel 0: almost dead debug1: channel 0: gc: notify user debug1: channel 0: gc: user detached debug1: channel 0: send close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: client-session, nchannels 1 debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 2 0 >> I see the same thing on a Linux system and a Solaris system: >> >> % ssh -V >> OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 >> >> % ssh -V >> Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x0090811f >> >> Output of -v is: >> >> % ssh -v cryo bash -c '"/bin/ls /foo"' >> OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 >> debug1: Reading configuration data /home/quenelle/.ssh/config >> debug1: Reading configuration data /etc/ssh/ssh_config >> debug1: Applying options for * >> debug1: Connecting to cryo [10.133.144.28] port 22. >> debug1: Connection established. >> debug1: identity file /home/quenelle/.ssh/identity type -1 >> debug1: identity file /home/quenelle/.ssh/id_rsa type 1 >> debug1: identity file /home/quenelle/.ssh/id_dsa type 2 >> debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2 >> debug1: match: OpenSSH_4.2 pat OpenSSH* >> debug1: Enabling compatibility mode for protocol 2.0 >> debug1: Local version string SSH-2.0-OpenSSH_4.2 >> debug1: SSH2_MSG_KEXINIT sent >> debug1: SSH2_MSG_KEXINIT received >> debug1: kex: server->client aes128-cbc hmac-md5 none >> debug1: kex: client->server aes128-cbc hmac-md5 none >> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent >> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP >> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent >> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY >> debug1: Host 'cryo' is known and matches the RSA host key. >> debug1: Found key in /home/quenelle/.ssh/known_hosts:33 >> debug1: ssh_rsa_verify: signature correct >> debug1: SSH2_MSG_NEWKEYS sent >> debug1: expecting SSH2_MSG_NEWKEYS >> debug1: SSH2_MSG_NEWKEYS received >> debug1: SSH2_MSG_SERVICE_REQUEST sent >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> debug1: Authentications that can continue: publickey,keyboard-interactive >> debug1: Next authentication method: publickey >> debug1: Trying private key: /home/quenelle/.ssh/identity >> debug1: Offering public key: /home/quenelle/.ssh/id_rsa >> debug1: Server accepts key: pkalg ssh-rsa blen 149 >> debug1: read PEM private key done: type RSA >> debug1: Authentication succeeded (publickey). >> debug1: channel 0: new [client-session] >> debug1: Entering interactive session. >> debug1: Sending environment. >> debug1: Sending env LANG = en_US.UTF-8 >> debug1: Sending command: bash -c "/bin/ls /foo" >> /bin/ls: /foo: No such file or directory >> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 >> debug1: channel 0: free: client-session, nchannels 1 >> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds >> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 >> debug1: Exit status 2 >> >> Since the expected exit status is "127", and the status >> that the shell sees with $? is "0", I'm not sure how the "status 2" >> on the last line fits in. >> >> >> >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> From peter at stuge.se Sat Mar 19 05:20:28 2011 From: peter at stuge.se (Peter Stuge) Date: Fri, 18 Mar 2011 19:20:28 +0100 Subject: exit status of ssh? In-Reply-To: <4D838DE3.8020402@oracle.com> References: <4D82969B.4010105@oracle.com> <4D838DE3.8020402@oracle.com> Message-ID: <20110318182028.19784.qmail@stuge.se> Chris Quenelle wrote: >> try ssh cryo /bin/ls /foo and see what your exit code is then. > > Good point. But the results are the same. It works for me. $ ls /foo; echo $? ls: cannot access /foo: No such file or directory 2 $ ssh foo ls /foo; echo $? ls: /foo: No such file or directory 2 $ ssh -v box ls /foo; echo $? OpenSSH_5.4p1, OpenSSL 0.9.8k 25 Mar 2009 .. debug1: Remote protocol version 2.0, remote software version OpenSSH_5.0 .. debug1: Sending command: ls /foo ls: /foo: No such file or directory debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 Transferred: sent 2472, received 1920 bytes, in 0.4 seconds Bytes per second: sent 6804.5, received 5285.0 debug1: Exit status 2 2 $ //Peter From vinschen at redhat.com Sat Mar 19 06:19:43 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 18 Mar 2011 20:19:43 +0100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110307192930.GB12138@calimero.vinschen.de> References: <4D5BAAEF.3040002@zip.com.au> <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110307192930.GB12138@calimero.vinschen.de> Message-ID: <20110318191943.GE31220@calimero.vinschen.de> Ping? On Mar 7 20:29, Corinna Vinschen wrote: > Hi Darren, > > On Feb 17 23:27, Darren Tucker wrote: > > On 17/02/2011 10:34 PM, Corinna Vinschen wrote: > > >As an additional datapoint, we had a couple of similar bug reports after > > >I upgraded openssh in the Cygwin distro to 5.7p1 and then 5.8p1. One of > > >them even comes with a set of debug output of working (5.6p1) and > > >non-working (5.8p1) connection attempts: > > [...] > > >However, I tried with various older versions of SSH running on Cygwin, > > >Linux and Solaris to connect from 5.8p1 myself, and I'm unable to > > >reproduce this problem. > > > > Thanks for the extra info. I haven't been able to reproduce either. > > I've tried building 5.5p1 and 4.3p1 against (locally built) OpenSSL > > 0.9.6b and 0.9.8d. There seems to be some piece of the puzzle > > missing... > > > > I diffed the working and non working clients, and one difference is: > > debug1: sending SSH2_MSG_KEX_ECDH_INIT > > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > > > > although I'm not sure that's significant since Oren's output had > > SSH2_MSG_KEX_DH_GEX_GROUP. You could try forcing it with "ssh -vvv > > -o KexAlgorithms=diffie-hellman-group-exchange-sha1 server" > > > > (aside: I now want to add OpenSSL's version output to the server > > debug output) > > is there any progress in that matter? > > > Thanks, > Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From sfandino at yahoo.com Sat Mar 19 18:39:47 2011 From: sfandino at yahoo.com (=?UTF-8?B?U2FsdmFkb3IgRmFuZGnDsW8=?=) Date: Sat, 19 Mar 2011 08:39:47 +0100 Subject: exit status of ssh? In-Reply-To: <4D838DE3.8020402@oracle.com> References: <4D82969B.4010105@oracle.com> <4D838DE3.8020402@oracle.com> Message-ID: <4D845DC3.2020904@yahoo.com> On 03/18/2011 05:52 PM, Chris Quenelle wrote: > On Friday March 18 9:41AM, Michael Loftis wrote: >> On Thu, Mar 17, 2011 at 5:17 PM, Chris Quenelle >> wrote: >>> The man page for ssh says that the exit status of ssh should >>> be the exit status of the program that it runs. >>> >>> The session terminates when the command or shell on the remote machine >>> exits and all X11 and TCP/IP connections have been closed. The exit sta? >>> tus of the remote program is returned as the exit status of ssh. >>> ... >>> ssh exits with the exit status of the remote command or with 255 if an >>> error occurred. >>> >>> >>> But it doesn't seem to work. >>> >>> >>> % bash -c '"/bin/ls /foo"' ; echo $? >>> bash: /bin/ls /foo: No such file or directory >>> 127 >>> >>> % ssh cryo bash -c '"/bin/ls /foo"' ; echo $? >>> /bin/ls: /foo: No such file or directory >>> 0 What happens when you log in cryo and run the first command there? - Salva From stu at spacehopper.org Mon Mar 21 08:06:59 2011 From: stu at spacehopper.org (Stuart Henderson) Date: Sun, 20 Mar 2011 21:06:59 +0000 (UTC) Subject: exit status of ssh? References: <4D82969B.4010105@oracle.com> Message-ID: On 2011-03-17, Chris Quenelle wrote: > The man page for ssh says that the exit status of ssh should > be the exit status of the program that it runs. > > The session terminates when the command or shell on the remote machine > exits and all X11 and TCP/IP connections have been closed. The exit sta??? > tus of the remote program is returned as the exit status of ssh. > ... > ssh exits with the exit status of the remote command or with 255 if an > error occurred. > > > But it doesn't seem to work. What does 'type ssh' say? Some people alias it to a shell function which resets the window title, and in some cases that function doesn't correctly handle the exit code (/etc/ksh.kshrc in OpenBSD used to do this, for example). From chris.quenelle at oracle.com Tue Mar 22 05:47:34 2011 From: chris.quenelle at oracle.com (Chris Quenelle) Date: Mon, 21 Mar 2011 11:47:34 -0700 Subject: exit status of ssh? In-Reply-To: <4D845DC3.2020904@yahoo.com> References: <4D82969B.4010105@oracle.com> <4D838DE3.8020402@oracle.com> <4D845DC3.2020904@yahoo.com> Message-ID: <4D879D46.1090904@oracle.com> On Saturday March 19 12:39AM, Salvador Fandi?o wrote: > On 03/18/2011 05:52 PM, Chris Quenelle wrote: >> On Friday March 18 9:41AM, Michael Loftis wrote: >>> On Thu, Mar 17, 2011 at 5:17 PM, Chris Quenelle >>> wrote: >>>> The man page for ssh says that the exit status of ssh should >>>> be the exit status of the program that it runs. >>>> >>>> The session terminates when the command or shell on the remote machine >>>> exits and all X11 and TCP/IP connections have been closed. The exit >>>> sta? >>>> tus of the remote program is returned as the exit status of ssh. >>>> ... >>>> ssh exits with the exit status of the remote command or with 255 if an >>>> error occurred. >>>> >>>> >>>> But it doesn't seem to work. >>>> >>>> >>>> % bash -c '"/bin/ls /foo"' ; echo $? >>>> bash: /bin/ls /foo: No such file or directory >>>> 127 >>>> >>>> % ssh cryo bash -c '"/bin/ls /foo"' ; echo $? >>>> /bin/ls: /foo: No such file or directory >>>> 0 > > What happens when you log in cryo and run the first command there? > > - Salva cryo gives the same result as on the ssh-originating host: % ssh cryo % bash -c '"/bin/ls /foo"' ; echo $? bash: /bin/ls /foo: No such file or directory 127 So by reading between the lines, I assume that other people are not seeing this kind of behavior? That's very strange. I haven't yet gone to the trouble of setting up a new user account with it's own scratch ~/.ssh directory to see if it is reproducible. I assumed this was either a bug that nobody noticed, or it was some kind of pilot error on my part. --chris From peter at stuge.se Tue Mar 22 05:53:05 2011 From: peter at stuge.se (Peter Stuge) Date: Mon, 21 Mar 2011 19:53:05 +0100 Subject: exit status of ssh? In-Reply-To: <4D879D46.1090904@oracle.com> References: <4D82969B.4010105@oracle.com> <4D838DE3.8020402@oracle.com> <4D845DC3.2020904@yahoo.com> <4D879D46.1090904@oracle.com> Message-ID: <20110321185305.9884.qmail@stuge.se> Chris Quenelle wrote: > cryo gives the same result as on the ssh-originating host: > % ssh cryo > % bash -c '"/bin/ls /foo"' ; echo $? Note that this command is really bogus. You are asking bash to execute the command "/bin/ls /foo" ie. the program foo, in a subdirectory called l-s-space, in /bin. > bash: /bin/ls /foo: No such file or directory > 127 But regardless what the error is, I think you should be getting back the error code. $ bash -c '/bin/ls /foo'; echo $? /bin/ls: cannot access /foo: No such file or directory 2 $ bash -c '"/bin/ls /foo"'; echo $? bash: /bin/ls /foo: No such file or directory 127 $ ssh localhost '/bin/ls /foo'; echo $? /bin/ls: cannot access /foo: No such file or directory 2 $ ssh root '"/bin/ls /foo"'; echo $? bash: /bin/ls /foo: No such file or directory 127 > So by reading between the lines, I assume that other > people are not seeing this kind of behavior? As you can see above it all works as expected here. //Peter From chris.quenelle at oracle.com Tue Mar 22 05:54:03 2011 From: chris.quenelle at oracle.com (Chris Quenelle) Date: Mon, 21 Mar 2011 11:54:03 -0700 Subject: exit status of ssh? In-Reply-To: <4D879D46.1090904@oracle.com> References: <4D82969B.4010105@oracle.com> <4D838DE3.8020402@oracle.com> <4D845DC3.2020904@yahoo.com> <4D879D46.1090904@oracle.com> Message-ID: <4D879ECB.4040800@oracle.com> On Monday March 21 11:47AM, Chris Quenelle wrote: > > So by reading between the lines, I assume that other > people are not seeing this kind of behavior? > > That's very strange. I haven't yet gone to the trouble of setting > up a new user account with it's own scratch ~/.ssh directory > to see if it is reproducible. > > I assumed this was either a bug that nobody noticed, or it was > some kind of pilot error on my part. > Arg! It turned out to be pilot error. I have a shell function / alias for 'ssh' which sends escape characters to my term client. If I bypass the alias, and run the binary directly, then the return code works as expected. Never mind! thanks for your patience. --chris From dpal at redhat.com Thu Mar 24 00:47:17 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 23 Mar 2011 09:47:17 -0400 Subject: Proposal for collaboration In-Reply-To: <4C882DEB.7020007@redhat.com> References: <4C882DEB.7020007@redhat.com> Message-ID: <4D89F9E5.5080405@redhat.com> Hello, Some time ago I sent an email below with the thoughts regarding integrating SSH with the central identity server (IPA) that would provide the storage for keys and policies. The details are below. Unfortunately there was no reply then. We are very interested in continuation of this conversation as integration of SSH with central management solutions is something that is very frequently asked about. I hope we can start over and have a productive dialog this time. Thank you, Dmitri On 09/08/2010 08:44 PM, Dmitri Pal wrote: > Hello, > > My is Dmitri Pal and for the last two years I have been working on SSSD > and IPA open source projects. > SSSD is effectively a replacement for PAM/NSS combination with offline > caching. The details about the project can be read here: > https://fedorahosted.org/sssd/ > Quick overview of features is here: > https://fedorahosted.org/sssd/attachment/wiki/Contribute/sssd%20overview%20slides.2.pdf > SSSD has been actively developed during last two years. It is a part of > several Linux distributions and is pretty stable now. > > IPA is a project that combines MIT KDC with 389 DS. Its v2 is due to be > released later this year. > http://www.freeipa.org/page/Main_Page > https://fedorahosted.org/freeipa/ > > IPA as a server (though in the context of the discussion below can be > replaced with any other LDAP server) together with SSSD provide a > powerful central management solution for different security and identity > aspects of the UNIX/Linux systems. > > We think that SSSD and IPA projects are mature enough to start thinking > about integrating more tightly with different much more well established > utilities and security solutions as sudo and openssh. > Here are several ideas about how SSSD and IPA can be integrated with > openssh to provide better management capabilities to the users. > > 1) Centrally managing the user public keys. Instead of having user > public keys in a key file on each system the appropriate key(s) can be > delivered to the server host via SSSD and IPA (or other LDAP server). It > is similar to openssh-lpk effort but a bit different (see below). > 2) Centrally managing fingerprints of the server keys. If the server > host fingerprint is loaded into the central server like IPA the SSSD > would be able to get and cache it. openssh in turn can fetch it from > SSSD on as needed basis and do a silent fingerprint verification without > requiring user interaction. I see that there is a DNS option supported > but this lacks caching that SSSD will be able to provide. > 3) IPA introduces concept of hosts and host groups. SSSD has/will have a > capability to take advantage of such functionality. This means that SSSD > would be able to help openssh with .shosts and .rhosts contents too. > > I do not know the design and code of the openssh, sorry, to the extent > of starting to talk about specific functions but what I wanted to > suggest is defining some kind of pluggable interface in openssh that > would abstract the source of the public keys, fingerprints and access > checks (may be something else we can help with too). Such pluggable > interface would allow projects like openssh-lpk and SSSD to build > pluggable providers for those crucial pieces of information. > > Is there any interest of pursuing such path together? I see it as > creating an interface that can be enabled through a specific config > value. For example "SecurityProvider". This option would have to be a > path to a .so that should provide a defined agreed to interface. If the > configuration option is not given the current rules are respected. If it > is given then the openssh will call API functions to get keys, > fingerprints or do host checks implemented by this .so. > This can definitely be designed in some other way more suitable for the > openssh project and aligned to its vision but I hope it is clear what we > want to try to accomplish. > > Would be glad to discuss any options of mutual long and short term > collaboration. > > Thank you, > Dmitri Pal > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From bentley.macleod at columbia.edu Fri Mar 25 20:17:24 2011 From: bentley.macleod at columbia.edu (W.Bentley MacLeod) Date: Fri, 25 Mar 2011 05:17:24 -0400 (EDT) Subject: openssh-askpass 5.8p1-4.1 Message-ID: On opensuse 11.4 this is the only version of openssh. With unison the password dialog for openssh hangs - I had to use the opensuse 11.3 repos for a version of openssh that works with unison. (several people on the forums have reported this bug, but I did not see it in bugzilla). best bm ____________________________ Professor W. Bentley MacLeod Visiting Scholar Russell Sage Foundation 112 East 64th Street ? New York, NY 10065 http://www.columbia.edu/~wbm2103/ ____________________________ From vinschen at redhat.com Sat Mar 26 00:20:40 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 25 Mar 2011 14:20:40 +0100 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110318191943.GE31220@calimero.vinschen.de> References: <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110307192930.GB12138@calimero.vinschen.de> <20110318191943.GE31220@calimero.vinschen.de> Message-ID: <20110325132040.GD24762@calimero.vinschen.de> Ping 2. If there's a good reason that none of the core developers bothers to comment further on this serious problem, it would be nice to let us folks at least know why. On Mar 18 20:19, Corinna Vinschen wrote: > Ping? > > On Mar 7 20:29, Corinna Vinschen wrote: > > Hi Darren, > > > > On Feb 17 23:27, Darren Tucker wrote: > > > On 17/02/2011 10:34 PM, Corinna Vinschen wrote: > > > >As an additional datapoint, we had a couple of similar bug reports after > > > >I upgraded openssh in the Cygwin distro to 5.7p1 and then 5.8p1. One of > > > >them even comes with a set of debug output of working (5.6p1) and > > > >non-working (5.8p1) connection attempts: > > > [...] > > > >However, I tried with various older versions of SSH running on Cygwin, > > > >Linux and Solaris to connect from 5.8p1 myself, and I'm unable to > > > >reproduce this problem. > > > > > > Thanks for the extra info. I haven't been able to reproduce either. > > > I've tried building 5.5p1 and 4.3p1 against (locally built) OpenSSL > > > 0.9.6b and 0.9.8d. There seems to be some piece of the puzzle > > > missing... > > > > > > I diffed the working and non working clients, and one difference is: > > > debug1: sending SSH2_MSG_KEX_ECDH_INIT > > > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > > > > > > although I'm not sure that's significant since Oren's output had > > > SSH2_MSG_KEX_DH_GEX_GROUP. You could try forcing it with "ssh -vvv > > > -o KexAlgorithms=diffie-hellman-group-exchange-sha1 server" > > > > > > (aside: I now want to add OpenSSL's version output to the server > > > debug output) > > > > is there any progress in that matter? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From djm at mindrot.org Sun Mar 27 21:33:51 2011 From: djm at mindrot.org (Damien Miller) Date: Sun, 27 Mar 2011 21:33:51 +1100 (EST) Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: <20110325132040.GD24762@calimero.vinschen.de> References: <20110216110309.GD12486@orenhe-laptop> <4D5BD0A8.20306@zip.com.au> <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110307192930.GB12138@calimero.vinschen.de> <20110318191943.GE31220@calimero.vinschen.de> <20110325132040.GD24762@calimero.vinschen.de> Message-ID: I don't use Cygwin myself, so I don't have anything to add. It looks like something related to ECDH is crashing, but there is insufficient information for anyone to debug it. On Fri, 25 Mar 2011, Corinna Vinschen wrote: > Ping 2. > > > If there's a good reason that none of the core developers bothers to > comment further on this serious problem, it would be nice to let us > folks at least know why. > > > On Mar 18 20:19, Corinna Vinschen wrote: > > Ping? > > > > On Mar 7 20:29, Corinna Vinschen wrote: > > > Hi Darren, > > > > > > On Feb 17 23:27, Darren Tucker wrote: > > > > On 17/02/2011 10:34 PM, Corinna Vinschen wrote: > > > > >As an additional datapoint, we had a couple of similar bug reports after > > > > >I upgraded openssh in the Cygwin distro to 5.7p1 and then 5.8p1. One of > > > > >them even comes with a set of debug output of working (5.6p1) and > > > > >non-working (5.8p1) connection attempts: > > > > [...] > > > > >However, I tried with various older versions of SSH running on Cygwin, > > > > >Linux and Solaris to connect from 5.8p1 myself, and I'm unable to > > > > >reproduce this problem. > > > > > > > > Thanks for the extra info. I haven't been able to reproduce either. > > > > I've tried building 5.5p1 and 4.3p1 against (locally built) OpenSSL > > > > 0.9.6b and 0.9.8d. There seems to be some piece of the puzzle > > > > missing... > > > > > > > > I diffed the working and non working clients, and one difference is: > > > > debug1: sending SSH2_MSG_KEX_ECDH_INIT > > > > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > > > > > > > > although I'm not sure that's significant since Oren's output had > > > > SSH2_MSG_KEX_DH_GEX_GROUP. You could try forcing it with "ssh -vvv > > > > -o KexAlgorithms=diffie-hellman-group-exchange-sha1 server" > > > > > > > > (aside: I now want to add OpenSSL's version output to the server > > > > debug output) > > > > > > is there any progress in that matter? > > > Corinna > > -- > Corinna Vinschen > Cygwin Project Co-Leader > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Sun Mar 27 22:16:22 2011 From: djm at mindrot.org (Damien Miller) Date: Sun, 27 Mar 2011 22:16:22 +1100 (EST) Subject: Proposal for collaboration In-Reply-To: <4D89F9E5.5080405@redhat.com> References: <4C882DEB.7020007@redhat.com> <4D89F9E5.5080405@redhat.com> Message-ID: Hi, We'd probably support the your first two feature requests (delegating authorized_keys and known_hosts lookups) though agents or plugins. There are a couple of outstanding bugs on https://bugzilla.mindrot.org/ with patches to implement at least the authorized_keys part of this that have been on my TODO list for a while (and will probably stay there for a little while longer, sorry) I don't know if we would be that interested in externally-managed .shosts/.rhosts support. Hostbased authentication is a niche feature as it is and I'm not convinced that we should invest more effort to generalise it. I guess if the authorized_keys agent/helper code is reusable then we might consider it. -d On Wed, 23 Mar 2011, Dmitri Pal wrote: > Hello, > > Some time ago I sent an email below with the thoughts regarding > integrating SSH with the central identity server (IPA) that would > provide the storage for keys and policies. > The details are below. Unfortunately there was no reply then. > > We are very interested in continuation of this conversation as > integration of SSH with central management solutions is something that > is very frequently asked about. > > I hope we can start over and have a productive dialog this time. > > Thank you, > Dmitri > > On 09/08/2010 08:44 PM, Dmitri Pal wrote: > > Hello, > > > > My is Dmitri Pal and for the last two years I have been working on SSSD > > and IPA open source projects. > > SSSD is effectively a replacement for PAM/NSS combination with offline > > caching. The details about the project can be read here: > > https://fedorahosted.org/sssd/ > > Quick overview of features is here: > > https://fedorahosted.org/sssd/attachment/wiki/Contribute/sssd%20overview%20slides.2.pdf > > SSSD has been actively developed during last two years. It is a part of > > several Linux distributions and is pretty stable now. > > > > IPA is a project that combines MIT KDC with 389 DS. Its v2 is due to be > > released later this year. > > http://www.freeipa.org/page/Main_Page > > https://fedorahosted.org/freeipa/ > > > > IPA as a server (though in the context of the discussion below can be > > replaced with any other LDAP server) together with SSSD provide a > > powerful central management solution for different security and identity > > aspects of the UNIX/Linux systems. > > > > We think that SSSD and IPA projects are mature enough to start thinking > > about integrating more tightly with different much more well established > > utilities and security solutions as sudo and openssh. > > Here are several ideas about how SSSD and IPA can be integrated with > > openssh to provide better management capabilities to the users. > > > > 1) Centrally managing the user public keys. Instead of having user > > public keys in a key file on each system the appropriate key(s) can be > > delivered to the server host via SSSD and IPA (or other LDAP server). It > > is similar to openssh-lpk effort but a bit different (see below). > > 2) Centrally managing fingerprints of the server keys. If the server > > host fingerprint is loaded into the central server like IPA the SSSD > > would be able to get and cache it. openssh in turn can fetch it from > > SSSD on as needed basis and do a silent fingerprint verification without > > requiring user interaction. I see that there is a DNS option supported > > but this lacks caching that SSSD will be able to provide. > > 3) IPA introduces concept of hosts and host groups. SSSD has/will have a > > capability to take advantage of such functionality. This means that SSSD > > would be able to help openssh with .shosts and .rhosts contents too. > > > > I do not know the design and code of the openssh, sorry, to the extent > > of starting to talk about specific functions but what I wanted to > > suggest is defining some kind of pluggable interface in openssh that > > would abstract the source of the public keys, fingerprints and access > > checks (may be something else we can help with too). Such pluggable > > interface would allow projects like openssh-lpk and SSSD to build > > pluggable providers for those crucial pieces of information. > > > > Is there any interest of pursuing such path together? I see it as > > creating an interface that can be enabled through a specific config > > value. For example "SecurityProvider". This option would have to be a > > path to a .so that should provide a defined agreed to interface. If the > > configuration option is not given the current rules are respected. If it > > is given then the openssh will call API functions to get keys, > > fingerprints or do host checks implemented by this .so. > > This can definitely be designed in some other way more suitable for the > > openssh project and aligned to its vision but I hope it is clear what we > > want to try to accomplish. > > > > Would be glad to discuss any options of mutual long and short term > > collaboration. > > > > Thank you, > > Dmitri Pal > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From vinschen at redhat.com Sun Mar 27 22:41:30 2011 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 27 Mar 2011 13:41:30 +0200 Subject: ssh 'connection reset by peer' problem since 5.8p1 In-Reply-To: References: <20110216135222.GF12486@orenhe-laptop> <4D5BE265.9030906@zip.com.au> <20110216211533.GA25449@orenhe-laptop> <20110216233017.GC29655@orenhe-laptop> <20110217113448.GA29762@calimero.vinschen.de> <4D5D1443.6050101@zip.com.au> <20110307192930.GB12138@calimero.vinschen.de> <20110318191943.GE31220@calimero.vinschen.de> <20110325132040.GD24762@calimero.vinschen.de> Message-ID: <20110327114130.GF3454@calimero.vinschen.de> On Mar 27 21:33, Damien Miller wrote: > I don't use Cygwin myself, so I don't have anything to add. It looks like > something related to ECDH is crashing, but there is insufficient information > for anyone to debug it. Please read the thread again. It has nothing to do with Cygwin in the first place. It occurs on other systems as well. We just have two Cygwin users which reported the problem, that's all. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From bert.wesarg at googlemail.com Mon Mar 28 17:34:00 2011 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Mon, 28 Mar 2011 08:34:00 +0200 Subject: [PATCH] ssh: set proctitle for mux master In-Reply-To: References: Message-ID: On Mon, Feb 14, 2011 at 17:56, Bert Wesarg wrote: > On Mon, Feb 7, 2011 at 22:11, Bert Wesarg wrote: >> Preserving the command line from the invoking ssh command doesn't >> make much sense, so use setproctitle() to hide the arguments. > > I would also suggest that the mux master chdir into /. Ping. Bert From djm at mindrot.org Mon Mar 28 17:43:40 2011 From: djm at mindrot.org (Damien Miller) Date: Mon, 28 Mar 2011 17:43:40 +1100 (EST) Subject: [PATCH] ssh: set proctitle for mux master In-Reply-To: References: Message-ID: Did you post this to bugzilla? I haven't had much time to hack on OpenSSH since the last release, but things posted into bugzilla won't get forgotten. On Mon, 28 Mar 2011, Bert Wesarg wrote: > On Mon, Feb 14, 2011 at 17:56, Bert Wesarg wrote: > > On Mon, Feb 7, 2011 at 22:11, Bert Wesarg wrote: > >> Preserving the command line from the invoking ssh command doesn't > >> make much sense, so use setproctitle() to hide the arguments. > > > > I would also suggest that the mux master chdir into /. > > Ping. > > Bert > From bert.wesarg at googlemail.com Mon Mar 28 17:48:09 2011 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Mon, 28 Mar 2011 08:48:09 +0200 Subject: [PATCH] ssh: set proctitle for mux master In-Reply-To: References: Message-ID: On Mon, Mar 28, 2011 at 08:43, Damien Miller wrote: > Did you post this to bugzilla? I haven't had much time to hack on OpenSSH > since the last release, but things posted into bugzilla won't get forgotten. No, will do. Thanks. Bert From dpal at redhat.com Tue Mar 29 01:27:33 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 28 Mar 2011 10:27:33 -0400 Subject: Proposal for collaboration In-Reply-To: References: <4C882DEB.7020007@redhat.com> <4D89F9E5.5080405@redhat.com> Message-ID: <4D909AD5.2090804@redhat.com> On 03/27/2011 07:16 AM, Damien Miller wrote: > Hi, > First of all thank you for the long awaited reply! > We'd probably support the your first two feature requests (delegating > authorized_keys and known_hosts lookups) though agents or plugins. Can you please elaborate on this a little bit? Do you have a specific design or plans? > There are a couple of outstanding bugs on https://bugzilla.mindrot.org/ > with patches to implement at least the authorized_keys part of this > that have been on my TODO list for a while (and will probably stay > there for a little while longer, sorry) Any hints on when you would be able to look into this? We have our own prioritization and time lines so without a clear understanding of when it is possible we would not be able to plan the effort on our side. > I don't know if we would be that interested in externally-managed > .shosts/.rhosts support. Hostbased authentication is a niche feature > as it is and I'm not convinced that we should invest more effort to > generalise it. I guess if the authorized_keys agent/helper code is > reusable then we might consider it. This was just an idea as we in IPA and SSSD pay a lot of attention to the host management to and have a way to provide this information easily. We can defer it for now. > -d > > On Wed, 23 Mar 2011, Dmitri Pal wrote: > >> Hello, >> >> Some time ago I sent an email below with the thoughts regarding >> integrating SSH with the central identity server (IPA) that would >> provide the storage for keys and policies. >> The details are below. Unfortunately there was no reply then. >> >> We are very interested in continuation of this conversation as >> integration of SSH with central management solutions is something that >> is very frequently asked about. >> >> I hope we can start over and have a productive dialog this time. >> >> Thank you, >> Dmitri >> >> On 09/08/2010 08:44 PM, Dmitri Pal wrote: >>> Hello, >>> >>> My is Dmitri Pal and for the last two years I have been working on SSSD >>> and IPA open source projects. >>> SSSD is effectively a replacement for PAM/NSS combination with offline >>> caching. The details about the project can be read here: >>> https://fedorahosted.org/sssd/ >>> Quick overview of features is here: >>> https://fedorahosted.org/sssd/attachment/wiki/Contribute/sssd%20overview%20slides.2.pdf >>> SSSD has been actively developed during last two years. It is a part of >>> several Linux distributions and is pretty stable now. >>> >>> IPA is a project that combines MIT KDC with 389 DS. Its v2 is due to be >>> released later this year. >>> http://www.freeipa.org/page/Main_Page >>> https://fedorahosted.org/freeipa/ >>> >>> IPA as a server (though in the context of the discussion below can be >>> replaced with any other LDAP server) together with SSSD provide a >>> powerful central management solution for different security and identity >>> aspects of the UNIX/Linux systems. >>> >>> We think that SSSD and IPA projects are mature enough to start thinking >>> about integrating more tightly with different much more well established >>> utilities and security solutions as sudo and openssh. >>> Here are several ideas about how SSSD and IPA can be integrated with >>> openssh to provide better management capabilities to the users. >>> >>> 1) Centrally managing the user public keys. Instead of having user >>> public keys in a key file on each system the appropriate key(s) can be >>> delivered to the server host via SSSD and IPA (or other LDAP server). It >>> is similar to openssh-lpk effort but a bit different (see below). >>> 2) Centrally managing fingerprints of the server keys. If the server >>> host fingerprint is loaded into the central server like IPA the SSSD >>> would be able to get and cache it. openssh in turn can fetch it from >>> SSSD on as needed basis and do a silent fingerprint verification without >>> requiring user interaction. I see that there is a DNS option supported >>> but this lacks caching that SSSD will be able to provide. >>> 3) IPA introduces concept of hosts and host groups. SSSD has/will have a >>> capability to take advantage of such functionality. This means that SSSD >>> would be able to help openssh with .shosts and .rhosts contents too. >>> >>> I do not know the design and code of the openssh, sorry, to the extent >>> of starting to talk about specific functions but what I wanted to >>> suggest is defining some kind of pluggable interface in openssh that >>> would abstract the source of the public keys, fingerprints and access >>> checks (may be something else we can help with too). Such pluggable >>> interface would allow projects like openssh-lpk and SSSD to build >>> pluggable providers for those crucial pieces of information. >>> >>> Is there any interest of pursuing such path together? I see it as >>> creating an interface that can be enabled through a specific config >>> value. For example "SecurityProvider". This option would have to be a >>> path to a .so that should provide a defined agreed to interface. If the >>> configuration option is not given the current rules are respected. If it >>> is given then the openssh will call API functions to get keys, >>> fingerprints or do host checks implemented by this .so. >>> This can definitely be designed in some other way more suitable for the >>> openssh project and aligned to its vision but I hope it is clear what we >>> want to try to accomplish. >>> >>> Would be glad to discuss any options of mutual long and short term >>> collaboration. >>> >>> Thank you, >>> Dmitri Pal >>> >>> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IPA project, >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rongqing.li at windriver.com Thu Mar 31 19:25:35 2011 From: rongqing.li at windriver.com (rongqing.li at windriver.com) Date: Thu, 31 Mar 2011 16:25:35 +0800 Subject: [v1 PATCH 0/1] Review request for a memory leak fix for openssh Message-ID: <1301559936-22783-1-git-send-email-rongqing.li@windriver.com> ---------------------------------------------------- Summary: fix a memory leak for Openssh ---------------------------------------------------- Upstream Project Name: OpenSSH Upstream Project URL: anoncvs at anoncvs.mindrot.org:/cvs Applies to: anoncvs at anoncvs.mindrot.org:/cvs Brief Description: the memory which is allocated by matchpathcon should be freed after it is used Will Submit to: Damien Miller. ; openssh-unix-dev at mindrot.org Origin of patch: Discovered by me Comments: --------- the memory which is allocated by matchpathcon should be freed after it is used Added Files: ------------ None. Removed Files: -------------- None. Remaining Changes (diffstat): ----------------------------- openbsd-compat/port-linux.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Testings I've done: ------------------- run ssh From rongqing.li at windriver.com Thu Mar 31 19:25:36 2011 From: rongqing.li at windriver.com (rongqing.li at windriver.com) Date: Thu, 31 Mar 2011 16:25:36 +0800 Subject: [v1 PATCH 1/1] Free memory In-Reply-To: <1301559936-22783-1-git-send-email-rongqing.li@windriver.com> References: <1301559936-22783-1-git-send-email-rongqing.li@windriver.com> Message-ID: <1301559936-22783-2-git-send-email-rongqing.li@windriver.com> The memory which is allocated by matchpathcon should be freed after it is used Signed-off-by: Roy Li --- openbsd-compat/port-linux.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/openbsd-compat/port-linux.c +++ b/openbsd-compat/port-linux.c @@ -217,8 +217,10 @@ ssh_selinux_setfscreatecon(const char *p setfscreatecon(NULL); return; } - if (matchpathcon(path, 0700, &context) == 0) + if (matchpathcon(path, 0700, &context) == 0) { setfscreatecon(context); + freecon(context); + } } #endif /* WITH_SELINUX */ From rongqing.li at windriver.com Thu Mar 31 19:23:34 2011 From: rongqing.li at windriver.com (rongqing.li at windriver.com) Date: Thu, 31 Mar 2011 16:23:34 +0800 Subject: [v1 PATCH 1/1] Free memory Message-ID: <1301559814-16053-2-git-send-email-rongqing.li@windriver.com> The memory which is allocated by matchpathcon should be freed after it is used Signed-off-by: Roy Li --- openbsd-compat/port-linux.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/openbsd-compat/port-linux.c +++ b/openbsd-compat/port-linux.c @@ -217,8 +217,10 @@ ssh_selinux_setfscreatecon(const char *p setfscreatecon(NULL); return; } - if (matchpathcon(path, 0700, &context) == 0) + if (matchpathcon(path, 0700, &context) == 0) { setfscreatecon(context); + freecon(context); + } } #endif /* WITH_SELINUX */