From djm at mindrot.org Tue Mar 1 13:52:15 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Mar 2016 13:52:15 +1100 (AEDT) Subject: Announce: OpenSSH 7.2 released In-Reply-To: <20160229110352.GA3743@riva.ucam.org> References: <20160229110352.GA3743@riva.ucam.org> Message-ID: On Mon, 29 Feb 2016, Colin Watson wrote: > On Sun, Feb 28, 2016 at 07:12:27PM -0700, Damien Miller wrote: > > OpenSSH 7.2 has just been released. It will be available from the > > mirrors listed at http://www.openssh.com/ shortly. > > Thanks! > > I notice that there's no V_7_2_P1 tag in git; I normally use the tag as > part of my packaging preparations. Please could a tag be pushed? It's there now :) -d From pouar at pouar.net Wed Mar 2 12:05:58 2016 From: pouar at pouar.net (Pouar) Date: Tue, 1 Mar 2016 19:05:58 -0600 Subject: Any chance for newer curves like M-511 be implemented in a future release? Message-ID: <56D63C76.7000105@localhost> I don't mean right away, I mean like some arbitrary future version of OpenSSH. These curves look useful and I would like to use them someday. -- Pouar From djm at mindrot.org Wed Mar 2 14:57:40 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 2 Mar 2016 14:57:40 +1100 (AEDT) Subject: Any chance for newer curves like M-511 be implemented in a future release? In-Reply-To: <56D63C76.7000105@localhost> References: <56D63C76.7000105@localhost> Message-ID: On Tue, 1 Mar 2016, Pouar wrote: > I don't mean right away, I mean like some arbitrary future version of > OpenSSH. These curves look useful and I would like to use them someday. The only other curve that we might consider implementing at present is Ed448. -d From vinschen at redhat.com Thu Mar 3 07:00:12 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 2 Mar 2016 21:00:12 +0100 Subject: Announce: OpenSSH 7.2 released In-Reply-To: References: Message-ID: <20160302200012.GA7579@calimero.vinschen.de> On Feb 28 19:12, Damien Miller wrote: > OpenSSH 7.2 has just been released. It will be available from the > mirrors listed at http://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol 2.0 implementation and > includes sftp client and server support. OpenSSH also includes > transitional support for the legacy SSH 1.3 and 1.5 protocols > that may be enabled at compile-time. > > Once again, we would like to thank the OpenSSH community for their > continued support of the project, especially those who contributed > code or patches, reported bugs, tested snapshots or donated to the > project. More information on donations may be found at: > http://www.openssh.com/donations.html There's a backward incompatible change in this release which is not mentioned in the release notes. The slogin symlink as well as the slogin.1 man page are not created anymore by the Makefile. This change potentially breaks lots and lots of aliases, shell scripts, and GUI keyboard shortcuts. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From des at des.no Fri Mar 4 20:02:04 2016 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 04 Mar 2016 10:02:04 +0100 Subject: Using 'ForceCommand' Option In-Reply-To: (Lesley Kimmel's message of "Wed, 17 Feb 2016 16:47:27 -0600") References: <20160217211719.GH24952@greenie.muc.de> Message-ID: <8660x262gj.fsf@desk.des.no> Lesley Kimmel writes: > So I probably shouldn't have said "arbitrary" script. What I really > want to do is to present a terms of service notice (/etc/issue). But I > also want to get the user to actually confirm (by typing 'y') that > they accept. If they try to exit or type anything other than 'y' they > will be denied access. It is relatively trivial to write a PAM module to do that. DES -- Dag-Erling Sm?rgrav - des at des.no From amk at spamfence.net Sat Mar 5 00:41:37 2016 From: amk at spamfence.net (Andreas M. Kirchwitz) Date: Fri, 4 Mar 2016 13:41:37 +0000 (UTC) Subject: Announce: OpenSSH 7.2 released References: <20160302200012.GA7579@calimero.vinschen.de> Message-ID: Corinna Vinschen wrote: > There's a backward incompatible change in this release which is not > mentioned in the release notes. The slogin symlink as well as the > slogin.1 man page are not created anymore by the Makefile. > > This change potentially breaks lots and lots of aliases, shell scripts, > and GUI keyboard shortcuts. This may also be a serious security issue! On most systems I know of the brandnew versions of OpenSSH are installed in parallel to the SSH that ships with the operating system. So users put (for example) /usr/local/bin in front of /usr/bin to get the new OpenSSH binaries instead of the old ones from the system. The shell automatically uses the new binaries because they come first in the shell command path. Now, when users run "slogin" they will no longer start the one from the new OpenSSH but instead the shell finds the old one from the operating system and starts that one. Although the old SSH from the operating system might be secure because it gets patches from the vendor, but usually it's an old version and lacks a lot of new features (functionaly + security). So users running "slogin" will not get the best protection possible. For people who used rlogin/rsh/rcp back in the old days, it's quite common to use slogin/ssh/scp in the same way (and the developers supported that behaviour by linking slogin to ssh). Now silently removing that historic link is a big issue. Yes, sure, it's mentioned in the "ChangeLog", but honestly, that should to be included in the main release notes. (IMHO, there should be a dummy script for "slogin" that warns users that they no longer get what they expect; it's better to break things instead of silently compromising security.) Greetings, Andreas From vinschen at redhat.com Sat Mar 5 02:31:39 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 4 Mar 2016 16:31:39 +0100 Subject: Announce: OpenSSH 7.2 released In-Reply-To: References: <20160302200012.GA7579@calimero.vinschen.de> Message-ID: <20160304153139.GE28315@calimero.vinschen.de> On Mar 4 13:41, Andreas M. Kirchwitz wrote: > Corinna Vinschen wrote: > > > There's a backward incompatible change in this release which is not > > mentioned in the release notes. The slogin symlink as well as the > > slogin.1 man page are not created anymore by the Makefile. > > > > This change potentially breaks lots and lots of aliases, shell scripts, > > and GUI keyboard shortcuts. > > This may also be a serious security issue! > [...] > (IMHO, there should be a dummy script for "slogin" that > warns users that they no longer get what they expect; > it's better to break things instead of silently compromising > security.) Please, no. Removing the script so the downstream distros can provide it by themselves is ok, but providing a broken script is worse, IMHO. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nkadel at gmail.com Sat Mar 5 11:06:26 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 4 Mar 2016 19:06:26 -0500 Subject: Using 'ForceCommand' Option In-Reply-To: <8660x262gj.fsf@desk.des.no> References: <20160217211719.GH24952@greenie.muc.de> <8660x262gj.fsf@desk.des.no> Message-ID: On Fri, Mar 4, 2016 at 4:02 AM, Dag-Erling Sm?rgrav wrote: > Lesley Kimmel writes: >> So I probably shouldn't have said "arbitrary" script. What I really >> want to do is to present a terms of service notice (/etc/issue). But I >> also want to get the user to actually confirm (by typing 'y') that >> they accept. If they try to exit or type anything other than 'y' they >> will be denied access. > > It is relatively trivial to write a PAM module to do that. > > DES > -- > Dag-Erling Sm?rgrav - des at des.no Which will have the relevant configuration overwritten and disabled the next time you run "authconfig" on Red Hat based sysems. I'm not sure if this occurs with other systems, but tuning PAM is like tuning SELinux: it's a lot of extra work with little return-on-investment, and in this case for a change that will irritate *every single user* and break a number of API's. I can't recommend this approach. From des at des.no Sun Mar 6 00:08:43 2016 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat, 05 Mar 2016 14:08:43 +0100 Subject: Using 'ForceCommand' Option In-Reply-To: (Nico Kadel-Garcia's message of "Fri, 4 Mar 2016 19:06:26 -0500") References: <20160217211719.GH24952@greenie.muc.de> <8660x262gj.fsf@desk.des.no> Message-ID: <86wpph3wdg.fsf@desk.des.no> Nico Kadel-Garcia writes: > Dag-Erling Sm?rgrav writes: > > It is relatively trivial to write a PAM module to do that. > Which will have the relevant configuration overwritten and disabled > the next time you run "authconfig" on Red Hat based sysems. I'm not > sure if this occurs with other systems, but tuning PAM is like tuning > SELinux: it's a lot of extra work with little return-on-investment, > and in this case for a change that will irritate *every single user* > and break a number of API's. I can't recommend this approach. It won't break any APIs, and have you considered that OP might not have a choice? That this may be a legal requirement? DES -- Dag-Erling Sm?rgrav - des at des.no From nkadel at gmail.com Sun Mar 6 02:07:11 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 5 Mar 2016 10:07:11 -0500 Subject: Using 'ForceCommand' Option In-Reply-To: <86wpph3wdg.fsf@desk.des.no> References: <20160217211719.GH24952@greenie.muc.de> <8660x262gj.fsf@desk.des.no> <86wpph3wdg.fsf@desk.des.no> Message-ID: On Sat, Mar 5, 2016 at 8:08 AM, Dag-Erling Sm?rgrav wrote: > Nico Kadel-Garcia writes: >> Dag-Erling Sm?rgrav writes: >> > It is relatively trivial to write a PAM module to do that. >> Which will have the relevant configuration overwritten and disabled >> the next time you run "authconfig" on Red Hat based sysems. I'm not >> sure if this occurs with other systems, but tuning PAM is like tuning >> SELinux: it's a lot of extra work with little return-on-investment, >> and in this case for a change that will irritate *every single user* >> and break a number of API's. I can't recommend this approach. > > It won't break any APIs, and have you considered that OP might not have > a choice? That this may be a legal requirement? > > DES As described, it won't break the SSH API per ses. A careless version could break rsync over SSH and tools that may rely on automatic connections via SSH keys or shared authentication models such as Kerberos. However, it's the API for tools that users run locally that are most likely to break. Scripts that run remote commands automatically and use "ssh -n" may break. And gods forbid, because it would be foolish but I've seen it done, scripts that have the password input and a full set of scripted command line interactions hardcoded as part of a remote shell interaction, one prevously recorded with the "script" command, will need to have an extra option added to handle this "reply yes" requirement. A particular Perl command I just saw with quite a complex little MySQL interaction leaps to mind and makes me shudder in horror. My concern for API's is basically that of an old XKCD cartoon, https://xkcd.com/1172/ . It's easy to break people's workflows that you never even realied existed. As already pointed out, if necessary, this can be done basically in /etc/profile (depending on the shells supported). That already resolves the "don't run this on automated remote SSH scripts" to avoid breaking non-interactive tools like rsync, and it gets you away from having to support a binary module that doesn't exist upstream and which is vulnerable to bog standard upgrade reconfigurations. I've run into support issues with just such PAM integration, with a senios sysadmin who wrote his own settings and couldn't be bothered to make the PAM configuration tool idempotent, so it *kept appending the required option* every time the configuration tool ran. From des at des.no Sun Mar 6 02:25:40 2016 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat, 05 Mar 2016 16:25:40 +0100 Subject: Using 'ForceCommand' Option In-Reply-To: (Nico Kadel-Garcia's message of "Sat, 5 Mar 2016 10:07:11 -0500") References: <20160217211719.GH24952@greenie.muc.de> <8660x262gj.fsf@desk.des.no> <86wpph3wdg.fsf@desk.des.no> Message-ID: <86oaat3q17.fsf@desk.des.no> Nico Kadel-Garcia writes: > As described, it won't break the SSH API per ses. A careless version > could break rsync over SSH No more so than asking for a password. DES -- Dag-Erling Sm?rgrav - des at des.no From abhi.dhiman83 at gmail.com Tue Mar 8 23:44:01 2016 From: abhi.dhiman83 at gmail.com (abhi dhiman) Date: Tue, 8 Mar 2016 18:14:01 +0530 Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 Message-ID: Hi All, Actually I am working with the OpenSSH version 6.2p which is vulnerable to above mentioned vulnerabilities. So am looking for some help how I can fix these vulnerabilities in my version. I need to fix it in the OpenSSH code. Regards Abhishek From gert at greenie.muc.de Wed Mar 9 00:12:13 2016 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 8 Mar 2016 14:12:13 +0100 Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 In-Reply-To: References: Message-ID: <20160308131213.GL24952@greenie.muc.de> Hi, On Tue, Mar 08, 2016 at 06:14:01PM +0530, abhi dhiman wrote: > Actually I am working with the OpenSSH version 6.2p which is vulnerable to > above mentioned vulnerabilities. > > So am looking for some help how I can fix these vulnerabilities in my > version. I need to fix it in the OpenSSH code. "Upgrade to 7.2"? 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 abhi.dhiman83 at gmail.com Wed Mar 9 00:19:58 2016 From: abhi.dhiman83 at gmail.com (abhi dhiman) Date: Tue, 8 Mar 2016 18:49:58 +0530 Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 In-Reply-To: <20160308131213.GL24952@greenie.muc.de> References: <20160308131213.GL24952@greenie.muc.de> Message-ID: Hi Gert, Thanks for your reply. But we can't upgrade to 7.2 version also we don't have plan to upgrade in near future. Can I fix these vulnerabilities in the current version? Regards Abhishek On Tue, Mar 8, 2016 at 6:42 PM, Gert Doering wrote: > Hi, > > On Tue, Mar 08, 2016 at 06:14:01PM +0530, abhi dhiman wrote: > > Actually I am working with the OpenSSH version 6.2p which is vulnerable > to > > above mentioned vulnerabilities. > > > > So am looking for some help how I can fix these vulnerabilities in my > > version. I need to fix it in the OpenSSH code. > > "Upgrade to 7.2"? > > 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 > -- abhi~dhiman From hecht at hlrs.de Wed Mar 9 00:38:30 2016 From: hecht at hlrs.de (Martin Hecht) Date: Tue, 8 Mar 2016 14:38:30 +0100 Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 In-Reply-To: References: <20160308131213.GL24952@greenie.muc.de> Message-ID: <56DED5D6.8070007@hlrs.de> Was that ssh shipped with your OS distribution? If yes, it might already be patched if you have installed the OS security patches. Check with your OS vendor. On 03/08/2016 02:19 PM, abhi dhiman wrote: > Hi Gert, > > Thanks for your reply. > > But we can't upgrade to 7.2 version also we don't have plan to upgrade in > near future. Can I fix these vulnerabilities in the current version? > > Regards > Abhishek > > On Tue, Mar 8, 2016 at 6:42 PM, Gert Doering wrote: > >> Hi, >> >> On Tue, Mar 08, 2016 at 06:14:01PM +0530, abhi dhiman wrote: >>> Actually I am working with the OpenSSH version 6.2p which is vulnerable >> to >>> above mentioned vulnerabilities. >>> >>> So am looking for some help how I can fix these vulnerabilities in my >>> version. I need to fix it in the OpenSSH code. >> "Upgrade to 7.2"? >> >> 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 >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: S/MIME Cryptographic Signature URL: From djm at openbsd.org Thu Mar 10 23:10:52 2016 From: djm at openbsd.org (Damien Miller) Date: Thu, 10 Mar 2016 05:10:52 -0700 (MST) Subject: OpenSSH Security Advisory: xauth command injection Message-ID: OpenSSH Security Advisory: x11fwd.adv This document may be found at: http://www.openssh.com/txt/x11fwd.adv 1. Affected configurations All versions of OpenSSH prior to 7.2p2 with X11Forwarding enabled. 2. Vulnerability Missing sanitisation of untrusted input allows an authenticated user who is able to request X11 forwarding to inject commands to xauth(1). Injection of xauth commands grants the ability to read arbitrary files under the authenticated user's privilege, Other xauth commands allow limited information leakage, file overwrite, port probing and generally expose xauth(1), which was not written with a hostile user in mind, as an attack surface. xauth(1) is run under the user's privilege, so this vulnerability offers no additional access to unrestricted accounts, but could circumvent key or account restrictions such as sshd_config ForceCommand, authorized_keys command="..." or restricted shells. 3. Mitigation Set X11Forwarding=no in sshd_config. This is the default. For authorized_keys that specify a "command" restriction, also set the "restrict" (available in OpenSSH >=7.2) or "no-x11-forwarding" restrictions. 4. Details As part of establishing an X11 forwarding session, sshd(8) accepts an X11 authentication credential from the client. This credential is supplied to the xauth(1) utility to establish it for X11 applications that the user subsequently runs. The contents of the credential's components (authentication scheme and credential data) were not sanitised to exclude meta-characters such as newlines. An attacker could therefore supply a credential that injected commands to xauth(1). The attacker could then use a number of xauth commands to read or overwrite arbitrary files subject to file permissions, connect to local ports or perform attacks on xauth(1) itself. OpenSSH 7.2p2 implements a whitelist of characters that are permitted to appear in X11 authentication credentials. 5. Credit This issue was identified by github.com/tintinweb and communicated to the OpenSSH developers on March 3rd, 2016. 6. Fix Portable OpenSSH 7.2p2 contains a fix for this vulnerability. Patches for supported OpenBSD releases (5.7, 5.8 and 5.9) have been committed to the -STABLE branches and are available on the errata pages: http://www.openbsd.org/errata57.html http://www.openbsd.org/errata58.html http://www.openbsd.org/errata59.html From djm at openbsd.org Thu Mar 10 23:12:01 2016 From: djm at openbsd.org (Damien Miller) Date: Thu, 10 Mar 2016 05:12:01 -0700 (MST) Subject: Announce: Portable OpenSSH 7.2p2 released Message-ID: Portable OpenSSH 7.2p2 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. OpenSSH also includes transitional support for the legacy SSH 1.3 and 1.5 protocols that may be enabled at compile-time. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Changes since OpenSSH 7.2p1 =========================== This release fixes a security bug: * sshd(8): sanitise X11 authentication credentials to avoid xauth command injection when X11Forwarding is enabled. Full details of the vulnerability are available at: http://www.openssh.com/txt/x11fwd.adv Checksums: ========== - SHA1 (openssh-7.2p2.tar.gz) = 70e35d7d6386fe08abbd823b3a12a3ca44ac6d38 - SHA256 (openssh-7.2p2.tar.gz) = pyeB0aBDh2oiT/GwAy2qQJTYdWWmhSh1nBwsq1SCVIw= Please note that the SHA256 signatures are base64 encoded and not hexadecimal (which is the default for most checksum tools). The PGP key used to sign the releases is available as RELEASE_KEY.asc from the mirror sites. Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From nkadel at gmail.com Thu Mar 10 23:54:32 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 10 Mar 2016 07:54:32 -0500 Subject: OpenSSH Security Advisory: xauth command injection In-Reply-To: References: Message-ID: On Thu, Mar 10, 2016 at 7:10 AM, Damien Miller wrote: > OpenSSH Security Advisory: x11fwd.adv > > This document may be found at: http://www.openssh.com/txt/x11fwd.adv > > 1. Affected configurations > > All versions of OpenSSH prior to 7.2p2 with X11Forwarding > enabled. > > 2. Vulnerability > > Missing sanitisation of untrusted input allows an > authenticated user who is able to request X11 forwarding > to inject commands to xauth(1). Ouch. I'm just trying to figure out under what normal circumstances a connection with X11 forwarding enabled wouldn't be owned by a user who already has normal system privileges for ssh, sftp, and scp access. I suppose it might be an unexpected filesystem access if someone's public SSH keys are tied to a "ForceCommand" option to run some X based application in $HOME/.ssh/authorized_keys, and that is actually relied on to limit access on the SSH server. And, of course, there is an XKCD cartoon about sanitizing inputs. https://xkcd.com/327/ From wieland at purdue.edu Fri Mar 11 09:07:31 2016 From: wieland at purdue.edu (Jeff Wieland) Date: Thu, 10 Mar 2016 17:07:31 -0500 Subject: Problems with -with-sandbox=solaris on Solaris 10 Message-ID: <56E1F023.1080301@purdue.edu> I was involved with the issues building OpenSSH 7.2p1 to use the Solaris sandbox, but I ended up dropping out of the discussion due to being on the road for most of the last couple of weeks. Anyway, the problems persist with OpenSSH 7.2p2 when building with --with-sandbox=solaris. I found that there's an error in openbsd-compat/port-solaris.h on line 30, because the type priv_set_t hasn't been defined: /opt/SUNWspro/bin/cc -m32 -xtarget=ultra -xarch=sparc -xO5 -xstrconst -xdepend -Xa -I. -I.. -I. -I./.. -I/opt/openssl-1.0/include -DHAVE_CONFIG_H -c arc4random.c "../openbsd-compat/port-solaris.h", line 30: warning: old-style declaration or incorrect type for: priv_set_t "../openbsd-compat/port-solaris.h", line 30: syntax error before or at: * "../openbsd-compat/port-solaris.h", line 30: warning: old-style declaration or incorrect type for: solaris_basic_privset cc: acomp failed for arc4random.c *** Error code 2 make: Fatal error: Command failed for target `arc4random.o' Current working directory /opt/src/sys/openssh/openssh-7.2p2/openbsd-compat *** Error code 1 make: Fatal error: Command failed for target `openbsd-compat/libopenbsd-compat.a' The fix appears to be simple -- add #include to openbsd-compat/port-solaris.h. I've also found that to build with Solaris sandbox support, you need to turn on Solaris privileges support with --with-solaris-privs as well. In very brief testing, it does appear to work. -- Jeff Wieland | Purdue University Network Systems Administrator | ITIS UNIX Platforms Voice: (765)496-8234 | 155 S. Grant Street FAX: (765)496-1380 | West Lafayette, IN 47907 From alex at cooperi.net Fri Mar 11 10:23:38 2016 From: alex at cooperi.net (Alex Wilson) Date: Thu, 10 Mar 2016 15:23:38 -0800 Subject: Problems with -with-sandbox=solaris on Solaris 10 In-Reply-To: <56E1F023.1080301@purdue.edu> References: <56E1F023.1080301@purdue.edu> Message-ID: <56E201FA.5020407@cooperi.net> On 3/10/16 2:07 PM, Jeff Wieland wrote: > I was involved with the issues building OpenSSH 7.2p1 to use the > Solaris sandbox, but I ended up dropping out of the discussion > due to being on the road for most of the last couple of weeks. > > Anyway, the problems persist with OpenSSH 7.2p2 when building > with --with-sandbox=solaris. I found that there's an error in > openbsd-compat/port-solaris.h on line 30, because the type > priv_set_t hasn't been defined: > > > > The fix appears to be simple -- add #include to > openbsd-compat/port-solaris.h. > Yes, I've just finally caught up with starting to deploy 7.2 here (on Illumos) and noticed the same thing. Not sure how I missed it when building the proposed fix patch back when it was merged, though. I suspect that email thread had a few too many different patches floating around in it. This is the exact diff I used to fix up the build: diff --git a/openbsd-compat/port-solaris.h b/openbsd-compat/port-solaris.h index 3a41ea8..a7cb5eb 100644 --- a/openbsd-compat/port-solaris.h +++ b/openbsd-compat/port-solaris.h @@ -27,6 +27,7 @@ void solaris_contract_post_fork_child(void); void solaris_contract_post_fork_parent(pid_t pid); void solaris_set_default_project(struct passwd *); # ifdef USE_SOLARIS_PRIVS +#include priv_set_t *solaris_basic_privset(void); void solaris_drop_privs_pinfo_net_fork_exec(void); void solaris_drop_privs_root_pinfo_net(void); From dtucker at zip.com.au Fri Mar 11 14:49:28 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 11 Mar 2016 14:49:28 +1100 Subject: Problems with -with-sandbox=solaris on Solaris 10 In-Reply-To: <56E201FA.5020407@cooperi.net> References: <56E1F023.1080301@purdue.edu> <56E201FA.5020407@cooperi.net> Message-ID: On Fri, Mar 11, 2016 at 10:23 AM, Alex Wilson wrote: > This is the exact diff I used to fix up the build: [...] > +#include Applied, thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From des at des.no Fri Mar 11 20:41:01 2016 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 11 Mar 2016 10:41:01 +0100 Subject: OpenSSH Security Advisory: xauth command injection In-Reply-To: (Nico Kadel-Garcia's message of "Thu, 10 Mar 2016 07:54:32 -0500") References: Message-ID: <86fuvxcpxu.fsf@desk.des.no> Nico Kadel-Garcia writes: > I'm just trying to figure out under what normal circumstances a > connection with X11 forwarding enabled wouldn't be owned by a user who > already has normal system privileges for ssh, sftp, and scp access. Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have X11Forwarding enabled by default. DES -- Dag-Erling Sm?rgrav - des at des.no From nkadel at gmail.com Sat Mar 12 00:16:08 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 11 Mar 2016 08:16:08 -0500 Subject: OpenSSH Security Advisory: xauth command injection In-Reply-To: <86fuvxcpxu.fsf@desk.des.no> References: <86fuvxcpxu.fsf@desk.des.no> Message-ID: On Fri, Mar 11, 2016 at 4:41 AM, Dag-Erling Sm?rgrav wrote: > Nico Kadel-Garcia writes: >> I'm just trying to figure out under what normal circumstances a >> connection with X11 forwarding enabled wouldn't be owned by a user who >> already has normal system privileges for ssh, sftp, and scp access. > > Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have > X11Forwarding enabled by default. > > DES I'm not sure I see your point. The client connection is still associated with a specific client user and, in most situations, their normal SSH, scp, and sftp client privileges. I can see where for a ForceCommand limited connection, it provides a way to break out of the ForceCommand limitations I could see for such configuration, setting the sshd_config or authorized_keys options to set XauthLocation to /dev/null as well as disabling AllowTCPForwarding, AllowAgentForwarding, AcceptEnv, etc. Using ForceCommand securely can be tricky: this sounds like another reason to be very cautious, and especially not to rely on it for restricting connections for X based applications. From des at des.no Sat Mar 12 01:15:03 2016 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 11 Mar 2016 15:15:03 +0100 Subject: OpenSSH Security Advisory: xauth command injection In-Reply-To: (Nico Kadel-Garcia's message of "Fri, 11 Mar 2016 08:16:08 -0500") References: <86fuvxcpxu.fsf@desk.des.no> Message-ID: <86r3fhayoo.fsf@desk.des.no> Nico Kadel-Garcia writes: > Dag-Erling Sm?rgrav writes: > > Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have > > X11Forwarding enabled by default. > I'm not sure I see your point. With X11Forwarding off by default, one would assume that it is only enabled on a case-by-case basis for users or groups who already have the necessary privileges to run arbitrary code on the server and therefore have nothing to gain from exploiting this bug. With X11Forwarding on by default, it might remain enabled for e.g. gitolite users. DES -- Dag-Erling Sm?rgrav - des at des.no From imoverclocked at gmail.com Sat Mar 12 08:30:33 2016 From: imoverclocked at gmail.com (Tim Spriggs) Date: Fri, 11 Mar 2016 13:30:33 -0800 Subject: Forward only specific identities Message-ID: Hi OpenSSH peeps! I have looked around a few man pages and the usual sources of information but I can't seem to find a way to only forward specific identities to some hosts. What I would really like to have is a way to only forward the identity that gave me a successful auth: % ls ~/.ssh | grep .pub id_ecdsa.pub id_ed25519.pub id_rsa.pub % cat .ssh/config Host example.com: IdentitiesOnly=yes IdentityFile=/home/tspriggs/.ssh/id_rsa.pub Host another-example.com: IdentitiesOnly=yes IdentityFile=/home/tspriggs/.ssh/id_ecdsa.pub # This would be super cool: Host * OnlyForwardAuthedKey=yes % ssh tspriggs at example.com example.com % ssh-agent -L ssh-rsa ... example.com % ssh tspriggs at another-example.com Permission denied (publickey) example.com % logout Connection to example.com closed. % ssh tspriggs at another-example.com another-example.com % ... Cheers, -Tim From vinschen at redhat.com Sun Mar 13 06:42:47 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 12 Mar 2016 20:42:47 +0100 Subject: Problem with ssh-copy-id when home folder contains spaces Message-ID: <20160312194247.GA6544@calimero.vinschen.de> Hi, some guy on the Cygwin mailing list found that ssh-copy-id chokes on directories with spaces, which are quite common on Windows. He also provided an easy fix, basically just adding quotes, which I attached to this mail. Would that be ok to apply upstream? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- diff --git a/usr/bin/ssh-copy-id.old b/usr/bin/ssh-copy-id index afde8b1..bef5c95 100755 --- a/usr/bin/ssh-copy-id.old +++ b/usr/bin/ssh-copy-id @@ -233,17 +233,17 @@ populate_new_ids() { -o ControlPath=none \ -o LogLevel=INFO \ -o PreferredAuthentications=publickey \ - -o IdentitiesOnly=yes "$@" exit 2>$L_TMP_ID_FILE.stderr "$L_TMP_ID_FILE.stderr" $L_TMP_ID_FILE + : > "$L_TMP_ID_FILE" else - grep 'Permission denied' $L_TMP_ID_FILE.stderr >/dev/null || { - sed -e 's/^/ERROR: /' <$L_TMP_ID_FILE.stderr >$L_TMP_ID_FILE + grep 'Permission denied' "$L_TMP_ID_FILE.stderr" >/dev/null || { + sed -e 's/^/ERROR: /' <"$L_TMP_ID_FILE.stderr" >"$L_TMP_ID_FILE" cat >/dev/null #consume the other keys, causing loop to end } fi - cat $L_TMP_ID_FILE + cat "$L_TMP_ID_FILE" done } ) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From phil at hands.com Sun Mar 13 22:09:33 2016 From: phil at hands.com (Philip Hands) Date: Sun, 13 Mar 2016 12:09:33 +0100 Subject: Problem with ssh-copy-id when home folder contains spaces In-Reply-To: <20160312194247.GA6544@calimero.vinschen.de> References: <20160312194247.GA6544@calimero.vinschen.de> Message-ID: <877fh6vdle.fsf@whist.hands.com> Corinna Vinschen writes: > Hi, > > some guy on the Cygwin mailing list found that ssh-copy-id chokes > on directories with spaces, which are quite common on Windows. > > He also provided an easy fix, basically just adding quotes, which I > attached to this mail. Would that be ok to apply upstream? Done: http://git.hands.com/ssh-copy-id I've reported it as a (fixed) bug, and marked it as blocking V_7_3, so it ought to make the next release: https://bugzilla.mindrot.org/show_bug.cgi?id=2551 Thanks for reporting it. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From vinschen at redhat.com Sun Mar 13 22:38:18 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 13 Mar 2016 12:38:18 +0100 Subject: Problem with ssh-copy-id when home folder contains spaces In-Reply-To: <877fh6vdle.fsf@whist.hands.com> References: <20160312194247.GA6544@calimero.vinschen.de> <877fh6vdle.fsf@whist.hands.com> Message-ID: <20160313113818.GG25791@calimero.vinschen.de> On Mar 13 12:09, Philip Hands wrote: > Corinna Vinschen writes: > > > Hi, > > > > some guy on the Cygwin mailing list found that ssh-copy-id chokes > > on directories with spaces, which are quite common on Windows. > > > > He also provided an easy fix, basically just adding quotes, which I > > attached to this mail. Would that be ok to apply upstream? > > Done: > > http://git.hands.com/ssh-copy-id > > I've reported it as a (fixed) bug, and marked it as blocking V_7_3, so > it ought to make the next release: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2551 > > Thanks for reporting it. Thanks for applying. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From des at des.no Mon Mar 14 04:09:38 2016 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sun, 13 Mar 2016 18:09:38 +0100 Subject: roaming.h Message-ID: <86twka1ezx.fsf@desk.des.no> Commit a306863831c57ec5fad918687cc5d289ee8e2635 removed roaming support, but left behind an empty roaming.h. I assume that was unintentional. DES -- Dag-Erling Sm?rgrav - des at des.no From dtucker at zip.com.au Mon Mar 14 09:29:22 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 14 Mar 2016 09:29:22 +1100 Subject: Problem with ssh-copy-id when home folder contains spaces In-Reply-To: <877fh6vdle.fsf@whist.hands.com> References: <20160312194247.GA6544@calimero.vinschen.de> <877fh6vdle.fsf@whist.hands.com> Message-ID: On Sun, Mar 13, 2016 at 10:09 PM, Philip Hands wrote: [...] > http://git.hands.com/ssh-copy-id Also applied to the main tree. > I've reported it as a (fixed) bug, Please don't mark a bug fixed until it's applied to the main tree. We're unlikely to look closely at marked-fixed bugs so if we miss the email thread we might miss the bug. Thanks all. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Mar 14 09:33:58 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 14 Mar 2016 09:33:58 +1100 Subject: roaming.h In-Reply-To: <86twka1ezx.fsf@desk.des.no> References: <86twka1ezx.fsf@desk.des.no> Message-ID: On Mon, Mar 14, 2016 at 4:09 AM, Dag-Erling Sm?rgrav wrote: > Commit a306863831c57ec5fad918687cc5d289ee8e2635 removed roaming support, > but left behind an empty roaming.h. I assume that was unintentional. It was. It has been removed from OpenBSD and while we have scripts to help manage pulling changes into -portable they don't handle deletions since they're reletively uncommon. Fixed, thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Mar 14 10:14:46 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 14 Mar 2016 10:14:46 +1100 Subject: Forward only specific identities In-Reply-To: References: Message-ID: On Sat, Mar 12, 2016 at 8:30 AM, Tim Spriggs wrote: > Hi OpenSSH peeps! > > I have looked around a few man pages and the usual sources of > information but I can't seem to find a way to only forward specific > identities to some hosts. What I would really like to have is a way to > only forward the identity that gave me a successful auth: Right now ssh (which forwards the request to the agent) doesn't understand the agent protocol, so it can't differentiate. It's something Damien has mentioned as something we'd like to add but I don't know of any concrete plans. In the mean time, you could use a separate agent for the key in question and point $SSH_AUTH_SOCK at the appropriate socket. -- 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 nkadel at gmail.com Mon Mar 14 11:08:39 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 13 Mar 2016 20:08:39 -0400 Subject: OpenSSH Security Advisory: xauth command injection In-Reply-To: <86r3fhayoo.fsf@desk.des.no> References: <86fuvxcpxu.fsf@desk.des.no> <86r3fhayoo.fsf@desk.des.no> Message-ID: On Fri, Mar 11, 2016 at 9:15 AM, Dag-Erling Sm?rgrav wrote: > Nico Kadel-Garcia writes: >> Dag-Erling Sm?rgrav writes: >> > Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have >> > X11Forwarding enabled by default. >> I'm not sure I see your point. > > With X11Forwarding off by default, one would assume that it is only > enabled on a case-by-case basis for users or groups who already have the > necessary privileges to run arbitrary code on the server and therefore > have nothing to gain from exploiting this bug. With X11Forwarding on by > default, it might remain enabled for e.g. gitolite users. > > DES OK, right. gitolite and similar tools that use ForcCommand, such as "svn+ssh" based setups or "rsnapshot" based backup setups should be ideally, be publishing keys with Forcecommand and no-port-forwarding,no-X11-forwarding,no-pty" options. From abhi.dhiman83 at gmail.com Mon Mar 14 18:01:43 2016 From: abhi.dhiman83 at gmail.com (abhi dhiman) Date: Mon, 14 Mar 2016 12:31:43 +0530 Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 In-Reply-To: <56DED5D6.8070007@hlrs.de> References: <20160308131213.GL24952@greenie.muc.de> <56DED5D6.8070007@hlrs.de> Message-ID: Hi All, Please direct me to the code changes for above vulnerabilities. We don't have a vendor but we use Openssh in our software. So can't upgrade it right now. Regards Abhishek On Tue, Mar 8, 2016 at 7:08 PM, Martin Hecht wrote: > > Was that ssh shipped with your OS distribution? If yes, it might already > be patched if you have installed the OS security patches. Check with > your OS vendor. > > On 03/08/2016 02:19 PM, abhi dhiman wrote: > > Hi Gert, > > > > Thanks for your reply. > > > > But we can't upgrade to 7.2 version also we don't have plan to upgrade in > > near future. Can I fix these vulnerabilities in the current version? > > > > Regards > > Abhishek > > > > On Tue, Mar 8, 2016 at 6:42 PM, Gert Doering > wrote: > > > >> Hi, > >> > >> On Tue, Mar 08, 2016 at 06:14:01PM +0530, abhi dhiman wrote: > >>> Actually I am working with the OpenSSH version 6.2p which is vulnerable > >> to > >>> above mentioned vulnerabilities. > >>> > >>> So am looking for some help how I can fix these vulnerabilities in my > >>> version. I need to fix it in the OpenSSH code. > >> "Upgrade to 7.2"? > >> > >> 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 > >> > > > > > > > -- abhi~dhiman From abhi.dhiman83 at gmail.com Mon Mar 14 18:04:37 2016 From: abhi.dhiman83 at gmail.com (abhi dhiman) Date: Mon, 14 Mar 2016 12:34:37 +0530 Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 In-Reply-To: References: <20160308131213.GL24952@greenie.muc.de> <56DED5D6.8070007@hlrs.de> Message-ID: Hi All, I fount following text on internet. 5161: Error handling in the SSH protocol in (1) SSH Tectia Client and Server and Connector 4.0 through 4.4.11, 5.0 through 5.2.4, and 5.3 through 5.3.8; Client and Server and ConnectSecure 6.0 through 6.0.4; Server for Linux on IBM System z 6.0.4; Server for IBM z/OS 5.5.1 and earlier, 6.0.0, and 6.0.1; and Client 4.0-J through 4.3.3-J and 4.0-K through 4.3.10-K; and (2) OpenSSH 4.7p1 and possibly other versions, when using a block cipher algorithm in Cipher Block Chaining (CBC) mode, makes it easier for remote attackers to recover certain plaintext data from an arbitrary block of ciphertext in an SSH session via unknown vectors. 1483: OpenSSH 4.3p2, and probably other versions, allows local users to hijack forwarded X connections by causing ssh to set DISPLAY to :10, even when another process is listening on the associated port, as demonstrated by opening TCP port 6010 (IPv4) and sniffing a cookie sent by Emacs. Are these vulnerabilities applicable on Openssh 6.2p version? Do we need to patch these in 6.2p. Regards Abhishek On Mon, Mar 14, 2016 at 12:31 PM, abhi dhiman wrote: > Hi All, > > Please direct me to the code changes for above vulnerabilities. > We don't have a vendor but we use Openssh in our software. So can't > upgrade it right now. > > Regards > Abhishek > > On Tue, Mar 8, 2016 at 7:08 PM, Martin Hecht wrote: > >> >> Was that ssh shipped with your OS distribution? If yes, it might already >> be patched if you have installed the OS security patches. Check with >> your OS vendor. >> >> On 03/08/2016 02:19 PM, abhi dhiman wrote: >> > Hi Gert, >> > >> > Thanks for your reply. >> > >> > But we can't upgrade to 7.2 version also we don't have plan to upgrade >> in >> > near future. Can I fix these vulnerabilities in the current version? >> > >> > Regards >> > Abhishek >> > >> > On Tue, Mar 8, 2016 at 6:42 PM, Gert Doering >> wrote: >> > >> >> Hi, >> >> >> >> On Tue, Mar 08, 2016 at 06:14:01PM +0530, abhi dhiman wrote: >> >>> Actually I am working with the OpenSSH version 6.2p which is >> vulnerable >> >> to >> >>> above mentioned vulnerabilities. >> >>> >> >>> So am looking for some help how I can fix these vulnerabilities in my >> >>> version. I need to fix it in the OpenSSH code. >> >> "Upgrade to 7.2"? >> >> >> >> 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 >> >> >> > >> > >> >> >> > > > -- > abhi~dhiman > -- abhi~dhiman From djm at mindrot.org Tue Mar 15 03:36:33 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 Mar 2016 03:36:33 +1100 (AEDT) Subject: OpenSSH Security Advisory: xauth command injection In-Reply-To: References: <86fuvxcpxu.fsf@desk.des.no> <86r3fhayoo.fsf@desk.des.no> Message-ID: On Sun, 13 Mar 2016, Nico Kadel-Garcia wrote: > >> Dag-Erling Sm?rgrav writes: > >> > Some OS distributions (FreeBSD, RHEL / CentOS, probably Fedora) have > >> > X11Forwarding enabled by default. > >> I'm not sure I see your point. > > > > With X11Forwarding off by default, one would assume that it is only > > enabled on a case-by-case basis for users or groups who already have the > > necessary privileges to run arbitrary code on the server and therefore > > have nothing to gain from exploiting this bug. With X11Forwarding on by > > default, it might remain enabled for e.g. gitolite users. > > OK, right. gitolite and similar tools that use ForcCommand, such as > "svn+ssh" based setups or "rsnapshot" based backup setups should be > ideally, be publishing keys with Forcecommand and > no-port-forwarding,no-X11-forwarding,no-pty" options. better to use "restrict" if you're running a recent OpenSSH From djm at mindrot.org Tue Mar 15 03:42:10 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 Mar 2016 03:42:10 +1100 (AEDT) Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 In-Reply-To: References: <20160308131213.GL24952@greenie.muc.de> <56DED5D6.8070007@hlrs.de> Message-ID: On Mon, 14 Mar 2016, abhi dhiman wrote: > Hi All, > > Please direct me to the code changes for above vulnerabilities. > We don't have a vendor but we use Openssh in our software. So can't upgrade > it right now. OpenSSH is maintained by a small team who only have the resources to support the current version. If you need to generate cherry-pick patches then you'll either need to do it yourself or find a competent developer to do it for you. Finding them yourself isn't too hard: checkout the version containing the fix from git and look at the commit log. Security vulnerabilities usually preciptate a release quite quickly, so it will like be one of the last commits in the log. Do be careful: people have caused problem by mis-applying cherry-pick patches inappropriately before. It's much better just to use the latest version. -d From rmoucha at syr.edu Tue Mar 15 03:52:32 2016 From: rmoucha at syr.edu (Robert Moucha) Date: Mon, 14 Mar 2016 16:52:32 +0000 Subject: OpenSSH 7.2 slogin not removed from openssh.spec Message-ID: <1ED809FC-1329-468E-AAC1-BEBD5BAC69C8@syr.edu> It appears that the redhat/openssh.spec has not been updated to account for the removal of slogin from the build. This breaks rpmbuild. Specifically lines 361 and 362 still have the following: %attr(-,root,root) %{_bindir}/slogin %attr(-,root,root) %{_mandir}/man1/slogin.1* Robert Moucha Geophysics Syracuse University From vinschen at redhat.com Tue Mar 15 04:06:23 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 14 Mar 2016 18:06:23 +0100 Subject: OpenSSH 7.2 slogin not removed from openssh.spec In-Reply-To: <1ED809FC-1329-468E-AAC1-BEBD5BAC69C8@syr.edu> References: <1ED809FC-1329-468E-AAC1-BEBD5BAC69C8@syr.edu> Message-ID: <20160314170623.GA1157@calimero.vinschen.de> On Mar 14 16:52, Robert Moucha wrote: > It appears that the redhat/openssh.spec has not been updated to account for the removal of slogin from the build. This breaks rpmbuild. > Specifically lines 361 and 362 still have the following: > > > %attr(-,root,root) %{_bindir}/slogin > > %attr(-,root,root) %{_mandir}/man1/slogin.1* IMHO the right thing to do is to revert the patch removing the symlinks. I can't think of any good reason to break backward compatibility with existing installations. The Cygwin and Fedora distros now maintain fixed spec files creating the symlinks by themselves for the time being. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dustin at null-ptr.net Tue Mar 15 04:11:27 2016 From: dustin at null-ptr.net (Dustin Lundquist) Date: Mon, 14 Mar 2016 10:11:27 -0700 Subject: Forward only specific identities In-Reply-To: References: Message-ID: It's possible to use a proxy to filter the SSH agent connections. I found this https://github.com/tiwe-de/ssh-agent-filter, but it didn't meet our exact needs to allow multiple users to share an identity so I implemented https://github.com/blueboxgroup/sshagentmux. -Dustin On Sun, Mar 13, 2016 at 4:14 PM, Darren Tucker wrote: > On Sat, Mar 12, 2016 at 8:30 AM, Tim Spriggs > wrote: > > Hi OpenSSH peeps! > > > > I have looked around a few man pages and the usual sources of > > information but I can't seem to find a way to only forward specific > > identities to some hosts. What I would really like to have is a way to > > only forward the identity that gave me a successful auth: > > Right now ssh (which forwards the request to the agent) doesn't > understand the agent protocol, so it can't differentiate. It's > something Damien has mentioned as something we'd like to add but I > don't know of any concrete plans. > > In the mean time, you could use a separate agent for the key in > question and point $SSH_AUTH_SOCK at the appropriate socket. > > -- > 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 djm at mindrot.org Tue Mar 15 04:33:59 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 Mar 2016 04:33:59 +1100 (AEDT) Subject: OpenSSH 7.2 slogin not removed from openssh.spec In-Reply-To: <20160314170623.GA1157@calimero.vinschen.de> References: <1ED809FC-1329-468E-AAC1-BEBD5BAC69C8@syr.edu> <20160314170623.GA1157@calimero.vinschen.de> Message-ID: On Mon, 14 Mar 2016, Corinna Vinschen wrote: > On Mar 14 16:52, Robert Moucha wrote: > > It appears that the redhat/openssh.spec has not been updated to account for the removal of slogin from the build. This breaks rpmbuild. > > Specifically lines 361 and 362 still have the following: > > > > > > %attr(-,root,root) %{_bindir}/slogin > > > > %attr(-,root,root) %{_mandir}/man1/slogin.1* thanks - I've removed them from the .spec files. > IMHO the right thing to do is to revert the patch removing the symlinks. > I can't think of any good reason to break backward compatibility with > existing installations. > > The Cygwin and Fedora distros now maintain fixed spec files creating > the symlinks by themselves for the time being. Well, I messed up by neglecting to mention the slogin removal from the 7.2 release notes but I don't plan on putting it back. Adapting is just s/slogin/ssh/ in scripts with 100% backwards-compatibility. If downstreams want to maintain a symlink in their scripts then that's naturally fine though. -d From phil at hands.com Tue Mar 15 04:55:53 2016 From: phil at hands.com (Philip Hands) Date: Mon, 14 Mar 2016 18:55:53 +0100 Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 In-Reply-To: References: Message-ID: <87d1qxrljq.fsf@whist.hands.com> abhi dhiman writes: > Hi All, > > Actually I am working with the OpenSSH version 6.2p which is vulnerable to > above mentioned vulnerabilities. Are you sure? I was going to suggest that you take a look at Debian's packages, such as the 6.0p1 package from "wheezy", but looking at the changelog, I only see mention of CVE-2008-1483: http://metadata.ftp-master.debian.org/changelogs/main/o/openssh/openssh_6.0p1-4+deb7u3_changelog Likewise for 6.6p1: http://metadata.ftp-master.debian.org/changelogs/main/o/openssh/openssh_6.6p1-4~bpo70+1_changelog Note that CVE-2008-1483 was fixed in Debian's 4.7p1-5 package, in 22 Mar 2008, so I'm wondering who would have supplied a vulnerable version of 6.2p (release in 2012). It looks to me as though it was fixed in 4.9, so I'm very doubtful about the assertion that 6.2 is vulnerable. As for CVE-2015-6565, this: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-6565 claims that versions 6.8 and 6.9 are vulnerable, so again not 6.2. I'll leave you to look at the other two. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From abhi.dhiman83 at gmail.com Wed Mar 16 00:54:09 2016 From: abhi.dhiman83 at gmail.com (abhi dhiman) Date: Tue, 15 Mar 2016 19:24:09 +0530 Subject: Need Help to Fix CVE-2008-1483, CVE-2008-5161, CVE-2015-5600 and CVE-2015-6565 In-Reply-To: <87d1qxrljq.fsf@whist.hands.com> References: <87d1qxrljq.fsf@whist.hands.com> Message-ID: Thanks a lot guys for the pointers. Regards Abhishek On 14-Mar-2016 11:30 pm, "Philip Hands" wrote: > abhi dhiman writes: > > > Hi All, > > > > Actually I am working with the OpenSSH version 6.2p which is vulnerable > to > > above mentioned vulnerabilities. > > Are you sure? > > I was going to suggest that you take a look at Debian's packages, such > as the 6.0p1 package from "wheezy", but looking at the changelog, I only > see mention of CVE-2008-1483: > > > http://metadata.ftp-master.debian.org/changelogs/main/o/openssh/openssh_6.0p1-4+deb7u3_changelog > > Likewise for 6.6p1: > > > http://metadata.ftp-master.debian.org/changelogs/main/o/openssh/openssh_6.6p1-4~bpo70+1_changelog > > Note that CVE-2008-1483 was fixed in Debian's 4.7p1-5 package, in 22 Mar > 2008, so I'm wondering who would have supplied a vulnerable version of > 6.2p (release in 2012). > > It looks to me as though it was fixed in 4.9, so I'm very doubtful > about the assertion that 6.2 is vulnerable. > > As for CVE-2015-6565, this: > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-6565 > > claims that versions 6.8 and 6.9 are vulnerable, so again not 6.2. > > I'll leave you to look at the other two. > > Cheers, Phil. > -- > |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. > |-| http://www.hands.com/ http://ftp.uk.debian.org/ > |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY > From steffen at sdaoden.eu Wed Mar 16 21:54:19 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 16 Mar 2016 11:54:19 +0100 Subject: Does SCTP help against TCP reset attacks? Message-ID: <20160316105419.HmJwkG-XE%steffen@sdaoden.eu> Hello, i have a question regarding SCTP support of OpenSSH. (I have searched the list, and it seems to show up periodically every two years, and since it's that time again i dare to ask...) It can't be described better than what i've placed in a bug report yesterday, so please let me (mostly) copy & paste that: Hello. I don't know how you do it, i never managed a(n exposed) server until January and now [.] i think what i have to face are TCP RST attacks on SSH connections, leading to "connection reset"s ["connection closed" on client side in fact] (of course). My first reaction was something like "go UDP" but all i effectively need is SSH, so OpenVPN is much to fully blown for a bit of scp/ssh/git over ssh, and mosh (or a quick'n dirty shot with new OpenSSL and DTLS, plus pty plus sh) is a complete disruption of the workflow. And IPSec is really, really no no no. Looking around a bit i found RFC 4953, "Defending TCP Against Spoofing Attacks", and that mentions SCTP in a few places, e.g., "Other transport protocols, such as SCTP and DCCP, also have limited antispoofing mechanisms" and "whereas others establish per-connection identity based on exchanged nonces (e.g., SCTP)". Now i knew there was a SCTP patch floating for OpenSSH years ago, and it is indeed actively maintained until today and even available in the OpenSSH that Gentoo packages. I'm not at all a network expert so i don't know wether SCTP will really helps against the particular attack i'm facing, but it sounds as if it would address some problems in this area, and so i'm kindly asking for inclusion of that actively maintained patch in place-your-favourite-OS(-distribution). I've downloaded the patch from [1], the OpenSSH bugzilla entries are [2] and [3]. Note that the patch ([1]) needs itself a patch for using SCTP via getopt aka command line (new -z option). [1] http://ftp.uni-erlangen.de/pub/mirrors/gentoo/distfiles/openssh-7.2_p1-sctp.patch.xz [2] https://bugzilla.mindrot.org/show_bug.cgi?id=1604 [3] https://bugzilla.mindrot.org/show_bug.cgi?id=2016 Probably an expert can help answering the question wether SCTP would prevent TCP reset attacks (i guess what would be needed would be real confidence in mac/address/port of source). And if so, can't it be included in the portable version of OpenSSH? The initial comments of Markus Friedl and Darren Tucker didn't sound all that bad, imho, and the patch is actively maintained for many years. Thanks, and ciao, --steffen From erjoalgo at gmail.com Sun Mar 20 07:53:32 2016 From: erjoalgo at gmail.com (Ernesto Alfonso) Date: Sat, 19 Mar 2016 13:53:32 -0700 Subject: ssh-copy-id no newline bug Message-ID: When editing ~/.ssh/authorized_keys manually, sometimes users forget to add a newline at the end of the file, causing the next ssh-copy-id call to append a new key to an existing key, invalidating both keys. This can be fixed by simply adding a newline before appending the key. Something like this change to openssh-source/openssh-6.7p1/contrib/ssh-copy-id might work: # Assuming that the remote host treats ~/.ssh/authorized_keys as one might expect populate_new_ids 0 [ "$DRY_RUN" ] || printf '%s\n' "$NEW_IDS" | ssh "$@" " umask 077 ; mkdir -p .ssh && \ echo >> .ssh/authorized_keys && \ cat >> .ssh/authorized_keys || exit 1 ; if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh .ssh/authorized_keys ; fi" \ || exit 1 ADDED=$(printf '%s\n' "$NEW_IDS" | wc -l) ;; From nkadel at gmail.com Sun Mar 20 16:37:30 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 20 Mar 2016 01:37:30 -0400 Subject: ssh-copy-id no newline bug In-Reply-To: References: Message-ID: On Sat, Mar 19, 2016 at 4:53 PM, Ernesto Alfonso wrote: > When editing ~/.ssh/authorized_keys manually, sometimes users forget > to add a newline at the end of the file, causing the next ssh-copy-id > call to append a new key to an existing key, invalidating both keys. Mind you, it's also fixed by using Emacs intead of vi. [ esc-x runs-for-cover ] From phil at hands.com Mon Mar 21 06:15:31 2016 From: phil at hands.com (Philip Hands) Date: Sun, 20 Mar 2016 20:15:31 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: References: Message-ID: <87oaa9nep8.fsf@whist.hands.com> Ernesto Alfonso writes: > When editing ~/.ssh/authorized_keys manually, sometimes users forget > to add a newline at the end of the file, causing the next ssh-copy-id > call to append a new key to an existing key, invalidating both keys. > > This can be fixed by simply adding a newline before appending the key. > > Something like this change to > openssh-source/openssh-6.7p1/contrib/ssh-copy-id might work: This seems like it should do no harm (given that sshd(8) declares that blank lines are ignored as comments), although I'd instead do it by adding a \n to the printf, thus: [ "$DRY_RUN" ] || printf '\n%s\n' "$NEW_IDS" | ssh ... Is anyone going to be upset by the resulting blank lines being added by ssh-copy-id when the file was not missing a terminating newline? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From alex at alex.org.uk Mon Mar 21 06:30:01 2016 From: alex at alex.org.uk (Alex Bligh) Date: Sun, 20 Mar 2016 19:30:01 +0000 Subject: ssh-copy-id no newline bug In-Reply-To: <87oaa9nep8.fsf@whist.hands.com> References: <87oaa9nep8.fsf@whist.hands.com> Message-ID: <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> On 20 Mar 2016, at 19:15, Philip Hands wrote: > Is anyone going to be upset by the resulting blank lines being added by > ssh-copy-id when the file was not missing a terminating newline? Well it would be at least mildly annoying my previously nice looking file now has a pile of blank lines in just because someone didn't know how to use their editor ... -- Alex Bligh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From lists at spuddy.org Mon Mar 21 06:51:23 2016 From: lists at spuddy.org (Stephen Harris) Date: Sun, 20 Mar 2016 15:51:23 -0400 Subject: ssh-copy-id no newline bug In-Reply-To: <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> Message-ID: <20160320195123.GA19628@mercury7.spuddy.org> On Sun, Mar 20, 2016 at 07:30:01PM +0000, Alex Bligh wrote: > > On 20 Mar 2016, at 19:15, Philip Hands wrote: > > > Is anyone going to be upset by the resulting blank lines being added by > > ssh-copy-id when the file was not missing a terminating newline? > > Well it would be at least mildly annoying my previously nice looking file > now has a pile of blank lines in just because someone didn't know > how to use their editor ... You can be pretty sure it'd end up causing a bug report as well ("ssh-copy-id introduces blank lines into good files"). -- rgds Stephen From cjwatson at debian.org Mon Mar 21 07:30:33 2016 From: cjwatson at debian.org (Colin Watson) Date: Sun, 20 Mar 2016 20:30:33 +0000 Subject: ssh-copy-id no newline bug In-Reply-To: <20160320195123.GA19628@mercury7.spuddy.org> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> Message-ID: <20160320203033.GA16474@riva.ucam.org> On Sun, Mar 20, 2016 at 03:51:23PM -0400, Stephen Harris wrote: > On Sun, Mar 20, 2016 at 07:30:01PM +0000, Alex Bligh wrote: > > On 20 Mar 2016, at 19:15, Philip Hands wrote: > > > Is anyone going to be upset by the resulting blank lines being added by > > > ssh-copy-id when the file was not missing a terminating newline? > > > > Well it would be at least mildly annoying my previously nice looking file > > now has a pile of blank lines in just because someone didn't know > > how to use their editor ... > > You can be pretty sure it'd end up causing a bug report as well > ("ssh-copy-id introduces blank lines into good files"). How about something like: if [ "$(sed -n '${s/.*//;p}' ~/.ssh/authorized_keys | wc -l)" = 0 ]; then echo >> ~/.ssh/authorized_keys fi I feel like there must be a neater but still portable way to do this, and the above would require some careful quoting to work in the context of ssh-copy-id. -- Colin Watson [cjwatson at debian.org] From erjoalgo at gmail.com Mon Mar 21 07:48:44 2016 From: erjoalgo at gmail.com (Ernesto Alfonso) Date: Sun, 20 Mar 2016 13:48:44 -0700 Subject: ssh-copy-id no newline bug In-Reply-To: <20160320195123.GA19628@mercury7.spuddy.org> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> Message-ID: I agree it would be bad to add empty lines. I came up with this function: function is_newline_terminated { test -z "$(tail -c1 "${1}")" } to check whether an append would corrupt the file. Maybe something like: is_newline_terminated ~/.ssh/authorized_keys || echo >> ~/.ssh/authorized_keys would work in the appropriate place. On 3/20/16, Stephen Harris wrote: > On Sun, Mar 20, 2016 at 07:30:01PM +0000, Alex Bligh wrote: >> >> On 20 Mar 2016, at 19:15, Philip Hands wrote: >> >> > Is anyone going to be upset by the resulting blank lines being added by >> > ssh-copy-id when the file was not missing a terminating newline? >> >> Well it would be at least mildly annoying my previously nice looking file >> now has a pile of blank lines in just because someone didn't know >> how to use their editor ... > > You can be pretty sure it'd end up causing a bug report as well > ("ssh-copy-id introduces blank lines into good files"). > > -- > > rgds > Stephen > From mstone at mathom.us Mon Mar 21 07:51:45 2016 From: mstone at mathom.us (Michael Stone) Date: Sun, 20 Mar 2016 16:51:45 -0400 Subject: ssh-copy-id no newline bug In-Reply-To: <20160320203033.GA16474@riva.ucam.org> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> Message-ID: <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> On Sun, Mar 20, 2016 at 08:30:33PM +0000, Colin Watson wrote: >How about something like: > > if [ "$(sed -n '${s/.*//;p}' ~/.ssh/authorized_keys | wc -l)" = 0 ]; then > echo >> ~/.ssh/authorized_keys > fi > >I feel like there must be a neater but still portable way to do this, Maybe if [ ! -z `tail -c 1 ~/.ssh/authorized_keys` ] ; then Mike Stone From mancha1 at zoho.com Mon Mar 21 16:32:50 2016 From: mancha1 at zoho.com (mancha) Date: Mon, 21 Mar 2016 05:32:50 +0000 Subject: [ANN] OpenSSH 7.2p2 TCP Wrapper support Message-ID: <20160321053250.GA12766@zoho.com> Hello. Patch re-introducing TCP Wrapper (libwrap) support has been updated for use with OpenSSH 7.2p2: https://twitter.com/mancha140/status/711785757426454528 Note: don't forget to autoreconf -fiv. Enjoy. --mancha -- https://twitter.com/mancha140 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mancha1 at zoho.com Mon Mar 21 20:31:07 2016 From: mancha1 at zoho.com (mancha) Date: Mon, 21 Mar 2016 09:31:07 +0000 Subject: [ANN] OpenSSH 7.2p2 TCP Wrapper support In-Reply-To: <20160321053250.GA12766@zoho.com> References: <20160321053250.GA12766@zoho.com> Message-ID: <20160321093107.GB12766@zoho.com> On Mon, Mar 21, 2016 at 05:32:50AM +0000, mancha wrote: > Hello. > > Patch re-introducing TCP Wrapper (libwrap) support has been updated for > use with OpenSSH 7.2p2: > > https://twitter.com/mancha140/status/711785757426454528 > > Note: don't forget to autoreconf -fiv. > > Enjoy. > > --mancha > > -- > https://twitter.com/mancha140 The wrong version of the patch was up for an hour or so. You can verify you have the correct version against this hash: SHA256 (openssh-7.2p2-libwrap.diff) = 255bd13aa34017bbdeb0157c605cd251d66b1705d0413453a6ef41fd95eb553a -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From phil at hands.com Tue Mar 22 18:34:46 2016 From: phil at hands.com (Philip Hands) Date: Tue, 22 Mar 2016 08:34:46 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> Message-ID: <8760wfney1.fsf@whist.hands.com> Michael Stone writes: > On Sun, Mar 20, 2016 at 08:30:33PM +0000, Colin Watson wrote: >>How about something like: >> >> if [ "$(sed -n '${s/.*//;p}' ~/.ssh/authorized_keys | wc -l)" = 0 ]; then >> echo >> ~/.ssh/authorized_keys >> fi >> >>I feel like there must be a neater but still portable way to do this, > > Maybe > > if [ ! -z `tail -c 1 ~/.ssh/authorized_keys` ] ; then Ah, thanks for that, I'd forgotten about the -c option. I think that adding the following, just before the 'mkdir .ssh', should do the trick: [ "`tail -c1 .ssh/authorized_keys 2>/dev/null`" ] && echo > .ssh/authorized_keys ; anyone know of portability issues with that? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From gert at greenie.muc.de Tue Mar 22 18:56:22 2016 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 22 Mar 2016 08:56:22 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: <8760wfney1.fsf@whist.hands.com> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> Message-ID: <20160322075622.GZ53051@greenie.muc.de> Hi, On Tue, Mar 22, 2016 at 08:34:46AM +0100, Philip Hands wrote: > I think that adding the following, just before the 'mkdir .ssh', should > do the trick: > > [ "`tail -c1 .ssh/authorized_keys 2>/dev/null`" ] && echo > .ssh/authorized_keys ; > > anyone know of portability issues with that? I'm not sure what the test will do, but the "echo" should be an "echo >>", no? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 291 bytes Desc: not available URL: From phil at hands.com Tue Mar 22 19:17:21 2016 From: phil at hands.com (Philip Hands) Date: Tue, 22 Mar 2016 09:17:21 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: <20160322075622.GZ53051@greenie.muc.de> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> <20160322075622.GZ53051@greenie.muc.de> Message-ID: <87zitrlyem.fsf@whist.hands.com> Gert Doering writes: > Hi, > > On Tue, Mar 22, 2016 at 08:34:46AM +0100, Philip Hands wrote: >> I think that adding the following, just before the 'mkdir .ssh', should >> do the trick: >> >> [ "`tail -c1 .ssh/authorized_keys 2>/dev/null`" ] && echo > .ssh/authorized_keys ; >> >> anyone know of portability issues with that? > > I'm not sure what the test will do, but the "echo" should be an > "echo >>", no? Yes. Doh! ;-) The test gets the last character of the file, and puts it in quotes after removing new-lines -- which basically means that test fails if there's a newline there, or if the file's empty, since that gives you: [ "" ] which means that the second half of the && does not need to be evaluated -- the result being that a newline is only added if the last character of the file is not already a newline. The only thing that's wrong with that is if the file is empty it'll end up with a blank line at the start, but a) why would there be an empty file there? and b) who cares? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From gert at greenie.muc.de Tue Mar 22 19:31:11 2016 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 22 Mar 2016 09:31:11 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: <87zitrlyem.fsf@whist.hands.com> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> <20160322075622.GZ53051@greenie.muc.de> <87zitrlyem.fsf@whist.hands.com> Message-ID: <20160322083111.GB53051@greenie.muc.de> Hi, On Tue, Mar 22, 2016 at 09:17:21AM +0100, Philip Hands wrote: > The test gets the last character of the file, and puts it in quotes > after removing new-lines -- which basically means that test fails if > there's a newline there, or if the file's empty, since that gives you: > > [ "" ] Thanks, I learned something new today - from "man test": string True if string is not the null string. ... never really noticed this line in 20+ years of shell scripting :-) To add some useful content - I've checked the oldest (and most exotic) systems I have around, and both SCO Open Server 5.0 and AIX document the same thing, so it should be truly portable. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 291 bytes Desc: not available URL: From cristian.ionescu-idbohrn at axis.com Tue Mar 22 20:12:39 2016 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 22 Mar 2016 10:12:39 +0100 (CET) Subject: ssh-copy-id no newline bug In-Reply-To: <87zitrlyem.fsf@whist.hands.com> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> <20160322075622.GZ53051@greenie.muc.de> <87zitrlyem.fsf@whist.hands.com> Message-ID: On Tue, 22 Mar 2016, Philip Hands wrote: > > which means that the second half of the && does not need to be > evaluated -- the result being that a newline is only added if the last > character of the file is not already a newline. Well, then there's the case with the non-existing file and the other case with an empty file. What about this: f=/tmp/ff && >>$f && [ "$(tail -c1 $f)" ] && echo >>$f || :;stat $f >>$f # like `touch', but no fork (makes sure the file # exists) so `tail' will not fail tail -c1 $f # on an empty file will return "" (as if there was a # a there ;stat $f # is there just to show what's going on Cheers, -- Cristian From foonon at gmail.com Tue Mar 22 12:55:13 2016 From: foonon at gmail.com (John Devitofranceschi) Date: Mon, 21 Mar 2016 21:55:13 -0400 Subject: Automatically forwarding fresh Kerberos tickets? Message-ID: <6D940141-B1A7-4648-9500-3A5C532D12B5@gmail.com> In an environment where users use smart cards to authenticate on Windows and then use ssh to login to UNIX systems via GSSAPI, it is nigh impossible to renew/refresh the Kerberos credentials in the UNIX session. If the user fails to renew their credentials before they expire, the user is stuck and must log out and log back in to get valid tickets. Meanwhile it is entirely likely that on the Windows desktop where they ssh'd from, fresh credentials have been served up constantly (when unlocking the screen, for example). Might it be possible to modify OpenSSH to configure the client to automatically forward fresh Kerberos credentials to the target session (assuming the sshd on the target has been modified to accept such updates)? Or is this a change that the current implementation just couldn?t allow? jd -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2393 bytes Desc: not available URL: From deengert at gmail.com Tue Mar 22 23:46:31 2016 From: deengert at gmail.com (Douglas E Engert) Date: Tue, 22 Mar 2016 07:46:31 -0500 Subject: Automatically forwarding fresh Kerberos tickets? In-Reply-To: <6D940141-B1A7-4648-9500-3A5C532D12B5@gmail.com> References: <6D940141-B1A7-4648-9500-3A5C532D12B5@gmail.com> Message-ID: <56F13EA7.8070102@gmail.com> On 3/21/2016 8:55 PM, John Devitofranceschi wrote: > > In an environment where users use smart cards to authenticate on Windows and then use ssh to login to UNIX systems via GSSAPI, it is nigh impossible to renew/refresh the Kerberos credentials in the UNIX session. If the user fails to renew their credentials before they expire, the user is stuck and must log out and log back in to get valid tickets. > > Meanwhile it is entirely likely that on the Windows desktop where they ssh'd from, fresh credentials have been served up constantly (when unlocking the screen, for example). > > Might it be possible to modify OpenSSH to configure the client to automatically forward fresh Kerberos credentials to the target session (assuming the sshd on the target has been modified to accept such updates)? Or is this a change that the current implementation just couldn?t allow? > That would be a great feature would would depend on changes to the gssapi key exchange protocol. As you said: "it is nigh impossible" and for years people have been working around it by using renewable tickets. Most kerberos KDC would issue tickets for 10 to 24 hours, but renewable for a week. But to avoid "If the user fails to renew" I used to have the login session start a refresh.creds.token.sh so the user did not have to think. about having to do it themselves. It would also get AFS tokens too: #!/bin/sh while /usr/bin/true do /usr/bin/kinit -R /usr/afsws/bin/aklog /usr/bin/sleep 3600 done Now the Microsoft is starting to use SSH, (Google for: windows 10 powershell ssh) There may be more of a push to get the gssapi key exchange to send renewed tickets. > jd > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Douglas E. Engert From jbasney at illinois.edu Wed Mar 23 00:50:41 2016 From: jbasney at illinois.edu (Basney, Jim) Date: Tue, 22 Mar 2016 13:50:41 +0000 Subject: Automatically forwarding fresh Kerberos tickets? In-Reply-To: <6D940141-B1A7-4648-9500-3A5C532D12B5@gmail.com> References: <6D940141-B1A7-4648-9500-3A5C532D12B5@gmail.com> Message-ID: On 3/21/16, 8:55 PM, John Devitofranceschi wrote: >In an environment where users use smart cards to authenticate on Windows >and then use ssh to login to UNIX systems via GSSAPI, it is nigh >impossible to renew/refresh the Kerberos credentials in the UNIX session. >If the user fails to renew their credentials before they expire, the user >is stuck and must log out and log back in to get valid tickets. > >Meanwhile it is entirely likely that on the Windows desktop where they >ssh'd from, fresh credentials have been served up constantly (when >unlocking the screen, for example). > >Might it be possible to modify OpenSSH to configure the client to >automatically forward fresh Kerberos credentials to the target session >(assuming the sshd on the target has been modified to accept such >updates)? Or is this a change that the current implementation just >couldn?t allow? Does the Cascading Credentials capability in Simon Wilkinson's OpenSSH Kerberos/GSSAPI patch (http://www.sxw.org.uk/computing/patches/openssh) provide the desired functionality? -Jim From deengert at gmail.com Wed Mar 23 01:40:35 2016 From: deengert at gmail.com (Douglas E Engert) Date: Tue, 22 Mar 2016 09:40:35 -0500 Subject: Automatically forwarding fresh Kerberos tickets? In-Reply-To: References: <6D940141-B1A7-4648-9500-3A5C532D12B5@gmail.com> Message-ID: <56F15963.8040300@gmail.com> On 3/22/2016 8:50 AM, Basney, Jim wrote: > On 3/21/16, 8:55 PM, John Devitofranceschi wrote: >> In an environment where users use smart cards to authenticate on Windows >> and then use ssh to login to UNIX systems via GSSAPI, it is nigh >> impossible to renew/refresh the Kerberos credentials in the UNIX session. >> If the user fails to renew their credentials before they expire, the user >> is stuck and must log out and log back in to get valid tickets. >> >> Meanwhile it is entirely likely that on the Windows desktop where they >> ssh'd from, fresh credentials have been served up constantly (when >> unlocking the screen, for example). >> >> Might it be possible to modify OpenSSH to configure the client to >> automatically forward fresh Kerberos credentials to the target session >> (assuming the sshd on the target has been modified to accept such >> updates)? Or is this a change that the current implementation just >> couldn?t allow? > > Does the Cascading Credentials capability in Simon Wilkinson's OpenSSH > Kerberos/GSSAPI patch (http://www.sxw.org.uk/computing/patches/openssh) > provide the desired functionality? Sure looks like it should. On Ubuntu 14.4 with OpenSSH_6.6.1p1: man sshd_config lists GssapiStoreCredentialsOnRekey man ssh_config lists GSSAPIRenewalForcesRekey > > -Jim > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Douglas E. Engert From tgc at jupiterrise.com Wed Mar 23 08:10:54 2016 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Tue, 22 Mar 2016 22:10:54 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: <8760wfney1.fsf@whist.hands.com> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> Message-ID: <56F1B4DE.5010905@jupiterrise.com> On 22/03/16 08:34, Philip Hands wrote: > > [ "`tail -c1 .ssh/authorized_keys 2>/dev/null`" ] && echo > .ssh/authorized_keys ; > > anyone know of portability issues with that? > On Solaris 10 and older /usr/bin/tail does not understand the -c1 syntax, it needs -1c instead. The XPG4 version in /usr/xpg4/bin/tail can understand either syntax. I did not have Solaris 11 available to check. -tgc From phil at hands.com Wed Mar 23 08:32:43 2016 From: phil at hands.com (Philip Hands) Date: Tue, 22 Mar 2016 22:32:43 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: <56F1B4DE.5010905@jupiterrise.com> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> <56F1B4DE.5010905@jupiterrise.com> Message-ID: <87d1qmmc5g.fsf@whist.hands.com> "Tom G. Christensen" writes: > On 22/03/16 08:34, Philip Hands wrote: >> >> [ "`tail -c1 .ssh/authorized_keys 2>/dev/null`" ] && echo > .ssh/authorized_keys ; >> >> anyone know of portability issues with that? >> > > On Solaris 10 and older /usr/bin/tail does not understand the -c1 > syntax, it needs -1c instead. OK, it seems that tail from coreutils on Debian can deal with -1c as well -- odd -- is this actually the portable option despite not being in the manual? BTW can Solaris 10's tail handle it with a space after the c, thus: tail -c 1 Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From tgc at jupiterrise.com Wed Mar 23 09:16:38 2016 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Tue, 22 Mar 2016 23:16:38 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: <87d1qmmc5g.fsf@whist.hands.com> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> <56F1B4DE.5010905@jupiterrise.com> <87d1qmmc5g.fsf@whist.hands.com> Message-ID: <56F1C446.6000805@jupiterrise.com> On 22/03/16 22:32, Philip Hands wrote: > "Tom G. Christensen" writes: > >> On 22/03/16 08:34, Philip Hands wrote: >>> >>> [ "`tail -c1 .ssh/authorized_keys 2>/dev/null`" ] && echo > .ssh/authorized_keys ; >>> >>> anyone know of portability issues with that? >>> >> >> On Solaris 10 and older /usr/bin/tail does not understand the -c1 >> syntax, it needs -1c instead. > > OK, it seems that tail from coreutils on Debian can deal with -1c as > well -- odd -- is this actually the portable option despite not being in > the manual? > > BTW can Solaris 10's tail handle it with a space after the c, thus: > > tail -c 1 > No. It seems the default tail in /usr/bin is the old one from the BSD days of SunOS 4 hence it does not know the more modern syntax. You can see the manpage here: https://docs.oracle.com/cd/E26502_01/html/E29030/tail-1.html -tgc From sagasucy at gmail.com Wed Mar 23 19:08:52 2016 From: sagasucy at gmail.com (anurag singh) Date: Wed, 23 Mar 2016 13:38:52 +0530 Subject: configure file Message-ID: Where is configure file how can i run ./configure command Thanks Anurag From dtucker at zip.com.au Wed Mar 23 20:46:56 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 23 Mar 2016 20:46:56 +1100 Subject: configure file In-Reply-To: References: Message-ID: On Wed, Mar 23, 2016 at 7:08 PM, anurag singh wrote: > Where is configure file > how can i run ./configure command If you have a release tarball it should be in the tarball. If you checked out the git tree you can create it from autoconf.ac by running "autoreconf". -- 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 mstone at mathom.us Thu Mar 24 06:00:01 2016 From: mstone at mathom.us (Michael Stone) Date: Wed, 23 Mar 2016 15:00:01 -0400 Subject: ssh-copy-id no newline bug In-Reply-To: <87d1qmmc5g.fsf@whist.hands.com> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> <56F1B4DE.5010905@jupiterrise.com> <87d1qmmc5g.fsf@whist.hands.com> Message-ID: <20160323190001.GA2834@mathom.us> On Tue, Mar 22, 2016 at 10:32:43PM +0100, Philip Hands wrote: >OK, it seems that tail from coreutils on Debian can deal with -1c as >well -- odd -- is this actually the portable option despite not being in >the manual? > >BTW can Solaris 10's tail handle it with a space after the c, thus: > > tail -c 1 That's the POSIX syntax. Friends don't let friends use the non-POSIX solaris utilities. Mike Stone From phil at hands.com Thu Mar 24 07:08:13 2016 From: phil at hands.com (Philip Hands) Date: Wed, 23 Mar 2016 21:08:13 +0100 Subject: ssh-copy-id no newline bug In-Reply-To: <20160323190001.GA2834@mathom.us> References: <87oaa9nep8.fsf@whist.hands.com> <0B725110-9B5E-4DBD-A3EC-A1D3F25D2CC8@alex.org.uk> <20160320195123.GA19628@mercury7.spuddy.org> <20160320203033.GA16474@riva.ucam.org> <4f072a36-eedc-11e5-9b6a-00163eeb5320@msgid.mathom.us> <8760wfney1.fsf@whist.hands.com> <56F1B4DE.5010905@jupiterrise.com> <87d1qmmc5g.fsf@whist.hands.com> <20160323190001.GA2834@mathom.us> Message-ID: <8737rhlzyq.fsf@whist.hands.com> Michael Stone writes: > On Tue, Mar 22, 2016 at 10:32:43PM +0100, Philip Hands wrote: >>OK, it seems that tail from coreutils on Debian can deal with -1c as >>well -- odd -- is this actually the portable option despite not being in >>the manual? >> >>BTW can Solaris 10's tail handle it with a space after the c, thus: >> >> tail -c 1 > > That's the POSIX syntax. > > Friends don't let friends use the non-POSIX solaris utilities. I guess that's a function of the PATH in use, and we don't have much control over that unless I were to start adding weird tests in this command line, so I'm not quite sure what you're trying to say there. Anyway, having read the GNU coreutils info page, I see it supports the -1c "obsolete" usage, and recent BSD manpages say they support the same "historical" usage too, so the best bet would seem to be -1c (unless there are some modern tail implementations that fail to support this). On the strength of that, and having considered suggestions in this thread, I'm settling on adding this after the ``mkdir .ssh &&'' : f=.ssh/authorized_keys && { [ -z "`tail -1c $f 2>/dev/null`" ] || echo >> $f ; } && I've inverted the test, in order that the series of &&'s can continue, it's using -1c for tail, as that seems likely to be maximally portable, likewise `` is more portable than $(), I don't see much benefit in creating the file just so that the tail won't fail, so I've got the 2>/dev/null instead (I'm open to persuasion on that, since if one creates the file, and doesn't discard the STDERR, then if tail manages to fail for some other reason, we'd perhaps find out about it), and the use of a variable ($f) removes duplication later in the line, and keeps the line length under 255 which could conceivably be a limit in some awful shell somewhere. Did I miss anything? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From kstailey at yahoo.com Wed Mar 23 22:12:49 2016 From: kstailey at yahoo.com (Ken Stailey) Date: Wed, 23 Mar 2016 11:12:49 +0000 (UTC) Subject: Wish List - test for directory argument before asking for password References: <670196697.3091353.1458731569062.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <670196697.3091353.1458731569062.JavaMail.yahoo@mail.yahoo.com> Hi, I noticed that I had to type in my password first then I was told my argument was invalid (forgot to use -r) Then I had to type my password in again which wasted my time (unless you call it practice). Would it be much trouble to adjust the workflow to test the arguments and then ask for the password? Thank you,Ken From cjwatson at debian.org Fri Mar 25 22:41:31 2016 From: cjwatson at debian.org (Colin Watson) Date: Fri, 25 Mar 2016 11:41:31 +0000 Subject: Dead link to FAQ Message-ID: <20160325114131.GA18427@riva.ucam.org> http://www.openssh.com/portable.html has a dead link to the FAQ on http://www.openssh.com/faq.html. I know this used to work - did it move, or was it intentionally removed? Thanks, -- Colin Watson [cjwatson at debian.org] From aarmour at cipmail.org Mon Mar 28 05:37:48 2016 From: aarmour at cipmail.org (ty armour) Date: Sun, 27 Mar 2016 14:37:48 -0400 Subject: relating to development Message-ID: I could use some tutorials on how to develop the backend of openssh. I need to be able to lock down hardware via ssh so I can do remote audio production sessions. I need to have access to hardware via ssh. all the hardware from the CPU to ram and networking cards. Though I am not sure If im gonna have to develop custom microchips for this, I thought maybe itd be a good place to start by asking for any and every tutorial on developing the backend of openssh. just post everything online. I may have to build my own custom motherboards and computers to achieve this stuff properly but its worth asking for tutorials anyway. From nkadel at gmail.com Mon Mar 28 10:30:03 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 27 Mar 2016 19:30:03 -0400 Subject: relating to development In-Reply-To: References: Message-ID: On Sun, Mar 27, 2016 at 2:37 PM, ty armour wrote: > I could use some tutorials on how to develop the backend of openssh. > > I need to be able to lock down hardware via ssh so I can do remote audio > production sessions. > > I need to have access to hardware via ssh. all the hardware from the CPU to > ram and networking cards. These are orthogonal issues. SSH is a communications protocol that operates in uerland. With very few exceptions, it uses standard "libc" calls to handle memory, CPU functions, and the network stack. And below libc, the kernel does the direct management of the memory and network. If you need system level tools to report on the network stack or system resource, those are tied to the kernel and built into the operating sytem. If you need management or reporting of those, look at operating system tools and provide a good manual for users of your remote SSH sessions rather than writing your own. If you're integrating those dynamically into individual SSH sessions, I suspect you're going to hurt yourself. A customized shell for SSH clients to connect to and provide managed access to such tools? Doable, likely not worth the effort. > Though I am not sure If im gonna have to develop custom microchips for > this, I thought maybe itd be a good place to start by asking for any and > every tutorial on developing the backend of openssh. Read RFC 4253 on the SSH protocol. Then I'd urge you not to go there. There are a *lot* of small devices that do SSH quite adequately, and building encryption hardware from scratch is painful, fragile, and likely to burn all your venture capital money with no viable product. Been there, done that, watched projects blow their budgets and get completely discarded because they tried to invent their own customized "lowest chip count/highest speed" SSH setups instead of using a bog standard micro CPU chipset with a micro-Linux or micro-BSD. > just post everything online. > > I may have to build my own custom motherboards and computers to achieve > this stuff properly but its worth asking for tutorials anyway. Don't bother. the number of existing rackmount devices, and boards to do this already is fairly large, so there is no profit margin. Raritan is well known, and their devices worked pretty well the last time I checked 3 years ago. From nakai at sgi.com Mon Mar 28 21:54:20 2016 From: nakai at sgi.com (Nakai Toru (Technical Support)) Date: Mon, 28 Mar 2016 19:54:20 +0900 Subject: Is it possible to extend log message? Message-ID: <56F90D5C.1010807@sgi.com> Hello folks, Is it possible to extend log message as large as PATH_MAX? Current length of message format including file path is small against linux PATH_MAX, 4096. diff --git a/log.c b/log.c index ad12930..95df4a9 100644 --- a/log.c +++ b/log.c @@ -359,7 +359,7 @@ log_redirect_stderr_to(const char *logfile) log_stderr_fd = fd; } -#define MSGBUFSIZ 1024 +#define MSGBUFSIZ 5192 void set_log_handler(log_handler_fn *handler, void *ctx) @@ -448,11 +448,11 @@ do_log(LogLevel level, const char *fmt, va_list args) } else { #if defined(HAVE_OPENLOG_R) && defined(SYSLOG_DATA_INIT) openlog_r(argv0 ? argv0 : __progname, LOG_PID, log_facility, &sd - syslog_r(pri, &sdata, "%.500s", fmtbuf); + syslog_r(pri, &sdata, "%s", fmtbuf); closelog_r(&sdata); #else openlog(argv0 ? argv0 : __progname, LOG_PID, log_facility); - syslog(pri, "%.500s", fmtbuf); + syslog(pri, "%s", fmtbuf); closelog(); #endif } Thanks nakai From nkadel at gmail.com Mon Mar 28 22:04:27 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 28 Mar 2016 07:04:27 -0400 Subject: Is it possible to extend log message? In-Reply-To: <56F90D5C.1010807@sgi.com> References: <56F90D5C.1010807@sgi.com> Message-ID: On Mon, Mar 28, 2016 at 6:54 AM, Nakai Toru (Technical Support) wrote: > Hello folks, > > Is it possible to extend log message as large as PATH_MAX? > Current length of message format including file path is small against linux PATH_MAX, 4096. > > diff --git a/log.c b/log.c > index ad12930..95df4a9 100644 > --- a/log.c > +++ b/log.c > @@ -359,7 +359,7 @@ log_redirect_stderr_to(const char *logfile) > log_stderr_fd = fd; > } > > -#define MSGBUFSIZ 1024 > +#define MSGBUFSIZ 5192 > > void > set_log_handler(log_handler_fn *handler, void *ctx) > @@ -448,11 +448,11 @@ do_log(LogLevel level, const char *fmt, va_list args) > } else { > #if defined(HAVE_OPENLOG_R) && defined(SYSLOG_DATA_INIT) > openlog_r(argv0 ? argv0 : __progname, LOG_PID, log_facility, &sd > - syslog_r(pri, &sdata, "%.500s", fmtbuf); > + syslog_r(pri, &sdata, "%s", fmtbuf); > closelog_r(&sdata); > #else > openlog(argv0 ? argv0 : __progname, LOG_PID, log_facility); > - syslog(pri, "%.500s", fmtbuf); > + syslog(pri, "%s", fmtbuf); > closelog(); > #endif > } > > Thanks > > nakai Possible? Probably, But what precisely were you thinking needs more than 500 characters? From nakai at sgi.com Mon Mar 28 22:16:06 2016 From: nakai at sgi.com (Nakai Toru (Technical Support)) Date: Mon, 28 Mar 2016 20:16:06 +0900 Subject: Is it possible to extend log message? In-Reply-To: References: <56F90D5C.1010807@sgi.com> Message-ID: <56F91276.80602@sgi.com> On 2016/03/28 20:04, Nico Kadel-Garcia wrote: > Possible? Probably, But what precisely were you thinking needs more > than 500 characters? Because of the message is suppressed if the path name is very long as following. Mar 28 00:00:00 hostA sftp-server[123]: set "/very/long/path/name/here" mod ^^^^ So we can't see what "modtime" is set in this case. Thanks nakai From nkadel at gmail.com Mon Mar 28 23:07:59 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 28 Mar 2016 08:07:59 -0400 Subject: Is it possible to extend log message? In-Reply-To: <56F91276.80602@sgi.com> References: <56F90D5C.1010807@sgi.com> <56F91276.80602@sgi.com> Message-ID: On Mon, Mar 28, 2016 at 7:16 AM, Nakai Toru (Technical Support) wrote: > > On 2016/03/28 20:04, Nico Kadel-Garcia wrote: >> >> Possible? Probably, But what precisely were you thinking needs more >> than 500 characters? > > > Because of the message is suppressed if the path name is very long as > following. > > Mar 28 00:00:00 hostA sftp-server[123]: set "/very/long/path/name/here" mod > > ^^^^ > > So we can't see what "modtime" is set in this case. > > Thanks > > nakai Wouldn't it be much, much easier not to use such long paths? And generally easier for your userbase to work with? From dan at lightwave.net.ru Mon Mar 28 23:24:27 2016 From: dan at lightwave.net.ru (Dan Yefihmov) Date: Mon, 28 Mar 2016 15:24:27 +0300 Subject: Is it possible to extend log message? In-Reply-To: References: <56F90D5C.1010807@sgi.com> <56F91276.80602@sgi.com> Message-ID: <741A0B25-5D6E-4BED-BC9C-4A56742DA291@lightwave.net.ru> On March 28, 2016 3:07:59 PM GMT+03:00, Nico Kadel-Garcia wrote: >Wouldn't it be much, much easier not to use such long paths? And >generally easier for your userbase to work with? Probably. But the software must be malleable enough anyway, just to not dictate it's users TheOnlyRightWayToOperateThatTheLordDecidedOnceForever. -- Sincerely Yours, Dan. From mstone at mathom.us Tue Mar 29 00:37:42 2016 From: mstone at mathom.us (Michael Stone) Date: Mon, 28 Mar 2016 09:37:42 -0400 Subject: Is it possible to extend log message? In-Reply-To: References: <56F90D5C.1010807@sgi.com> <56F91276.80602@sgi.com> Message-ID: <1fcdb834-f4ea-11e5-9b6a-00163eeb5320@msgid.mathom.us> On Mon, Mar 28, 2016 at 08:07:59AM -0400, Nico Kadel-Garcia wrote: >Wouldn't it be much, much easier not to use such long paths? And >generally easier for your userbase to work with? Yeah, and of course for potentially security-sensitive log messages, make sure you ask the bad guys to not use long paths either. Mike Stone From lists at y42.org Tue Mar 29 22:23:38 2016 From: lists at y42.org (IMAP List Administration) Date: Tue, 29 Mar 2016 13:23:38 +0200 Subject: request: add IP address to a log message to allow blocking Message-ID: <56FA65BA.6010704@y42.org> Hello, I'm seeing a lot of messages like this: fatal: Read from socket failed: Connection reset by peer [preauth] I presume they are the result of someone trying a brute-force attack of some kind, and would like to ban the attacker, but cannot, because the IP address is missing. If you haven't already, an you please add the IP address to this message, and any similar messages? I'm using version 6.7p1. thanks, Rob From steffen at sdaoden.eu Wed Mar 30 06:21:07 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 29 Mar 2016 21:21:07 +0200 Subject: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 Message-ID: <20160329192107.Xw2uF-jht%steffen@sdaoden.eu> Hello, the fix says it all. sftp.1 uses correct syntax already. Ciao, --- ssh.1.orig 2016-03-29 21:15:31.616819859 +0200 +++ ssh.1 2016-03-29 21:15:52.996820743 +0200 @@ -1049,7 +1049,7 @@ for remote and .Fl KD Oo Ar bind_address : Oc Ar port .Sm on for dynamic port-forwardings. -.Ic !\& Ns Ar command +.Ic \&! Ns Ar command allows the user to execute a local command if the .Ic PermitLocalCommand option is enabled in --- ssh_config.5.orig 2016-03-29 20:43:23.853406023 +0200 +++ ssh_config.5 2016-03-29 20:42:21.703403428 +0200 @@ -1220,7 +1220,7 @@ The default is Allow local command execution via the .Ic LocalCommand option or using the -.Ic !\& Ns Ar command +.Ic \&! Ns Ar command escape sequence in .Xr ssh 1 . The argument must be --steffen From djm at mindrot.org Wed Mar 30 09:10:00 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Mar 2016 09:10:00 +1100 (AEDT) Subject: request: add IP address to a log message to allow blocking In-Reply-To: <56FA65BA.6010704@y42.org> References: <56FA65BA.6010704@y42.org> Message-ID: On Tue, 29 Mar 2016, IMAP List Administration wrote: > Hello, > > I'm seeing a lot of messages like this: > > fatal: Read from socket failed: Connection reset by peer [preauth] > > I presume they are the result of someone trying a brute-force attack of some > kind, and would like to ban the attacker, but cannot, because the IP address is > missing. > > If you haven't already, an you please add the IP address to this message, and > any similar messages? I'm using version 6.7p1. I actually added that recently. It will be in openssh-7.3, due in a couple of months. -d From dkg at fifthhorseman.net Wed Mar 30 09:22:26 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 29 Mar 2016 18:22:26 -0400 Subject: request: add IP address to a log message to allow blocking In-Reply-To: References: <56FA65BA.6010704@y42.org> Message-ID: <877fgk2acd.fsf@alice.fifthhorseman.net> On Tue 2016-03-29 18:10:00 -0400, Damien Miller wrote: > On Tue, 29 Mar 2016, IMAP List Administration wrote: >> If you haven't already, an you please add the IP address to this message, and >> any similar messages? I'm using version 6.7p1. > > I actually added that recently. It will be in openssh-7.3, due in a > couple of months. Will it be configurable? There are situations where people actively don't want to have any IP addresses logged for legal reasons, and ideally it would be easy to get diagnostics without risks of IP addresses being written to log storage. --dkg From martin at oneiros.de Wed Mar 30 09:37:13 2016 From: martin at oneiros.de (=?UTF-8?Q?Martin_Schr=C3=B6der?=) Date: Wed, 30 Mar 2016 00:37:13 +0200 Subject: request: add IP address to a log message to allow blocking In-Reply-To: <877fgk2acd.fsf@alice.fifthhorseman.net> References: <56FA65BA.6010704@y42.org> <877fgk2acd.fsf@alice.fifthhorseman.net> Message-ID: 2016-03-30 0:22 GMT+02:00 Daniel Kahn Gillmor : > Will it be configurable? There are situations where people actively > don't want to have any IP addresses logged for legal reasons, and > ideally it would be easy to get diagnostics without risks of IP > addresses being written to log storage. Aye. Or scramble the lower octet of IPv4 addresses (don't know what's the equivalent for IPv6). Best Martin From djm at mindrot.org Wed Mar 30 20:10:29 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Mar 2016 20:10:29 +1100 (AEDT) Subject: request: add IP address to a log message to allow blocking In-Reply-To: <877fgk2acd.fsf@alice.fifthhorseman.net> References: <56FA65BA.6010704@y42.org> <877fgk2acd.fsf@alice.fifthhorseman.net> Message-ID: On Tue, 29 Mar 2016, Daniel Kahn Gillmor wrote: > On Tue 2016-03-29 18:10:00 -0400, Damien Miller wrote: > > On Tue, 29 Mar 2016, IMAP List Administration wrote: > >> If you haven't already, an you please add the IP address to this message, and > >> any similar messages? I'm using version 6.7p1. > > > > I actually added that recently. It will be in openssh-7.3, due in a > > couple of months. > > Will it be configurable? There are situations where people actively > don't want to have any IP addresses logged for legal reasons, and > ideally it would be easy to get diagnostics without risks of IP > addresses being written to log storage. No, it won't be configurable. We've always logged IP addresses in some circumstances, we're just being more consistent in doing so. Anyone who has had special requirements around log privacy should have implemented filtering years ago. -d