From Nick.Williams at morganstanley.com Sun Apr 1 21:45:25 2012 From: Nick.Williams at morganstanley.com (Williams, Nick) Date: Sun, 1 Apr 2012 12:45:25 +0100 Subject: patch for OSX In-Reply-To: <20120330005907.GA5787@gate.dtucker.net> References: <20120330005907.GA5787@gate.dtucker.net> Message-ID: Bah, sorry about that. Inline... >From 4d0c46a8f89bbd3778e4e664cfb94476bc5a770c Mon Sep 17 00:00:00 2001 From: Nick Williams Date: Wed, 28 Mar 2012 12:48:27 +0100 Subject: [PATCH] fix for incorrect boolean logic in OD code (OSX) The opendirectory lookups in gss-serv-krb5.c, used for OS X had reversed boolean logic meaning that the code will fail if ever the OD lookup or the group membership calls returned success. Obviously this is wrong, but even more so the log messages were a bit sparse so it was hard to see why the PAM call was being rejected. This commit fixes the logic and adds in some extra log messages in the case of failure. --- gss-serv-krb5.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/gss-serv-krb5.c b/gss-serv-krb5.c index ae4ee1c..879c76a 100644 --- a/gss-serv-krb5.c +++ b/gss-serv-krb5.c @@ -91,26 +91,29 @@ od_kuserok(krb5_context context, krb5_principal principal, const char *luser) uuid_t krb_uuid, un_uuid; ret = krb5_unparse_name(context, principal, &kprinc); - if (!ret) { + if (ret) { logit("od_kuserok - krb5_unparse_name failed: %d", ret); goto error; } ret = mbr_identifier_to_uuid(ID_TYPE_USERNAME, luser, strlen(luser), un_uuid); - if (!ret) { - logit("od_kuserok - mbr_identifier_to_uuid: %d", ret); + if (ret) { + logit("od_kuserok - mbr_identifier_to_uuid(%s) failed: %d", luser, ret); goto error; } ret = mbr_identifier_to_uuid(ID_TYPE_KERBEROS, kprinc, strlen(kprinc), krb_uuid); - if (!ret) { + if (ret) { + logit("od_kuserok - mbr_id_to_uuid(%s) failed: %d", kprinc, ret); goto error; } ret = uuid_compare(krb_uuid, un_uuid); if (0 == ret) { retval = TRUE; - } + } else { + logit("od_kuserok - uuids do not match, refusing"); + } error: if (kprinc) -- 1.7.10-rc2 > -----Original Message----- > From: Darren Tucker [mailto:dtucker at zip.com.au] > Sent: 30 March 2012 01:59 > To: Williams, Nick (Enterprise Infrastructure) > Cc: openssh-unix-dev at mindrot.org > Subject: Re: patch for OSX > > On Wed, Mar 28, 2012 at 01:01:51PM +0100, Williams, Nick wrote: > > Attached is a patch to make sshd work on OSX when using plain ol' > > Kerberos authentication as opposed to opendirectory authentication. > > Unfortunately your diff didn't make it to the list (it strips any > attachments that aren't plain text). Please resend as text or inline, > or open a bug at https://bugzilla.mindrot.org and attach it there. > > Thanks. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing. From xu_zhong_xing at 163.com Tue Apr 3 12:20:46 2012 From: xu_zhong_xing at 163.com (Xu Zhongxing) Date: Tue, 3 Apr 2012 10:20:46 +0800 (CST) Subject: Potential NULL pointer dereference Message-ID: <18a0700d.3e30.13676011d92.Coremail.xu_zhong_xing@163.com> In openssh 5.9p1, clientloop.c In line 1469, xxx_kex is checked against NULL, but at line 1513, xxx_kex is dereferenced directly. Is this inconsistent? From vnagrik at gmail.com Fri Apr 6 08:10:10 2012 From: vnagrik at gmail.com (Vinay Nagrik) Date: Thu, 5 Apr 2012 15:10:10 -0700 Subject: Need to build openssh rpm from 5.8 source Message-ID: Hello Openssh group, I have downloaded the .tar.gz file from openssh site openssh-5.8p2. I need to build this src into an rpm. I don?t see any makefile utility in the main directory. Although there are bunch of .c and .h files. And I see Makefile in other directory, but none seems to build the openssh-5.8p2 target. Could someone guide me as to how to build it from scratch. I am beginner to the list and need this help. -- Thanks Nagrik From imorgan at nas.nasa.gov Fri Apr 6 08:59:56 2012 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 5 Apr 2012 15:59:56 -0700 Subject: Need to build openssh rpm from 5.8 source In-Reply-To: References: Message-ID: <20120405225956.GC4747@linux124.nas.nasa.gov> On Thu, Apr 05, 2012 at 17:10:10 -0500, Vinay Nagrik wrote: > Hello Openssh group, > > I have downloaded the .tar.gz file from openssh site openssh-5.8p2. I need > to build this src into an rpm. I don?t see any makefile utility in the > main directory. Although there are bunch of .c and .h files. And I see > Makefile in other directory, but none seems to build the openssh-5.8p2 > target. > > Could someone guide me as to how to build it from scratch. > > I am beginner to the list and need this help. > -- > Thanks > > Nagrik Use rpmbuild in combination with one of the .spec files under the contrib directory, such as contrib/redhat/openssh.spec. -- Iain Morgan From nkadel at gmail.com Fri Apr 6 10:30:06 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 5 Apr 2012 20:30:06 -0400 Subject: Need to build openssh rpm from 5.8 source In-Reply-To: References: Message-ID: On Thu, Apr 5, 2012 at 6:10 PM, Vinay Nagrik wrote: > Hello Openssh group, > > I have downloaded the .tar.gz file from openssh site openssh-5.8p2. I need > to build this src into an rpm. I don?t see any makefile utility in the > main directory. Although there are bunch of .c and .h files. And I see > Makefile in other directory, but none seems to build the openssh-5.8p2 > target. > Grab the SRPM from the next upstream release. Fedora 16 has that SRPM. Review it and try to compile it locally, and be prepared to tweak dependencies. You don't mention which OS you're working from: RHEL 6 should be able to compile that SRPM without too much grief. configure.in and Makefile.in are used by the "autoconf" tool. You can try running "./configure" to see if it can find your necessary libraries and tools to compile. If you work from the SRPM, you can review how that tool is used for you. > Could someone guide me as to how to build it from scratch. > > I am beginner to the list and need this help. > -- Looks like you're a beginner to Linux software building as well: you may encounter some resistance from the OpenBSD purists, since OpenSSH is currently being maintained by the OpenBSD community. From eli at barzilay.org Fri Apr 6 18:18:09 2012 From: eli at barzilay.org (Eli Barzilay) Date: Fri, 6 Apr 2012 04:18:09 -0400 Subject: Feature request config entry for `-T' Message-ID: <20350.42689.820709.402368@winooski.ccs.neu.edu> Hi, AFAICT, there is no .ssh/config option for disabling pseudo-tty allocation. It would be nice to have one. Context: we're using gitolite in our project, and it sets things up to run a command with "no-pty". Every once in a while, users will try to ssh to the machine to see that things are working, and when they see the "PTY allocation request failed on channel 0" warning, they assume that something is broken. This happens infrequently enough that there is no way for people to remember the explanation, let alone remember to add a `-T'. However, they all have config entries for the server, so if an option to disable pty allocation in the config would have resolved this problem. Thanks, -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From dtucker at zip.com.au Fri Apr 6 20:08:07 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 6 Apr 2012 20:08:07 +1000 Subject: Feature request config entry for `-T' In-Reply-To: <20350.42689.820709.402368@winooski.ccs.neu.edu> References: <20350.42689.820709.402368@winooski.ccs.neu.edu> Message-ID: On Fri, Apr 6, 2012 at 6:18 PM, Eli Barzilay wrote: > AFAICT, there is no .ssh/config option for disabling pseudo-tty > allocation. ?It would be nice to have one. RequestTTY Specifies whether to request a pseudo-tty for the session. The argument may be one of: ``no'' (never request a TTY), ``yes'' (always request a TTY when standard input is a TTY), ``force'' (always request a TTY) or ``auto'' (request a TTY when opening a login session). This option mirrors the -t and -T flags for ssh(1). It was added in 5.9. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4? 37C9 C982 80C7 8FF4 FA69 ? ? Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From eli at barzilay.org Fri Apr 6 20:37:11 2012 From: eli at barzilay.org (Eli Barzilay) Date: Fri, 6 Apr 2012 06:37:11 -0400 Subject: Feature request config entry for `-T' In-Reply-To: References: <20350.42689.820709.402368@winooski.ccs.neu.edu> Message-ID: <20350.51031.933496.625677@winooski.ccs.neu.edu> 30 minutes ago, Darren Tucker wrote: > On Fri, Apr 6, 2012 at 6:18 PM, Eli Barzilay wrote: > > AFAICT, there is no .ssh/config option for disabling pseudo-tty > > allocation. ?It would be nice to have one. > > RequestTTY > Specifies whether to request a pseudo-tty for the session. The > argument may be one of: ``no'' (never request a TTY), ``yes'' > (always request a TTY when standard input is a TTY), ``force'' > (always request a TTY) or ``auto'' (request a TTY when opening a > login session). This option mirrors the -t and -T flags for > ssh(1). > > It was added in 5.9. Ah -- thanks! (Now all I need is to wait N years for this version to propagate...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! From calestyo at scientia.net Tue Apr 10 01:04:00 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Mon, 09 Apr 2012 17:04:00 +0200 Subject: ControlMaster and ControlPersist leads to zombie processes Message-ID: <24206a505218f4163e03a2811702373d@scientia.net> Hi. Perhaps you can help me with this: What I do is using Nagios (actually Icinga) and having checks on remote hosts executed via ssh. In order to dramatically speed checks up (from about 0,300 ms to 0,010 ms) I use ControlMaster = auto, which also makes the mux process spawned on the first check. As checks are typically sequentially scheduled I want the mux process to persist but it should also go away automatically after some days if not re-used (e.g. when I don't check a host anymore). So I have something like ControlPersist 2d. Now I stumbled across the following problem (and I'm actually not sure whether it's a ssh issue or Icinga): The first time the check is done (which is when the mux process is spawned) it times out. The mux process keeps running and everything works on subsequent checks. The timeout is one enforced by Icinga (60s), when it thinks the command doesn't return. I made some checks and the following turns out to happen on the FIRST connection: - executing the command on the remote side is actually done - on the local side, the ssh process (or a wrapper shell script around) becomes a zombie as soon as the remote command was executed - after 60s, when Icinga enforces it's timeout, the zombie goes away - the (local) mux process continues to run Any ideas why this could happen? Is there perhaps something that lets the parent processes notice that there is still a running child (i.e. the mux process)? Thanks, Chris. From anatol.pomozov at gmail.com Tue Apr 10 06:57:57 2012 From: anatol.pomozov at gmail.com (Anatol Pomozov) Date: Mon, 9 Apr 2012 13:57:57 -0700 Subject: How to set an attribute for a link? Message-ID: Hi, I am working on fuse4x (fuse for macosx) and sshfs. And I discovered a bug with sshfs when copying a link over sshfs is failed. It happens because sshfs tries to invoke SETSTAT on a link when target is not copied yet. I checked sshfs sources and found that it uses SSH_FXP_SETSTAT operation. https://github.com/fuse4x/sshfs/blob/master/sshfs.c#L2287 SSH_FXP_SETSTAT sets attributes to target file but I need to set an attribute to link itself. What I need is SSH_FXP_LSETSTAT. I tried to search over web and did not find any mention of SSH_FXP_LSETSTAT. Is there any official way to set an attribute for a link? Is there any openssh specific extension for it or maybe some workaround? Here is another related bug reported against linux debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640038 Thanks for you help. From reza.hedayat at adnovum.ch Wed Apr 11 18:11:03 2012 From: reza.hedayat at adnovum.ch (Reza Hedayat) Date: Wed, 11 Apr 2012 10:11:03 +0200 Subject: Invalid user name: function okname() in scp.c In-Reply-To: <4F63D924.6020708@gmail.com> References: <4F56500F.9040808@adnovum.ch> <4F565A2E.5040800@gmail.com> <4F572BA6.6010003@adnovum.ch> <4F607BE9.30508@adnovum.ch> <4F63D924.6020708@gmail.com> Message-ID: <4F853C97.3040203@adnovum.ch> Hi ?ngel Sorry for my late response, but your solution approach was in clarification. Unfortunately, all user names on the IBM AS/400 systems of our customer have a hash sign at the *first position*. Therefore, your solution will not solve this problem. As I've written in my last mail, SSH client and SFTP work perfectly with # characters in user names. Therefore, SCP should also work identically. So, why can't we just adapt the logic in SCP and allow # characters like in SSH and SFTP? Best wishes Reza On 03/17/12 01:21, ?ngel Gonz?lez wrote: > On 14/03/12 12:07, Reza Hedayat wrote: >> Hi ?ngel >> >> I just wanted to enquire if there is a chance that you will remove the >> hash sign (#) validation from the OpenSSH code base. >> >> Even the attempt to escape the # character results in rejection of the >> complete command by SCP. >> SSH client and SFTP work perfectly with # characters in user names, it >> is just SCP that rejects it. >> On the server side there are IBM AS/400 systems having usernames >> containing # characters, which are completely valid, legal and >> commonplace on that platform. >> >> Best wishes >> Reza > Hello Reza, > I gave it a go. See the attached patch. > I just allowed # in the middle of a word, which _should_ be safe to do, > as in it's only special for a shell as the first token character (per > POSIX rules). > It seems to work fine. > > Best regards > > > From mwlucas at blackhelicopters.org Fri Apr 13 03:18:58 2012 From: mwlucas at blackhelicopters.org (Michael W. Lucas) Date: Thu, 12 Apr 2012 13:18:58 -0400 Subject: SSH book for review Message-ID: <20120412171858.GA4645@bewilderbeast.blackhelicopters.org> Hi, I've recently published a short book on OpenSSH, as part of my "exterminate ALL the passwords" initiative. I'm giving copies to anyone who is interested in writing a review for a blog -- either theirs, or a tech association they're with, or basically anywhere. http://www.michaelwlucas.com/nonfiction/ssh-mastery Please contact me off-list if interested. Thanks, ==ml -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery mwlucas at BlackHelicopters.org, Twitter @mwlauthor From noreply+2541589697 at badoo.com Sat Apr 14 14:41:08 2012 From: noreply+2541589697 at badoo.com (Badoo) Date: Sat, 14 Apr 2012 04:41:08 +0000 Subject: Openssh Unix Dev, Amin left a message for you... Message-ID: <201204140441.q3E4fDI6025485@mailhub3.uq.edu.au> Amin left a message for you... Its sender and content will be shown only to you and you can delete it at any time. You can instantly reply to it, using the message exchange system. To find out what's in the message, just follow this link: http://eu1.badoo.com/0277236051/in/UWpmyyIhA-E/?lang_id=3&m=21&mid=4f88ffe30000000000030000977d94c1 Some other people in the area who are on Badoo Mikhail (Saint-Petersburg, Russia) Beheshte (Konar Kal, Iran) Danial (Bujnurd, Iran) http://eu1.badoo.com/0277236051/in/UWpmyyIhA-E/?lang_id=3&m=21&mid=4f88ffe30000000000030000977d94c1 If the link in this message does not work, try copying and pasting it into your browser. This email is part of our delivery procedure for the message sent by Amin. If you have received this email by mistake, please ignore it. The message will be deleted soon. Have fun! The Badoo Team You have received this email from Badoo Trading Limited (postal address below). http://eu1.badoo.com/impersonation.phtml?lang_id=3&mail_code=21&email=openssh-unix-dev%40mindrot.org&secret=&action=block&block_code=048e61&m=21&mid=4f88ffe30000000000030000977d94c1 Badoo Trading Limited is a limited company registered in England and Wales under CRN 7540255 with its registered office at 12 Red Lion Square, London, WC1R 4QD. From solo-openssl at goeswhere.com Mon Apr 16 03:43:29 2012 From: solo-openssl at goeswhere.com (solo-openssl at goeswhere.com) Date: Sun, 15 Apr 2012 18:43:29 +0100 Subject: Legacy MACs and Ciphers: Why? Message-ID: <20120415174329.GA32478@goeswhere.com> Why are legacy MACs (like md5-96), and legacy Ciphers (anything in cbc-mode, arcfour*(?)) enabled by default? My proposal would be to change the defaults for ssh_config and sshd_config to contain: MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1 Ciphers aes128-ctr,aes192-ctr,aes256-ctr ...removing md5, truncated versions of sha1, umac64 (for which I can find barely any review), any cipher in cbc mode and other non-mainstream algorithms. Additionally, why does ssh_config prefer hmac-md5 over less broken algorithms? Even if the above reduction of attack surface were not to happen, ssh_config could be changed such that the client prefers "more secure" algorithms if practical; i.e. change the default to: MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-ripemd160,umac-64 at openssh.com,hmac-md5,hmac-sha1-96,hmac-sha2-512-96,hmac-sha2-256-96,hmac-md5-96 "Ciphers" already "prefers" aes128-ctr, which seems reasonable. A quick review of available ssh clients [various free/shareware Windows clients (PuTTY derivatives (WinSCP), AbsoluteTelnet), dropbear, ConnectBot, Java libraries, ..], indicates universal support for hmac-sha1. hmac-sha256 and hmac-sha512, not so much. Everything I tested, however, was happy to ignore hmac-sha2-256 at the start of the specification list (as expected by the spec), as above. Incompatabilities of servers seem less important as the user may reconfigure the client. I am not aware of any widely deployed non-OpenSSH ssh servers to test against? I am aware that there are no attacks against MD5 with HMAC yet [RFC 6151], nor any widely reported practical attacks against cbc mode. I am aware that even SHA-1's use in as part of an HMAC construction has not been deprecated[1]. I feel that the migration away from otherwise deprecated technologies is the right way to go? If not, I'm interested in what decisions have been made with respect to these lists. Speed may be a consideration; MD5 is "faster"[2] than any of the SHA- algorithms. Maximum compatability, possibly. Anything else? [1]: http://csrc.nist.gov/groups/ST/hash/policy.html [2]: http://www.cryptopp.com/benchmarks.html From aris at 0xbadc0de.be Tue Apr 17 22:17:36 2012 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Tue, 17 Apr 2012 14:17:36 +0200 Subject: Legacy MACs and Ciphers: Why? In-Reply-To: <20120415174329.GA32478@goeswhere.com> References: <20120415174329.GA32478@goeswhere.com> Message-ID: <4F8D5F60.8010106@0xbadc0de.be> Hello, I am not an openssh developer, but as someone who has worked with the SSH protocol I have a few ideas on why it's not a so bad idea to keep these ciphers. First of all, as you mentioned, the list of the available ciphers can be used by the client to choose from, so the client can decide what is secure enough for it and select a cipher whose security is agreeing with his view on security and performance. An other important point is that the whole key exchange, including the list of the ciphers, is part of the session key calculation. It means that it is not possible to MiM a SSH connection and force the client to use an outdated cipher. And so the security of the protocol does not depend on the weakest cipher in the list (including macs). About the "weak" mac algorithms: the purpose of the HMAC is to protect the integrity of the content of an interactive session. It means that if an attacker can break a specific HMAC to insert his own content, he needs to do so in realtime, because SSH is a real time protocol. This greatly mitigates all known vulnerabilities in MD5, which require at least known plaintexts. To finish, my opinion as a libssh developer is that it's pain when a ssh server that is known to work perfectly with libssh at version X, stops to work at version X+1 because a perfectly working but slightly insecure version of cipher used in X is not available in X+1 anymore. While it's true that it's important to support the most secure ciphers, having enough time to do so is important. I'd like to add that some REQUIRED ciphers are in the RFC for a reason (opensolaris breaking aes128-cbc comes to my mind). Kr, Aris Le 15/04/12 19:43, solo-openssl at goeswhere.com a ?crit : > Why are legacy MACs (like md5-96), and legacy Ciphers (anything in > cbc-mode, arcfour*(?)) enabled by default? > > My proposal would be to change the defaults for ssh_config and > sshd_config to contain: > > MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1 > Ciphers aes128-ctr,aes192-ctr,aes256-ctr > > ...removing md5, truncated versions of sha1, umac64 (for > which I can find barely any review), any cipher in cbc mode > and other non-mainstream algorithms. > > Additionally, why does ssh_config prefer hmac-md5 over less > broken algorithms? > > Even if the above reduction of attack surface were not to happen, > ssh_config could be changed such that the client prefers > "more secure" algorithms if practical; i.e. change the default to: > MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-ripemd160,umac-64 at openssh.com,hmac-md5,hmac-sha1-96,hmac-sha2-512-96,hmac-sha2-256-96,hmac-md5-96 > > "Ciphers" already "prefers" aes128-ctr, which seems reasonable. > > > A quick review of available ssh clients [various free/shareware > Windows clients (PuTTY derivatives (WinSCP), AbsoluteTelnet), > dropbear, ConnectBot, Java libraries, ..], indicates universal > support for hmac-sha1. hmac-sha256 and hmac-sha512, not so much. > Everything I tested, however, was happy to ignore hmac-sha2-256 > at the start of the specification list (as expected by the spec), > as above. > > Incompatabilities of servers seem less important as the user may > reconfigure the client. I am not aware of any widely deployed > non-OpenSSH ssh servers to test against? > > I am aware that there are no attacks against MD5 with HMAC > yet [RFC 6151], nor any widely reported practical attacks against > cbc mode. I am aware that even SHA-1's use in as part of an HMAC > construction has not been deprecated[1]. > > I feel that the migration away from otherwise deprecated > technologies is the right way to go? If not, I'm interested > in what decisions have been made with respect to these lists. > Speed may be a consideration; MD5 is "faster"[2] than any of > the SHA- algorithms. Maximum compatability, possibly. > > Anything else? > > > [1]: http://csrc.nist.gov/groups/ST/hash/policy.html > [2]: http://www.cryptopp.com/benchmarks.html > > _______________________________________________ > 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 Thu Apr 19 22:19:10 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 19 Apr 2012 22:19:10 +1000 (EST) Subject: OpenSSL ASN.1 vulnerability: sshd not affected Message-ID: Hi, Tavis Ormandy found some bugs in OpenSSL's ASN.1 and buffer code that can be exploited to cause a heap overflow: http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html Fortunately OpenSSH's sshd is not vulnerable - it has avoided the use of ASN.1 parsing since 2002 when Markus wrote a custom RSA verification function (openssh_RSA_verify): http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-rsa.c?rev=HEAD;content-type=text%2Fplain That's now eight exploitable bugs that this change has saved us from. It's a good lesson in how excising even a relatively small amount of complex attack surface can make a substantial difference to the security of an application. This gloating only applies to sshd though - private key loading still uses the affected OpenSSL code, so if you are somehow allowing untrusted users to supply private keys to ssh, ssh-keygen or ssh-add in a privileged context then you should apply the OpenSSL fixes forthwith. -d From djm at mindrot.org Thu Apr 19 22:32:40 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 19 Apr 2012 22:32:40 +1000 (EST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <86ipi8y2wd.fsf@ds4.des.no> References: <868vjxbkkd.fsf@ds4.des.no> <86aa3qypb3.fsf@ds4.des.no> <86ipi8y2wd.fsf@ds4.des.no> Message-ID: On Tue, 13 Mar 2012, Dag-Erling Sm?rgrav wrote: > Damien Miller writes: > > Dag-Erling Sm?rgrav writes: > > > If I apply the patch and run autoreconf, config.h.in no longer contains > > > an entry for HAVE_OPENPTY, so although the configure script finds > > > openpty() in libutil, it still tries to build bsd-compat/openpty.c. > > okay, try this one please: > > That fixes openpty - but now it fails to build loginrec.c. FreeBSD has > UTMPX, and config.h is correct in that respect, but it still tries to > build parts of loginrec.c that are [UW]TMP-specific. > > See http://www.des.no/openssh/openssh-SNAP-20120313 for complete logs > and config.h. I've finally got around to installing FreeBSD to reproduce this. A fix[1] is in and will be in the 20120420 snapshot. -d [1] http://hg.mindrot.org/openssh/raw-rev/37678d290982 From aris at 0xbadc0de.be Fri Apr 20 05:49:56 2012 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Thu, 19 Apr 2012 21:49:56 +0200 Subject: OpenSSL ASN.1 vulnerability: sshd not affected In-Reply-To: References: Message-ID: <4F906C64.5090601@0xbadc0de.be> Le 19/04/12 14:19, Damien Miller a ?crit : > Fortunately OpenSSH's sshd is not vulnerable - it has avoided the use > of ASN.1 parsing since 2002 when Markus wrote a custom RSA verification > function (openssh_RSA_verify): Hi Damien, In order to check the impact that this bug has on other software using libcrypto, your email caught my eye. I have a hard day figuring out if RSA_verify from libcrypto is vulnerable. From what I could read, this bug is only exploitable when the ASN.1 parsing is done on BIO objects, and RSA_verify parses from memory, thus avoiding the bug. (I could see it calls d2i_X509_SIG() which is not bio nor fp). OpenSSL also claims [1] that this bug is not exploitable on SSL/TLS clients/servers, so my opinion is that OpenSSH (and other software using RSA_verify) are not vulnerable. But of course this doesn't alter anything in the good security practices in use for OpenSSH, that will protect from the next ASN.1 bug :) Aris [1] http://www.openssl.org/news/secadv_20120419.txt From openssh at roumenpetrov.info Fri Apr 20 07:04:43 2012 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Fri, 20 Apr 2012 00:04:43 +0300 Subject: OpenSSL ASN.1 vulnerability: sshd not affected In-Reply-To: References: Message-ID: <4F907DEB.8000601@roumenpetrov.info> Damien Miller wrote: > Hi, > > Tavis Ormandy found some bugs in OpenSSL's ASN.1 and buffer code that > can be exploited to cause a heap overflow: > > http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html > > Fortunately OpenSSH's sshd is not vulnerable - it has avoided the use > of ASN.1 parsing since 2002 when Markus wrote a custom RSA verification > function (openssh_RSA_verify): > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-rsa.c?rev=HEAD;content-type=text%2Fplain > > That's now eight exploitable bugs that this change has saved us from. > It's a good lesson in how excising even a relatively small amount of > complex attack surface can make a substantial difference to the security > of an application. > > This gloating only applies to sshd though - private key loading still > uses the affected OpenSSL code, so if you are somehow allowing untrusted > users to supply private keys to ssh, ssh-keygen or ssh-add in a > privileged context then you should apply the OpenSSL fixes forthwith. I cannot understand this sentence. Issue is with operation on file stream. I cannot remember exact version when key reading from streams was replaces by "atomic" operation - read file into memory and then use memory to parse. Please could you clarify are user programs vulnerable or not ? > -d > Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From djm at mindrot.org Fri Apr 20 10:08:22 2012 From: djm at mindrot.org (Damien Miller) Date: Fri, 20 Apr 2012 10:08:22 +1000 (EST) Subject: OpenSSL ASN.1 vulnerability: sshd not affected In-Reply-To: <4F906C64.5090601@0xbadc0de.be> References: <4F906C64.5090601@0xbadc0de.be> Message-ID: On Thu, 19 Apr 2012, Aris Adamantiadis wrote: > Le 19/04/12 14:19, Damien Miller a ?crit : > > Fortunately OpenSSH's sshd is not vulnerable - it has avoided the use > > of ASN.1 parsing since 2002 when Markus wrote a custom RSA verification > > function (openssh_RSA_verify): > > Hi Damien, > > In order to check the impact that this bug has on other software using > libcrypto, your email caught my eye. > I have a hard day figuring out if RSA_verify from libcrypto is > vulnerable. From what I could read, this bug is only exploitable when > the ASN.1 parsing is done on BIO objects, and RSA_verify parses from > memory, thus avoiding the bug. (I could see it calls d2i_X509_SIG() > which is not bio nor fp). > OpenSSL also claims [1] that this bug is not exploitable on SSL/TLS > clients/servers, so my opinion is that OpenSSH (and other software > using RSA_verify) are not vulnerable. > > But of course this doesn't alter anything in the good security > practices in use for OpenSSH, that will protect from the next ASN.1 bug :) Yes, I think you're right - the bug is only hit when calling d2i_*_(bio|fp) functions. I believed these were done implicitly when parsing DER-encoded structures and PEM-encoded keys, but a few people have told me that this is not the case. My gloating was therefore misplaced. Tavis' findings did include and depend on another problem in OpenSSL's memory buffer code. This bug seems like it could enable exploitability of other bugs that have not yet been found or made public, so IMO it would be a good idea to patch anyway. -d From cjwatson at debian.org Sat Apr 21 19:56:18 2012 From: cjwatson at debian.org (Colin Watson) Date: Sat, 21 Apr 2012 10:56:18 +0100 Subject: [regid23@yahoo.com: Bug#669667: faq.html: missing separator between two distinct shell command s] Message-ID: <20120421095617.GD10046@riva.dynamic.greenend.org.uk> I received the attached bug report from a Debian user; it applies to http://www.openssh.com/faq.html (I ship a copy of the FAQ in the Debian package). Could somebody make this adjustment on the OpenSSH web site? Thanks, -- Colin Watson [cjwatson at debian.org] -------------- next part -------------- An embedded message was scrubbed... From: Regid Ichira Subject: Bug#669667: faq.html: missing separator between two distinct shell command s Date: Fri, 20 Apr 2012 13:34:28 -0700 (PDT) Size: 6437 URL: From dtucker at zip.com.au Sat Apr 21 22:13:13 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 21 Apr 2012 22:13:13 +1000 Subject: [regid23@yahoo.com: Bug#669667: faq.html: missing separator between two distinct shell command s] In-Reply-To: <20120421095617.GD10046@riva.dynamic.greenend.org.uk> References: <20120421095617.GD10046@riva.dynamic.greenend.org.uk> Message-ID: <20120421121313.GA13684@gate.dtucker.net> On Sat, Apr 21, 2012 at 10:56:18AM +0100, Colin Watson wrote: > I received the attached bug report from a Debian user; it applies to > http://www.openssh.com/faq.html (I ship a copy of the FAQ in the Debian > package). Could somebody make this adjustment on the OpenSSH web site? Applied, thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From des at des.no Fri Apr 20 22:06:08 2012 From: des at des.no (Dag-Erling =?utf-8?Q?Sm=C3=B8rgrav?=) Date: Fri, 20 Apr 2012 14:06:08 +0200 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: (Damien Miller's message of "Thu, 19 Apr 2012 22:32:40 +1000 (EST)") References: <868vjxbkkd.fsf@ds4.des.no> <86aa3qypb3.fsf@ds4.des.no> <86ipi8y2wd.fsf@ds4.des.no> Message-ID: <86fwbyvc9b.fsf@ds4.des.no> Damien Miller writes: > Dag-Erling Sm?rgrav writes: > > That fixes openpty - but now it fails to build loginrec.c. FreeBSD has > > UTMPX, and config.h is correct in that respect, but it still tries to > > build parts of loginrec.c that are [UW]TMP-specific. > I've finally got around to installing FreeBSD to reproduce this. A fix[1] > is in and will be in the 20120420 snapshot. I just downloaded 20120420 and tried to build it; it fails in the exact same place. Logs at . DES -- Dag-Erling Sm?rgrav - des at des.no From dtucker at zip.com.au Sun Apr 22 10:13:02 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 22 Apr 2012 10:13:02 +1000 Subject: patch for OSX In-Reply-To: References: <20120330005907.GA5787@gate.dtucker.net> Message-ID: <20120422001302.GA16122@gate.dtucker.net> Nick had problems sending the patch to the list, so I'm just passing this along. I'm not sure that the patch is correct, but the man page for krb5_unparse_name does say "If no errors occur, the return value is 0. Otherwise, a Kerberos error code is returned." ------------------------------------ Gah, email filters stripping usefulness! Sorry. I've removed the GIT patch headers just to get the diff through ;-). Let me know if this works. Cheers, Nick The opendirectory lookups in gss-serv-krb5.c, used for OS X had reversed boolean logic meaning that the code will fail if ever the OD lookup or the group membership calls returned success. Obviously this is wrong, but even more so the log messages were a bit sparse so it was hard to see why the PAM call was being rejected. This commit fixes the logic and adds in some extra log messages in the case of failure. --- gss-serv-krb5.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/gss-serv-krb5.c b/gss-serv-krb5.c index ae4ee1c..879c76a 100644 --- a/gss-serv-krb5.c +++ b/gss-serv-krb5.c @@ -91,26 +91,29 @@ od_kuserok(krb5_context context, krb5_principal principal, const char *luser) uuid_t krb_uuid, un_uuid; ret = krb5_unparse_name(context, principal, &kprinc); - if (!ret) { + if (ret) { logit("od_kuserok - krb5_unparse_name failed: %d", ret); goto error; } ret = mbr_identifier_to_uuid(ID_TYPE_USERNAME, luser, strlen(luser), un_uuid); - if (!ret) { - logit("od_kuserok - mbr_identifier_to_uuid: %d", ret); + if (ret) { + logit("od_kuserok - mbr_identifier_to_uuid(%s) failed: %d", luser, ret); goto error; } ret = mbr_identifier_to_uuid(ID_TYPE_KERBEROS, kprinc, strlen(kprinc), krb_uuid); - if (!ret) { + if (ret) { + logit("od_kuserok - mbr_id_to_uuid(%s) failed: %d", kprinc, ret); goto error; } ret = uuid_compare(krb_uuid, un_uuid); if (0 == ret) { retval = TRUE; - } + } else { + logit("od_kuserok - uuids do not match, refusing"); + } error: if (kprinc) -- 1.7.10-rc2 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Sun Apr 22 10:19:23 2012 From: djm at mindrot.org (Damien Miller) Date: Sun, 22 Apr 2012 10:19:23 +1000 (EST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <86fwbyvc9b.fsf@ds4.des.no> References: <868vjxbkkd.fsf@ds4.des.no> <86aa3qypb3.fsf@ds4.des.no> <86ipi8y2wd.fsf@ds4.des.no> <86fwbyvc9b.fsf@ds4.des.no> Message-ID: On Fri, 20 Apr 2012, Dag-Erling Sm?rgrav wrote: > Damien Miller writes: > > Dag-Erling Sm?rgrav writes: > > > That fixes openpty - but now it fails to build loginrec.c. FreeBSD has > > > UTMPX, and config.h is correct in that respect, but it still tries to > > > build parts of loginrec.c that are [UW]TMP-specific. > > I've finally got around to installing FreeBSD to reproduce this. A fix[1] > > is in and will be in the 20120420 snapshot. > > I just downloaded 20120420 and tried to build it; it fails in the exact > same place. Logs at . Actually, it's failing in loginrec.c now and not openpty() anymore. It looks like it is failing to pick up that it should be using utmpx. I reproduced the previous problem on FreeBSD 9, and it compiled without error. I'll try to get a FreeBSD 10 VM up next week, but it will be too late for the 6.0 release, sorry. -d From djm at cvs.openbsd.org Sun Apr 22 10:53:12 2012 From: djm at cvs.openbsd.org (Damien Miller) Date: Sat, 21 Apr 2012 18:53:12 -0600 (MDT) Subject: Announce: OpenSSH 6.0 released Message-ID: <201204220053.q3M0rCYY012084@cvs.openbsd.org> OpenSSH 6.0 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Changes since OpenSSH 5.9 ========================= This is primarily a bugfix release. Features: * ssh-keygen(1): Add optional checkpoints for moduli screening * ssh-add(1): new -k option to load plain keys (skipping certificates) * sshd(8): Add wildcard support to PermitOpen, allowing things like "PermitOpen localhost:*". bz #1857 * ssh(1): support for cancelling local and remote port forwards via the multiplex socket. Use ssh -O cancel -L xx:xx:xx -R yy:yy:yy user at host" to request the cancellation of the specified forwardings * support cancellation of local/dynamic forwardings from ~C commandline Bugfixes: * ssh(1): ensure that $DISPLAY contains only valid characters before using it to extract xauth data so that it can't be used to play local shell metacharacter games. * ssh(1): unbreak remote portforwarding with dynamic allocated listen ports * scp(1): uppress adding '--' to remote commandlines when the first argument does not start with '-'. saves breakage on some difficult-to-upgrade embedded/router platforms * ssh(1)/sshd(8): fix typo in IPQoS parsing: there is no "AF14" class, but there is an "AF21" class * ssh(1)/sshd(8): do not permit SSH2_MSG_SERVICE_REQUEST/ACCEPT during rekeying * ssh(1): skip attempting to create ~/.ssh when -F is passed * sshd(8): unbreak stdio forwarding when ControlPersist is in use; bz#1943 * sshd(1): send tty break to pty master instead of (probably already closed) slave side; bz#1859 * sftp(1): silence error spam for "ls */foo" in directory with files; bz#1683 * Fixed a number of memory and file descriptor leaks Portable OpenSSH: * Add a new privilege separation sandbox implementation for Linux's new seccomp sandbox, automatically enabled on platforms that support it. (Note: privilege separation sandboxing is still experimental) * Fix compilation problems on FreeBSD, where libutil contained openpty() but not login(). * ssh-keygen(1): don't fail in -A on platforms that don't support ECC * Add optional support for LDNS, a BSD licensed DNS resolver library which supports DNSSEC * Relax OpenSSL version check to allow running OpenSSH binaries on systems with OpenSSL libraries with a newer "fix" or "patch" level than the binaries were originally compiled on (previous check only allowed movement within "patch" releases). bz#1991 * Fix builds using contributed Redhat spec file. bz#1992 Checksums: ========== - SHA1 (openssh-6.0.tar.gz) = 5d30aba0423c44e89924bb44c5d2153635506a9f - SHA1 (openssh-6.0p1.tar.gz) = f691e53ef83417031a2854b8b1b661c9c08e4422 Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From philipp.marek at linbit.com Wed Apr 25 18:02:11 2012 From: philipp.marek at linbit.com (Philipp Marek) Date: Wed, 25 Apr 2012 10:02:11 +0200 Subject: Feature request: virtual servers Message-ID: <201204251002.11357.philipp.marek@linbit.com> Hello everybody, I'd like to get SSH provide some virtual server feature. Eg. when connecting to an existing server on a different port I'd like to chroot all users to some directory. This can currently be done by starting sshd twice, with different config files (or perhaps command line options); but getting that "right" for all circumstances (init.d, upstart, systemd, ...) is hard. So I'd like to ask for the "Match" statements to allow matching the accepting port number and/or IP address. Another example: when connecting to a service-IP-address I want to use some "common" host keys, not the per-server generated ones; but, as the files might only get accessible when the service IP is on this machine, too, that would mean loading the server keys _after_ accepting the connection ... so that might be a bit more work, but would be much appreciated! Regards, Phil From djm at mindrot.org Thu Apr 26 09:34:53 2012 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Apr 2012 09:34:53 +1000 (EST) Subject: Feature request: virtual servers In-Reply-To: <201204251002.11357.philipp.marek@linbit.com> References: <201204251002.11357.philipp.marek@linbit.com> Message-ID: On Wed, 25 Apr 2012, Philipp Marek wrote: > Hello everybody, > > I'd like to get SSH provide some virtual server feature. > > > Eg. when connecting to an existing server on a different port I'd like to > chroot all users to some directory. > > This can currently be done by starting sshd twice, with different config > files (or perhaps command line options); but getting that "right" for all > circumstances (init.d, upstart, systemd, ...) is hard. > > So I'd like to ask for the "Match" statements to allow matching the > accepting port number and/or IP address. I think Darren had a pending patch for this. Darren? > Another example: when connecting to a service-IP-address I want to use some > "common" host keys, not the per-server generated ones; but, as the files > might only get accessible when the service IP is on this machine, too, that > would mean loading the server keys _after_ accepting the connection ... so > that might be a bit more work, but would be much appreciated! It isn't entirely clear what you are trying to achieve here. But, if I'm understanding you right, couldn't you start a sshd with the right keys at the time the service IP is assigned to the host? sshd doesn't support varying the host keys based on local or remote address/ port now and it's probably not something we're interested in supporting in the future (it would add quite a bit of complexity for something that can be achieved by running multiple instances). -d From dtucker at zip.com.au Thu Apr 26 13:50:42 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 26 Apr 2012 13:50:42 +1000 Subject: Feature request: virtual servers In-Reply-To: References: <201204251002.11357.philipp.marek@linbit.com> Message-ID: <20120426035042.GA27364@gate.dtucker.net> On Thu, Apr 26, 2012 at 09:34:53AM +1000, Damien Miller wrote: > On Wed, 25 Apr 2012, Philipp Marek wrote: [...] > > So I'd like to ask for the "Match" statements to allow matching the > > accepting port number and/or IP address. > > I think Darren had a pending patch for this. Darren? Here's the diff (I haven't looked at in a while, but it should apply cleanly to 6.0. It still builds OK). It adds "Match LocalAddress" and "Match LocalPort" which does pretty much what it says on the tin. Index: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/auth.c,v retrieving revision 1.150 diff -u -p -r1.150 auth.c --- auth.c 22 Apr 2012 01:21:43 -0000 1.150 +++ auth.c 26 Apr 2012 03:37:07 -0000 @@ -545,9 +545,14 @@ getpwnamallow(const char *user) #endif #endif struct passwd *pw; + extern ConnectionInfo connection_info; - parse_server_match_config(&options, user, - get_canonical_hostname(options.use_dns), get_remote_ipaddr()); + connection_info.user = user; + connection_info.host = get_canonical_hostname(options.use_dns); + connection_info.address = get_remote_ipaddr(); + connection_info.laddress = get_local_ipaddr(packet_get_connection_in()); + connection_info.lport = get_local_port(); + parse_server_match_config(&options, &connection_info); #if defined(_AIX) && defined(HAVE_SETAUTHDB) aix_setauthdb(user); Index: servconf.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/servconf.c,v retrieving revision 1.222 diff -u -p -r1.222 servconf.c --- servconf.c 22 Apr 2012 01:24:44 -0000 1.222 +++ servconf.c 26 Apr 2012 03:37:07 -0000 @@ -601,19 +601,20 @@ out: } static int -match_cfg_line(char **condition, int line, const char *user, const char *host, - const char *address) +match_cfg_line(char **condition, int line, ConnectionInfo *ci) { - int result = 1; + int result = 1, port; char *arg, *attrib, *cp = *condition; size_t len; - if (user == NULL) + if (ci == NULL) debug3("checking syntax for 'Match %s'", cp); else - debug3("checking match for '%s' user %s host %s addr %s", cp, - user ? user : "(null)", host ? host : "(null)", - address ? address : "(null)"); + debug3("checking match for '%s' user %s host %s addr %s " + "laddr %s lport %d", cp, ci->user ? ci->user : "(null)", + ci->host ? ci->host : "(null)", + ci->address ? ci->address : "(null)", + ci->laddress ? ci->laddress : "(null)", ci->lport); while ((attrib = strdelim(&cp)) && *attrib != '\0') { if ((arg = strdelim(&cp)) == NULL || *arg == '\0') { @@ -622,37 +623,45 @@ match_cfg_line(char **condition, int lin } len = strlen(arg); if (strcasecmp(attrib, "user") == 0) { - if (!user) { + if (ci == NULL || ci->user == NULL) { result = 0; continue; } - if (match_pattern_list(user, arg, len, 0) != 1) + if (match_pattern_list(ci->user, arg, len, 0) != 1) result = 0; else debug("user %.100s matched 'User %.100s' at " - "line %d", user, arg, line); + "line %d", ci->user, arg, line); } else if (strcasecmp(attrib, "group") == 0) { - switch (match_cfg_line_group(arg, line, user)) { + if (ci == NULL || ci->user == NULL) { + result = 0; + continue; + } + switch (match_cfg_line_group(arg, line, ci->user)) { case -1: return -1; case 0: result = 0; } } else if (strcasecmp(attrib, "host") == 0) { - if (!host) { + if (ci == NULL || ci->host == NULL) { result = 0; continue; } - if (match_hostname(host, arg, len) != 1) + if (match_hostname(ci->host, arg, len) != 1) result = 0; else debug("connection from %.100s matched 'Host " - "%.100s' at line %d", host, arg, line); + "%.100s' at line %d", ci->host, arg, line); } else if (strcasecmp(attrib, "address") == 0) { - switch (addr_match_list(address, arg)) { + if (ci == NULL || ci->address == NULL) { + result = 0; + continue; + } + switch (addr_match_list(ci->address, arg)) { case 1: debug("connection from %.100s matched 'Address " - "%.100s' at line %d", address, arg, line); + "%.100s' at line %d", ci->address, arg, line); break; case 0: case -1: @@ -661,12 +670,42 @@ match_cfg_line(char **condition, int lin case -2: return -1; } + } else if (strcasecmp(attrib, "localaddress") == 0){ + if (ci == NULL || ci->laddress == NULL) { + result = 0; + continue; + } + switch (addr_match_list(ci->laddress, arg)) { + case 1: + debug("connection from %.100s matched " + "'LocalAddress %.100s' at line %d", + ci->laddress, arg, line); + break; + case 0: + case -1: + result = 0; + break; + case -2: + return -1; + } + } else if (strcasecmp(attrib, "localport") == 0) { + if ((port = a2port(arg)) == -1) { + error("Invalid LocalPort '%s' on Match line", + arg); + return -1; + } + if (ci == NULL) { + result = 0; + continue; + } + if (a2port(arg) == ci->lport) + result = 1; } else { error("Unsupported Match attribute %s", attrib); return -1; } } - if (user != NULL) + if (ci != NULL) debug3("match %sfound", result ? "" : "not "); *condition = cp; return result; @@ -713,8 +752,8 @@ static const struct multistate multistat int process_server_config_line(ServerOptions *options, char *line, - const char *filename, int linenum, int *activep, const char *user, - const char *host, const char *address) + const char *filename, int linenum, int *activep, + ConnectionInfo *connectinfo) { char *cp, **charptr, *arg, *p; int cmdline = 0, *intptr, value, value2, n; @@ -745,7 +784,7 @@ process_server_config_line(ServerOptions if (*activep && opcode != sMatch) debug3("%s:%d setting %s %s", filename, linenum, arg, cp); if (*activep == 0 && !(flags & SSHCFG_MATCH)) { - if (user == NULL) { + if (connectinfo == NULL) { fatal("%s line %d: Directive '%s' is not allowed " "within a Match block", filename, linenum, arg); } else { /* this is a directive we have already processed */ @@ -1316,7 +1355,7 @@ process_server_config_line(ServerOptions if (cmdline) fatal("Match directive not supported as a command-line " "option"); - value = match_cfg_line(&cp, linenum, user, host, address); + value = match_cfg_line(&cp, linenum, connectinfo); if (value < 0) fatal("%s line %d: Bad Match condition", filename, linenum); @@ -1478,16 +1517,57 @@ load_server_config(const char *filename, } void -parse_server_match_config(ServerOptions *options, const char *user, - const char *host, const char *address) +parse_server_match_config(ServerOptions *options, ConnectionInfo *connectinfo) { ServerOptions mo; initialize_server_options(&mo); - parse_server_config(&mo, "reprocess config", &cfg, user, host, address); + parse_server_config(&mo, "reprocess config", &cfg, connectinfo); copy_set_server_options(options, &mo, 0); } +int parse_server_match_testspec(ConnectionInfo *ci, char *spec) +{ + char *p; + + while ((p = strsep(&spec, ",")) && *p != '\0') { + if (strncmp(p, "addr=", 5) == 0) + ci->address = xstrdup(p + 5); + else if (strncmp(p, "host=", 5) == 0) + ci->host = xstrdup(p + 5); + else if (strncmp(p, "user=", 5) == 0) + ci->user = xstrdup(p + 5); + else if (strncmp(p, "laddr=", 6) == 0) + ci->laddress = xstrdup(p + 6); + else if (strncmp(p, "lport=", 6) == 0) + ci->lport = a2port(p + 6); + if (ci->lport == -1) { + fprintf(stderr, "Invalid port '%s' in test mode" + " specification %s\n", p+6, p); + return -1; + } + else { + fprintf(stderr, "Invalid test mode specification %s\n", + p); + return -1; + } + } + return 0; +} + +/* + * returns 1 for a complete spec, 0 for partial spec and -1 for an + * empty spec. + */ +int server_match_spec_complete(ConnectionInfo *ci) +{ + if (ci->user && ci->host && ci->address) + return 1; /* complete */ + if (!ci->user && !ci->host && !ci->address) + return -1; /* empty */ + return 0; /* partial */ +} + /* Helper macros */ #define M_CP_INTOPT(n) do {\ if (src->n != -1) \ @@ -1561,7 +1641,7 @@ copy_set_server_options(ServerOptions *d void parse_server_config(ServerOptions *options, const char *filename, Buffer *conf, - const char *user, const char *host, const char *address) + ConnectionInfo *connectinfo) { int active, linenum, bad_options = 0; char *cp, *obuf, *cbuf; @@ -1569,11 +1649,11 @@ parse_server_config(ServerOptions *optio debug2("%s: config %s len %d", __func__, filename, buffer_len(conf)); obuf = cbuf = xstrdup(buffer_ptr(conf)); - active = user ? 0 : 1; + active = connectinfo ? 0 : 1; linenum = 1; while ((cp = strsep(&cbuf, "\n")) != NULL) { if (process_server_config_line(options, cp, filename, - linenum++, &active, user, host, address) != 0) + linenum++, &active, connectinfo) != 0) bad_options++; } xfree(obuf); Index: servconf.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/servconf.h,v retrieving revision 1.92 diff -u -p -r1.92 servconf.h --- servconf.h 22 Apr 2012 01:24:44 -0000 1.92 +++ servconf.h 26 Apr 2012 03:37:07 -0000 @@ -170,6 +170,17 @@ typedef struct { char *version_addendum; /* Appended to SSH banner */ } ServerOptions; + +/* Information about the incoming connection as used by Match */ +typedef struct { + const char *user; + const char *host; /* possibly resolved hostname */ + const char *address; /* remote address */ + const char *laddress; /* local address */ + int lport; /* local port */ +} ConnectionInfo; + + /* * These are string config options that must be copied between the * Match sub-config and the main config, and must be sent from the @@ -187,12 +198,13 @@ typedef struct { void initialize_server_options(ServerOptions *); void fill_default_server_options(ServerOptions *); int process_server_config_line(ServerOptions *, char *, const char *, int, - int *, const char *, const char *, const char *); + int *, ConnectionInfo *); void load_server_config(const char *, Buffer *); void parse_server_config(ServerOptions *, const char *, Buffer *, - const char *, const char *, const char *); -void parse_server_match_config(ServerOptions *, const char *, const char *, - const char *); + ConnectionInfo *); +void parse_server_match_config(ServerOptions *, ConnectionInfo *); +int parse_server_match_testspec(ConnectionInfo *, char *); +int server_match_spec_complete(ConnectionInfo *); void copy_set_server_options(ServerOptions *, ServerOptions *, int); void dump_config(ServerOptions *); char *derelativise_path(const char *); Index: sshd.8 =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.8,v retrieving revision 1.225 diff -u -p -r1.225 sshd.8 --- sshd.8 2 Oct 2011 07:57:38 -0000 1.225 +++ sshd.8 10 Oct 2011 06:14:47 -0000 @@ -114,6 +114,8 @@ The connection parameters are supplied a The keywords are .Dq user , .Dq host , +.Dq laddr , +.Dq lport , and .Dq addr . All are required and may be supplied in any order, either with multiple Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.c,v retrieving revision 1.413 diff -u -p -r1.413 sshd.c --- sshd.c 22 Apr 2012 01:24:44 -0000 1.413 +++ sshd.c 26 Apr 2012 03:37:07 -0000 @@ -143,6 +143,9 @@ extern char *__progname; /* Server configuration options. */ ServerOptions options; +/* Connection information used by Match */ +ConnectionInfo connection_info; + /* Name of the server configuration file. */ char *config_file_name = _PATH_SERVER_CONFIG_FILE; @@ -1325,9 +1328,8 @@ main(int ac, char **av) int opt, i, j, on = 1; int sock_in = -1, sock_out = -1, newsock = -1; const char *remote_ip; - char *test_user = NULL, *test_host = NULL, *test_addr = NULL; int remote_port; - char *line, *p, *cp; + char *line; int config_s[2] = { -1 , -1 }; u_int64_t ibytes, obytes; mode_t new_umask; @@ -1454,20 +1456,9 @@ main(int ac, char **av) test_flag = 2; break; case 'C': - cp = optarg; - while ((p = strsep(&cp, ",")) && *p != '\0') { - if (strncmp(p, "addr=", 5) == 0) - test_addr = xstrdup(p + 5); - else if (strncmp(p, "host=", 5) == 0) - test_host = xstrdup(p + 5); - else if (strncmp(p, "user=", 5) == 0) - test_user = xstrdup(p + 5); - else { - fprintf(stderr, "Invalid test " - "mode specification %s\n", p); - exit(1); - } - } + if (parse_server_match_testspec(&connection_info, + optarg) == -1) + exit(1); break; case 'u': utmp_len = (u_int)strtonum(optarg, 0, MAXHOSTNAMELEN+1, NULL); @@ -1479,7 +1470,7 @@ main(int ac, char **av) case 'o': line = xstrdup(optarg); if (process_server_config_line(&options, line, - "command-line", 0, NULL, NULL, NULL, NULL) != 0) + "command-line", 0, NULL, NULL) != 0) exit(1); xfree(line); break; @@ -1535,13 +1526,10 @@ main(int ac, char **av) * the parameters we need. If we're not doing an extended test, * do not silently ignore connection test params. */ - if (test_flag >= 2 && - (test_user != NULL || test_host != NULL || test_addr != NULL) - && (test_user == NULL || test_host == NULL || test_addr == NULL)) + if (test_flag >= 2 && server_match_spec_complete(&connection_info) == 0) fatal("user, host and addr are all required when testing " "Match configs"); - if (test_flag < 2 && (test_user != NULL || test_host != NULL || - test_addr != NULL)) + if (test_flag < 2 && server_match_spec_complete(&connection_info) >= 0) fatal("Config test connection parameter (-C) provided without " "test mode (-T)"); @@ -1553,7 +1541,7 @@ main(int ac, char **av) load_server_config(config_file_name, &cfg); parse_server_config(&options, rexeced_flag ? "rexec" : config_file_name, - &cfg, NULL, NULL, NULL); + &cfg, NULL); seed_rng(); @@ -1715,9 +1703,8 @@ main(int ac, char **av) } if (test_flag > 1) { - if (test_user != NULL && test_addr != NULL && test_host != NULL) - parse_server_match_config(&options, test_user, - test_host, test_addr); + if (server_match_spec_complete(&connection_info) == 1) + parse_server_match_config(&options, &connection_info); dump_config(&options); } Index: sshd_config.5 =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd_config.5,v retrieving revision 1.145 diff -u -p -r1.145 sshd_config.5 --- sshd_config.5 22 Apr 2012 01:25:11 -0000 1.145 +++ sshd_config.5 26 Apr 2012 03:37:07 -0000 @@ -677,6 +677,8 @@ The available criteria are .Cm User , .Cm Group , .Cm Host , +.Cm LocalAddress , +.Cm LocalPort , and .Cm Address . The match patterns may consist of single entries or comma-separated -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From philipp.marek at linbit.com Thu Apr 26 16:34:32 2012 From: philipp.marek at linbit.com (Philipp Marek) Date: Thu, 26 Apr 2012 08:34:32 +0200 Subject: Feature request: virtual servers In-Reply-To: <20120426035042.GA27364@gate.dtucker.net> References: <201204251002.11357.philipp.marek@linbit.com> <20120426035042.GA27364@gate.dtucker.net> Message-ID: <201204260834.33198.philipp.marek@linbit.com> On Thursday, 26. Apr 2012, Darren Tucker wrote: > On Thu, Apr 26, 2012 at 09:34:53AM +1000, Damien Miller wrote: > > On Wed, 25 Apr 2012, Philipp Marek wrote: > > > So I'd like to ask for the "Match" statements to allow matching the > > > accepting port number and/or IP address. > > > > I think Darren had a pending patch for this. Darren? > > Here's the diff (I haven't looked at in a while, but it should apply > cleanly to 6.0. It still builds OK). > > It adds "Match LocalAddress" and "Match LocalPort" which does pretty > much what it says on the tin. Hey, that's great! Could you put that in OpenSSH, so that -portable and the distributions can pick that up sometime? >> sshd doesn't support varying the host keys based on local or >> remote address/port now and it's probably not something we're >> interested in supporting in the future (it would add quite a >> bit of complexity for something that can be achieved by >> running multiple instances). Understood. For the service-IP address with failover it's not a problem to start a new SSHd; the only nice thing would be an "Include" statement, so that this instance only has definitions like HostKey ... HostKey ... HostKey ... Include /path/to/common/config Thank you very much! Regards, Phil -- : Ing. Philipp Marek : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com : DRBD? and LINBIT? are registered trademarks of LINBIT, Austria. From kurt.w.heberlein at hp.com Fri Apr 27 05:49:56 2012 From: kurt.w.heberlein at hp.com (Heberlein, Kurt William) Date: Thu, 26 Apr 2012 20:49:56 +0100 Subject: Max Packet Size in sshd server and negotiation with client Message-ID: Hi, Forgive what might be a basic question. In channel open processing the server has a hardcoded maximum of 35000 bytes which corresponds to the recommended value in RFC4253. It appears that this is open to negotiation, and the RFC implies it might be desirable to support larger sizes in some channels. What determines what the absolute maximum is in openssh sshd? Presumably no client can negotiate a maximum that is larger than that advertised by the server? Thanks Kurt Heberlein Senior Staff Software Engineer 3PAR R&D HP Storage www.hp.com (510) 668 9441 kurt dot w dot heberlein at-sign hp dot com From bert.wesarg at googlemail.com Fri Apr 27 19:29:56 2012 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Fri, 27 Apr 2012 11:29:56 +0200 Subject: [PATCH] mux: fix memory leak of control path if bind() fails Message-ID: <3aaa51afd883ceb37ec351a1bed24e8ba7a5883a.1335518820.git.bert.wesarg@googlemail.com> --- mux.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mux.c b/mux.c index d90605e..fa796bd 100644 --- a/mux.c +++ b/mux.c @@ -1195,6 +1195,7 @@ muxserver_listen(void) close(muxserver_sock); muxserver_sock = -1; } + xfree(orig_control_path); xfree(options.control_path); options.control_path = NULL; options.control_master = SSHCTL_MASTER_NO; @@ -1216,7 +1217,6 @@ muxserver_listen(void) } error("ControlSocket %s already exists, disabling multiplexing", orig_control_path); - xfree(orig_control_path); unlink(options.control_path); goto disable_mux_master; } -- 1.7.9.rc0.542.g07ca1 From des at des.no Fri Apr 27 21:43:25 2012 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 27 Apr 2012 13:43:25 +0200 Subject: [PATCH] mux: fix memory leak of control path if bind() fails In-Reply-To: <3aaa51afd883ceb37ec351a1bed24e8ba7a5883a.1335518820.git.bert.wesarg@googlemail.com> (Bert Wesarg's message of "Fri, 27 Apr 2012 11:29:56 +0200") References: <3aaa51afd883ceb37ec351a1bed24e8ba7a5883a.1335518820.git.bert.wesarg@googlemail.com> Message-ID: <86fwbpo0wy.fsf@ds4.des.no> Bert Wesarg writes: > + xfree(orig_control_path); so you want to free the buffer > error("ControlSocket %s already exists, disabling multiplexing", > orig_control_path); about 20 lines before passing it to a printf() equivalent? DES -- Dag-Erling Sm?rgrav - des at des.no From bert.wesarg at googlemail.com Fri Apr 27 21:47:07 2012 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Fri, 27 Apr 2012 13:47:07 +0200 Subject: [PATCH] mux: fix memory leak of control path if bind() fails In-Reply-To: <86fwbpo0wy.fsf@ds4.des.no> References: <3aaa51afd883ceb37ec351a1bed24e8ba7a5883a.1335518820.git.bert.wesarg@googlemail.com> <86fwbpo0wy.fsf@ds4.des.no> Message-ID: 2012/4/27 Dag-Erling Sm?rgrav : > Bert Wesarg writes: >> + ? ? ? ? ? ? ? ? ? ? xfree(orig_control_path); > > so you want to free the buffer > >> ? ? ? ? ? ? ? error("ControlSocket %s already exists, disabling multiplexing", >> ? ? ? ? ? ? ? ? ? orig_control_path); > > about 20 lines before passing it to a printf() equivalent? Luckily there is a return only 4 lines after the free. Bert > > DES > -- > Dag-Erling Sm?rgrav - des at des.no From dotancohen at gmail.com Mon Apr 30 23:55:00 2012 From: dotancohen at gmail.com (Dotan Cohen) Date: Mon, 30 Apr 2012 16:55:00 +0300 Subject: Transferring file to local machine when SSHing into a foreign box Message-ID: One can log into a remote shell via SSH, and one can use an FTP application to log in via SFTP using the same credentials over SSH. Why then, can one not initiate a file transfer from the remote host to the local host when logged into a shell via SSH? I know that I could use scp or rsync to move the files, but the requires authenticating which is not something that I can always do from the host. From my limited understanding the existing SSH connection is all that should be needed, as SSH has file transfer capability. Apparently quite a few people are interested in this feature, here is one example from many that can be found of people requesting this functionality: http://stackoverflow.com/questions/440524/ssh-a-way-to-transfer-files-without-opening-a-separate-sftp-session Would it be appropriate for me to file a feature request on the OpenSSH bugzilla, considering that I am not able to write the code to implement the feature? Thanks. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com