From daggs at gmx.com Sun Jun 1 04:02:33 2014 From: daggs at gmx.com (daggs) Date: Sat, 31 May 2014 20:02:33 +0200 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: , Message-ID: Greetings Darren, > Sent: Friday, May 30, 2014 at 4:33 PM > From: "Darren Tucker" > To: daggs > Cc: "OpenSSH Devel List" > Subject: Re: sftp session disconnects right after passwd enter > > On Fri, May 30, 2014 at 3:13 AM, daggs wrote: > [...] > > > > > This indicates that you are using a modified version of OpenSSH. Can > > you > > > > reproduce the problem with the stock version compiled from the code on > > > > openssh.com? > > > I'm running gentoo, no sure what patches get applied, will check. > > afai can see, this is are the patches which gets applied but only the > > latter is used as I don't compile openssh with X509 flag set. > > > [snip links to patches] > > > any ideas? > > > Yes, my idea was to actually try an unmodified version rather than just > guess. > tried that, it fails compilation with an unknown error. I'll try opening a bug in gentoo's bugzilla. see what they have to say on the matter > Other than that, look at what PAM modules are in the sshd stack and check > your system logs for errors from those at the time you try it. > > -- > 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. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From daggs at gmx.com Sun Jun 1 04:05:26 2014 From: daggs at gmx.com (daggs) Date: Sat, 31 May 2014 20:05:26 +0200 Subject: sftp session disconnects right after passwd enter In-Reply-To: <99132C7D-AB3E-45F3-B8C0-38E1F35305AB@offwriting.org> References: , <99132C7D-AB3E-45F3-B8C0-38E1F35305AB@offwriting.org> Message-ID: Greetings Ben, > Sent: Friday, May 30, 2014 at 5:27 PM > From: "Ben Lindstrom" > To: daggs > Cc: "OpenSSH Devel List" > Subject: Re: sftp session disconnects right after passwd enter > > > > On May 30, 2014, at 8:33 AM, Darren Tucker wrote: > > > On Fri, May 30, 2014 at 3:13 AM, daggs wrote: > > [...] > > > >>>> This indicates that you are using a modified version of OpenSSH. Can > >> you > >>>> reproduce the problem with the stock version compiled from the code on > >>>> openssh.com? > >>> I'm running gentoo, no sure what patches get applied, will check. > >> afai can see, this is are the patches which gets applied but only the > >> latter is used as I don't compile openssh with X509 flag set. > >> > > [snip links to patches] > > > >> any ideas? > > > > > > Yes, my idea was to actually try an unmodified version rather than just > > guess. > > > > Other than that, look at what PAM modules are in the sshd stack and check > > your system logs for errors from those at the time you try it. > > Since we were talking about this slightly earlier.. it may not be a bad idea to check > who owns the directories on /home/%u and such. As I suspect it isn't root, and > this will also cause you issues. > > - Ben > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > /home/%u belong to root:root, content doesn't. From daggs at gmx.com Mon Jun 2 05:56:59 2014 From: daggs at gmx.com (daggs) Date: Sun, 1 Jun 2014 21:56:59 +0200 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: , Message-ID: Greetings Darren, >Sent:?Friday, May 30, 2014 at 4:33 PM >From:?"Darren Tucker" >To:?daggs >Cc:?"OpenSSH Devel List" >Subject:?Re: sftp session disconnects right after passwd enter > >On Fri, May 30, 2014 at 3:13 AM, daggs wrote: >[...] >> > This indicates that you are using a modified version of OpenSSH. Can you > >> reproduce the problem with the stock version compiled from the code on >> > openssh.com[http://openssh.com]? >> I'm running gentoo, no sure what patches get applied, will check.afai can see, this is are the patches which gets applied but only the latter is used as I don't >compile openssh with X509 flag set. >[snip links to patches]?any ideas? > >Yes, my idea was to actually try an unmodified version rather than just guess. > >Other than that, look at what PAM modules are in the sshd stack and check your system logs for errors from those at the time you try it. I fixed a config issue, now it works without the ChrootDirectory, how can I fix it? Thanks. From keisial at gmail.com Mon Jun 2 06:39:17 2014 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Sun, 01 Jun 2014 22:39:17 +0200 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: , Message-ID: <538B8F75.4030507@gmail.com> On 01/06/14 21:56, daggs wrote: > I fixed a config issue, now it works without the ChrootDirectory, how > can I fix it? Thanks. What about changing /usr/lib64/misc/sftp-server to internal-sftp ? I suspect you don't have a /home/sftp_user/usr/lib64/misc/sftp-server binary ;) From nkadel at gmail.com Mon Jun 2 06:51:29 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 1 Jun 2014 16:51:29 -0400 Subject: sftp session disconnects right after passwd enter In-Reply-To: <538B8F75.4030507@gmail.com> References: <538B8F75.4030507@gmail.com> Message-ID: On Sun, Jun 1, 2014 at 4:39 PM, ?ngel Gonz?lez wrote: > On 01/06/14 21:56, daggs wrote: >> >> I fixed a config issue, now it works without the ChrootDirectory, how can >> I fix it? Thanks. > > What about changing /usr/lib64/misc/sftp-server to internal-sftp ? > > I suspect you don't have a /home/sftp_user/usr/lib64/misc/sftp-server binary > ;) He's right. You should, normally, be using the "internal-sftp" option for that SFTP binary. From daggs at gmx.com Mon Jun 2 15:17:08 2014 From: daggs at gmx.com (daggs) Date: Mon, 2 Jun 2014 07:17:08 +0200 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: <538B8F75.4030507@gmail.com>, Message-ID: Greetings Nico, ?ngel > Sent: Sunday, June 01, 2014 at 11:51 PM > From: "Nico Kadel-Garcia" > To: "?ngel Gonz?lez" > Cc: daggs , "openssh-unix-dev at mindrot.org" > Subject: Re: sftp session disconnects right after passwd enter > > On Sun, Jun 1, 2014 at 4:39 PM, ?ngel Gonz?lez wrote: > > On 01/06/14 21:56, daggs wrote: > >> > >> I fixed a config issue, now it works without the ChrootDirectory, how can > >> I fix it? Thanks. > > > > What about changing /usr/lib64/misc/sftp-server to internal-sftp ? > > > > I suspect you don't have a /home/sftp_user/usr/lib64/misc/sftp-server binary > > ;) > > He's right. You should, normally, be using the "internal-sftp" option > for that SFTP binary. > you are both correct, the first bug was that the path given to the binary didn't exists, after changing it to the correct path, I was able to connect without the chrootdirectory defined. but it seems that chrootdirectory can be used only with internal-sftp so I've modified it and it works. I do wonder why chrootdirectory can work only with internal-sftp thanks to all of the help. From nkadel at gmail.com Mon Jun 2 21:49:05 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 2 Jun 2014 07:49:05 -0400 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: <538B8F75.4030507@gmail.com> Message-ID: On Mon, Jun 2, 2014 at 1:17 AM, daggs wrote: > you are both correct, the first bug was that the path given to the binary didn't exists, after changing it to the correct path, I was able to connect without the chrootdirectory defined. > but it seems that chrootdirectory can be used only with internal-sftp so I've modified it and it works. > > I do wonder why chrootdirectory can work only with internal-sftp > > thanks to all of the help. Chroot cages are tricky. To use the specified binary, the full set of libraries and "devices" would have to be available in the chroot cage, at least as implemented in OpenSSH. It's also why the usernames and group memberships don't show up for the chrooted clients unless there is a copy of /etc/passwd and /etc/group in the chroot subdirectory with the relevant user and group entries. The chrooted programs are really, rally not supposed to be able to reach outside of that chroot cage for *any* other filesystem based resources. It's not an absolute protection: look up "chroot cage breaking" for examples of how people have historically escaped the cage. But I've found it to be a useful restriction to prevent casual system browsing by people I do *not* want looking at other user's home directories or system contents. Unfortunately, I also find the restrictions for SFTP to be burdensome. To set up multiple chroot cages for multiple users, one has to either make user specific sshd_config settings, or provide a "shared" top level root owned chroot cage that breaks the user isolation that is part of the whole point of chroot cages. That's why I use vsftpd and FTPS, instead. While it may not be as robustly built as OpenSSH's SFTP chroot, it's one heck of a lot easier to manage and configure, and can play very nicely in environments where people also have shell access. From daggs at gmx.com Tue Jun 3 00:30:56 2014 From: daggs at gmx.com (daggs) Date: Mon, 2 Jun 2014 16:30:56 +0200 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: <538B8F75.4030507@gmail.com> , Message-ID: Greetings Nico, > Sent: Monday, June 02, 2014 at 2:49 PM > From: "Nico Kadel-Garcia" > To: daggs > Cc: "openssh-unix-dev at mindrot.org" , "?ngel Gonz?lez" > Subject: Re: sftp session disconnects right after passwd enter > > On Mon, Jun 2, 2014 at 1:17 AM, daggs wrote: > > > you are both correct, the first bug was that the path given to the binary didn't exists, after changing it to the correct path, I was able to connect without the chrootdirectory defined. > > but it seems that chrootdirectory can be used only with internal-sftp so I've modified it and it works. > > > > I do wonder why chrootdirectory can work only with internal-sftp > > > > thanks to all of the help. > > Chroot cages are tricky. To use the specified binary, the full set of > libraries and "devices" would have to be available in the chroot cage, > at least as implemented in OpenSSH. It's also why the usernames and > group memberships don't show up for the chrooted clients unless there > is a copy of /etc/passwd and /etc/group in the chroot subdirectory > with the relevant user and group entries. The chrooted programs are > really, rally not supposed to be able to reach outside of that chroot > cage for *any* other filesystem based resources. > > It's not an absolute protection: look up "chroot cage breaking" for > examples of how people have historically escaped the cage. But I've > found it to be a useful restriction to prevent casual system browsing > by people I do *not* want looking at other user's home directories or > system contents. > > Unfortunately, I also find the restrictions for SFTP to be burdensome. > To set up multiple chroot cages for multiple users, one has to either > make user specific sshd_config settings, or provide a "shared" top > level root owned chroot cage that breaks the user isolation that is > part of the whole point of chroot cages. That's why I use vsftpd and > FTPS, instead. While it may not be as robustly built as OpenSSH's SFTP > chroot, it's one heck of a lot easier to manage and configure, and can > play very nicely in environments where people also have shell access. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > I've tried vsftpd but I didn't succeeded in configuring to do what I want (chroot env for a a specific user which connects via sftp by providing key for initial authentication followed by password when the origin is outside of a local lan).\ that is why I decided to go with sftp. From djm at mindrot.org Tue Jun 3 09:17:58 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 3 Jun 2014 09:17:58 +1000 (EST) Subject: sftp session disconnects right after passwd enter In-Reply-To: References: <538B8F75.4030507@gmail.com> Message-ID: On Mon, 2 Jun 2014, Nico Kadel-Garcia wrote: > Unfortunately, I also find the restrictions for SFTP to be burdensome. > To set up multiple chroot cages for multiple users, one has to either > make user specific sshd_config settings that's incorrect mkdir -p /chroot/user_a/sftp /chroot/user_b/sftp chown user_a /chroot/user_a/sftp ; chown user_b /chroot/user_b/sftp and in sshd_config: ChrootDirectory /chroot/%u Subsystem sftp internal-sftp -d /sftp From nkadel at gmail.com Tue Jun 3 11:40:16 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 2 Jun 2014 21:40:16 -0400 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: <538B8F75.4030507@gmail.com> Message-ID: On Mon, Jun 2, 2014 at 7:17 PM, Damien Miller wrote: > On Mon, 2 Jun 2014, Nico Kadel-Garcia wrote: > >> Unfortunately, I also find the restrictions for SFTP to be burdensome. >> To set up multiple chroot cages for multiple users, one has to either >> make user specific sshd_config settings > > that's incorrect > > mkdir -p /chroot/user_a/sftp /chroot/user_b/sftp > chown user_a /chroot/user_a/sftp ; chown user_b /chroot/user_b/sftp > > and in sshd_config: > > ChrootDirectory /chroot/%u > Subsystem sftp internal-sftp -d /sftp Interesting, but But it's certainly not in any of the documentation in the default OpenSSH for RHEL 6 or CentOS 6 which is still at OpenSSH 5.3p1. And it doesn't seem to work on that version. Building and maintaining a backported OpenSSH system is a lot of work. I've done it repeatedly, since my first work with SSH version 1 in 1996, and I don't recommend it for the faint of heart or those without compelling needs. I'm also afraid that your command line arguments are vulnerable to problems with individually set local 'umask' settings. I'd instead be sure to set the permissions as clearly as possible. Using the Gnu coreutils based "install" command, I would use: id -u user_a && id -g user_a && \ install -d /chroot/user_a -m 0755 -o root -g root && \ install -d /chroot/user_a/sftp -m 0700 -o user_a -g user_a id -u user_b && id -g user_b && \ install -d /chroot/user_b -m 0755 -o root -g root && \ install -d /chroot/user_b/sftp -m 0700 -o user_b -g user_b And if scripting it, I'd make it report error conditions more intelligently. I actually just went through tis with a test SFTP server. I'll look forward to a more recent version of OpenSSH that has the "-d" option for the "Subsystem sftp internal-sftp" settings. From info at cryptocrack.de Tue Jun 3 18:51:05 2014 From: info at cryptocrack.de (Lukas Fleischer) Date: Tue, 03 Jun 2014 10:51:05 +0200 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <3CCAL3N1Bhquf8R_OX2zsEExYhOXt7vPMvMXNbhKpFXgAuMp967Lw@mail.gmail.com> References: <3CCAL3N1Bhquf8R_OX2zsEExYhOXt7vPMvMXNbhKpFXgAuMp967Lw@mail.gmail.com> Message-ID: <20140603085105.1307.47556@typhoon> Hi, Are there any news on this? We are currently setting up a service that uses Git over SSH and a single UNIX account with public key authentication. We already have 25000 users (~10000 of which will be regularly using the service) and in order to avoid linear search on each login, it would be great to have support for looking up keys in a database. What is the status of the patch (using environment variables)? If there is anything that needs to be done to get this included into mainline, I would gladly help you with that. Regards, Lukas From sduckwo at clemson.edu Tue Jun 3 23:25:16 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Tue, 3 Jun 2014 09:25:16 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140603085105.1307.47556@typhoon> References: <3CCAL3N1Bhquf8R_OX2zsEExYhOXt7vPMvMXNbhKpFXgAuMp967Lw@mail.gmail.com> <20140603085105.1307.47556@typhoon> Message-ID: On Tue, Jun 3, 2014 at 4:51 AM, Lukas Fleischer wrote: > What is the status of the patch (using environment variables)? If there > is anything that needs to be done to get this included into mainline, I > would gladly help you with that. > The patch is stable for me - we've been using it for many months with no issues. It has been posted to the openssh bugzilla database at https://bugzilla.mindrot.org/show_bug.cgi?id=2081. It is also available at https://github.com/ScottDuckworth/openssh-akcenv. If you find it useful then please reply to the list or bump the bug report to get some attention put on it so that it might be included in mainline. From info at cryptocrack.de Wed Jun 4 05:32:48 2014 From: info at cryptocrack.de (Lukas Fleischer) Date: Tue, 03 Jun 2014 21:32:48 +0200 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <3CCAL3N1Bhquf8R_OX2zsEExYhOXt7vPMvMXNbhKpFXgAuMp967Lw@mail.gmail.com> <20140603085105.1307.47556@typhoon> Message-ID: <20140603193248.916.56510@typhoon.lan> On Tue, 03 Jun 2014 at 15:25:16, Scott Duckworth wrote: > On Tue, Jun 3, 2014 at 4:51 AM, Lukas Fleischer wrote: > > > What is the status of the patch (using environment variables)? If there > > is anything that needs to be done to get this included into mainline, I > > would gladly help you with that. > > > > The patch is stable for me - we've been using it for many months with no > issues. It has been posted to the openssh bugzilla database at > https://bugzilla.mindrot.org/show_bug.cgi?id=2081. It is also available at > https://github.com/ScottDuckworth/openssh-akcenv. > > If you find it useful then please reply to the list or bump the bug report > to get some attention put on it so that it might be included in mainline. Yes, this is extremely useful! Big +1. I wonder if there is a way to obtain a textual representation of the key without writing it to a temporary file, though? From sduckwo at clemson.edu Wed Jun 4 06:32:40 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Tue, 3 Jun 2014 16:32:40 -0400 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140603193248.916.56510@typhoon.lan> References: <3CCAL3N1Bhquf8R_OX2zsEExYhOXt7vPMvMXNbhKpFXgAuMp967Lw@mail.gmail.com> <20140603085105.1307.47556@typhoon> <20140603193248.916.56510@typhoon.lan> Message-ID: On Tue, Jun 3, 2014 at 3:32 PM, Lukas Fleischer wrote: > I wonder if there is a way to obtain a textual representation of the key > without writing it to a temporary file, though? > Agreed, that would be better. If anybody knows how to do this please chime in. From info at cryptocrack.de Wed Jun 4 07:14:30 2014 From: info at cryptocrack.de (Lukas Fleischer) Date: Tue, 03 Jun 2014 23:14:30 +0200 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: References: <3CCAL3N1Bhquf8R_OX2zsEExYhOXt7vPMvMXNbhKpFXgAuMp967Lw@mail.gmail.com> <20140603085105.1307.47556@typhoon> <20140603193248.916.56510@typhoon.lan> Message-ID: <20140603211430.1403.46012@typhoon.lan> On Tue, 03 Jun 2014 at 22:32:40, Scott Duckworth wrote: > On Tue, Jun 3, 2014 at 3:32 PM, Lukas Fleischer wrote: > > > I wonder if there is a way to obtain a textual representation of the key > > without writing it to a temporary file, though? > > > > Agreed, that would be better. If anybody knows how to do this please chime > in. If there isn't a function to do that already, you could factor out the code to build the textual representation and move it to a new function that writes the representation to a buffer (or returns it as a pointer to a newly allocated "string"). Then, key_write() would simply become a wrapper around that function. From dirkx at webweaving.org Wed Jun 4 18:24:59 2014 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Wed, 4 Jun 2014 10:24:59 +0200 Subject: [patch] Tiny patch to change 'no slots' to debug in PKCS#11 situations Message-ID: Folks, Not very critical - but below would help make the PKCS#11 experience a bit smoother. The, occasionally informative, no-slots message is moved to ?debug?; as otherwise, in a mixed pkcs#11 and file-based environment virtually all non chip-card driven ssh connections spew ?no slot? on stderr. And in day to day use - the only time you want this message is when you are debugging an issue; such as a faulty card or reader. Tested on freebsd and osx. Thanks, Dw. diff -u openssh-6.6p1.orig/ssh-pkcs11.c openssh-6.6p1/ssh-pkcs11.c --- openssh-6.6p1.orig/ssh-pkcs11.c 2014-06-04 10:19:09.000000000 +0200 +++ openssh-6.6p1/ssh-pkcs11.c 2014-06-04 10:20:29.000000000 +0200 @@ -602,7 +602,7 @@ goto fail; } if (p->nslots == 0) { - error("no slots"); + debug("no slots"); goto fail; } p->slotlist = xcalloc(p->nslots, sizeof(CK_SLOT_ID)); From imorgan at nas.nasa.gov Fri Jun 6 04:50:24 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 5 Jun 2014 11:50:24 -0700 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140603211430.1403.46012@typhoon.lan> References: <3CCAL3N1Bhquf8R_OX2zsEExYhOXt7vPMvMXNbhKpFXgAuMp967Lw@mail.gmail.com> <20140603085105.1307.47556@typhoon> <20140603193248.916.56510@typhoon.lan> <20140603211430.1403.46012@typhoon.lan> Message-ID: <20140605185023.GA17947@linux124.nas.nasa.gov> I should have read the actual security announcement rather than basing my initial response on the git commit messages; the SSL/TLS MITM issue makes this more critical. -- Iain On Tue, Jun 03, 2014 at 23:14:30 +0200, Lukas Fleischer wrote: > On Tue, 03 Jun 2014 at 22:32:40, Scott Duckworth wrote: > > On Tue, Jun 3, 2014 at 3:32 PM, Lukas Fleischer wrote: > > > > > I wonder if there is a way to obtain a textual representation of the key > > > without writing it to a temporary file, though? > > > > > > > Agreed, that would be better. If anybody knows how to do this please chime > > in. > > If there isn't a function to do that already, you could factor out the > code to build the textual representation and move it to a new function > that writes the representation to a buffer (or returns it as a pointer > to a newly allocated "string"). Then, key_write() would simply become a > wrapper around that function. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From imorgan at nas.nasa.gov Fri Jun 6 05:30:16 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 5 Jun 2014 12:30:16 -0700 Subject: patch to send incoming key to AuthorizedKeysCommand via stdin In-Reply-To: <20140605185023.GA17947@linux124.nas.nasa.gov> References: <3CCAL3N1Bhquf8R_OX2zsEExYhOXt7vPMvMXNbhKpFXgAuMp967Lw@mail.gmail.com> <20140603085105.1307.47556@typhoon> <20140603193248.916.56510@typhoon.lan> <20140603211430.1403.46012@typhoon.lan> <20140605185023.GA17947@linux124.nas.nasa.gov> Message-ID: <20140605193016.GB17947@linux124.nas.nasa.gov> On Thu, Jun 05, 2014 at 11:50:24 -0700, Iain Morgan wrote: > I should have read the actual security announcement rather than basing > my initial response on the git commit messages; the SSL/TLS MITM issue > makes this more critical. > Err, sorry about that. Haste and bad eyesight make for a bad combination. -- Iain Morgan From cu.truong at atos.net Fri Jun 6 17:59:09 2014 From: cu.truong at atos.net (Truong, Van Cu) Date: Fri, 6 Jun 2014 07:59:09 +0000 Subject: does the openSSL security vulnerability (CVE-2014-0224) affect openssh? Message-ID: <51D043D3C285E449AA3178ADB8CAD96036FDD01E@DEFTHW99EZ4MSX.ww931.my-it-solutions.net> Dear openssh developers, can you please check, whether the vulnerability of openSSL (CVE-2014-0224): http://www.openssl.org/news/secadv_20140605.txt openssh affects? Many thanks Van Cu Truong Tel.: +49 (211) 399 33598 Mobile: +49 (163) 1651728 cu.truongl at atos.net Otto-Hahn-Ring 6 81739 M?nchen, Deutschland de.atos.net [https://careers.atos.net/fe/images/client/Atos01/v1/css/logo.gif] From aw at osn.de Fri Jun 6 18:15:40 2014 From: aw at osn.de (Armin Wolfermann) Date: Fri, 6 Jun 2014 10:15:40 +0200 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match Message-ID: <20140606081540.GA4665@kuba.osn.de> Hi all, this is a patch to make Ciphers, MACs and KexAlgorithms available in Match blocks. Now I can reach a -current machine with some Android terminal app without changing the default ciphers for all clients: Match Address 192.168.1.2 Ciphers aes128-cbc MACs hmac-sha1 KexAlgorithms diffie-hellman-group-exchange-sha1 Index: servconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.c,v retrieving revision 1.249 diff -u -p -u -r1.249 servconf.c --- servconf.c 29 Jan 2014 06:18:35 -0000 1.249 +++ servconf.c 6 Jun 2014 08:04:06 -0000 @@ -399,8 +399,8 @@ static struct { { "denyusers", sDenyUsers, SSHCFG_ALL }, { "allowgroups", sAllowGroups, SSHCFG_ALL }, { "denygroups", sDenyGroups, SSHCFG_ALL }, - { "ciphers", sCiphers, SSHCFG_GLOBAL }, - { "macs", sMacs, SSHCFG_GLOBAL }, + { "ciphers", sCiphers, SSHCFG_ALL }, + { "macs", sMacs, SSHCFG_ALL }, { "protocol", sProtocol, SSHCFG_GLOBAL }, { "gatewayports", sGatewayPorts, SSHCFG_ALL }, { "subsystem", sSubsystem, SSHCFG_GLOBAL }, @@ -427,7 +427,7 @@ static struct { { "revokedkeys", sRevokedKeys, SSHCFG_ALL }, { "trustedusercakeys", sTrustedUserCAKeys, SSHCFG_ALL }, { "authorizedprincipalsfile", sAuthorizedPrincipalsFile, SSHCFG_ALL }, - { "kexalgorithms", sKexAlgorithms, SSHCFG_GLOBAL }, + { "kexalgorithms", sKexAlgorithms, SSHCFG_ALL }, { "ipqos", sIPQoS, SSHCFG_ALL }, { "authorizedkeyscommand", sAuthorizedKeysCommand, SSHCFG_ALL }, { "authorizedkeyscommanduser", sAuthorizedKeysCommandUser, SSHCFG_ALL }, @@ -1239,7 +1239,7 @@ process_server_config_line(ServerOptions if (!ciphers_valid(arg)) fatal("%s line %d: Bad SSH2 cipher spec '%s'.", filename, linenum, arg ? arg : ""); - if (options->ciphers == NULL) + if (*activep && options->ciphers == NULL) options->ciphers = xstrdup(arg); break; @@ -1250,7 +1250,7 @@ process_server_config_line(ServerOptions if (!mac_valid(arg)) fatal("%s line %d: Bad SSH2 mac spec '%s'.", filename, linenum, arg ? arg : ""); - if (options->macs == NULL) + if (*activep && options->macs == NULL) options->macs = xstrdup(arg); break; @@ -1262,7 +1262,7 @@ process_server_config_line(ServerOptions if (!kex_names_valid(arg)) fatal("%s line %d: Bad SSH2 KexAlgorithms '%s'.", filename, linenum, arg ? arg : ""); - if (options->kex_algorithms == NULL) + if (*activep && options->kex_algorithms == NULL) options->kex_algorithms = xstrdup(arg); break; Index: servconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.h,v retrieving revision 1.112 diff -u -p -u -r1.112 servconf.h --- servconf.h 29 Jan 2014 06:18:35 -0000 1.112 +++ servconf.h 6 Jun 2014 08:04:06 -0000 @@ -209,6 +209,9 @@ struct connection_info { M_CP_STROPT(authorized_principals_file); \ M_CP_STROPT(authorized_keys_command); \ M_CP_STROPT(authorized_keys_command_user); \ + M_CP_STROPT(ciphers); \ + M_CP_STROPT(macs); \ + M_CP_STROPT(kex_algorithms); \ M_CP_STRARRAYOPT(authorized_keys_files, num_authkeys_files); \ M_CP_STRARRAYOPT(allow_users, num_allow_users); \ M_CP_STRARRAYOPT(deny_users, num_deny_users); \ Index: sshd.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd.c,v retrieving revision 1.426 diff -u -p -u -r1.426 sshd.c --- sshd.c 29 Apr 2014 18:01:49 -0000 1.426 +++ sshd.c 6 Jun 2014 08:04:06 -0000 @@ -1919,6 +1919,10 @@ main(int ac, char **av) verbose("Connection from %s port %d on %s port %d", remote_ip, remote_port, get_local_ipaddr(sock_in), get_local_port()); + + /* Match configuration against the connection */ + connection_info = get_connection_info(1, options.use_dns); + parse_server_match_config(&options, connection_info); /* * We don't want to listen forever unless the other side Index: sshd_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.173 diff -u -p -u -r1.173 sshd_config.5 --- sshd_config.5 28 Mar 2014 05:17:11 -0000 1.173 +++ sshd_config.5 6 Jun 2014 08:04:06 -0000 @@ -896,6 +896,7 @@ Available keywords are .Cm AuthorizedPrincipalsFile , .Cm Banner , .Cm ChrootDirectory , +.Cm Ciphers , .Cm DenyGroups , .Cm DenyUsers , .Cm ForceCommand , @@ -905,6 +906,8 @@ Available keywords are .Cm HostbasedUsesNameFromPacketOnly , .Cm KbdInteractiveAuthentication , .Cm KerberosAuthentication , +.Cm KexAlgorithms , +.Cm MACs , .Cm MaxAuthTries , .Cm MaxSessions , .Cm PasswordAuthentication , Regards, Armin Wolfermann From dkg at fifthhorseman.net Sat Jun 7 01:11:59 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 06 Jun 2014 11:11:59 -0400 Subject: does the openSSL security vulnerability (CVE-2014-0224) affect openssh? In-Reply-To: <51D043D3C285E449AA3178ADB8CAD96036FDD01E@DEFTHW99EZ4MSX.ww931.my-it-solutions.net> References: <51D043D3C285E449AA3178ADB8CAD96036FDD01E@DEFTHW99EZ4MSX.ww931.my-it-solutions.net> Message-ID: <5391DA3F.1030500@fifthhorseman.net> On 06/06/2014 03:59 AM, Truong, Van Cu wrote: > can you please check, whether the vulnerability of openSSL (CVE-2014-0224): > http://www.openssl.org/news/secadv_20140605.txt > openssh affects? CVE-2014-0224 is a flaw in the handling of certain Transport Layer Security (TLS) or Secure Sockets Layer (SSL) messages. the Secure Shell (SSH) is a different protocol from SSL or TLS. OpenSSH relies on the OpenSSL library for access to the cryptographic primitives it provides, not for the TLS or SSL implementations. So OpenSSH is not vulnerable to CVE-2014-0224. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From djm at mindrot.org Sun Jun 8 09:16:56 2014 From: djm at mindrot.org (Damien Miller) Date: Sun, 8 Jun 2014 09:16:56 +1000 (EST) Subject: does the openSSL security vulnerability (CVE-2014-0224) affect openssh? In-Reply-To: <51D043D3C285E449AA3178ADB8CAD96036FDD01E@DEFTHW99EZ4MSX.ww931.my-it-solutions.net> References: <51D043D3C285E449AA3178ADB8CAD96036FDD01E@DEFTHW99EZ4MSX.ww931.my-it-solutions.net> Message-ID: On Fri, 6 Jun 2014, Truong, Van Cu wrote: > Dear openssh developers, > > can you please check, whether the vulnerability of openSSL (CVE-2014-0224): > http://www.openssl.org/news/secadv_20140605.txt > openssh affects? No, they are all SSL related. -d From djm at mindrot.org Sun Jun 8 09:23:38 2014 From: djm at mindrot.org (Damien Miller) Date: Sun, 8 Jun 2014 09:23:38 +1000 (EST) Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: <20140606081540.GA4665@kuba.osn.de> References: <20140606081540.GA4665@kuba.osn.de> Message-ID: On Fri, 6 Jun 2014, Armin Wolfermann wrote: > Hi all, > > this is a patch to make Ciphers, MACs and KexAlgorithms available in > Match blocks. Now I can reach a -current machine with some Android > terminal app without changing the default ciphers for all clients: > > Match Address 192.168.1.2 > Ciphers aes128-cbc > MACs hmac-sha1 > KexAlgorithms diffie-hellman-group-exchange-sha1 Unfortunately, this a a bit confusing - some Match criteria only work after key exchange has completed. If users try something like Match user djm Ciphers aes128-cbc then it will never work. For this reason, we've made any any sshd_config directives that must be applied before key exchange available by Match. -d From koct9i at gmail.com Sun Jun 8 20:11:50 2014 From: koct9i at gmail.com (Konstantin Khlebnikov) Date: Sun, 8 Jun 2014 14:11:50 +0400 Subject: [PATCH] contrib/ssh-copy-id: do not use shared connection Message-ID: ssh-copy-id always needs new connection to the server when it evaluates its version and tests if the key is already installed. Before this patch ssh-copy-id might reuse existing shared connection and hang in REMOTE_VERSION=(...) because it get interactive connection which never ends. Also it will think that the key is already there because connection using it is succeed. This patch adds option "ControlPath=none" into command line and remote command "exit" to be sure that test connection never hangs. -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-copy-id-disable-shared-connection.patch Type: text/x-patch Size: 1055 bytes Desc: not available URL: From aw at osn.de Sun Jun 8 22:32:34 2014 From: aw at osn.de (Armin Wolfermann) Date: Sun, 8 Jun 2014 14:32:34 +0200 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: References: <20140606081540.GA4665@kuba.osn.de> Message-ID: <20140608123234.GA9842@kuba.osn.de> * Damien Miller [08.06.2014 01:23]: > Unfortunately, this a a bit confusing - some Match criteria only work > after key exchange has completed. If users try something like > > Match user djm > Ciphers aes128-cbc > > then it will never work. For this reason, we've made any any sshd_config > directives that must be applied before key exchange available by Match. Would some additional documentation suffice or should an error/warning be generated when using such a combination? Index: sshd_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.173 diff -u -p -u -r1.173 sshd_config.5 --- sshd_config.5 28 Mar 2014 05:17:11 -0000 1.173 +++ sshd_config.5 8 Jun 2014 12:26:11 -0000 @@ -896,6 +896,7 @@ Available keywords are .Cm AuthorizedPrincipalsFile , .Cm Banner , .Cm ChrootDirectory , +.Cm Ciphers , .Cm DenyGroups , .Cm DenyUsers , .Cm ForceCommand , @@ -905,6 +906,8 @@ Available keywords are .Cm HostbasedUsesNameFromPacketOnly , .Cm KbdInteractiveAuthentication , .Cm KerberosAuthentication , +.Cm KexAlgorithms , +.Cm MACs , .Cm MaxAuthTries , .Cm MaxSessions , .Cm PasswordAuthentication , @@ -921,6 +924,18 @@ Available keywords are .Cm X11Forwarding and .Cm X11UseLocalHost . +.Pp +The keywords +.Cm Ciphers , +.Cm KexAlgorithms +and +.Cm MACs +apply to pre-authenticated connections and will not modify configuration +when specified after the (post-authentication) +.Cm User +or +.Cm Group +criteria. .It Cm MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Regards, Armin Wolfermann From dtucker at zip.com.au Sun Jun 8 23:43:30 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 8 Jun 2014 09:43:30 -0400 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: References: <20140606081540.GA4665@kuba.osn.de> Message-ID: On Sat, Jun 7, 2014 at 7:23 PM, Damien Miller wrote: > On Fri, 6 Jun 2014, Armin Wolfermann wrote: > > [...] > Unfortunately, this a a bit confusing - some Match criteria only work > after key exchange has completed. If users try something like > > Match user djm > Ciphers aes128-cbc > > then it will never work. Actually in this particular case you could probably force a rekeying as soon as the username is received and make this work more or less as expected. That'd work for Compression too. -- 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 mouring at eviladmin.org Mon Jun 9 00:21:57 2014 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sun, 8 Jun 2014 09:21:57 -0500 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: References: <20140606081540.GA4665@kuba.osn.de> Message-ID: <85C63F59-1051-4817-9559-C1560C53D9A4@eviladmin.org> On Jun 8, 2014, at 8:43 AM, Darren Tucker wrote: > On Sat, Jun 7, 2014 at 7:23 PM, Damien Miller wrote: > >> On Fri, 6 Jun 2014, Armin Wolfermann wrote: >> >> [...] >> Unfortunately, this a a bit confusing - some Match criteria only work >> after key exchange has completed. If users try something like >> >> Match user djm >> Ciphers aes128-cbc >> >> then it will never work. > > > Actually in this particular case you could probably force a rekeying as > soon as the username is received and make this work more or less as > expected. That'd work for Compression too. However, if the SSH client in question is broken (as it sounds like Mr Wolfermann's Android clients are) it will never get to a rekey stage as it will fail to do the initial connection. Just feels hokey to try and play with Ciphers and Macs in the Match. - Ben From dtucker at zip.com.au Mon Jun 9 00:55:03 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 8 Jun 2014 10:55:03 -0400 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: <85C63F59-1051-4817-9559-C1560C53D9A4@eviladmin.org> References: <20140606081540.GA4665@kuba.osn.de> <85C63F59-1051-4817-9559-C1560C53D9A4@eviladmin.org> Message-ID: On Sun, Jun 8, 2014 at 10:21 AM, Ben Lindstrom wrote: > [...] > However, if the SSH client in question is broken (as it sounds like Mr > Wolfermann's Android clients are) it will never get to a rekey stage as it > will fail to do the initial connection. > Sure, but working around buggy clients is not the only possible use case for it. Say, requiring a particularly sensitive user to use a strong cipher. Now for working around buggy clients, adding a Match on the client version string would be possible, since it's known very early. Match Client someclient-2.6* Ciphers aes128-cbc (although I'd call it "Implementation" or some other neutral name so the same keyword could be used on both client and server). Just feels hokey to try and play with Ciphers and Macs in the Match. > Buggy implementations of these things are relatively common. To pick a real example: # Broken curve25519-sha256 at libssh.org Match Implementation OpenSSH-6.6 KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 Plus you could turn off DH Group exchange to those Cisco implementations that fail when asked for a preferred group >4k bit without compromising security for every other implementation. -- 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 aw at osn.de Mon Jun 9 02:15:29 2014 From: aw at osn.de (Armin Wolfermann) Date: Sun, 8 Jun 2014 18:15:29 +0200 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: References: <20140606081540.GA4665@kuba.osn.de> <85C63F59-1051-4817-9559-C1560C53D9A4@eviladmin.org> Message-ID: <20140608161529.GA22592@kuba.osn.de> * Darren Tucker [08.06.2014 16:56]: > (although I'd call it "Implementation" or some other neutral name so the > same keyword could be used on both client and server). I called it "Version" (the RFC calls it softwareversion) and prepared a rough patch that handles my use case with: Match Version TrileadSSH2Java_213 Ciphers aes128-cbc MACs hmac-sha1 KexAlgorithms diffie-hellman-group-exchange-sha1 If there is enough interest I will polish it up and resubmit later. Index: servconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.c,v retrieving revision 1.249 diff -u -p -u -r1.249 servconf.c --- servconf.c 29 Jan 2014 06:18:35 -0000 1.249 +++ servconf.c 8 Jun 2014 15:58:36 -0000 @@ -57,6 +57,7 @@ static void add_one_listen_addr(ServerOp /* Use of privilege separation or not */ extern int use_privsep; extern Buffer cfg; +extern char *remote_version_string; /* Initializes the server options to their default values. */ @@ -399,8 +400,8 @@ static struct { { "denyusers", sDenyUsers, SSHCFG_ALL }, { "allowgroups", sAllowGroups, SSHCFG_ALL }, { "denygroups", sDenyGroups, SSHCFG_ALL }, - { "ciphers", sCiphers, SSHCFG_GLOBAL }, - { "macs", sMacs, SSHCFG_GLOBAL }, + { "ciphers", sCiphers, SSHCFG_ALL }, + { "macs", sMacs, SSHCFG_ALL }, { "protocol", sProtocol, SSHCFG_GLOBAL }, { "gatewayports", sGatewayPorts, SSHCFG_ALL }, { "subsystem", sSubsystem, SSHCFG_GLOBAL }, @@ -415,7 +416,7 @@ static struct { { "clientalivecountmax", sClientAliveCountMax, SSHCFG_GLOBAL }, { "authorizedkeysfile", sAuthorizedKeysFile, SSHCFG_ALL }, { "authorizedkeysfile2", sDeprecated, SSHCFG_ALL }, - { "useprivilegeseparation", sUsePrivilegeSeparation, SSHCFG_GLOBAL}, + { "useprivilegeseparation", sUsePrivilegeSeparation, SSHCFG_GLOBAL }, { "acceptenv", sAcceptEnv, SSHCFG_ALL }, { "permittunnel", sPermitTunnel, SSHCFG_ALL }, { "permittty", sPermitTTY, SSHCFG_ALL }, @@ -427,7 +428,7 @@ static struct { { "revokedkeys", sRevokedKeys, SSHCFG_ALL }, { "trustedusercakeys", sTrustedUserCAKeys, SSHCFG_ALL }, { "authorizedprincipalsfile", sAuthorizedPrincipalsFile, SSHCFG_ALL }, - { "kexalgorithms", sKexAlgorithms, SSHCFG_GLOBAL }, + { "kexalgorithms", sKexAlgorithms, SSHCFG_ALL }, { "ipqos", sIPQoS, SSHCFG_ALL }, { "authorizedkeyscommand", sAuthorizedKeysCommand, SSHCFG_ALL }, { "authorizedkeyscommanduser", sAuthorizedKeysCommandUser, SSHCFG_ALL }, @@ -532,6 +533,7 @@ get_connection_info(int populate, int us ci.address = get_remote_ipaddr(); ci.laddress = get_local_ipaddr(packet_get_connection_in()); ci.lport = get_local_port(); + ci.version = remote_version_string; return &ci; } @@ -612,10 +614,13 @@ match_cfg_line(char **condition, int lin debug3("checking syntax for 'Match %s'", cp); else debug3("checking match for '%s' user %s host %s addr %s " - "laddr %s lport %d", cp, ci->user ? ci->user : "(null)", + "laddr %s lport %d version '%s'", cp, + ci->user ? ci->user : "(null)", ci->host ? ci->host : "(null)", ci->address ? ci->address : "(null)", - ci->laddress ? ci->laddress : "(null)", ci->lport); + ci->laddress ? ci->laddress : "(null)", + ci->lport, + ci->version ? ci->version : "(null)"); while ((attrib = strdelim(&cp)) && *attrib != '\0') { attributes++; @@ -717,6 +722,16 @@ match_cfg_line(char **condition, int lin ci->laddress, port, line); else result = 0; + } else if (strcasecmp(attrib, "version") == 0) { + if (ci == NULL || ci->version == NULL) { + result = 0; + continue; + } + if (strcasecmp(ci->version, arg) != 0) + result = 0; + else + debug("connection from %.100s matched 'Version " + "%.100s' at line %d", ci->version, arg, line); } else { error("Unsupported Match attribute %s", attrib); return -1; @@ -1239,7 +1254,7 @@ process_server_config_line(ServerOptions if (!ciphers_valid(arg)) fatal("%s line %d: Bad SSH2 cipher spec '%s'.", filename, linenum, arg ? arg : ""); - if (options->ciphers == NULL) + if (*activep && options->ciphers == NULL) options->ciphers = xstrdup(arg); break; @@ -1250,7 +1265,7 @@ process_server_config_line(ServerOptions if (!mac_valid(arg)) fatal("%s line %d: Bad SSH2 mac spec '%s'.", filename, linenum, arg ? arg : ""); - if (options->macs == NULL) + if (*activep && options->macs == NULL) options->macs = xstrdup(arg); break; @@ -1262,7 +1277,7 @@ process_server_config_line(ServerOptions if (!kex_names_valid(arg)) fatal("%s line %d: Bad SSH2 KexAlgorithms '%s'.", filename, linenum, arg ? arg : ""); - if (options->kex_algorithms == NULL) + if (*activep && options->kex_algorithms == NULL) options->kex_algorithms = xstrdup(arg); break; @@ -1663,6 +1678,8 @@ int parse_server_match_testspec(struct c " specification %s\n", p+6, p); return -1; } + } else if (strncmp(p, "version=", 8) == 0) { + ci->version = xstrdup(p + 8); } else { fprintf(stderr, "Invalid test mode specification %s\n", p); Index: servconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.h,v retrieving revision 1.112 diff -u -p -u -r1.112 servconf.h --- servconf.h 29 Jan 2014 06:18:35 -0000 1.112 +++ servconf.h 8 Jun 2014 15:58:36 -0000 @@ -190,6 +190,7 @@ struct connection_info { const char *address; /* remote address */ const char *laddress; /* local address */ int lport; /* local port */ + const char *version; /* remote version string */ }; @@ -209,6 +210,9 @@ struct connection_info { M_CP_STROPT(authorized_principals_file); \ M_CP_STROPT(authorized_keys_command); \ M_CP_STROPT(authorized_keys_command_user); \ + M_CP_STROPT(ciphers); \ + M_CP_STROPT(macs); \ + M_CP_STROPT(kex_algorithms); \ M_CP_STRARRAYOPT(authorized_keys_files, num_authkeys_files); \ M_CP_STRARRAYOPT(allow_users, num_allow_users); \ M_CP_STRARRAYOPT(deny_users, num_deny_users); \ Index: sshd.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd.c,v retrieving revision 1.426 diff -u -p -u -r1.426 sshd.c --- sshd.c 29 Apr 2014 18:01:49 -0000 1.426 +++ sshd.c 8 Jun 2014 15:58:36 -0000 @@ -166,6 +166,7 @@ int num_listen_socks = 0; */ char *client_version_string = NULL; char *server_version_string = NULL; +char *remote_version_string = NULL; /* for rekeying XXX fixme */ Kex *xxx_kex; @@ -460,6 +461,7 @@ sshd_exchange_identification(int sock_in close(sock_out); cleanup_exit(255); } + remote_version_string = xstrdup(remote_version); debug("Client protocol version %d.%d; client software version %.100s", remote_major, remote_minor, remote_version); @@ -1933,6 +1935,10 @@ main(int ac, char **av) alarm(options.login_grace_time); sshd_exchange_identification(sock_in, sock_out); + + /* Match configuration against the connection */ + connection_info = get_connection_info(1, options.use_dns); + parse_server_match_config(&options, connection_info); /* In inetd mode, generate ephemeral key only for proto 1 connections */ if (!compat20 && inetd_flag && sensitive_data.server_key == NULL) Regards, Armin Wolfermann From keisial at gmail.com Mon Jun 9 04:28:38 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 08 Jun 2014 20:28:38 +0200 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: <20140608161529.GA22592@kuba.osn.de> References: <20140606081540.GA4665@kuba.osn.de> <85C63F59-1051-4817-9559-C1560C53D9A4@eviladmin.org> <20140608161529.GA22592@kuba.osn.de> Message-ID: <5394AB56.1030206@gmail.com> On 06/08/14 18:15, Armin Wolfermann wrote: > * Darren Tucker [08.06.2014 16:56]: >> (although I'd call it "Implementation" or some other neutral name so the >> same keyword could be used on both client and server). > I called it "Version" (the RFC calls it softwareversion) and prepared a > rough patch that handles my use case with: > > Match Version TrileadSSH2Java_213 > Ciphers aes128-cbc > MACs hmac-sha1 > KexAlgorithms diffie-hellman-group-exchange-sha1 > > If there is enough interest I will polish it up and resubmit later. I'm not sure Version is intuitive enough. What about "remoteversion"? From aw at osn.de Mon Jun 9 06:42:45 2014 From: aw at osn.de (Armin Wolfermann) Date: Sun, 8 Jun 2014 22:42:45 +0200 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: <5394AB56.1030206@gmail.com> References: <20140606081540.GA4665@kuba.osn.de> <85C63F59-1051-4817-9559-C1560C53D9A4@eviladmin.org> <20140608161529.GA22592@kuba.osn.de> <5394AB56.1030206@gmail.com> Message-ID: <20140608204245.GB22592@kuba.osn.de> * ?ngel Gonz?lez [08.06.2014 20:29]: > I'm not sure Version is intuitive enough. What about "remoteversion"? We have LocalAddress/LocalPort but no other Remote* criterias. Don't know if this will fit together. From djm at mindrot.org Mon Jun 9 10:39:56 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Jun 2014 10:39:56 +1000 (EST) Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: References: <20140606081540.GA4665@kuba.osn.de> <85C63F59-1051-4817-9559-C1560C53D9A4@eviladmin.org> Message-ID: On Sun, 8 Jun 2014, Darren Tucker wrote: > # Broken curve25519-sha256 at libssh.org > Match Implementation OpenSSH-6.6 > KexAlgorithms > diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 > > Plus you could turn off DH Group exchange to those Cisco implementations > that fail when asked for a preferred group >4k bit without compromising > security for every other implementation. That opens a door for a MITM to degrade the crypto options used by spoofing one/both banner strings. Of course they would need to be able to fake the KEX hash later, but if they get to choose the algorithms used then this becomes more likely. I've been removing the compat hacks for old SSH implementations that cause dodgy crypto to be used for this very reason. -d From aw at osn.de Mon Jun 9 23:30:47 2014 From: aw at osn.de (Armin Wolfermann) Date: Mon, 9 Jun 2014 15:30:47 +0200 Subject: Patch: Ciphers, MACs and KexAlgorithms on Match In-Reply-To: References: <20140606081540.GA4665@kuba.osn.de> <85C63F59-1051-4817-9559-C1560C53D9A4@eviladmin.org> Message-ID: <20140609133047.GA688@kuba.osn.de> * Damien Miller [09.06.2014 02:40]: > I've been removing the compat hacks for old SSH implementations that > cause dodgy crypto to be used for this very reason. Ok, so now I'm back at my first patch. Should I add some checks for wrong combinations of Match User/Group and Ciphers or what else would be needed? From dkg at fifthhorseman.net Wed Jun 11 04:42:09 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Jun 2014 14:42:09 -0400 Subject: any concerns about including TZ in AcceptEnv Message-ID: <53975181.1070903@fifthhorseman.net> Hi OpenSSH folks-- this is more of a configuration question than a development question, i think, but: Are there any caveats worth being aware of about including the TZ variable in AcceptEnv for sshd_config by default? I don't see any particular risk, but if there are gotchas people know about, i'd be happy to be made aware of them. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From djm at mindrot.org Wed Jun 11 16:54:42 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Jun 2014 16:54:42 +1000 (EST) Subject: any concerns about including TZ in AcceptEnv In-Reply-To: <53975181.1070903@fifthhorseman.net> References: <53975181.1070903@fifthhorseman.net> Message-ID: On Tue, 10 Jun 2014, Daniel Kahn Gillmor wrote: > Hi OpenSSH folks-- > > this is more of a configuration question than a development question, i > think, but: > > Are there any caveats worth being aware of about including the TZ > variable in AcceptEnv for sshd_config by default? > > I don't see any particular risk, but if there are gotchas people know > about, i'd be happy to be made aware of them. some libc accept full paths to TZ files, so if you have any sort of restricted environment then you'd be trusting the TZ parser there. From loic.le-loarer at polytechnique.org Fri Jun 13 08:42:03 2014 From: loic.le-loarer at polytechnique.org (=?UTF-8?Q?Lo=C3=AFc_Le_Loarer?=) Date: Fri, 13 Jun 2014 00:42:03 +0200 Subject: Improve ControlPersist documentation Message-ID: Hi, While testing the ControlPersist option (which is very useful by the way, thank you), I find out that setting it to 0 has the same behaviour as setting it to yes, while I would have expected to exit as soon as the last client exits. I'd like to make this behaviour clear, I think it should be documentated in the man page for example like this: $ cvs diff -u ssh_config.5 Index: ssh_config.5 =================================================================== RCS file: /cvs/openssh/ssh_config.5,v retrieving revision 1.186 diff -u -r1.186 ssh_config.5 --- ssh_config.5 20 Apr 2014 03:22:46 -0000 1.186 +++ ssh_config.5 12 Jun 2014 22:34:51 -0000 @@ -529,7 +529,10 @@ .Xr sshd_config 5 , then the backgrounded master connection will automatically terminate after it has remained idle (with no client connections) for the -specified time. +specified time. If the time is 0, then the backgrounded master connection +will stay indefinitely (like if set to +.Dq yes +). .It Cm DynamicForward Specifies that a TCP port on the local machine be forwarded over the secure channel, and the application What do you think of that ? Of course, it would also be a good idea to change the behaviour and exits as soon as the last client exits. I tried to change the code in this way, but there is an issue in that the control background process doesn't even wait for the first client to connect... Thank in advance, Best regards -- Lo?c From mail at eworm.de Mon Jun 16 23:43:03 2014 From: mail at eworm.de (Christian Hesse) Date: Mon, 16 Jun 2014 15:43:03 +0200 Subject: [PATCH 1/1] rework printing for visual host key upper border Message-ID: <1402926183-14612-1-git-send-email-mail@eworm.de> Key types are getting longer and the current implementation of visual host key breaks with ED25519, resulting in (note the missing bracket): +--[ED25519 256--+ This reworks the calculation of visual host key upper border. Please be aware that this slightly modifies the output for other key types as well: +--[ DSA 1024]----+ +---[DSA 1024]----+ +--[ RSA 2048]----+ +---[RSA 2048]----+ +--[ECDSA 256]---+ +---[ECDSA 256]---+ +--[ED25519 256--+ +--[ED25519 256]--+ --- key.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/key.c b/key.c index e8fc5b1..a71d46c 100644 --- a/key.c +++ b/key.c @@ -547,13 +547,14 @@ key_fingerprint_randomart(u_char *dgst_raw, u_int dgst_raw_len, const Key *k) * intersects with itself. Matter of taste. */ char *augmentation_string = " .o+=*BOX@%&#/^SE"; - char *retval, *p; + char *retval, *p, key_details[FLDSIZE_X + 1]; u_char field[FLDSIZE_X][FLDSIZE_Y]; u_int i, b; int x, y; size_t len = strlen(augmentation_string) - 1; retval = xcalloc(1, (FLDSIZE_X + 3) * (FLDSIZE_Y + 2)); + p = retval; /* initialize field */ memset(field, 0, FLDSIZE_X * FLDSIZE_Y * sizeof(char)); @@ -587,11 +588,14 @@ key_fingerprint_randomart(u_char *dgst_raw, u_int dgst_raw_len, const Key *k) field[FLDSIZE_X / 2][FLDSIZE_Y / 2] = len - 1; field[x][y] = len; - /* fill in retval */ - snprintf(retval, FLDSIZE_X, "+--[%4s %4u]", key_type(k), key_size(k)); - p = strchr(retval, '\0'); + /* assemble key detail string */ + snprintf(key_details, FLDSIZE_X, "[%s %u]", key_type(k), key_size(k)); /* output upper border */ + *p++ = '+'; + for (i = 0; i < (FLDSIZE_X - strlen(key_details)) / 2; i++) + *p++ = '-'; + p += sprintf(p, "%s", key_details); for (i = p - retval - 1; i < FLDSIZE_X; i++) *p++ = '-'; *p++ = '+'; -- 2.0.0 From vinschen at redhat.com Mon Jun 16 19:18:30 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 16 Jun 2014 11:18:30 +0200 Subject: [patch/cygwin] contrib/cygwin/ssh-host-config In-Reply-To: References: <20140515085801.GO2436@calimero.vinschen.de> <20140521081343.GC24532@calimero.vinschen.de> Message-ID: <20140616091830.GA4903@calimero.vinschen.de> On May 27 14:35, Damien Miller wrote: > On Wed, 21 May 2014, Corinna Vinschen wrote: > > > Ping? > > Sorry, I haven't had much time to work on OpenSSH for the last few weeks. > > Both your patches are committed now. Thank you! Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From apb at cequrux.com Fri Jun 13 17:42:54 2014 From: apb at cequrux.com (Alan Barrett) Date: Fri, 13 Jun 2014 10:42:54 +0300 Subject: Improve ControlPersist documentation In-Reply-To: References: Message-ID: <20140613074254.GS13495@apb-laptoy.apb.alt.za> On Fri, 13 Jun 2014, Lo?c Le Loarer wrote: > While testing the ControlPersist option (which is very useful > by the way, thank you), I find out that setting it to 0 has the > same behaviour as setting it to yes, while I would have expected > to exit as soon as the last client exits. I think it should exit immediately, so the current behaviour of ControlPersist=0 waiting forever should be considered a bug to be fixed in code, not a feature to be added to documentation. > Of course, it would also be a good idea to change the behaviour > and exits as soon as the last client exits. I tried to change > the code in this way, but there is an issue in that the control > background process doesn't even wait for the first client to > connect... If fixing it properly is too difficult, then waiting for a very short time, like 1 second, might be a reasonable compromise. --apb (Alan Barrett) From james at coppermoth.com Tue Jun 17 18:05:28 2014 From: james at coppermoth.com (James Berry) Date: Tue, 17 Jun 2014 09:05:28 +0100 Subject: Reverse tunnel security settings Message-ID: I have a number of connections coming in to my host to create a reverse tunnel from machine 1: ssh -R:19991:192.168.250.251:80 user1 at host.org -N -f from machine 2: ssh -R:19992:192.168.250.251:80 user2 at host.org -N -f from machine 3: ssh -R:19993:192.168.250.251:80 user3 at host.org -N -f You can see that each user has a specific port that they should use. I would either like to dynamically set the correct port on my host (I know what they should be), or if I cannot I would like to restrict the connections so that the users can only open the tunnel on the ports that I have specified. I have not found anything in the configuration settings to restrict the ports that can be selected by an inbound connection. When a dynamic port (0) is used, this appears to just pick the next available port. I have experimentally patched serverloop.c to ignore the user specified port and used one based on the uid but wonder: a) Is there a good way to achieve this without patching openssh b) If the best way is to continue with the patch perhaps we can discuss options for what the patch should look like as I would prefer to submit to the project rather than maintain my own branch. I would suggest either calling out to an external program that returns the port (this may be considered to be a security problem), or some other mapping from users to the port (range?) they can choose From mvadkert at redhat.com Thu Jun 19 22:56:49 2014 From: mvadkert at redhat.com (mvadkert) Date: Thu, 19 Jun 2014 14:56:49 +0200 Subject: AuthenticationMethods in sshd_config accepting empty method list Message-ID: <53A2DE11.9000100@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, I just came across a contradiction between the man page of AuthenticationMethods and the accepted methods list. According to the sshd_config manual page: """ AuthenticationMethods Specifies the authentication methods that must be successfully completed for a user to be granted access. This option must be followed by one or more comma-separated lists of authentication method names. Successful authentication requires completion of every method in at least one of these lists. """" But in reality the also an empty list is accepted by sshd (servconf.c:1605). What is the reason to accept an empty method list? Does the man page need an update? Thanks and best regards, /M - -- Miroslav Vadkerti :: Red Hat s.r.o, Purky?ova 99/71, 612 45, Brno, Czech Republic -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTot4RAAoJEBliWhMliBCHoHsH/21Z8JGah1BByms9mO4dkT9k YLmykqWcUjopNwk2FykYVPm3K8RFO4zV45hha26v8Qdh3TpNjuQED0HuqBrtfY5H 8qZOsz1FNb9Ayi/+k3+Sgo7IJtO71XkLGFphsQLhnbntbD+wQt1nqIYRdBmZzN1n aV6KJOUaBVoVllFuAv9vINMQtMSc98Jas4ZPeShoTtzvEoRxrEP81PbNvXVHy6d8 zk8il2YUPPtd03k2CuDHmou+Lhb9NtG4PepsD3e1loLMwSqgT6X3Y5AGMkBmJ/2m bzuqJlxLOZ8k/b0PeBtixAMUbgS2Z0Ku2NsAxID+4iEBxIVOD5AZj6ZUKAX6yMI= =Ogu3 -----END PGP SIGNATURE----- From antony at phenome.org Fri Jun 20 04:17:50 2014 From: antony at phenome.org (Antony Antony) Date: Thu, 19 Jun 2014 20:17:50 +0200 Subject: [PATCH] permitremoteopen - to limit remote port forwarding per user Message-ID: <20140619181750.GA15005@hal> Hi, Here is a patch to limit reverse port forwarding(-R) per user/key on the server. For example add: permitremoteopen="8023" ssh-dss AAAAB3NzaC1kc3MAAACBAOUE.. in user's ~/.ssh/authorized_keys server will limit -R to port 8023 only. an example of violation. ssh -v -R 8022:127.0.0.1:22 -i.ssh/id_dsa foo at 10.0.0.1 debug1: Remote: Server denied remote port forward request. debug1: remote forward failure for: listen 8022, connect 127.0.0.1:22 Warning: remote port forwarding failed for listen port 8022 and ssh -v -R 8023:127.0.0.1:22 -i.ssh/id_dsa foo at 10.0.0.1 will forward the port. The patch should work on 6.6p1, 6.5p1, 6.4p1 and 6.6 regards, -antony -------------- next part -------------- A non-text attachment was scrubbed... Name: permitremoteopen.patch Type: text/x-diff Size: 13776 bytes Desc: not available URL: From yves at zioup.com Fri Jun 20 17:59:56 2014 From: yves at zioup.com (Yves Dorfsman) Date: Fri, 20 Jun 2014 01:59:56 -0600 Subject: malformed DNS query Message-ID: <53A3E9FC.6090809@zioup.com> On CoreOS, runnng openssh sshd version "OpenSSH_6.6p1-hpn14v4, OpenSSL 1.0.1g", when connecting the following query is sent to the DNS server: query[A] 2.2.0.10.in-addr.arpa Which makes no sense, it's an "A" request for a reverse record. Adding "UseDNS no", prevent the request (proving that the request does come from sshd). When connecting to machines with older sshd (OpenSSH_6.6.1p1, OpenSSL 1.0.1f) the request is a PRT request as expected. Any idea why this is happening? Is this a change in sshd or some other configuration on the server? -- Yves. From djm at mindrot.org Fri Jun 20 21:37:47 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 20 Jun 2014 21:37:47 +1000 (EST) Subject: malformed DNS query In-Reply-To: <53A3E9FC.6090809@zioup.com> References: <53A3E9FC.6090809@zioup.com> Message-ID: On Fri, 20 Jun 2014, Yves Dorfsman wrote: > > On CoreOS, runnng openssh sshd version "OpenSSH_6.6p1-hpn14v4, OpenSSL > 1.0.1g", when connecting the following query is sent to the DNS server: This isn't a version that we ship. Can you reproduce this with an unpatched release? -d From sthen at openbsd.org Sat Jun 21 07:25:43 2014 From: sthen at openbsd.org (Stuart Henderson) Date: Fri, 20 Jun 2014 22:25:43 +0100 Subject: Reverse tunnel security settings In-Reply-To: Message-ID: On 2014-06-17, James Berry wrote: > I have a number of connections coming in to my host to create a reverse tunnel > > from machine 1: ssh -R:19991:192.168.250.251:80 user1 at host.org -N -f > from machine 2: ssh -R:19992:192.168.250.251:80 user2 at host.org -N -f > from machine 3: ssh -R:19993:192.168.250.251:80 user3 at host.org -N -f > > > You can see that each user has a specific port that they should use. > > I would either like to dynamically set the correct port on my host (I > know what they should be), or if I cannot I would like to restrict the > connections so that the users can only open the tunnel on the ports > that I have specified. > > I have not found anything in the configuration settings to restrict > the ports that can be selected by an inbound connection. When a > dynamic port (0) is used, this appears to just pick the next available > port. > > I have experimentally patched serverloop.c to ignore the user > specified port and used one based on the uid but wonder: > a) Is there a good way to achieve this without patching openssh Restricting port numbers could be done with a firewall that permits uid specifications. PF can do this, though I'm not quite sure if doing this from a firewall counts as a "good way" and, given the controls already available on local forwarding, it does seem like something that it would be reasonable to implement internally in ssh. > b) If the best way is to continue with the patch perhaps we can > discuss options for what the patch should look like as I would prefer > to submit to the project rather than maintain my own branch. I would > suggest either calling out to an external program that returns the > port (this may be considered to be a security problem), or some other > mapping from users to the port (range?) they can choose For restrictions, it feels to me like this should probably be handled in a similar way to permitopen as done for local forwarding - i.e. config parameter (which can be used in a Match block per-user) and authorized_keys option (which can call out to an external program via AuthorizedKeysCommand if wanted). Then for the other part of what you're looking for, dynamic port allocation on the server just needs to take account of the port restrictions - in that case, the client could set port 0, server picks an allowed port and uses it, and the client doesn't have to worry about choosing it itself. From clauder at accedian.com Mon Jun 23 00:32:38 2014 From: clauder at accedian.com (Claude Robitaille) Date: Sun, 22 Jun 2014 10:32:38 -0400 Subject: openssh connection hangs upon shell exit Message-ID: I am using an openSSH server on a privately built distribution. I am can login with an interactive session, use scp and everything is fine except that when I exit the shell of an interactive session or when the copy transfer terminates (scp), sshd hangs forever. The shell process is in the zombie state, which indicates that the openssh process for the connection has not checked the child status. I understand that using a privately built distribution (distribution may be not the adequate terms but I have no other) is most certainly the root cause where some files, privileges, etc. is not set correctly. But I looked everywhere, including the FAQ on opensssh.com and can not find any useful guidance. Any pointers for where to look? Using debug and strace does not help. I can see 2 errors near the end but I am not sure they are real problem or related to my issue. Here is the end of this trace (the write \r correspond to the enter after exit): write(6, "\r", 1) = 1 select(9, [3 4 8], [], NULL, NULL) = 1 (in [8]) rt_sigprocmask(SIG_BLOCK, [CHLD], [TERM CHLD], 8) = 0 rt_sigprocmask(SIG_SETMASK, [TERM CHLD], NULL, 8) = 0 read(8, "\r\n", 16384) = 2 select(9, [3 4 8], [3], NULL, NULL) = 2 (in [8], out [3]) rt_sigprocmask(SIG_BLOCK, [CHLD], [TERM CHLD], 8) = 0 rt_sigprocmask(SIG_SETMASK, [TERM CHLD], NULL, 8) = 0 read(8, 0x7fff2c252970, 16384) = -1 EIO (Input/output error) write(2, "debug2: channel 0: read<=0 rfd 8"..., 41debug2: channel 0: read<=0 rfd 8 len -1 ) = 41 write(2, "debug2: channel 0: read failed\r\n", 32debug2: channel 0: read failed ) = 32 write(2, "debug2: channel 0: close_read\r\n", 31debug2: channel 0: close_read ) = 31 close(8) = 0 write(2, "debug2: channel 0: input open ->"..., 40debug2: channel 0: input open -> drain ) = 40 write(3, "\317\21\213\233\355\n\244`V\264\211\212\307\313\313\213aX\307\324\235\260.H\345T\330_\247\271e\266"..., 48) = 48 write(2, "debug2: channel 0: ibuf empty\r\n", 31debug2: channel 0: ibuf empty ) = 31 write(2, "debug2: channel 0: send eof\r\n", 29debug2: channel 0: send eof ) = 29 write(2, "debug2: channel 0: input drain -"..., 42debug2: channel 0: input drain -> closed ) = 42 select(9, [3 4], [3], NULL, NULL) = 1 (out [3]) rt_sigprocmask(SIG_BLOCK, [CHLD], [TERM CHLD], 8) = 0 rt_sigprocmask(SIG_SETMASK, [TERM CHLD], NULL, 8) = 0 write(3, "\323m\346\231\252\2024\235\272,<@\325\220$q\231\356\321\37\34\272\ndj\377\332\311:?j\360", 32) = 32 select(9, [3 4], [], NULL, NULLExiting on signal 2 debug1: do_cleanup debug1: session_pty_cleanup: session 0 release /dev/pts/0 syslogin_perform_logout: logout() returned an error The read error on fd 8 is probably Ok since I suspect it is the pipe to the shell, which terminated so an error here is probably normal (BTW, this shell is busybox). -- Avis de confidentialit? Les informations contenues dans le pr?sent message et dans toute pi?ce qui lui est jointe sont confidentielles et peuvent ?tre prot?g?es par le secret professionnel. Ces informations sont ? l?usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s?il vous plait communiquer imm?diatement avec l?exp?diteur et en d?truire tout exemplaire. De plus, il vous est strictement interdit de le divulguer, de le distribuer ou de le reproduire sans l?autorisation de l?exp?diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential information which may be privileged and which is intended for the exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or copying of this message and/or any attachment hereto without the consent of the sender is strictly prohibited. Thank you. From mail at eworm.de Mon Jun 23 18:12:15 2014 From: mail at eworm.de (Christian Hesse) Date: Mon, 23 Jun 2014 10:12:15 +0200 Subject: [PATCHv2 1/1] rework printing for visual host key upper border In-Reply-To: <1402926183-14612-1-git-send-email-mail@eworm.de> References: <1402926183-14612-1-git-send-email-mail@eworm.de> Message-ID: <1403511135-13640-1-git-send-email-mail@eworm.de> Key types are getting longer and the current implementation of visual host key breaks with ED25519, resulting in (note the missing bracket): +--[ED25519 256--+ This reworks the calculation of visual host key upper border. Please be aware that this slightly modifies the output for other key types as well: +--[ DSA 1024]----+ +---[DSA 1024]----+ +--[ RSA 2048]----+ +---[RSA 2048]----+ +--[ECDSA 256]---+ +---[ECDSA 256]---+ +--[ED25519 256--+ +--[ED25519 256]--+ --- key.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/key.c b/key.c index e8fc5b1..d75d7be 100644 --- a/key.c +++ b/key.c @@ -547,13 +547,14 @@ key_fingerprint_randomart(u_char *dgst_raw, u_int dgst_raw_len, const Key *k) * intersects with itself. Matter of taste. */ char *augmentation_string = " .o+=*BOX@%&#/^SE"; - char *retval, *p; + char *retval, *p, key_details[FLDSIZE_X + 1]; u_char field[FLDSIZE_X][FLDSIZE_Y]; u_int i, b; int x, y; size_t len = strlen(augmentation_string) - 1; retval = xcalloc(1, (FLDSIZE_X + 3) * (FLDSIZE_Y + 2)); + p = retval; /* initialize field */ memset(field, 0, FLDSIZE_X * FLDSIZE_Y * sizeof(char)); @@ -587,11 +588,15 @@ key_fingerprint_randomart(u_char *dgst_raw, u_int dgst_raw_len, const Key *k) field[FLDSIZE_X / 2][FLDSIZE_Y / 2] = len - 1; field[x][y] = len; - /* fill in retval */ - snprintf(retval, FLDSIZE_X, "+--[%4s %4u]", key_type(k), key_size(k)); - p = strchr(retval, '\0'); + /* assemble key detail string */ + snprintf(key_details, FLDSIZE_X, "[%s %u]", key_type(k), key_size(k)); /* output upper border */ + *p++ = '+'; + for (i = 0; i < (FLDSIZE_X - strlen(key_details)) / 2; i++) + *p++ = '-'; + for (i = 0; key_details[i] != 0; i++) + *p++ = key_details[i]; for (i = p - retval - 1; i < FLDSIZE_X; i++) *p++ = '-'; *p++ = '+'; -- 2.0.0 From techtonik at gmail.com Mon Jun 23 19:44:06 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Mon, 23 Jun 2014 12:44:06 +0300 Subject: -h, --help option Message-ID: Hi, tmux author refuses to add -h, --help option, because OpenSSH does not have it [1]. I don't see why convenience features of tmux should depend on OpenSSH, but because I have no other choice (and got curious) I ask here - why OpenSSH doesn't provide -h or --help option? I use PuTTY as my client, which processes --help option, and for `ssh` binary I usually use Google + StackOverflow. Having --help option that works as an human friendly entrypoint for more information about command would certainly save some time. Current output from `ssh --help`: usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-w local_tun[:remote_tun]] [user@]hostname [command] Proposed output: C:\Program Files\Git\bin>ssh.exe --87 usage: ssh [options] [user@]hostname [command] options: -h --help show this help -v --verbose increase verbosity --version show version -p port port if different from default (default:22) -l login_name -i identity_file -F configfile tunnel options: -D [bind_address:]port run SOCKS server -L [bind_address:]port:host:hostport connect local port to remote host -R [bind_address:]port:host:hostport forward local port for remote access at host:hostport use ssh --help --verbose to show more options. These can be expanded in `ssh -h -v`. I don't remember what these mean. [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] [-e escape_char] [-m mac_spec] [-O ctl_cmd] [-o option] [-S ctl_path] [-w local_tun[:remote_tun]] 1. http://sourceforge.net/p/tmux/mailman/message/32480639/ -- anatoly t. From mfriedl at gmail.com Mon Jun 23 20:00:06 2014 From: mfriedl at gmail.com (Markus Friedl) Date: Mon, 23 Jun 2014 12:00:06 +0200 Subject: -h, --help option In-Reply-To: References: Message-ID: ssh is too complex and a --help option would be a simplistic lie. However, it has an awesome manpage, and this is where the documentation should be. > Am 23.06.2014 um 11:44 schrieb anatoly techtonik : > > Hi, > > tmux author refuses to add -h, --help option, because OpenSSH > does not have it [1]. I don't see why convenience features of tmux > should depend on OpenSSH, but because I have no other choice > (and got curious) I ask here - why OpenSSH doesn't provide -h or > --help option? > > I use PuTTY as my client, which processes --help option, and for > `ssh` binary I usually use Google + StackOverflow. Having --help > option that works as an human friendly entrypoint for more > information about command would certainly save some time. > > Current output from `ssh --help`: > usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] > [-D [bind_address:]port] [-e escape_char] [-F configfile] > [-i identity_file] [-L [bind_address:]port:host:hostport] > [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] > [-R [bind_address:]port:host:hostport] [-S ctl_path] > [-w local_tun[:remote_tun]] [user@]hostname [command] > > Proposed output: > C:\Program Files\Git\bin>ssh.exe --87 > usage: ssh [options] [user@]hostname [command] > > options: > -h --help show this help > -v --verbose increase verbosity > --version show version > > -p port port if different from default (default:22) > -l login_name > -i identity_file > -F configfile > > tunnel options: > -D [bind_address:]port run SOCKS server > -L [bind_address:]port:host:hostport > connect local port to remote host > -R [bind_address:]port:host:hostport > forward local port for remote > access at host:hostport > > use ssh --help --verbose to show more options. > > > These can be expanded in `ssh -h -v`. I don't remember what these mean. > > [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] > [-e escape_char] > [-m mac_spec] [-O ctl_cmd] [-o option] > [-S ctl_path] > [-w local_tun[:remote_tun]] > > > 1. http://sourceforge.net/p/tmux/mailman/message/32480639/ > > -- > anatoly t. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From techtonik at gmail.com Mon Jun 23 20:48:40 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Mon, 23 Jun 2014 13:48:40 +0300 Subject: -h, --help option In-Reply-To: References: Message-ID: I can argue that man pages are absent at least on Windows, but it does not matter here, because comparing manual with command line help is wrong. In other words --help option is not a replacement for a full doc and it is not meant to provide detailed information about software. However, it provides a useful reference for most used options. See git for example, which provides both. `ssh --help` can not lie more than existing output from `ssh`, but to avoid any lies at all, at the end of --help output in proposed solution there is this line: >> use ssh --help --verbose to show more options. and it can be changed to: use `ssh --help --v` to see more options and `man ssh` for detailed info On Mon, Jun 23, 2014 at 1:00 PM, Markus Friedl wrote: > ssh is too complex and a --help option would be a simplistic lie. > > However, it has an awesome manpage, and this is where the documentation should be. > > > >> Am 23.06.2014 um 11:44 schrieb anatoly techtonik : >> >> Hi, >> >> tmux author refuses to add -h, --help option, because OpenSSH >> does not have it [1]. I don't see why convenience features of tmux >> should depend on OpenSSH, but because I have no other choice >> (and got curious) I ask here - why OpenSSH doesn't provide -h or >> --help option? >> >> I use PuTTY as my client, which processes --help option, and for >> `ssh` binary I usually use Google + StackOverflow. Having --help >> option that works as an human friendly entrypoint for more >> information about command would certainly save some time. >> >> Current output from `ssh --help`: >> usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] >> [-D [bind_address:]port] [-e escape_char] [-F configfile] >> [-i identity_file] [-L [bind_address:]port:host:hostport] >> [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] >> [-R [bind_address:]port:host:hostport] [-S ctl_path] >> [-w local_tun[:remote_tun]] [user@]hostname [command] >> >> Proposed output: >> C:\Program Files\Git\bin>ssh.exe --87 >> usage: ssh [options] [user@]hostname [command] >> >> options: >> -h --help show this help >> -v --verbose increase verbosity >> --version show version >> >> -p port port if different from default (default:22) >> -l login_name >> -i identity_file >> -F configfile >> >> tunnel options: >> -D [bind_address:]port run SOCKS server >> -L [bind_address:]port:host:hostport >> connect local port to remote host >> -R [bind_address:]port:host:hostport >> forward local port for remote >> access at host:hostport >> >> use ssh --help --verbose to show more options. >> >> >> These can be expanded in `ssh -h -v`. I don't remember what these mean. >> >> [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec] >> [-e escape_char] >> [-m mac_spec] [-O ctl_cmd] [-o option] >> [-S ctl_path] >> [-w local_tun[:remote_tun]] >> >> >> 1. http://sourceforge.net/p/tmux/mailman/message/32480639/ >> >> -- >> anatoly t. >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- anatoly t. From mouring at eviladmin.org Tue Jun 24 01:11:48 2014 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 23 Jun 2014 10:11:48 -0500 Subject: -h, --help option In-Reply-To: References: Message-ID: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> On Jun 23, 2014, at 5:48 AM, anatoly techtonik wrote: > I can argue that man pages are absent at least on Windows, but it does > not matter here, because comparing manual with command line help is > wrong. That would be an issue you should take up with the whomever packaged your ssh for windows. > In other words --help option is not a replacement for a full doc and it is > not meant to provide detailed information about software. However, it > provides a useful reference for most used options. See git for example, > which provides both. The issue with this is two fold: 1. Keep the documentation up in two places is more painful than one. 2. Attempting to sum up a lot of the ssh options via one-liners becomes pretty hard as even a paragraph or two in the manage doesn't always fully explain the minor ticks that may burn you if you aren't reading carefully. I agree with Markus that most --help ends up being a lie as it barely explains the meaning of the options a lot of times, and in the end I still have to dig up the manpage so they just cost more time for the developer. - Ben From llbecke at gmail.com Tue Jun 24 02:39:48 2014 From: llbecke at gmail.com (Larry Becke) Date: Mon, 23 Jun 2014 11:39:48 -0500 Subject: ListenAdress Exclusion Message-ID: I was wondering what everyone's thoughts were on a simpler way to exclude addresses from having listeners on them. I know a lot of people have multiple subnets, especially larger corporations. Some networks are non-route-able, and therefor unsuitable for use with SSH, aside from communication between other servers on the same subnet. Given that we may want to exclude those non-route-able subnets / vlans from SSH use, I am proposing that rather than listing all of the acceptable vlans for listeners, that we use the following format to build an exclusion list. That would be like ListenAddress 0.0.0.0 ListenAddress !192.168.0.0/24 ListenAddress !192.168.1.0/24 I have searched through the man pages and openssh documentation and have found nothing to this kind of configuration, with everyone talking about using tcp wrappers or iptables to block ssh from accepting connections on different subnets. I feel that this would be a simpler way to prevent ssh from even starting on those subnets. Thanks for your time and consideration. Larry Becke From gert at greenie.muc.de Tue Jun 24 04:40:24 2014 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 23 Jun 2014 20:40:24 +0200 Subject: ListenAdress Exclusion In-Reply-To: References: Message-ID: <20140623184024.GJ1118@greenie.muc.de> Hi, On Mon, Jun 23, 2014 at 11:39:48AM -0500, Larry Becke wrote: > I feel that this would be a simpler way to prevent ssh from even starting > on those subnets. Implementation would be fairly complex - there is no way to tell the socket API "Listen on 'any' but exclude *those*", so you'd have to enumerate all IP addresses the machine has (which might change during sshd lifetime), then match that with the exclude list, and use the result for many individual bind()s. As this is portability madness, I'd really avoid going there... (though I'm not an OpenSSH developer, just a sysadmin having run into issues with that with other software on more exotic platforms). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From djm at mindrot.org Tue Jun 24 16:28:16 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 24 Jun 2014 16:28:16 +1000 (EST) Subject: ListenAdress Exclusion In-Reply-To: References: Message-ID: On Mon, 23 Jun 2014, Larry Becke wrote: > I was wondering what everyone's thoughts were on a simpler way to exclude > addresses from having listeners on them. > > I know a lot of people have multiple subnets, especially larger > corporations. > > Some networks are non-route-able, and therefor unsuitable for use with SSH, > aside from communication between other servers on the same subnet. I made this patch earlier this year. It adds a ListenFilter sshd_config option to select addresses to listen on by network/mask. It required getifaddrs(), which is available on BSDish/Linux systems but probably not legacy Unix so porting it might be problematic. It also won't cope well with machines with dynamic interfaces: the addresses to listen on will be selected when sshd starts only. Usage: sshd_config => ListenAddress * ListenFilter 127.0.0.0/8 10.0.0.0/8 Will listen only on addresses matching 127.* and 10.* If there is enough interest then it might be worth polishing up and committing. -d Index: servconf.c =================================================================== RCS file: /var/cvs/openssh/servconf.c,v retrieving revision 1.247 diff -u -p -r1.247 servconf.c --- servconf.c 4 Feb 2014 00:12:57 -0000 1.247 +++ servconf.c 24 Mar 2014 07:29:56 -0000 @@ -153,6 +153,7 @@ initialize_server_options(ServerOptions options->ip_qos_interactive = -1; options->ip_qos_bulk = -1; options->version_addendum = NULL; + options->num_listen_filters = 0; } void @@ -348,6 +349,7 @@ typedef enum { sKexAlgorithms, sIPQoS, sVersionAddendum, sAuthorizedKeysCommand, sAuthorizedKeysCommandUser, sAuthenticationMethods, sHostKeyAgent, + sListenFilter, sDeprecated, sUnsupported } ServerOpCodes; @@ -474,6 +476,7 @@ static struct { { "authorizedkeyscommanduser", sAuthorizedKeysCommandUser, SSHCFG_ALL }, { "versionaddendum", sVersionAddendum, SSHCFG_GLOBAL }, { "authenticationmethods", sAuthenticationMethods, SSHCFG_ALL }, + { "listenfilter", sListenFilter, SSHCFG_GLOBAL }, { NULL, sBadOption, 0 } }; @@ -1620,6 +1623,25 @@ process_server_config_line(ServerOptions } return 0; + case sListenFilter: + if (*activep && options->num_listen_filters == 0) { + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_listen_filters >= + MAX_LISTEN_FILTERS) + fatal("%s line %d: " + "too many listen address filters.", + filename, linenum); + if (addr_match_list(NULL, arg) != 0) + fatal("%s line %d: " + "invalid ListenFilter address %s", + filename, linenum, arg); + options->listen_filter[ + options->num_listen_filters++] = + xstrdup(arg); + } + } + return 0; + case sDeprecated: logit("%s line %d: Deprecated option %s", filename, linenum, arg); @@ -2056,6 +2078,8 @@ dump_config(ServerOptions *o) dump_cfg_strarray(sAcceptEnv, o->num_accept_env, o->accept_env); dump_cfg_strarray_oneline(sAuthenticationMethods, o->num_auth_methods, o->auth_methods); + dump_cfg_strarray_oneline(sListenFilter, o->num_listen_filters, + o->listen_filter); /* other arguments */ for (i = 0; i < o->num_subsystems; i++) Index: servconf.h =================================================================== RCS file: /var/cvs/openssh/servconf.h,v retrieving revision 1.104 diff -u -p -r1.104 servconf.h --- servconf.h 4 Feb 2014 00:12:57 -0000 1.104 +++ servconf.h 24 Mar 2014 07:29:56 -0000 @@ -29,6 +29,7 @@ #define MAX_MATCH_GROUPS 256 /* Max # of groups for Match. */ #define MAX_AUTHKEYS_FILES 256 /* Max # of authorized_keys files. */ #define MAX_AUTH_METHODS 256 /* Max # of AuthenticationMethods. */ +#define MAX_LISTEN_FILTERS 4 /* Max # of ListenFilters. */ /* permit_root_login */ #define PERMIT_NOT_SET -1 @@ -183,6 +184,9 @@ typedef struct { u_int num_auth_methods; char *auth_methods[MAX_AUTH_METHODS]; + + u_int num_listen_filters; + char *listen_filter[MAX_LISTEN_FILTERS]; } ServerOptions; /* Information about the incoming connection as used by Match */ Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.448 diff -u -p -r1.448 sshd.c --- sshd.c 26 Feb 2014 23:20:08 -0000 1.448 +++ sshd.c 24 Mar 2014 07:29:56 -0000 @@ -71,6 +71,7 @@ #include #include #include +#include #include #include @@ -121,6 +122,7 @@ #include "roaming.h" #include "ssh-sandbox.h" #include "version.h" +#include "match.h" #ifdef LIBWRAP #include @@ -1073,6 +1075,114 @@ server_accept_inetd(int *sock_in, int *s debug("inetd sockets after dupping: %d, %d", *sock_in, *sock_out); } +static const char * +render_addr(struct sockaddr *addr) +{ + char ntop[NI_MAXHOST], strport[NI_MAXSERV]; + static char ret[NI_MAXHOST+NI_MAXSERV+2+1+1]; + int r; + + if (addr->sa_family != AF_INET && addr->sa_family != AF_INET6) { + snprintf(ret, sizeof(ret), "", + addr->sa_family); + return ret; + } + + if ((r = getnameinfo(addr, + addr->sa_family == AF_INET ? + sizeof(struct sockaddr_in) : sizeof(struct sockaddr_in6), + ntop, sizeof(ntop), strport, sizeof(strport), + NI_NUMERICHOST|NI_NUMERICSERV)) != 0) { + snprintf(ret, sizeof(ret), "", + ssh_gai_strerror(r)); + return ret; + } + snprintf(ret, sizeof(ret), "[%s]:%s", ntop, strport); + return ret; +} + +#define E_S4(a) ((struct sockaddr_in *)((a)->ai_addr)) +#define E_S6(a) ((struct sockaddr_in6 *)((a)->ai_addr)) + +/* Expand wildcard addresses in addrlist to actual interface addresses */ +static struct addrinfo * +expand_local_addrs(struct addrinfo *addrlist) +{ + struct ifaddrs *ifaddrs, *ifa; + struct addrinfo *ai, *ret = NULL, **rl = &ret; + int i, v6, have_wild4 = 0, have_wild6 = 0; + + if (addrlist == NULL) + return NULL; + + if (getifaddrs(&ifaddrs) != 0) + fatal("%s: getifaddrs: %s", __func__, strerror(errno)); + + for (i = 0, ai = addrlist; ai; ai = ai->ai_next, i++) { + if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6) { + debug3("%s: addr %d AF %d", __func__, i, ai->ai_family); + continue; + } + v6 = ai->ai_family == AF_INET6; + + debug3("%s: addr %d %s: %s", __func__, + i, v6 ? "IPv6" : "IPv4", render_addr(ai->ai_addr)); + + /* If the address is not all-zero then copy as-is */ + if ((!v6 && E_S4(ai)->sin_addr.s_addr != 0) || + (v6 && IN6_IS_ADDR_UNSPECIFIED(E_S6(ai)))) { + *rl = xcalloc(1, sizeof(*ai)); + **rl = *ai; + (*rl)->ai_addr = xcalloc(1, ai->ai_addrlen); + memcpy((*rl)->ai_addr, ai->ai_addr, ai->ai_addrlen); + (*rl)->ai_canonname = NULL; + (*rl)->ai_next = NULL; + rl = &(*rl)->ai_next; + continue; + } + /* If we've already seen a wildcard of this family then skip */ + if (v6) { + if (have_wild6) + continue; + have_wild6 = 1; + } else { + if (have_wild4) + continue; + have_wild4 = 1; + } + debug3("%s: expanding address", __func__); + /* Append all interface addresses with matching family here */ + for (ifa = ifaddrs; ifa; ifa = ifa->ifa_next) { + if (ifa->ifa_addr == NULL || + ifa->ifa_addr->sa_family != ai->ai_family) + continue; + /* Append */ + *rl = xcalloc(1, sizeof(*ai)); + **rl = *ai; + (*rl)->ai_addr = xcalloc(1, ai->ai_addrlen); + memcpy((*rl)->ai_addr, ifa->ifa_addr, + (*rl)->ai_addrlen); + if (v6) + E_S6(*rl)->sin6_port = E_S6(ai)->sin6_port; + else + E_S4(*rl)->sin_port = E_S4(ai)->sin_port; + (*rl)->ai_canonname = NULL; + (*rl)->ai_next = NULL; + debug3("%s: copied address %s from interface %s", + __func__, render_addr((*rl)->ai_addr), + ifa->ifa_name); + rl = &(*rl)->ai_next; + } + } + debug3("%s: result:", __func__); + for (i = 0, ai = ret; ai; ai = ai->ai_next, i++) { + debug3("%s: addr %d: %s", + __func__, i, render_addr(ai->ai_addr)); + } + freeaddrinfo(addrlist); + return ret; +} + /* * Listen for TCP connections */ @@ -1082,6 +1192,10 @@ server_listen(void) int ret, listen_sock, on = 1; struct addrinfo *ai; char ntop[NI_MAXHOST], strport[NI_MAXSERV]; + u_int matched, i; + + if (options.num_listen_filters > 0) + options.listen_addrs = expand_local_addrs(options.listen_addrs); for (ai = options.listen_addrs; ai; ai = ai->ai_next) { if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6) @@ -1094,6 +1208,18 @@ server_listen(void) NI_NUMERICHOST|NI_NUMERICSERV)) != 0) { error("getnameinfo failed: %.100s", ssh_gai_strerror(ret)); + continue; + } + for (i = matched = 0; i < options.num_listen_filters; i++) { + if (addr_match_cidr_list(ntop, + options.listen_filter[i]) == 1) { + matched = 1; + break; + } + } + if (options.num_listen_filters > 0 && !matched) { + debug("%s: listen address [%s]:%s did not match filter", + __func__, ntop, strport); continue; } /* Create socket for listening. */ From techtonik at gmail.com Tue Jun 24 17:12:15 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 24 Jun 2014 10:12:15 +0300 Subject: -h, --help option In-Reply-To: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> Message-ID: On Mon, Jun 23, 2014 at 6:11 PM, Ben Lindstrom wrote: > On Jun 23, 2014, at 5:48 AM, anatoly techtonik wrote: > >> I can argue that man pages are absent at least on Windows, but it does >> not matter here, because comparing manual with command line help is >> wrong. > > That would be an issue you should take up with the whomever packaged your ssh for windows. Manual page is a separate issue. I don't skip it just to make sure the point is covered. `ssh` on Windows comes with git from this package - http://msysgit.github.io/ because it highly depends on other Linux tools. The archive is 15Mb with 246Mb unpacked. The only manual shipped is HTML formatted man pages for Git itself. Including manuals for other 146 binary files from its /bin path would bloat the installation significantly. Git neglected Windows platform for a long time, but in the end they took usability on this platform seriously. HTML pages are more usable than man, just because we are all familiar with browsers and know where is their search button. >> In other words --help option is not a replacement for a full doc and it is >> not meant to provide detailed information about software. However, it >> provides a useful reference for most used options. See git for example, >> which provides both. > > The issue with this is two fold: > > 1. Keep the documentation up in two places is more painful than one. Again. Command line help is not documentation. - command line help is a one page reference. - documentation is a hundred(s) page description I don't see how maintaining a single page of human readable option description is more painful than maintaining hundred pages of C code that parses these options. --help page will be updated once in few years. Command line help is usually autogenerated, and libs like docopt even build commandline interface from its human description. > 2. Attempting to sum up a lot of the ssh options via one-liners becomes pretty hard as even a paragraph or two in the manage doesn't always fully explain the minor ticks that may burn you if you aren't reading carefully. 2.1. No need to sum up a lot of options - for --help only the most used/most important ones are needed 2.2. Minor tricks that burn users by default is an indicator of complex and maybe complicated interface, so an attempt to sum up the interface may lead to new ideas for refactoring to make it more suitable for humans. It may be more fruitful if you reply to original letter and comment on output example. > I agree with Markus that most --help ends up being a lie as it barely explains the meaning of the options a lot of times, and in the end I still have to dig up the manpage so they just cost more time for the developer. With such logic I can say that any non-expanded clause a lie, because it misses details. However, command line reference is never meant to be complete and contain them. Again, take git is an example. Also you're communicating with humans, so it is completely ok to mention 'consult man page for details' in --help output. Also, you need man page only once, to understand the concept. You can read about it from the web, and to be honest, answers on stackoverflow most of the time explain issues and solutions better that ssh man pages. In my sessions command line help is invoked pretty often - at least 1/4 of time, because I constantly work with multiple platforms - sometimes options do not match, but more often I just forget them. -- anatoly t. From opensshdev at r.paypc.com Tue Jun 24 17:44:37 2014 From: opensshdev at r.paypc.com (Morham) Date: Tue, 24 Jun 2014 00:44:37 -0700 Subject: Reverse tunnel security settings In-Reply-To: References: Message-ID: <53A92C65.4080309@r.paypc.com> On 6/20/2014 2:25 PM, Stuart Henderson wrote: > PF can do this, though I'm not quite sure if doing this from a firewall > counts as a "good way" and, given the controls already available on > local forwarding, it does seem like something that it would be > reasonable to implement internally in ssh. As of the 2.6.x kernels, iptables has support for it as well. See the "owner" module, and if you're going to do this, you might as well enable uid-logging in any LOG rules. If you use grsecurity, you can also create gids that restrict client or server (or both) network socket usage completely, i.e., big hammer. =M= From gprathap1121 at gmail.com Tue Jun 24 20:59:17 2014 From: gprathap1121 at gmail.com (G Prathap) Date: Tue, 24 Jun 2014 16:29:17 +0530 Subject: Space after openssh prompt Message-ID: Hello, I am working on a automation project, which uses ssh for connection to the server. once the ssh prompt is displayed there is a ' ' space by default between the ssh username and the prompt. This space is causing my automation script to stop working. Can I get some pointers in verification and modification of the ssh prompt after providing username & password. Thanks alot in advance. With Regards Prathap G From logan at elandsys.com Tue Jun 24 21:16:19 2014 From: logan at elandsys.com (Loganaden Velvindron) Date: Tue, 24 Jun 2014 04:16:19 -0700 Subject: Space after openssh prompt In-Reply-To: References: Message-ID: <20140624111619.GA26167@mx.elandsys.com> On Tue, Jun 24, 2014 at 04:29:17PM +0530, G Prathap wrote: > Hello, > > I am working on a automation project, which uses ssh for connection to the > server. > once the ssh prompt is displayed there is a ' ' space by default between > the > ssh username and the prompt. > > This space is causing my automation script to stop working. > > Can I get some pointers in verification and modification of the ssh prompt > after > providing username & password. > > Thanks alot in advance. > Please fix your automation script. > With Regards > Prathap G > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From mfriedl at gmail.com Tue Jun 24 21:48:17 2014 From: mfriedl at gmail.com (Markus Friedl) Date: Tue, 24 Jun 2014 13:48:17 +0200 Subject: -h, --help option In-Reply-To: References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> Message-ID: <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> Sorry, here won't be an extra --help. The manpage and the short usage output are already enough work. Without that focus the quality will decrease. -m > Am 24.06.2014 um 09:12 schrieb anatoly techtonik : > >> On Mon, Jun 23, 2014 at 6:11 PM, Ben Lindstrom wrote: >>> On Jun 23, 2014, at 5:48 AM, anatoly techtonik wrote: >>> >>> I can argue that man pages are absent at least on Windows, but it does >>> not matter here, because comparing manual with command line help is >>> wrong. >> >> That would be an issue you should take up with the whomever packaged your ssh for windows. > > Manual page is a separate issue. I don't skip it just to make sure the > point is covered. > > `ssh` on Windows comes with git from this package - > http://msysgit.github.io/ because it highly depends on other Linux tools. > The archive is 15Mb with 246Mb unpacked. The only manual shipped > is HTML formatted man pages for Git itself. Including manuals for other > 146 binary files from its /bin path would bloat the installation significantly. > > Git neglected Windows platform for a long time, but in the end they took > usability on this platform seriously. HTML pages are more usable than > man, just because we are all familiar with browsers and know where > is their search button. > >>> In other words --help option is not a replacement for a full doc and it is >>> not meant to provide detailed information about software. However, it >>> provides a useful reference for most used options. See git for example, >>> which provides both. >> >> The issue with this is two fold: >> >> 1. Keep the documentation up in two places is more painful than one. > > Again. Command line help is not documentation. > - command line help is a one page reference. > - documentation is a hundred(s) page description > > I don't see how maintaining a single page of human readable > option description is more painful than maintaining hundred > pages of C code that parses these options. > > --help page will be updated once in few years. Command line help is > usually autogenerated, and libs like docopt even build commandline > interface from its human description. > >> 2. Attempting to sum up a lot of the ssh options via one-liners becomes pretty hard as even a paragraph or two in the manage doesn't always fully explain the minor ticks that may burn you if you aren't reading carefully. > > 2.1. No need to sum up a lot of options - for --help only the most > used/most important ones are needed > 2.2. Minor tricks that burn users by default is an indicator of > complex and maybe complicated interface, so an attempt to sum up the > interface may lead to new ideas for refactoring to make it more > suitable for humans. > > It may be more fruitful if you reply to original letter and comment on > output example. > >> I agree with Markus that most --help ends up being a lie as it barely explains the meaning of the options a lot of times, and in the end I still have to dig up the manpage so they just cost more time for the developer. > > With such logic I can say that any non-expanded clause a lie, because > it misses details. However, command line reference is never meant to > be complete and contain them. Again, take git is an example. Also > you're communicating with humans, so it is completely ok to mention > 'consult man page for details' in --help output. > > Also, you need man page only once, to understand the concept. You can > read about it from the web, and to be honest, answers on stackoverflow > most of the time explain issues and solutions better that ssh man > pages. In my sessions command line help is invoked pretty often - at > least 1/4 of time, because I constantly work with multiple platforms - > sometimes options do not match, but more often I just forget them. > > -- > anatoly t. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From techtonik at gmail.com Wed Jun 25 00:08:58 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 24 Jun 2014 17:08:58 +0300 Subject: -h, --help option In-Reply-To: <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> Message-ID: Enough work? Is the main problem in that ssh option parsing code doesn't support long options and doing this in C in cross-platform manner doesn't worth the development time? Maybe the problem is that people are not interested to do this work, because it simply doesn't affect them? On Tue, Jun 24, 2014 at 2:48 PM, Markus Friedl wrote: > Sorry, here won't be an extra --help. > > The manpage and the short usage output are already enough work. > > Without that focus the quality will decrease. > > -m > > > >> Am 24.06.2014 um 09:12 schrieb anatoly techtonik : >> >>> On Mon, Jun 23, 2014 at 6:11 PM, Ben Lindstrom wrote: >>>> On Jun 23, 2014, at 5:48 AM, anatoly techtonik wrote: >>>> >>>> I can argue that man pages are absent at least on Windows, but it does >>>> not matter here, because comparing manual with command line help is >>>> wrong. >>> >>> That would be an issue you should take up with the whomever packaged your ssh for windows. >> >> Manual page is a separate issue. I don't skip it just to make sure the >> point is covered. >> >> `ssh` on Windows comes with git from this package - >> http://msysgit.github.io/ because it highly depends on other Linux tools. >> The archive is 15Mb with 246Mb unpacked. The only manual shipped >> is HTML formatted man pages for Git itself. Including manuals for other >> 146 binary files from its /bin path would bloat the installation significantly. >> >> Git neglected Windows platform for a long time, but in the end they took >> usability on this platform seriously. HTML pages are more usable than >> man, just because we are all familiar with browsers and know where >> is their search button. >> >>>> In other words --help option is not a replacement for a full doc and it is >>>> not meant to provide detailed information about software. However, it >>>> provides a useful reference for most used options. See git for example, >>>> which provides both. >>> >>> The issue with this is two fold: >>> >>> 1. Keep the documentation up in two places is more painful than one. >> >> Again. Command line help is not documentation. >> - command line help is a one page reference. >> - documentation is a hundred(s) page description >> >> I don't see how maintaining a single page of human readable >> option description is more painful than maintaining hundred >> pages of C code that parses these options. >> >> --help page will be updated once in few years. Command line help is >> usually autogenerated, and libs like docopt even build commandline >> interface from its human description. >> >>> 2. Attempting to sum up a lot of the ssh options via one-liners becomes pretty hard as even a paragraph or two in the manage doesn't always fully explain the minor ticks that may burn you if you aren't reading carefully. >> >> 2.1. No need to sum up a lot of options - for --help only the most >> used/most important ones are needed >> 2.2. Minor tricks that burn users by default is an indicator of >> complex and maybe complicated interface, so an attempt to sum up the >> interface may lead to new ideas for refactoring to make it more >> suitable for humans. >> >> It may be more fruitful if you reply to original letter and comment on >> output example. >> >>> I agree with Markus that most --help ends up being a lie as it barely explains the meaning of the options a lot of times, and in the end I still have to dig up the manpage so they just cost more time for the developer. >> >> With such logic I can say that any non-expanded clause a lie, because >> it misses details. However, command line reference is never meant to >> be complete and contain them. Again, take git is an example. Also >> you're communicating with humans, so it is completely ok to mention >> 'consult man page for details' in --help output. >> >> Also, you need man page only once, to understand the concept. You can >> read about it from the web, and to be honest, answers on stackoverflow >> most of the time explain issues and solutions better that ssh man >> pages. In my sessions command line help is invoked pretty often - at >> least 1/4 of time, because I constantly work with multiple platforms - >> sometimes options do not match, but more often I just forget them. >> >> -- >> anatoly t. >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- anatoly t. From dtucker at zip.com.au Wed Jun 25 02:24:00 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 24 Jun 2014 12:24:00 -0400 Subject: -h, --help option In-Reply-To: References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> Message-ID: On Tue, Jun 24, 2014 at 10:08 AM, anatoly techtonik wrote: > Enough work? Is the main problem in that ssh option parsing code doesn't > support long options and doing this in C in cross-platform manner doesn't > worth the development time? > Long options are a non-standard GNU extension. OpenSSH aims to be a POSIX program. See http://pubs.opengroup.org/onlinepubs/009695399/functions/getopt.html and http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02 . > Maybe the problem is that people are not interested to do this work, > because it simply doesn't affect them? More like people disagree with you that it should be done. from upthread: > HTML pages are more usable than man, just because we are all familiar > with browsers and know where is their search button. Try http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 -- 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 techtonik at gmail.com Wed Jun 25 04:53:42 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 24 Jun 2014 21:53:42 +0300 Subject: -h, --help option In-Reply-To: References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> Message-ID: On Tue, Jun 24, 2014 at 7:24 PM, Darren Tucker wrote: > On Tue, Jun 24, 2014 at 10:08 AM, anatoly techtonik > wrote: >> >> Enough work? Is the main problem in that ssh option parsing code doesn't >> support long options and doing this in C in cross-platform manner doesn't >> worth the development time? > > Long options are a non-standard GNU extension. OpenSSH aims to be a POSIX > program. See > http://pubs.opengroup.org/onlinepubs/009695399/functions/getopt.html and > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02 Do GNU/POSIX standards evolve? If not, is there any more modern standard that includes these? I am worried, because --help is a standard option for any Python program, so no Python program can be POSIX compliant. Are there any modern initiatives to develop standard like POSIX. Modern means backed up with latest UX research that emerged in the last decade? >> Maybe the problem is that people are not interested to do this work, >> because it simply doesn't affect them? > More like people disagree with you that it should be done. Right. There are only two replies and it is always hard to persuade my stats senses that the selection is representative even if there are no reasons to doubt. > from upthread: >> >> HTML pages are more usable than man, just because we are all familiar with >> browsers and know where is their search button. > > > Try http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 StackOverflow is better and more Google friendly. =) -- anatoly t. From scott_n at xypro.com Wed Jun 25 05:05:10 2014 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 24 Jun 2014 19:05:10 +0000 Subject: -h, --help option In-Reply-To: References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> Message-ID: Quoth anatoly: >Do GNU/POSIX standards evolve? If not, is there any more modern standard that includes these? > I am worried, because --help is a standard option for any Python program, so no Python program can be POSIX compliant. > >Are there any modern initiatives to develop standard like POSIX. Modern means backed up with latest UX research that emerged in the last decade? I'm just a layman and a lurker, but wouldn't there also be licensing issues with using the GNU long options code? From william at 25thandClement.com Wed Jun 25 05:56:49 2014 From: william at 25thandClement.com (William Ahern) Date: Tue, 24 Jun 2014 12:56:49 -0700 Subject: -h, --help option In-Reply-To: References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> Message-ID: <20140624195649.GB18793@wilbur.25thandClement.com> On Tue, Jun 24, 2014 at 09:53:42PM +0300, anatoly techtonik wrote: > On Tue, Jun 24, 2014 at 7:24 PM, Darren Tucker wrote: > > On Tue, Jun 24, 2014 at 10:08 AM, anatoly techtonik > > wrote: > >> > >> Enough work? Is the main problem in that ssh option parsing code doesn't > >> support long options and doing this in C in cross-platform manner doesn't > >> worth the development time? > > > > Long options are a non-standard GNU extension. OpenSSH aims to be a POSIX > > program. See > > http://pubs.opengroup.org/onlinepubs/009695399/functions/getopt.html and > > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02 > > Do GNU/POSIX standards evolve? If not, is there any more modern standard that > includes these? I am worried, because --help is a standard option for any Python > program, so no Python program can be POSIX compliant. OpenSSH uses chroot, which is technically a BSD extension not in POSIX. I personally wouldn't characterize getopt_long as a GNU extension, considering how widely it's supported. All the open source POSIX-compliant and POSIX-aspiring platforms support it. OpenBSD added it in 2002. Solaris has it. AFAIK the only widely used Unix systems that don't implement it are AIX, HP-UX, and QNX. But freely licensed (non-GPL versions) abound. And like chroot I expect getopt_long to continue spreading. Unlike chroot, though, supporting getopt_long is alot of hassle for little benefit. _Especially_ considering that the developers don't see much value in even supporting getopt. That getopt_long isn't in POSIX is almost beside the point, and maybe the reply was just a polite way to end the discussion with an indisputable counter-argument. And what Python does is irrelevant to OpenSSH and its goals. However, if you want to champion getopt_long's introduction to POSIX, feel free. POSIX is a still being developed, and they're still taking feature requests for Issue 8. I couldn't find a ticket for getopt_long at austingroupbugs.net. But you should inquire with someone more familiar with the process before opening a ticket. > Are there any modern initiatives to develop standard like POSIX. Modern means > backed up with latest UX research that emerged in the last decade? > > >> Maybe the problem is that people are not interested to do this work, > >> because it simply doesn't affect them? > > More like people disagree with you that it should be done. > > Right. There are only two replies and it is always hard to persuade my stats > senses that the selection is representative even if there are no reasons to > doubt. That nobody else is speaking up speaks volumes, I think. If a long-time maintainer says that it's not worthwhile, then why continue arguing after all the chips are on the table? Maybe the project will change its mind down the road, but in the meantime you should probably accept the answer you got. Also, it's usually poor form to request a feature without also offering a patch, even if the patch is just a jumping off point. Without actually editing the code you have no perspective regarding the relative costs. > > from upthread: > >> > >> HTML pages are more usable than man, just because we are all familiar with > >> browsers and know where is their search button. > > > > Try http://www.openbsd.org/cgi-bin/man.cgi?query=ssh&sektion=1 > > StackOverflow is better and more Google friendly. =) I'm sure that the OpenSSH maintainers don't believe Stack Overflow to be a preferable resource to the manual page. Personally I think it's a poor habit to consult such a forum before consulting the documentation. Stack Overflow is rife with cargo culting. That said, if you care to visit Usenet I believe there are some people who work on POSIX who read comp.unix.programmer. They may also post on Stack Overflow for all I know, but comp.unix.programmer is a more reliable and trustworthy forum with more in-depth discussions. In 10 years I expect Stack Overflow to be effectively gone, replaced by some other website, but comp.unix.programmer to still be active. From dtucker at zip.com.au Wed Jun 25 07:05:47 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 24 Jun 2014 17:05:47 -0400 Subject: -h, --help option In-Reply-To: <20140624195649.GB18793@wilbur.25thandClement.com> References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> <20140624195649.GB18793@wilbur.25thandClement.com> Message-ID: On Tue, Jun 24, 2014 at 3:56 PM, William Ahern wrote: > > OpenSSH uses chroot, which is technically a BSD extension not in POSIX. You have a source for that? It was in Unix System 7: http://plan9.bell-labs.com/7thEdMan/vol1/man2.bun and it's in SuSv2: http://pubs.opengroup.org/onlinepubs/007908799/xsh/chroot.html [...] > Also, it's usually poor form to request a feature without also offering a > patch IMO asking if something would be accepted before expending the effort is reasonable. -- 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 techtonik at gmail.com Wed Jun 25 07:29:41 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 25 Jun 2014 00:29:41 +0300 Subject: -h, --help option In-Reply-To: <20140624195649.GB18793@wilbur.25thandClement.com> References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> <20140624195649.GB18793@wilbur.25thandClement.com> Message-ID: On Tue, Jun 24, 2014 at 10:56 PM, William Ahern wrote: > > That getopt_long isn't in POSIX is almost beside the point, and maybe the > reply was just a polite way to end the discussion with an indisputable > counter-argument. And what Python does is irrelevant to OpenSSH and its > goals. Well, from http://www.openssh.com/goals.html it looks like OpenSSH goals is to be cryptic. I don't see anything about being user friendly, so you're right. ) > However, if you want to champion getopt_long's introduction to POSIX, feel > free. I don't know what is getopt_long. Python uses optparse (ported to other scripting languages) and given the choice, I'd use http://docopt.org/ - it has MIT licensed C code generator that is probably easier to modify than to rewrite getopt_long. > POSIX is a still being developed, and they're still taking feature > requests for Issue 8. I couldn't find a ticket for getopt_long at > austingroupbugs.net. But you should inquire with someone more familiar with > the process before opening a ticket. I feel like shaving yaks. Nobody else uses --help option for any program out there? Nobody finds it convenient? > That nobody else is speaking up speaks volumes, I think. If a long-time > maintainer says that it's not worthwhile, then why continue arguing after > all the chips are on the table? Maybe the project will change its mind down > the road, but in the meantime you should probably accept the answer you got. All answers are accepted regardless of status or personalities. >> >> StackOverflow is better and more Google friendly. =) > > I'm sure that the OpenSSH maintainers don't believe Stack Overflow to be a > preferable resource to the manual page. Personally I think it's a poor habit > to consult such a forum before consulting the documentation. Stack Overflow > is rife with cargo culting. Every generation has its own way of communication. I believe those who prefer mailing lists will use 'man ssh' and those who use SO, use '--help', so I am just expressing interests of likeminded group of people. How large is this group? Well, I don't know. But at least SO provides some stats about common problems: http://stackoverflow.com/questions/tagged/ssh?sort=votes&pageSize=15 > That said, if you care to visit Usenet I believe there are some people who > work on POSIX who read comp.unix.programmer. They may also post on Stack > Overflow for all I know, but comp.unix.programmer is a more reliable and > trustworthy forum with more in-depth discussions. In 10 years I expect Stack > Overflow to be effectively gone, replaced by some other website, but > comp.unix.programmer to still be active. Do you mean this Google Group? I am not sure why it should be better than SO. https://groups.google.com/forum/#!forum/comp.unix.programmer -- anatoly t. From william at 25thandclement.com Wed Jun 25 07:54:51 2014 From: william at 25thandclement.com (William Ahern) Date: Tue, 24 Jun 2014 14:54:51 -0700 Subject: -h, --help option In-Reply-To: References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> <20140624195649.GB18793@wilbur.25thandClement.com> Message-ID: <20140624215451.GA1874@wilbur.25thandClement.com> On Tue, Jun 24, 2014 at 05:05:47PM -0400, Darren Tucker wrote: > On Tue, Jun 24, 2014 at 3:56 PM, William Ahern > wrote: > > > > OpenSSH uses chroot, which is technically a BSD extension not in POSIX. > > > You have a source for that? It was in Unix System 7: > http://plan9.bell-labs.com/7thEdMan/vol1/man2.bun > and it's in SuSv2: > http://pubs.opengroup.org/onlinepubs/007908799/xsh/chroot.html > chroot was removed in POSIX.1-2001 / SUSv3. B.3.2 System Interfaces Removed in the Previous Version The following system interfaces, headers, and external variables were removed in the previous version of this standard: ... chroot() See http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap03.html The most recent version is POSIX.1-2008 / SUSv4 TC1 (2013), which actually includes a ton of erstwhile GNU extensions, as Red Hat and other Linux vendors actively pushed for adoption of glibc interfaces. OpenBSD has been busy over the past several years slowly adding some of these. I'm surprised getopt_long never made the cut (or wasn't proposed) given how widely it was already supported compared to interfaces like fmemopen, which previously existed nowhere else except on Linux. But other than maybe RHEL and AIX, nobody supports POSIX.1-2008, not even Solaris. But POSIX.1-2008 added many functions that people took for granted, like dirfd, fopendir, strsignal, and mkdtemp. So POSIX-compatible isn't a very useful term alone. Sticking to POSIX.1-2001 is too limiting, but you can't actually depend on POSIX.1-2008 (definitely don't define _POSIX_C_SOURCE to 200809 unless you're a masochist) because then you wouldn't be portable by an stretch of the imagination. From peter at stuge.se Wed Jun 25 08:57:16 2014 From: peter at stuge.se (Peter Stuge) Date: Wed, 25 Jun 2014 00:57:16 +0200 Subject: -h, --help option In-Reply-To: References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> <0037FF29-E788-4294-83B5-57201D5A8BB1@gmail.com> <20140624195649.GB18793@wilbur.25thandClement.com> Message-ID: <20140624225717.1441.qmail@stuge.se> anatoly techtonik wrote: > Every generation has its own way of communication. http://bropages.org/ssh //Peter From markcs at gwyll.eu Wed Jun 25 10:30:48 2014 From: markcs at gwyll.eu (=?utf-8?Q?M=C3=A1rk_Csaba?=) Date: Wed, 25 Jun 2014 02:30:48 +0200 Subject: SFTP & Message-ID: Hello List. ? i?m trying to setup a limited SSH server with SFTP. The requirements: -????????? There are users to whom only SFTP should be available. (sftp-only group) -????????? There are users to whom SFTP and shell access should be available (admin group) -????????? SFTP clients have to authenticate with username and password -????????? shell users have to authenticate with private key. ? I put Into the sshd_config global section: PasswordAuthentication no ? and the end of the sshd_config: Subsystem?????? sftp??? internal-sftp ? Match Group admin ??? AllowTCPForwarding yes ??? X11Forwarding yes ??? ForceCommand bash ? Match Group sftp-only ??? PasswordAuthentication yes ??? AllowTCPForwarding no ??? X11Forwarding no ??? ForceCommand internal-sftp ? This config works well for SFTP users ? but if a user is a member of both group, the SFTP client fails to connect. Obviously because of the ForceCommand. ? Is there a way to achieve the requirements above? Is there a way to create rules according to connection type? I mean ? is there any difference within the connection/authentication between eg. PuTTy and FileZilla? ? Thank you, Csaba ? -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 7857 bytes Desc: not available URL: From peter at stuge.se Wed Jun 25 10:35:22 2014 From: peter at stuge.se (Peter Stuge) Date: Wed, 25 Jun 2014 02:35:22 +0200 Subject: SFTP & In-Reply-To: References: Message-ID: <20140625003522.8234.qmail@stuge.se> M?rk Csaba wrote: > Match Group admin > ??? AllowTCPForwarding yes > ??? X11Forwarding yes > ??? ForceCommand bash > Is there a way to achieve the requirements above? Remove the admin ForceCommand. > Is there a way to create rules according to connection type? In theory there's a way, but it's unreliable and unsecured. It heuristics on plain text sent before any crypto is used. Such rules could be tricked with a telnet client. //Peter From nkadel at gmail.com Wed Jun 25 14:36:13 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 25 Jun 2014 00:36:13 -0400 Subject: SFTP & In-Reply-To: References: Message-ID: On Tue, Jun 24, 2014 at 8:30 PM, M?rk Csaba wrote: > Hello List. > > > i?m trying to setup a limited SSH server with SFTP. > > The requirements: > > - There are users to whom only SFTP should be available. (sftp-only group) > > - There are users to whom SFTP and shell access should be available (admin group) > > - SFTP clients have to authenticate with username and password > > - shell users have to authenticate with private key. > > > I put Into the sshd_config global section: > > PasswordAuthentication no > > > and the end of the sshd_config: > > Subsystem sftp internal-sftp > > > Match Group admin > > AllowTCPForwarding yes > > X11Forwarding yes > > ForceCommand bash > > > Match Group sftp-only > > PasswordAuthentication yes > > AllowTCPForwarding no > > X11Forwarding no > > ForceCommand internal-sftp > > > This config works well for SFTP users ? but if a user is a member of both group, the SFTP client fails to connect. Obviously because of the ForceCommand. > > > Is there a way to achieve the requirements above? > > Is there a way to create rules according to connection type? I mean ? is there any difference within the connection/authentication between eg. PuTTy and FileZilla? Put your limited sftp server on a separate port, or your SSH server on a separate port, to start with. That way you don't wind up mixing and matching the configurations. From djm at mindrot.org Wed Jun 25 15:08:50 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Jun 2014 15:08:50 +1000 (EST) Subject: SFTP & In-Reply-To: References: Message-ID: On Wed, 25 Jun 2014, M?rk Csaba wrote: > Match Group admin > > AllowTCPForwarding yes > > X11Forwarding yes > > ForceCommand bash > > > Match Group sftp-only > > PasswordAuthentication yes > > AllowTCPForwarding no > > X11Forwarding no > > ForceCommand internal-sftp > > > This config works well for SFTP users ? but if a user is a member of > both group, the SFTP client fails to connect. Obviously because of the > ForceCommand. "Match group sftp-only,!admin" for the second case might and removing the "ForceCommand bash" from the first might work. From markcs at gwyll.eu Wed Jun 25 18:31:04 2014 From: markcs at gwyll.eu (=?utf-8?Q?M=C3=A1rk_Csaba?=) Date: Wed, 25 Jun 2014 10:31:04 +0200 Subject: SFTP & In-Reply-To: References: Message-ID: Thank you guys for the answers. The "Match group sftp-only,!admin" didn't worked with a user which is in both group. But it shows me that this is not a good idea. :) I've modified the rules ... so only "Match group sftp-only" left in the config ... the users in the admin group have to use their private key to connect to SFTP. This is an acceptable compromise. Thank you for your help and your time! Regards, Csaba -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+markcs=gwyll.eu at mindrot.org] On Behalf Of Damien Miller Sent: Wednesday, June 25, 2014 7:09 AM "Match group sftp-only,!admin" for the second case might and removing the "ForceCommand bash" from the first might work. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2373 bytes Desc: not available URL: From vinschen at redhat.com Wed Jun 25 18:35:27 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 25 Jun 2014 10:35:27 +0200 Subject: -h, --help option In-Reply-To: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> References: <7BF19463-1B81-44E2-983E-BA1891546113@eviladmin.org> Message-ID: <20140625083527.GM1803@calimero.vinschen.de> On Jun 23 10:11, Ben Lindstrom wrote: > On Jun 23, 2014, at 5:48 AM, anatoly techtonik wrote: > > > I can argue that man pages are absent at least on Windows, but it does > > not matter here, because comparing manual with command line help is > > wrong. > > That would be an issue you should take up with the whomever packaged your ssh for windows. > > > In other words --help option is not a replacement for a full doc and it is > > not meant to provide detailed information about software. However, it > > provides a useful reference for most used options. See git for example, > > which provides both. > > The issue with this is two fold: > > 1. Keep the documentation up in two places is more painful than one. > 2. Attempting to sum up a lot of the ssh options via one-liners becomes pretty hard as even a paragraph or two in the manage doesn't always fully explain the minor ticks that may burn you if you aren't reading carefully. In a somewhat twisted way, --help already works ;-) $ scp --help scp: unknown option -- - usage: scp [-12346BCpqrv] [-c cipher] [-F ssh_config] [-i identity_file] [-l limit] [-o ssh_option] [-P port] [-S program] [[user@]host1:]file1 ... [[user@]host2:]file2 As for one-liner help output, we already have two noticable exceptions from this rule: $ ssh-agent --help ssh-agent: unknown option -- - usage: ssh-agent [options] [command [arg ...]] Options: -c Generate C-shell commands on stdout. -s Generate Bourne shell commands on stdout. -k Kill the current agent. -d Debug mode. -a socket Bind agent socket to given name. -t life Default identity lifetime (seconds). $ ssh-keygen --help ssh-keygen: unknown option -- - usage: ssh-keygen [options] Options: -A Generate non-existent host keys for all key types. -a number Number of KDF rounds for new key format or moduli primality tests. -B Show bubblebabble digest of key file. -b bits Number of bits in the key to create. [...] Whatever you guys think about this kind of help output, from my point of view the more helpful(!) help output of ssh-keygen was often a life-saver. Also, a more helpful help output is still a *lot* faster over a slow remote connection than having to call `man'. And sometimes man pages aren't even installed on systems with tight filesystems. Just my 2ct, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From alon.barlev at gmail.com Sat Jun 28 05:46:30 2014 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 27 Jun 2014 22:46:30 +0300 Subject: Using AuthorizedKeysCommand in unprivileged sshd mode Message-ID: Hi, I have a setup in which I run sshd as unprivileged user at dedicated port to serve specific application. It is working perfectly! One tweak I had to do, since the AuthorizedKeysCommand feature requires file to be owned by root, I had to use root owned command at root owned directory, although it does not add a security value. At auth2-pubkey.c::user_key_command_allowed2(), we have the following: if (auth_secure_path(options.authorized_keys_command, &st, NULL, 0, errmsg, sizeof(errmsg)) != 0) { error("Unsafe AuthorizedKeysCommand: %s", errmsg); goto out; } This enforce root uid explicitly (arg#4). Will it be acceptable to use geteuid() instead of 0, to allow unprivileged process to apply its own? Or add sshd_config option to enable alternate user ownership? Regards, Alon Bar-Lev From alon.barlev at gmail.com Sun Jun 29 03:43:06 2014 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 28 Jun 2014 20:43:06 +0300 Subject: Using AuthorizedKeysCommand in unprivileged sshd mode In-Reply-To: References: Message-ID: On Fri, Jun 27, 2014 at 10:46 PM, Alon Bar-Lev wrote: > Hi, > > I have a setup in which I run sshd as unprivileged user at dedicated port to > serve specific application. > > It is working perfectly! > > One tweak I had to do, since the AuthorizedKeysCommand feature requires file > to be owned by root, I had to use root owned command at root owned > directory, although it does not add a security value. > > At auth2-pubkey.c::user_key_command_allowed2(), we have the following: > > if (auth_secure_path(options.authorized_keys_command, &st, NULL, 0, > errmsg, sizeof(errmsg)) != 0) { > error("Unsafe AuthorizedKeysCommand: %s", errmsg); > goto out; > } > > This enforce root uid explicitly (arg#4). > > Will it be acceptable to use geteuid() instead of 0, to allow unprivileged > process to apply its own? Or add sshd_config option to enable alternate user > ownership? Actually, I think it is better to have a new sshd_config option as a configuration in which all files are owned by one unprivileged user, and sshd is running as other unprivileged user without being able to modify any of the files, is better security wise if static environment is required while the AuthorizedKeysCommand is used to retrieve authorized keys via rpc. In this mode the sshd_config, AuthorizedKeysCommand, the private key are all owned by one user, readable by the user runs the sshd. One caveat left is that the sshd cannot access /etc/ssh/moduli at some distributions, and there is no way to override the build time SSHDIR, I can solve this as well by using sshd_config parameter if is acceptable. Alon